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:
  • Install WebSphere eXtreme Scale Client on your WebSphere Application Server and WebSphere Portal nodes. See Installing WebSphere eXtreme Scale Client with WebSphere Application Server for more information.
  • WebSphere Portal Version 7 or later.
  • Custom portlets must be configured within WebSphere Portal. The administrative portlets that come with WebSphere Portal cannot currently be integrated with data grids.

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.
  • When session persistence is required.

    For example, if the session data from your custom portlets must stay available during a WebSphere Portal Server failure, you can persist the HTTP sessions to the WebSphere DataPower XC10 Appliance data grid. Data replicates among many servers, increasing data availability.

  • In a multiple data center topology.

    If your topology spans multiple data centers across different physical locations, you can persist the WebSphere Portal HTTP sessions to the WebSphere DataPower XC10 Appliance data grid. The sessions replicate across data grids in the data centers. If a data center fails, the sessions are rolled over to another data center that has a copy of the data grid data.

  • To lower memory requirements on the WebSphere Portal Server tier.

    By offloading session data to a remote tier of container servers, a subset of sessions are on the WebSphere Portal servers. This offload of data reduces the memory requirements on the WebSphere Portal Server tier.

Procedure

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

    See Creating 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 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 more information.
  3. 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.
Parent topic: Creating session persistence to a data grid
Related tasks:
Configuring Transport Layer Security (TLS)
Administering with the HTTP command interface
Related information:
Managing keys with the IKEYMAN graphical interface