Configuring HTTP session manager with WebSphere Portal

You can persist HTTP sessions from WebSphere® Portal into a data grid.

Before you begin

Your WebSphere eXtreme Scale Client and WebSphere Portal environment must meet the following requirements:

About this task

Introducing WebSphere DataPower XC10 Appliance into a WebSphere Portal environment can be beneficial in the following scenarios:
Important: Although the following scenarios introduce benefits, increased processor usage in the WebSphere Portal tier can result from introducing WebSphere DataPower XC10 Appliance into the environment.

Procedure

  1. Configure the wps WebSphere Portal application and any custom portlets to enable the sessions to be stored in the data grid.

    See Configuring WebSphere Application Server HTTP session persistence to a data grid for more information. This action results in the splicing of the custom portlets to enable session persistance to your data grid.

  2. If Transport Layer Security/Secure Sockets Layer (TLS/SSL) is configured for the WebSphere Portal server and for the appliance, you must configure the TLS/SSL truststores.
    • If the resulting outbound communication from the WebSphere Portal server to the appliance uses TLS/SSL, you must add the appliance certificate to the WebSphere Application Server configuration. Use the addXC10PublicCert.py script. This script is in the was_root/bin directory:
      wsadmin.bat -conntype SOAP -port <PORTAL_SERVER_SOAP_PORT> -lang jython 
      -user wpsadmin -password wpsadmin -f addXC10PublicCert.py
    • If the resulting inbound communication from the appliance to the WebSphere Portal server uses TLS/SSL, update the appliance truststore to include the public certificates for the WebSphere Portal server. Updating the truststore enables communication between the appliance and WebSphere Portal.
    1. Extract the public key of the Portal Server personal certificate. Use the IKEYMAN utility. This utility creates a .arm file. See Extracting public certificates for truststore files for more information.
    2. Download the public truststore for the appliance. See Configuring Transport Layer Security (TLS) for WebSphere Application Server for more information.
    3. Use the iKeyman utility to update the truststore.jks file that you extracted from the appliance with the public Portal Server certificate in the .arm file. See Importing signer certificates for more information.
    4. Upload the updated truststore file to the appliance. Click Submit TLS settings after you upload the truststore. The collective automatically restarts when you submit the TLS settings and the new truststore is added to the other appliances in the collective. See Configuring Transport Layer Security (TLS) for WebSphere Application Server for more information.
  3. Some versions of WebSphere Portal server can have runtime errors when cookies are added to an HTTP response. Since WebSphere DataPower XC10 Appliance adds cookies for failover and other purposes, these cookies need to be added to WebSphere Portal server cookie ignore list. For more information, see the cookie.ignore.regex parameter section of Caching pages shared by multiple users on the IBM WebSphere Portal wiki. The two cookies that need to be added to the list are IBMID.* and IBMSessionHandle.*. The updated list may look like this for example "digest\\.ignore.*|LtpaToken|LtpaToken2|JSESSIONID|IBMID.*|IBMSessionHandle.*". For more information, see Caching pages shared by multiple users on the IBM WebSphere Portal wiki.
  4. Restart the WebSphere Portal servers. See WebSphere Portal Version 7: Starting and stopping servers, deployment managers, and node agents for more information.

Results

You can access the WebSphere Portal Server, and HTTP session data for the configured custom portlets is persisted to the data grid.
If the entire data grid that is hosting the application session data is unreachable from the web container client, the client instead uses the base web container in WebSphere Application Server for session management. The data grid might be unreachable in the following scenarios:
  • A network problem between the Web container and the remote container servers.
  • The remote container server processes have been stopped.
The number of session references kept in memory, specified by sessionTableSize parameter, is still maintained when the sessions are stored in the base web container. The least recently used sessions are invalidated from the web container session cache when the sessionTableSize value is exceeded. If the remote data grid becomes available, sessions that were invalidated from the web container cache can retrieve data from the remote data grid and load the data into a new session. If the entire remote data grid is not available and the session is invalidated from the session cache, the user’s session data is lost. Because of this issue, you should not shut down the entire production remote data grid when the system is running under load.