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***
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.
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.
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.