Hi Team,
We are starting a new Constellation application and would like to understand the recommended approach for the initial Pega Blueprint import.
Our organization already has an Enterprise Common application along with several existing business applications. However, for this initiative, we are creating a completely new business application, which will be built on top of Enterprise Common.
Our development approach is:
Developers will work only in MyApplicationDev.
Pega Unit tests will be maintained in MyApplicationTest.
Only validated functionality will be merged into MyApplication (Target Application).
Since this is a brand-new application, we are trying to understand the best practice for the first Blueprint import.
1)Should we first create the Target, Test, and Development applications manually and then import the Blueprint?
2)If the Blueprint is imported into the Target application and generates rules in a branch of the Target application’s rulesets, can that same branch be added to the Development application which is built on the Target application for further refinement?
I would recommend to import Blueprint that will create the Target application first. Blueprint is designed to generate the initial application layer, case types, data objects, personas, and application structure. Once the import is complete and the target application is established, you can then create:
MyApplicationDev built on MyApplication
This ensures the Dev and Test applications are aligned with the actual application generated by Blueprint and avoids creating application layers upfront that may need adjustment after the import. The Blueprint import process creates a new application (or a new application layer built on an existing application) as part of the import workflow.
For the second question, yes. The Blueprint-generated content is initially created in a branch associated with the target application. That branch can be added to the Development application for further refinement and validation, and later merged back into the target application using your normal branch-based development process.
Thank you for the detailed explanation. This clarifies the recommended approach and is very helpful.
I agree with Ramesh’s recommendation with a little nuance. I would use the import to create my app layer, but I would not import any classes, cases, etc on the initial import.
I would then review and merge the branch, set up my dev ops pipelines and add in my built-on applications and/or components to my app definition.
With your infrastructure now in place, I would import a second time, this time pulling in my first case and data. When you are doing this, you will now be able to identify which classes your imported classes should inherit from or reuse. That way, if you had an enterprise classes you wanted to leverage, you could get the inheritance correct and avoid duplicating classes that already exist in your hierarchy.
As a pre-export exercise, I would make sure my property names for classes I was inheriting from matched what was in blueprint to minimize cleanup post-import.
One other thing to consider when making the switch from traditional UI to constellation: make sure all you data pages are marked as API and if you are leveraging OOTB data pages - check those as well, because there are several that are not marked as API and therefore will not work with constellation.