I have started to publish articles on ADF Code Corner hosted on Oracle OTN and managed by Frank Nimphius. You can read my first post there - 087. How-to improve LOV performance with shared AM in ADF BC.
Stay tuned, more articles to come !
If you are working with Oracle UCM 11g, I can imagine you may encounter hard times, when thinking about content security architecture design. But really, its not so complex - as it looks first, just there are lots of confusion between Security Groups, Accounts and Access Control Lists (ACL). For your reference, in Oracle UCM its not enough to define security groups to protect content - Understanding Oracle UCM 11g and Oracle ADF 11g Security Integration. One of the recommended ways is to use security Accounts in combination with Security Groups to protect RWDA permissions for files and folders. However, while this approach is recommended - is not so practical. Idea of using Security Groups and Accounts combination is hardly acceptable by customers, because first is hard to understand, second is hard to maintain. Its hard to maintain, because from administration point there is no difference between Security Group and Account, but it matters for UCM.
We prefer to use Access Control List (ACL) functionality to implement content security in Oracle UCM 11g. ACL was available in previous versions of UCM, before 10g and returned back in 11g. This suggests ACL being simple to understand and preferred solution to protect content security - 5.6 Access Control List Security.
Goal of this post is to describe few missing steps from Oracle UCM 11g documentation, related to ACL configuration.
This should be enough to enable ACL support, as per documentation.
Major difference between UCM 10g and 11g, in 11g it runs directly integrated into WebLogic. This simplifies lots of administration and configuration tasks, for example UCM security is synchronized with WebLogic security providers. This means its enough to define Active Directory security provider for WebLogic, it will be visible for UCM as well.
While running large ADF/WebCenter 11g PS3/PS4 applications in stress test or production environment, users can experience random errors related to ADF view state token. For example such errors can be observed in the log: StateManagerImpl restoreView Could not find saved view state for token -ejrgnqgsv.
We can refer to section 8.2 Oracle ADF View Performance from Oracle Fusion Middleware Performance and Tuning Guide. It describes org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS property and instructs how to tune performance by reducing the size of state token cache. By default, for ADF application tokens size is set to 15 (I personally would recommend to set it to 25 and then measure application performance, if no performance issues, its better to keep available tokens value higher), it can be tuned to 2. When it is set to 1, ADF application will return error after browser Back button click. When we create new WebCenter application in JDeveloper, org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS is set to 3, this means WebCenter application would keep only three tokens in memory. Number of tokens is set to 3, probably to reduce memory usage for heavy WebCenter applications.
We have noticed, when Web session timeout is set to default 30 minutes, after 10-15 minutes of user inactivity - could not find saved view state for token error is be reported randomly. This is unexpected behavior, because user is not pressing browser Back button, but still gets error during inactivity, even before timeout.
This means org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS = 3, as it set for WebCenter 11g PS3/PS4 applications, looks like not enough. When this value was increased to 25, state token error was not reproduced anymore.
Hope this hint will help you, in case of unexpected error will be encountered for missing view state during user inactivity.