Question
Murex
LB
Last activity: 9 Mar 2017 4:52 EST
EstablishOperator Activity Not Being Called
Hello,
We have a save as of the EstablishOperator activity on our own Ruleset, but it doesn't seem to be getting called.
So I was wondering whether there is something else that needs to be configured and maybe point to the new EstablishOperator activity ?
Any help is appreciated :)
Thanks!
Joe
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Accepted Solution
Pegasystems Inc.
US
Hi Joe,
At the time the EstablishOperator activity runs you are not yet authenticated in PRPC. You are authenticated with the context and allowed to access PRPC but now PRPC is going to try to map the user principal to Data-Admin-Operator-ID. Once that is done then you are authenticated with PRPC.
So, your activity has to be available to unauthenticated users in PRPC. You copied that activity to your own ruleset but is that ruleset available to unauthenticated users?
You need to look at your SysAdmin->Requestor Type data rule for <SystemName>.Browser . This contains an AccessGroup that is used for unauthenticated users. Make sure the ruleset you have copied EstablishOperator lives is provided by the AccessGroup.
Note: Don't give unautheticated users access to the same AccessGroup as authenticated users. Instead create a RuleSet like <CompanyName>SSO or <AppName>SSO that is mapped to an AccessGroup that provides the core PRPC and just that one RuleSet used for SSO, Single Sign On.
EPAM Systems, Inc.
ES
Hello Joe,
I have verified in Pega 7.1.8, that it's an available rule(Below is the screen-shot for your reference)
How about doing a "Private Edit" and changing the activity as per your requirement instead of "SaveAs".
Kindly notify, if it helps.
Regards,
Asif
Murex
LB
Hey Asif,
The activity is present. Our issue is that's it's not being called. Additionally, we need to Save As of the activity as we need to override it (it's on a PEGA RS so we can't check in, and Private Edit is not an option as we actually need the changes to be applied to the system rather than only for a single operator).
Thanks,
Joe
Accepted Solution
Pegasystems Inc.
US
Hi Joe,
At the time the EstablishOperator activity runs you are not yet authenticated in PRPC. You are authenticated with the context and allowed to access PRPC but now PRPC is going to try to map the user principal to Data-Admin-Operator-ID. Once that is done then you are authenticated with PRPC.
So, your activity has to be available to unauthenticated users in PRPC. You copied that activity to your own ruleset but is that ruleset available to unauthenticated users?
You need to look at your SysAdmin->Requestor Type data rule for <SystemName>.Browser . This contains an AccessGroup that is used for unauthenticated users. Make sure the ruleset you have copied EstablishOperator lives is provided by the AccessGroup.
Note: Don't give unautheticated users access to the same AccessGroup as authenticated users. Instead create a RuleSet like <CompanyName>SSO or <AppName>SSO that is mapped to an AccessGroup that provides the core PRPC and just that one RuleSet used for SSO, Single Sign On.
Murex
LB
Hi Chris,
Thanks a mill for the reply, it was extremely beneficial.
I've added the Requester Type data rule as it was missing. For the meantime, I gave it the same access group I have and which contains the new EstablishOperator activity (I'll be changing that later on once I create the dedicated RS and Unauthenticated Access Group). The EstablishOperator activity still doesn't seem to be getting called. Is there anything else I should be looking at?
Thanks!
Joe
Capgemini
IN
Thats what I know.
1. Create an application build on top of Pegarules. Give name <appName>Authentication.
2.Add the Ruleset that contain the EstablishOperator in the application.
3. Create Access Group which points to the application.
4. Add the access group in the Browser requestor type.
5. Select the access group and save.(The radio button beside the access group).
If not working you might consider a restart.
-Saikat
Murex
LB
Hey Saikat,
Thank you for your reply.
I've attached a screenshot for your reference.
Let me know if that's what you meant!
Thanks, Joe
Pegasystems Inc.
US
You added a Requestor type as it was missing? No...you couldn't even login if it was missing.
I think you just need to find your system name. Your system name can be found on the System->General information landing page or on the clipboard page pxProcess.pxSystemName
Murex
LB
OK Chris, thanks for that.
System name turned out to be pega. But when I modify the corresponding Browser requestor type to a new Access Group, I can't log back into the system.
Am I still missing something? I've attached a screenshot for reference. (So when I try to switch from the second access group to the third, I can't log in anymore).
Thanks a lot for your help!
Joe
Updated: 20 Feb 2017 22:28 EST
Pegasystems Inc.
US
You have it set perfect.
After you switched the correct browser requestor type to an new Access Group you can't login through SSO anymore or you can't login at all even through normal PRServlet? If just SSO will need to look at EstablishOperator activity more.
***Updated by moderator: Lochan to remove information on private session***
Pegasystems Inc.
IN
Hi Chris,
This is a great discussion and I hate to put in a spanner, but we encourage you to either continue the troubleshooting out here OR we go through an SR if this needs a closer look that's easier through a screen share!
Thank you,
Murex
LB
Hi Chris,
Sorry for the late reply. Back then, we couldn't log in into the system at all. I think that was due to the fact that we've customized our log in screen on a new Unauthenticated Ruleset and the Access Group didn't include that.
As I understand, the best practice is to create a new application that only has access to that Ruleset and make the access group point to that application?
Thanks a lot Chris :)