This appendix describes some general guidelines to help you ensure session stickiness. Session stickiness, generally, refers to ensuring that the requests for a particular session get routed to the same physical machine that serviced the first request for that session. This helps to reduce the situation where sessions are lost as a result of requests for a session being routed to different servers.
For any of the following scenarios, all PeopleSoft web servers need to have the same session-cookie name:
The Load-Balancer uses the PeopleSoft web server's session-cookie as the stickiness criterion.
Any of the any the supported proxy servers is used to forward requests to the PeopleSoft web servers.
Ensure that the session-cookie name is the same for all web server instances to which the Load Balancer or proxy dispatches requests. The cookie name needs to be configured in the appropriate configuration section of the Load-Balancer or proxy server.
Typically, PeopleTools recommends that the portal and content sites run in separate PeopleSoft Internet Architecture domains. If these sites are running in the same PeopleSoft Internet Architecture domain (as in having multiple sites within the same domain, with one site for Portal and the other sites for content), then there is no need to load-balance requests separately to the content sites, because the requests will be routed to the same JVM's.
When Portal and content sites run in the same PeopleSoft domain as multiple sites, they share the same session because the web application is the same for all sites. PeopleTools does not recommend configuring Portal and content sites in the same PeopleSoft domain for performance and reliability reasons.
So assuming that Portal and content sites are running in separate PeopleSoft domains, they will have separate ports and, usually, separate hosts. In this case, if Portal and content sites are using the same physical load balancer, the routing rules will have to be set up for these sites separately.
When using Enterprise Portal and Content Providers:
The session-cookie name of Enterprise Portal and the Remote Content Provider must be absolutely distinct. For example,
Enterprise Portal's session-cookie name: PTENPRTL-8080-PORTAL-PSJESSIONID
Content Provider's session-cookie name: PTFIN-9090-PORTAL-PSJESSIONID
Neither of the systems' session-cookie name must be part of the other's session-cookie name. The following example illustrates a bad choice of a session-cookie name:
Enterprise Portal's session-cookie name: PORTAL-PSJESSIONID
Content Provider's session-cookie name: PTFIN-9090-PORTAL-PSJESSIONID
If there are multiple Enterprise Portal or Content Provider web servers with Load-Balancer or Proxy, see carefully choose a session-cookie name.
For example, consider an environment having a Load Balancer in front of two Enterprise Portal web servers, with the session-cookie's name used as Load Balancer's stickiness criterion. Suppose the name of the session-cookie is PTENPRTL-8080-PORTAL-PSJESSIONID. In this case, both Enterprise Portal web servers must have the same session-cookie name: PTENPRTL-8080-PORTAL-PSJESSIONID.
If this environment has an HCM Load balancer with four HCM web servers, with the session-cookie name as stickiness criterion, each of the HCM web servers must have the same cookie, like HTR-9090-PORTAL-PSJESSIONID and this name must be distinct from the name of the session-cookie used for Enterprise Portal.
PeopleSoft Internet Architecture constructs absolute URLs in certain scenarios (such as the Homepage URL to which the user is re-directed after successful login). Certain Load Balancers and proxy servers change the HOST header of the request to the target web server's name before forwarding the request. This causes PeopleSoft to construct the URL with the host-name of the web-server, rather than the name of the Load Balancer or proxy, which means that subsequent requests would be sent directly to the web server, instead of routing requests by way of the Load Balancer or proxy. In order to ensure that URLs can be constructed with the Load Balancer or proxy's host name, the Virtual Addressing page of the Web Profile needs to be set with the Load Balancer or proxy information.
To modify virtual addressing information:
Select PeopleTools, Web Profile, Web Profile Configuration, and open the web profile configured for the site.
Click on the Virtual Addressing tab and populate the Default Addressing section with the Load-Balancer or Proxy's host name, scheme and port.
Example: Suppose the system has been set up to be accessed through a Load Balancer which has a host-name of mycompany.com and accepts http requests at port 8080. Suppose the PeopleSoft site's name is ps. The URL for accessing the site would be as follows:
http://mycompany.com:8080/ps/signon.html
In this case, the Default Addressing section will need to be set with Protocol: http, Port: 8080, and Host: mycompany.com.
Save the Web Profile.
Re-start the web server.
Browsers enforce the rules stated by RFC 2965 for sending cookies to servers. If the cookie's domain is not set when the browser receives the cookie, that cookie is associated with the server that sent the cookie. If the cookie's domain has been set but does not match the name or the domain suffix of the server, then the browser does not send the cookie. Therefore, not having the correct cookie domain can lead to failure in maintaining a PeopleSoft session.
The cookie domain value is configured in web server-specific configuration by the PeopleSoft Internet Architecture setup if the Authentication Token Domain value has been entered. If this field was left blank during PeopleSoft Internet Architecture setup, either re-install PeopleSoft Internet Architecture or configure the cookie domain manually in the web server-specific configuration.
See Also
http://www.ietf.org/rfc/rfc2965.txt
If session-stickiness is configured with a timeout on the Load Balancer, that timeout value must be higher than the PeopleSoft Inactivity Logout timeout configured in the current Web Profile.
Keep in mind the session cookie name format. The session-cookie name must not start with a digit (0-9) and must not contain dots.
Example of bad name for session-cookie: 11.12.13.14-80-PORTAL-JSESSIONID
Example of good name for session-cookie: FINTSTWEB-80-PORTAL-JSESSIONID
To configure session cookie name:
Open a browser and access the WebSphere Administrative Console.
Go to Enterprise Applications, and select the PeopleSoft application and select the Manage Modules link.
Click on Portal.war.
Click on Session Management under Additional properties.
Make sure that the check box Override Session Management is enabled.
Click the Enable cookies link.
Set the cookie name.
The recommended format is:
<hostname>-<port>-PORTAL-PSJSESSIONID
Example: PSTST-8080-PORTAL-PSJSESSIONID
The default name of session-cookie is JSESSIONID.
Re-start the WebSphere Server to make this change effective.
To configure the cookie domain:
Open a browser and access the WebSphere Administrative Console.
Go to Enterprise Applications, and select the PeopleSoft application and select Manage Modules link.
Click on Portal.war.
Click on Session Management under Additional properties.
Make sure that the check box Override Session Management is enabled.
Click Enable cookies link
Enter the value in the Cookie domain field.
Re-start the WebSphere Server to make this change effective.
The session cookie name is configured in weblogic.xml of the Portal web application/servlet. This file can be found in the following directory: <PIA_HOME>/webserv/<DOMAIN-NAME>/applications/peoplesoft/PORTAL/WEB-INF
Locate the tag CookieName in weblogic.xml, as in the following example:
<session-param> <param-name>CookieName</param-name> <param-value>PSTST-8080-PORTAL-PSJSESSIONID</param-value> </session-param>
The name of session cookie is assigned in the tag <param value>. In this example, the session-cookie name is PSTST-8080-PORTAL-PSJSESSIONID.
Re-start the WebLogic Server to make this change effective.
Update the CookieDomain manually in weblogic.xml file, as in the following example:
<session-param> <param-name> CookieDomain </param-name> <param-value> .company.com </param-value>
In this example, the value .company.com is the domain that will be assigned to the session-cookie.
Re-start the WebLogic Server to make this change effective.