Framework + Impl Layers or Impl Layer on Top of Impl Layer?
As opposed to building Framework + Implementation layers, you can build an Application one Impl layer at a time.
After all, the name of an Application implies how it should the used – the same as any class that you develop.
NOTE: What is not obvious is that if you choose to build on top of an “Implementation” App as opposed to a “Framework” App you need to go to the “Documentation” tab of the Application rule to allow the App to be displayed as a possible Built-on Application
Pega supports both ruleset and class resolution dimensions as shown the figure below.
When you choose “Framework” in the New Application Wizard what you have done is force your first Implementation layer App to be “Impl 2” in this figure.
IF, instead, you use Implementation-only strategy, you can:
- Create “Impl 1” first thereby preserving the class name plus not affecting existing instances
- THEN create “Impl 2” as a new-class/new-ruleset combination for your second Implementation layer Application
NOTE: When using the Implementation-only strategy there is no need to use “FW” in class names – you simply name that layer in a “framework-sounding” way then use it as such.
.
I cannot speak for all of Pega. My personal opinion is that too often projects start out immediately creating a framework application and the first application within an implementation layer. In doing so, a workpool and class group is created for the framework application layer but is never used, instance-wise, typically. Creating a framework app when it is not needed is an example of "premature generalization".
IMHO, before deciding to create a framework layer, the business should be asked whether they intend to "productize" it, meaning do they intend to build multiple implementations on top of that framework in the future? For a large multinational companies this makes perfect sense - different geographic regions may need a specialized version of a certain application to account for different business rules, UI, etc.. But for a number of companies this need does not exist.
There is also the temptation to create both a framework and implementation layer to satisfy the need for division-specific applications where each class would be prefixed with Org-Div-. This does not mean Org-FW-App or Org-Div-FW-App classes must exist for every Org-Div-App class. As opposed to Org- being the reuse layer, Org-Div- becomes the reuse layer.
Hi Pedel,
When we select a first implementation application as template for implementation two, generated work class for implementation two is directly inherited from Work-Cover- instead of implementation one. So how can we reuse implementation one rules using inheritance? Is it just used for a template to copy case types from implementation one?
Within a 7.1.9 Application rule, uncheck the box in the "DCO Settings" section within the Documentation tab.
Note: this checkbox is generated unchecked when you create a Framework Application.
When you choose to create an "Implementation" only Application, any Application with the box unchecked will be suggested as a possible Built-on App.
Note: in soon-to-be-released version 7.3 this checkbox has been moved to an "Application Wizard" tab. In 7.3 you would check the box to have it be suggested as possible Built-on App.
Hi Pedel,
Thanks for sharing this info, but why Pega gone away from both layers (FW and Impl) option while creating new application in Pega 7.2.2. what is strong use case behind this. Can you please help in undertsanding this.
Thanks in advance
Shivaram Bhupathi