Why is session tracking important
A primary feature of RUEI is to report on web application performance with the context of the user. This is the 'session' related data such as 'All Sessions' as well as the instance data in 'Session Diagnostics'. A Session is the collection of all HTTP interactions performed by a single user and it's related attributes. Session related attributes are value's that do not change over the course of the session, such as the client ip-address, the browser that was used as well as the user-id.
When session tracking is not configured correctly none of the above mentioned value's are expected to make any sense. A Large number of anonymous user-id's are reported, the session to page view ratio is going to be off and even page-load-time is affected.
For this reason it's vital to review the session tracking configuration carefully.
How RUEI identifies what HTTP request belongs to a session
RUEI receives all HTTP interactions (hits) from all users on the monitored web application simultaneously. RUEI needs a value in each hit that matches the following criteria in order to successfully assign each hit to the right session:
Should be the same for each hit that is generated by the user's browser for the duration of the session.
Should be different from all other hits generated by users using the web application simultaneously
This value is expected to be stored in a cookie, a session cookie.
Technical requirements for a good session cookie
A Session cookie that is ideal for RUEI to work with meets the following criteria
Should be set at the very first hit
Should be set for the full domain of the web application. Make it as broad as possible, not including a Path directive as we want to ensure that also hits like .css .jpg .png .js have the cookie set, no matter what sub-domain they are loaded from
Should be a "Session" Cookie. Meaning it's set only during this browser lifetime. When the browser is closed the cookie is destroyed. This is accomplished by not setting an expiration time.
Should contain a unique (hash) value
Should be distinct in value for each user
An example javascript to accomplish all of the above would be:
This code will:
Check if the cookie with name RUEItrack already exist or not
If not, it will create the cookie with this name,
parseInt(Math.random()*2147418112)+new Date().getTime() Generates the unique value
path=/ ensure's this is not a cookie for a specific path
domain=.oracle.com ensures the cookie is send with all requests to a broad number of sub-domains.
Now, the experienced user will note that the javascript set cookie does not meet all criteria as it will not send the cookie with the very first hit. This is true and makes a javascript side cookie a 'second best' after a server-side cookie. However, RUEI does have some smart tricks up it's sleeve to still be able to include that first hit in the session by looking at the referer. When this cookie is generated on, for example, the login page, this will still work great for RUEI.
How to Identify an Existing, Session Tracking Cookie for Use
Now that we know having session tracking is a good thing and what a good session tracking cookie should include, let's see how to identify existing cookies being and if these are usable for RUEI.
Start with clean browser. Remove all cookies for the web application you are investigating.
In both Chrome or Firefox hit F12 to pull up the developer view. Then navigate to the 'Network' tab for insight into cookies being send and received. In this document we will use Chrome.
Ensure that 'Preserve logs' is ticked.
Now we are ready to access the web application. For this example we use https://support.oracle.com
Questions to ask ourselves:
What new cookies have been set -> BIGipServer....
Is the cookie set on the first hit? -> Yes
Is the cookie a session cookie? -> Under Expires, it says "Session", so Yes.
Is the cookie value unique? -> Not sure from the output, would need to compare with more test data. (Experience provided that BIGIP cookies are generally not unique enough).
Is the cookie covering the complete application? -> Path is set to /, which is good, domain is not given, this means it applies to the domain name it was requested on, which is support.oracle.com. Depending on our application identification configuration in RUEI this may be sufficient.
Is the cookie value consistent through-out the session? -> Yes. Verified by making more clicks and see if the value remains the same.
Reviewing the above questions shows that the BIGipServer is a contender, but let's have a look at the following few hits
The first hit resulted in a 302 - Redirect to another hit. This hit sets a new server-side cookie named MOSCP**SESSION**ID
Walking through the same questions as earlier we get:
First hit? -> No, but second is a pretty good winner still.
Session Cookie? ->Yes
Unique Value? -> Looks like it yes. Would need to be validated.
Covering full application domain? -> Path is set to /. Domain is derived to be support.oracle.com
Consistent through-out session? -> Yes.
Conclusion: MOSCPSESSIONID is the most suitable candidate to use. First off it ticks most of the boxes. Second, compared to BIGipServer... it's value appears more uniquely generated.
Configuring Session Tracking in RUEI
Here we have 2 options. Global and local session tracking
Creating a global entry will have the cookie value apply to all applications and suites configured in RUEI. This may be fast and convenient method if you only have a single application or don't care specially about your RUEI annalist having restrictions on data access.
Because in that last point lies the main difference.
When using the global setting and a user browses across more then 1 application that are monitored by RUEI, this will be reported as a single session. But when defining the same cookie value for both applications in their local configuration. RUEI will split out the user-session between the two applications. Then you end up with 2 user-sessions from the same end-user, each with data from only the one application.
Global Session Tracking
A cookie for global session tracking is configured as follows
Local Session Tracking
A cookie for local session tracking is configured like this:
Reference Documentation and Knowledge Base Articles
RUEI 12.1.0.7 User Guide 12.2 Specifying the Session Tracking Mechanism
Setting up javascript cookie in EBS: How to include a session tracking cookie for RUEI in EBS using personalization. (Doc ID 1643747.1)
Setting up a javascript cookie in Siebel OpenUI SBL - How to add RUEI's Browser JS Library to Siebel OpenUI (Doc ID 2009046.1)
This document is also available on My Oracle Support under Doc ID 2060072.1