"Shut the door"... every household has shouted it (or been shouted at). Why? Well, it keeps the house draft free and secure and it's polite not to leave the door open.
Session State in WebLogic
Every time a user logs into PeopleSoft a user session state object is created in the web server. This memory based object is used to hold the user session data including where the user is on a component (i.e. what page), what they entered in the previous pages, the component buffer, etc. This state object naturally consumes memory in WebLogic. If 1,000 users login then 1,000 state objects are created in memory in WebLogic. If all 1,000 users just close their browser without logging out then there's still 1,000 state objects in memory. It's like walking through the entire house and leaving all the doors open! So, what can we do to manage this?
When the user logs out of PeopleSoft then this state object is destroyed. But, what happens if the user doesn't log out? What if they just close their browser or they leave their logged in browser session and walk away from their workstation?
User Logout Behaviour
It's always polite to close a door behind you. But what happens if you leave the door open? At home someone might yell at the kids to shut the door or maybe you have a butler who goes around closing doors that are left open! Well, in PeopleSoft there is a mechanism (or butler) which will automatically close the door. This protects the memory of the web server and therefore doesn't leave a logged in session hanging around indefinitely.
 |
| The PeopleSoft Butler | Closing doors |
 |
| Web Profile | Security tab |
Leave your session unattended for 20 minutes and the butler will close the door for you and log you out. If you have the Inactivity Logout setting high (i.e. 8 hours) then you're storing up web server memory problems as users login , close their browser and therefore don't get tidied up for 8 hours ! Be careful with this setting.
PSACCESSLOG
Every time a user logs into PeopleSoft a row is inserted into PSACCESSLOG table recording the following information.
|
OPRID |
PeopleSoft userid logging in |
You'll find
entries in here for system users like PTWEBSERVER and the USERID used
to start the Application and Process Scheduler Domains. |
|
LOGIPADDRESS |
The remote IP
address of the initiating client. |
This is
likely to be a load balancer or proxy rather than the IP address of the
client browser. |
|
LOGINDTTM |
The date and
time of the login |
|
|
LOGOUTDTTM |
The date and
time of the logout. |
If the
LOGOUTDTTM is the same value as the LOGINDTGTM then this signals that the
user has not logged out yet. |
|
PT_SIGNON_TYPE |
The type of
connection for this login |
0 = Non PIA login (ie Application
Designer/Data Mover or REST/SOAP call) 1 = PIA login |
This table has been around ever since I can remember but, in PeopleTools 8.60, some new data is now being logged.
I noted above that the LOGOUTDTTM is always set to be the same as the LOGINDTTM and is only updated when either the user logs out, their browser inactivity timeout logs them out or the "butler" in WebLogic logs them out because they closed their browser. The problem is, you don't know which of these has happened. There's a delivered Query PT_SEC_CURUSER_LIST which attempts to show current logged in users on the basis that the LOGINDTTM = LOGOUTDTTM but this still won't tell you what type of logout occurred.
But, this problem is solved in PeopleTools 8.60 and 2 new fields have been added to the PSACCESSLOG table.
|
PT_TRACING_ID |
PeopleBooks says this is "The Tracing ID assigned to the user's session."
. |
Not very
helpful explanation from PeopleBooks as to what this is. I have an idea that
it might be related to identifying the correct row to update when a user has
logged in multiple times with the same USERID. How would PeopleTools
know which user to logout if all it had to find the row was a USERID and the
fact that the user has not logged out? Possibly this field creates a
unique way of identify the actual row to update on
logout. |
|
PT_SIGNOUT_REASON |
The reason
the client logeed out (if known) |
This solves
our problem of knowing HOW the user logged out. Possible values for
this field are: A =
User Abandoned. In other words
the user closed their browser without logging out. E =
Browser Expired. The user has their browser
open, logged in but did not respond to the inactivity warning and the
Inactivity Logout time elapsed and forced the logout. L =
User Logout. Good boys and girls click the
Logout link. R =
User Re-login. While the user was signed in, a
new login from the same browser session arrived for the same or antoher user O =
Other. Not sure what this might include. Will have to monitor a
live production system to see. |
 |
| Example of users with their logout status |
Comments