Question
PayPal
US
Last activity: 7 Jan 2020 14:55 EST
Cases belong to different applications to be accessed without switching access groups
Our requirement is to support cases belong to different applications to be accessed in the same portal without switching access groups manually by end users.
This is our design approach. End users will have generic framework level access(derived from a separate authorization service). We will have an identifier to designate the case belongs to which application. We will have to dynamically switch the application based on the identifier in the application, by setting active access group of the thread every time the case is accessed. This solution not only solves the purpose but also will make the class structure look cleaner. Will there be any inadvertent effects in switching application dynamically? Is there any other better approach? What things do we really need to consider for SLA processing/Services/Agent processing?
***Edited by Moderator: Lochan to update platform capability tags***
Pegasystems Inc.
IN
Hi,
There is a concept called Federated Case Management in Pega which allows you to access Cases of different Applications.
Please go through this link : https://community.pega.com/knowledgebase/articles/case-management/learning-about-federated-case-management
PayPal
US
Thanks for sharing the details. Will check and get back.
I think, in federated case management also, the context is switched dynamically by setting thread's current active access group.
Pegasystems Inc.
FR
Hello,
Can this video be helpful maybe: https://community.pega.com/video-library/multiple-built-applications
PayPal
US
Thanks. We thought about using multiple built applications.
Consider, we have App1 and App2 which is built on top of FW. There is a CommonApp built on App1 and App2 using multiple built on application to have access to both applications.
Consider, there is rule named “GetAccountInfo” in class MyCo-FW-Data-Account. This rule is overridden with different implementations in rulesets RR1:01-01(App1) and RR2:01-01(App2). When using App1, I should get RR1 implementation of GetAccountInfo and when using App2, I should get RR2 of GetAccountInfo. This cannot be achieved with multiple built on applications unless we have to create a different classes in App1 and App2 to use same rule name or we have to create rules with different names in order to get different implementation.
Pegasystems Inc.
US
This is what I can think of as possible options.
Option 1: (No switching of AG is needed in this approach – although simple but overhead in terms of security)..
Create a thin application (Generic App) built-on App1 and App2. Point the Agent/Operator to new Generic AG. You can also maintain a Data Table to control access to different case types based on a parameter passed from the user desktop (or application onclick).
Security / RARO , Workbaskets, Skills will need to defined for all the case types across both the Apps in this Generic AG. Additional complexity with different level of Agent Roles desired resulting into more Generic AG's to be defined..
If same activity is present in App1 and App2 rulesets, it will go by the built-on application order for rule resolution. This can be avoided by putting restrictions programmatically to NOT allow extension of FW/OOTB activity and other critical rule types in individual Application Layers by developers.
Option 2: (Preferred)
Lets say : AG1 --> App & AG2 --> App2 (AG= Access Group)
Create a new AG (GenericAG) pointing to a default Generic Application (Generic App) built-on Pega Platform directly.
This is what I can think of as possible options.
Option 1: (No switching of AG is needed in this approach – although simple but overhead in terms of security)..
Create a thin application (Generic App) built-on App1 and App2. Point the Agent/Operator to new Generic AG. You can also maintain a Data Table to control access to different case types based on a parameter passed from the user desktop (or application onclick).
Security / RARO , Workbaskets, Skills will need to defined for all the case types across both the Apps in this Generic AG. Additional complexity with different level of Agent Roles desired resulting into more Generic AG's to be defined..
If same activity is present in App1 and App2 rulesets, it will go by the built-on application order for rule resolution. This can be avoided by putting restrictions programmatically to NOT allow extension of FW/OOTB activity and other critical rule types in individual Application Layers by developers.
Option 2: (Preferred)
Lets say : AG1 --> App & AG2 --> App2 (AG= Access Group)
Create a new AG (GenericAG) pointing to a default Generic Application (Generic App) built-on Pega Platform directly.
When the user logs in, and based on the parameter, we can extend the “CustomShowDesktop” activity defined at the Operator record to dynamically switch the AG (Get Authentication Handle and change the current active accessgroup) based on the input criteria to either App1 or App2. Both AG1 and AG2 should be defined as additional accessgroups on the Agent/Operator record with default AG = GenericAG.
This will provide better isolation in terms of security , WB's, Skills etc.. defined at individual application layers. At any point in time, you can also determine agents who have access to App1 and App2. Secondly, in future if you have App3, this approach can easily extend to support App3 with minimal effort.
Thanks
Pegasystems Inc.
US
Have similar requirement and thinking of these additional scenarios -
With option2# how would search work. As a end user I need to be able to search on cases in 2 applications. FCM gives this but how does option2 give this capability.
Also how would case in app1 refer to case in app2- navigation should be seamless. Say case in app1 wants to create a child case which belongs to app2.