Question
Adqura
IN
Last activity: 3 Jan 2022 8:15 EST
Best Practices around Merging two Pega Applications into Single Application
We initially designed two different applications with App2(Implementation only ) is built on App1(FW+ Implementation) but we now feel it's better to merge them into a single application as it's easier to manage with respect to development/deployment and access as well.
Can some help on best practices around Merging two Applications into a Single Application.
Below are our questions
- Does pega support dual ECS in a single application like below
- Org-App1-FW-Work/Data/Int/UIPages
- Org-App2-Work/Data/Int/UIPages
- Do we need to re-factor the class structure to support only one application??
- Is it as simple as just moving the rulesets into a single application and the rest should fall in place?
Updated: 31 Dec 2021 0:22 EST
Adqura
IN
I am still looking for a solution to the question above. Can anyone please help me with this?
ASRC
US
How are the case types used in different applications?
- Does pega support dual ECS in a single application like below
- Org-App1-FW-Work/Data/Int/UIPages
- Org-App2-Work/Data/Int/UIPage
If your App2 is inheriting App1 class structure then you dont need to make any changes. But verify the order of the rulesets in your application. As long as the framework rulesets are below the Implementation application rulesets then everything should work in place.
Adqura
IN
Cooperatieve Rabobank U.A
NL
@RajuBadkal PEGA usually supports only one Work Pool/Class Group per application, so when you open an Operator mapped to an access group, you can only see the Work Pool mapped to that Access Group's Application.
If the objective is to only reference the rules of both classes, then that can be managed in the below approach :
(1) Provide one class in the directed inheritance path of the other. This would ensure that the classes are interlinked, and the rule reference picks up the same rule in different classes according to priority.
(2) Also, add the application, which contains the class in the Directed Inheritance path, in the built-on application list. This would ensure that the rules in that application can be referenced directly in the parent application.
If the class relationship is not required, then you can skip the Step (1).
Hope this is clear enough !
Updated: 3 Jan 2022 5:18 EST
Adqura
IN
Thanks, @VTALUKDAR .
Actually, as per the initial design, we wanted
App1 Application: Used for Exposed API's ( only Services)
App2 Application: Customer Decisioning Hub + Case framework + Integration with other applications
Now, we were thinking to merge App1 into App2 so that, we use only one application and avoid any maintenance issues
Hence wanted to check the best way to do it and what needs to be taken care.
Cooperatieve Rabobank U.A
NL
@RajuBadkal Normally, a division of layers is a better approach to go with. Even though it increases the Built-on application structure, maintainability would increase in the longer run. For example, if you ever need another Top-level application , you can simply reference the existing Built-on apps, instead of putting them all in one giant app.
This would be my suggestion :
--- Parent App (Top Level application)
Built on : --- CDH Customizations (which in turn would be built on CDH App)
--- Case Framework App
--- Integration Application (Would contain the Data Model and the Integration layer attributes.)
Updated: 3 Jan 2022 7:17 EST
Adqura
IN
Thanks, @VTALUKDAR your suggested approach look very good I liked it, whereas, we would not be able to adopt it now that many of the features are built and deployed onto PROD. Hence we are looking for minimal changes to merge two applications if there are too many complexities, we better leave it as-is.
I was thinking of the below approach
- Merging the rulesets of App1 into App2
- Updating the required access to groups to point to App2
- Updated the inheritance of App1 top classes to inheritance from respect classes from App2 like Work/Data/Int etc
Above should work is what I feel hence wanted to clarify once. Do you see any issue in this approach @VTALUKDAR
Cooperatieve Rabobank U.A
NL
@RajuBadkal If you are looking for short-term low-impact solutions, then your approach would work fine.