Showing posts with label WebCenter Portal. Show all posts
Showing posts with label WebCenter Portal. Show all posts

Friday, 30 October 2015

Integrating Oracle Coherence with WebCenter Portal

Oracle Coherence is the cache tool of Oracle and is intended to store frequently used data of applications. In the case of WebCenter Portal, this product is crucial to achieve a good performance of the platform, so it is strongly recommended to configure Coherence with Portal installations. In this post I include some guidelines and tips to integrate Portal and Coherence.

Testing Coherence Configuration

Once Coherence has been installed, the tool must be tested to check it is properly configured. This link provides a good step-by-step test.

Integration with Content Presenter

Coherence is usually integrated with WebCenter Content via Content Presenter. This process is explained in detail by the A-Team in this post, basically it consists in editing the content-coherence-cache-config.xml file, create the jar library and add it to the Portal application. By configuring this, the retrieval of content from WebCenter Content would be reduced drastically by caching the Content Presenter items in Coherence.

Caching WebCenter Portal transactions

Now that content is cached, page loading time would have decreased, but in order to really improve performance, transactions should be cached too. Portal is usually integrated with external web services, retrieving information from them, this type of transactions are costly in time, due to the network communication with the third party environment and its processing time.
To cache those transactions, a generic application must be created using the CacheFactory class and others, which will implement the communciation with Coherence. Oracle official documentation provides a comprehensive guide to create a Coherence application here, including the tangosol-coherence-override.xml file. This application will be deployed as JAR library and included in the libraries of the WebCenter Portal application. Once these methods are accesible from the application, simple invocations are implemented to store (put) and retrieve (get) from Coherence.

public void put (Object key, Object o,long time);
Where key is the identificator, o is the value and time is the storage time.
 
Oracle Coherence is so flexible that it allows developers to cache objects. For instance, it may be convenient to cache a whole java object with the response of a web service, which would include all the information of a customer.
In this case, it is important to assign proper expiration times for objects, otherwise users would receive old wrong data. Ideally, that time could be high (days or months) if the modification of the data is done via the Portal application too, so developers would execute cache flush of an object every time it is updated; therefore the cached data would always be correct. Problems arise when that data is updated by third-party applications, out of the scope of WebCenter Portal.

It is advised to have different cache repositories for different expiration time, so there would be one for objects with 1 hour expiration, another one for 1 day, etc. This is supposed to increase performance of the tool in large implementations.

Coherence Administration Application 

Cache administration could be undertaken using a simple ADF application, where all the cache objects are displayed in a table, along with buttons that would allow to flush the whole cache or a specific element. The implementation is not complicated, just using loops to get all the objects and functions to perform the actions. This is very useful when Portal administrators have the need to solve an issue regarding a wrong cached object, they could search for the element and flush it; another scenario is when a massive update is performed in the systems and the whole cache turns invalid, it can be flushed completely with just one click. Also, it might be interesting to include an 'Add' button to create objects using a form. Obviously, this application must be user protected so just granted users can access.



Monitoring Coherence

Coherence can be monitored using jConsole, the configuration needed is not complicated and it is detailed in this document. After that, jConsole will display Coherence MBeans and clusters.

Another choice is to use Enterprise Manager as monitoring tool, as described in this A-Team post.

Conclusion

Considering the complexity of WebCenter Portal implementations, Oracle Coherence is a must to keep a good performance of the platform and reduce page load time. For example, the use of Coherence enabled a real Portal environment to reduce the loading time from 25 seconds to just 3.

References

Building your first Coherence application
Class CacheFactory
Coherence Monitoring Management in Oracle Enterprise Manager
Configure Coherence for Oracle WebCenter Portal Framework Content Presenter Task Flow
Oracle Coherence Overview
Testing a Coherence Installation
Using JMX to manage Coherence
Using WebCenter and Oracle Coherence Together – Discussion and How To 

Monday, 25 May 2015

Oracle Access Manager Error page customised

WebCenter Portal is usually integrated with Oracle Access Manager (OAM) to manage its authentication. This integration has several advantages such as enabling Single Sign On (SSO) across all Oracle products, but it may cause some problems to end users.

Issue


Recently, a client with a private users area received complaints regarding an unexpected error page been displayed in Portal. Even a user tweeted that page tagging the company, so the problem was considered critical to the top management. The page was the following standard unfriendly OAM error page:



The URL was: /oam/server/auth_cred_submit.

Firstly, we tried to reproduce the issue, which was not easy because users did not remember the actions they performed. After some testing, the issue was reproduced:

  1. Access protected URL.
  2. Portal application login page is displayed.
  3. Introduce valid credentials.
  4. Portal home page is accessed.
  5. Click browser Back button.
  6. OAM error page appears.
We tried to map that URL (auth_cred_submit) as an error by web server configuration, but that was not a solution because it was actually the URL that performs login too.

The explanation of this error is:
  • The login page submits the "request_id" or the "OAM_REQ" value sent by OAM when redirecting to the external login page. 
  • When user introduces credentials and click login, a value for request_id is set into the HTTP Header.
  • The back button does not reset the values already set via cookie or Header information into the browser. 
  • The second time "auth_cred_submit" is accessed, the values from the previous login are sent to the server, which interprets them as invalid because are from a different session. 

So Oracle Support was contacted about this problem. If that page could not be avoided, at least we wanted to have it customised.

Solution

 

Apparently, that OAM page cannot be customised, but the engineer managed to reproduce the issue and built an effective workaround. It involves deploying a custom pages application in OAM application server.
  1. Copy oamcustompages.war file in a local machine. This file is located in the following path: $IDM_HOME/oam/server/tools/custompages/
  2. Unpack this war file.
  3. Navigate to the "pages" folder inside the uncompressed war and create a page named: Error.html. That page would contain the HTML code to be displayed in the reproduced scenario, so it should include the cient look&feel.
  4. Other pages in that folder may be deleted.
  5. Compress the folders back to oamcustompages.war. Then rename that file, i.e. oamcustompages1.war.
  6. Deploy the war in the application server where OAM is running. For information about deploying an application to WebLogic Server, check this link.
  7. OAM Custom Pages must be updated using WLST:
    7.1 Start WebLogic Scripting Tool (WLST) in OAM Oracle home, located under the installation folder: /Oracle_IDM1/common/bin).

    7.2. Connect to the Weblogic AdminServer as the Weblogic Administration User.
    For instance:
    wls:/offline> connect();
    Please enter your username [weblogic] :weblogic
    Please enter your password [welcome1] :Oracle
    Please enter your server URL [t3://localhost:7001] :t3://oamadminserver.oracle.com:7001


    7.3. Execute the following WLST command:
    updateCustomPages(pageExtension ="html", context="/oamcustompages1");

    Where context is the name assigned to the war file in step 5.
    You should receive the following message: "Custom page configuration updated successfully"

    8. Test the scenario. A new error message should be displayed, defined in Error.html file.
This solution works perfectly for our scenario, but we also wanted to avoid displaying an error page to the final users. So Error.html was modified to add a javascript redirect to OAM logout page:

<meta http-equiv="refresh" content="0;url=/../oam/server/logout?end_url=/myApp">

As this content is in the page header, as soon as it starts loading, user is redirected to logout page, where session cookie (OAMAuthnCookie_) is removed. Eventually, the login page is displayed to the user, this is specified by the URL parameter end_url. So customers would not even see the error page.

References


Oracle Service Request: SR 3-10186096271 : OAM how to avoid auth_cred_submit page to be displayed to users
Installing and Configuring OAM with WebCenter Portal
Benefits of Oracle Access Manager
Deploying Applications to WebLogic Server
WebLogic Scripting Tool Command Reference 
Enabling Error Page Customization
Using meta refresh to create an instant client-side redirect
Configuring Centralized Logout for OAM 11g

Wednesday, 25 February 2015

WebCenter Portal Automatic Logout

WebCenter Portal is usually integrated with Oracle Access Manager (OAM) to manage its authentication. This integration has several advantages such as enabling Single Sign On (SSO) across all Oracle products, but it may cause problems when timeout occurs.

In order to increase performance and maximise platform, OAM should have a reduced timeout for user sessions. So after that time, user would lose its login cookie and when he/she clicks on any link, an error page would be displayed.

To avoid that, you may use the following workaround:

Add a refresh command in the Portal template header and set the time to the OAM timeout minus 10 seconds, i.e. If OAM timeout is 15 minutes, set the refresh to 890 seconds. As the target URL, specify the OAM logout address, passing as parameter the page to be displayed after logout (end_url). For instance:

<meta http-equiv="refresh" content="890; URL=/../oam/server/logout?end_url=/myApp"/>

This tag must be included in the header of the page, before the pageTemplateDef tag.

As a result, when user inactivity is near OAM timeout, the page will refresh automatically and the application login page will be displayed.

References


Oracle Service Requests: SR 3-9350587377 : OAM11.1.2.2.0 - send error page when come over OAM inactivity timeout
Installing and Configuring OAM with WebCenter Portal
Benefits of Oracle Access Manager
HTML meta tag

Thursday, 12 February 2015

WebCenter Portal disable skin version warning

If you have a look at your WebCenter Portal output log (.out), it is quite likely that you will find an annoying warning repeated constantly like the following one:

<Jan 15, 2015 10:09:27 AM COT> <Warning> <org.apache.myfaces.trinidadinternal.skin.SkinFactoryImpl> <BEA-000000> <Cannot find a skin that matches family portal and version v1. We will use the skin portal.desktop.> 

This is not a big issue because it does not affect Portal operations, but it makes difficult to track logs and clients have the right to have a free of errors/warnings log.

The solution is described in this post by the A-Team. It is related to the skin version defined in your Portal application, so the recommended action is to delete the skin-version tag in the trinidad-config.xml file.

<?xml version="1.0" encoding="windows-1252"?>
<trinidad-config xmlns="http://myfaces.apache.org/trinidad/config">
  <skin-family>#{preferenceBean.defaultTrinidadSkin}</skin-family>
  <skin-version>v1</skin-version>
</trinidad-config>

After re-deploying the application the warning message should disappear.

However, apart from that issue, there is another one related to skins:

<Dec 19, 2014 8:09:41 AM COT> <Warning> <org.apache.myfaces.trinidadinternal.skin.SkinCSSDocumentHandler> <BEA-000000> <Not a valid @agent CSS property rule: max-version: 9.0>
<Dec 19, 2014 8:09:41 AM COT> <Warning> <org.apache.myfaces.trinidadinternal.skin.SkinCSSDocumentHandler> <BEA-000000> <Not a valid @agent CSS property rule: max-version: 16.0>


So far, these warnings have no workaround yet. According to an SR I opened with Oracle, it is a benign message and it should be fixed in 11.1.1.9 version.


References


Removing the “Cannot find a skin that matches family portal and version v1.1″ message
Oracle Support Doc ID 1965182.1
ADF BUG 14722194

Thursday, 22 January 2015

Rendering ADF based on the device type

According to some statistics, nowadays more than half of internet usage occurs on mobile platforms. So it is time to ask yourself if your Portal is working properly in tablets and phones.

Latest WebCenter Portal release (11.1.1.8) includes some useful features that control how the pages are displayed in different devices. Also, if you are interested in modifying some Portal behavior in your code, deviceManagement EL expressions are available.

The following piece of code will return the device type accessing Portal:

<af:outputText value="#{DeviceAgent.currentScopeDeviceGroup.name}" id="a1"/>

This group of expressions has several applications, for instance conditional rendering:

                    <af:commandLink rendered="#{DeviceAgent.currentScopeDeviceGroup.name eq 'desktopBrowsers' or DeviceAgent.currentScopeDeviceGroup.name eq 'iOSTablets'}"
                                    text="Register"
                                    id="gl1" styleClass="linkBlue">
                      <af:clientListener method="open" type="click"/>
                    </af:commandLink>


That piece of code will show a Registration link only if the user is accessing Portal via desktop computer or iPads.

Possible values: desktopBrowsers, iOSTablets, iOSPhones, androidTablets, ...

References

 

Tablet Growth: Usage Statistics and Expectations

 

Tuesday, 13 January 2015

Disable Browser Caching in WebCenter Portal Pages

Before WebCenter Portal applications go live it is recommended to perform a hacking audit. One of the typical issues is usually the caching of login pages. Login pages have sensitive information about the user and it is good practive to disable browser caching in those cases.

In order to achieve that, HTML meta tags can be added to the header of the JSPX page. The lines that disable caching are:

<meta http-equiv="Cache-Control" content="no-store”/>

<meta http-equiv="Pragma" content="no-cache" />

Those tags need to be inside a verbatim tag before the content facet. For instance:

  <f:view>
    <af:document title="#{portalResource['login_title']}" id="d1">
      <f:facet name="metaContainer">
        <f:verbatim>
          <meta http-equiv="Cache-Control" content="no-store"/>
          <meta http-equiv="Pragma" content="no-cache"/>

        </f:verbatim>
      </f:facet>
      <af:form id="formlogin">
        <af:pageTemplate value="#{bindings.pageTemplateBinding}" id="pt1SAD"
                         viewId="/oracle/webcenter/portalapp/pagetemplates/MiPageTemplate.jspx">
          <f:attribute name="showNavigation" value="#{false}"/>
          <f:attribute name="showLogin" value="#{false}"/>
          <f:facet name="content">


References


http://stackoverflow.com/questions/49547/making-sure-a-web-page-is-not-cached-across-all-browsers
https://www.mnot.net/cache_docs/