Question
TATA CONSULTANCY SERVICES
US
Last activity: 8 Jan 2016 3:49 EST
Existing Requestor Retrieved - Passivation Issue
Hi All,
I'm troubleshooting a production problem that is happening for a single user. In that process, have enabled the Global DB Trace through SMA and below is the snapshot of first few events that are happening when user loads Pega mashup page.
In the third row, we can see --> Existing Requestor Retrieved message.
- Instead of creating a New Requestor, why Pega is trying to retrieve some old requestor ?? From the user standpoint, we have asked the user to clear all the browser cache & cookies and requested for a fresh login but why this is happening ?
- How can we clear the old/stale requestors associated with the impacted user ? Ideally the SystemCleaner Agent should have taken care of this ??
Any thoughts ?? By the way we are running on Pega 7.X & HA is configured.
Thanks
Hari Kumar Alampuru
Message was edited by: Vidyaranjan Av
Pegasystems Inc.
US
TATA CONSULTANCY SERVICES
US
Hi Chris,
Thanks for the insights !
Issue here is that for one of the IAC User (Operator ID record) has an incorrect Access Group tagged to it in the pr_operators Table present in PRPC DB. We have to get that AccessGroup corrected.
After posting this question... verified our application IAC Authentication Logic....
As per our IAC Authentication Service Activity logic, when a NEW User comes to PRPC via IAC (who never connected earlier to our Application IAC Gadget), we have a code check to see if the calling Operator exists in pr_operators Table or not , based on that we retrieve the IAC Model Operator Id record (which has the IAC AccessGroup to it) from PRPC DB with "Operator" Page as Step-Page and map the NEW User's name & Organization information to Operator Page.
After setting up additional properties on the Operator Page, at last we have a step (param.pyOperPage = @java("myStepPage") ) after which Pega OOTB triggers few rules & inserts the NEW Operator Record into the DB.
Hi Chris,
Thanks for the insights !
Issue here is that for one of the IAC User (Operator ID record) has an incorrect Access Group tagged to it in the pr_operators Table present in PRPC DB. We have to get that AccessGroup corrected.
After posting this question... verified our application IAC Authentication Logic....
As per our IAC Authentication Service Activity logic, when a NEW User comes to PRPC via IAC (who never connected earlier to our Application IAC Gadget), we have a code check to see if the calling Operator exists in pr_operators Table or not , based on that we retrieve the IAC Model Operator Id record (which has the IAC AccessGroup to it) from PRPC DB with "Operator" Page as Step-Page and map the NEW User's name & Organization information to Operator Page.
After setting up additional properties on the Operator Page, at last we have a step (param.pyOperPage = @java("myStepPage") ) after which Pega OOTB triggers few rules & inserts the NEW Operator Record into the DB.
But when an existing User (not a NEW User) connects to IAC, Authentication Service Activity will not create a new profile rather it just pulls the Operator Record instance from the pr_operators Table present in PRPC DB. But due to some reason, the Operator Record Instance for the impacted user is having an incorrect Access-Group tagged to the Operator profile and we dont have any code logic to check if the existing Operator Record that is retrieved from the Database is having correct IAC AccessGroup tagged to it or not.
System proceed further without that check the accessgroups & the Operator ID record gets re-saved/ updated with the incorrect AccessGroup only to pr_operators Table. Leading to the below error on screen for user.
What we tried few hours back is that, we opened the impacted Operator profile record through designer studio & we have deleted the Operator profile. So, that as per application logic, when user connects to IAC, it checks if the user is an existing user or not in pr_operator table. Since it will not find the record , it will create a fresh IAC profile.
But after deleting operator record, user is getting Blank Screen when connected to IAC. bit different from one what the user got earlier.
We are trying to capture httpwatch logs, Global DB Trace logs & authentication activity steps at debug log-level to see what's going on NOW. We'll ask user to completely reboot her machine and try if there is any improvement.
Thanks
Hari Kumar Alampuru
Pegasystems Inc.
US
Hari,
After you deleted the record and the user tried to connect again was the record added again? If so was it correct?
Having the user do a reboot isn't going to clear anything PRPC needs.
--Chris
TATA CONSULTANCY SERVICES
US
Hi Chris, We are yet to hear back from the impacted user .
TATA CONSULTANCY SERVICES
US
Hi Chris,
Yes, After we deleted the record and when the user tried to connect again - record got added with the correct profile ! Code worked as expected for the New User logins. User is now able to see IAC pages.
But, in future we have to correct our application IAC Authentication logic to handle this specific error scenario -->
Where the Existing User's Profile gets corrupted/updated with an unknown Access Group.
We have to put a logic to check if the Access-Group is correct one or not. If its not correct or the Trusted one which need to be on the User Profile then we can do obj-delete the Operator record in the Authentication activity so that system can create a new profile on the fly !
Thanks for clarifying that "The "existing requestor retrieved" in event 51157 is not part of passivation. This is the next request that is occurring during the load of your gadget." .. Otherwise we would have gone in a wrong direction !
Thanks
Harikumar Alampuru
Hi Hari,
You are showing three events here: 51155 to 51157. These are all using the same requestor, H88C77...
Even if you didn't say you were using a mashup I can tell you are using one. So first some back ground on the three events:
These are two separate browser requests associated with these three events.
The first two events are for PRGatewayPing which is part of the PegaInternetApplicationComposer.js when using IAC and fires this request on the browser onLoad event before initializing the gadget(s) on the page. I can tell you are not using the PRGateway application as this request reached PRPC. When using the PRGateway application this request does not get sent to PRPC. This request is used to determine what cookie should be used for any type of URL encryption that maybe enabled. This activity call does not require authentication.
The third request is for the Code-Security.IACAuthentication and that is the activity defined in your Data-Admin-AuthService probably named IACAuthentication. This processing only gets called when the requestor needs to be authenticated. The browser request is for running the activity for the gadget. It can't run that until the requestor is authenticated.
More about the data:
Hi Hari,
You are showing three events here: 51155 to 51157. These are all using the same requestor, H88C77...
Even if you didn't say you were using a mashup I can tell you are using one. So first some back ground on the three events:
These are two separate browser requests associated with these three events.
The first two events are for PRGatewayPing which is part of the PegaInternetApplicationComposer.js when using IAC and fires this request on the browser onLoad event before initializing the gadget(s) on the page. I can tell you are not using the PRGateway application as this request reached PRPC. When using the PRGateway application this request does not get sent to PRPC. This request is used to determine what cookie should be used for any type of URL encryption that maybe enabled. This activity call does not require authentication.
The third request is for the Code-Security.IACAuthentication and that is the activity defined in your Data-Admin-AuthService probably named IACAuthentication. This processing only gets called when the requestor needs to be authenticated. The browser request is for running the activity for the gadget. It can't run that until the requestor is authenticated.
More about the data:
This requestor is not authenticated yet, <unknown> in the user column. The sever probably sent back a unauthenticated Pega-RULES cookie, starts with {atn} but still ends up pointing to a "H" requestor on the system. If you look in events 51158/9/10, after authentication has run, the User column starts to get populated.
The "existing requestor retrieved" in event 51157 is not part of passivation. This is the next request that is occurring during the load of your gadget. The requestor was established during the PRGatewayPing call but it's not authenticated yet so the engine is running the Data-Admin-AuthService login activity for you before running the gadget processing activity. This is simply saying that this is the requestor the authentication is being run on. There was no time for passivation to occur here, this all happens usually within the same second.
What is the issue you are trying to debug?
From what you have provided here I can basically tell this was not using an old requestor . This looks like the first few steps of a proper authentication that is using a new requestor when using an IAC gadget that does not use the PRGateway application.
That being said it's very common for IAC gadgets to use passivated Pega-RULES requestors and I will explain why.
PRPC uses browser level in memory session cookies, these are in memory only and are associated with the browser .exe. You can't clear these with browser level cache or cookie clears . Once a session is established with PRPC the browser memory is mapping the in memory Pega-RULES cookie to the host and context root of the application. Every request to the same host and context root the cookie will be sent.
To clear the cookie one of two things needs to happen:
1) Server responds setting the cookie to a value of "none". (PRPC Logoff will set this to none)
2) Close the browser, no more .exe (Not closing the tab or logging off the primary application when using IAC)
When in the primary application if you navigate away from the IAC gadget that doesn't directly clear the Pega-RULES cookie. So the next time the user accesses the gadget, could be hours or minutes, the same in memory Pega-RULES cookie will be sent from the browser to the server. If passivation has occurred then the requestor will be retrieved from a passivated state and used. This isn't a bad state either.