Case Type rule Should be in Fw layer or Impl layer?
in ECS class structure, most of the rules we keep in the Framework layer, and some of the rules which need specialization we bring to Implementation layer. We keep work class both in FW layer and Impl layer, because to pint different work table.
now question is for Case Type rule, assume there is no requirement of specialization in the case type rule for Impl layer, then what is the best practice?
whether same case type rule should be in both FW and IMPL layer
only FW layer.
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
If there is no requirement to specialize an application then you do not create a specialization layer.
If you do have a specialization requirement THEN you create a specialization layer.
Regardless whether a requirement currently exists to specialize, object-oriented principles should be followed to ensure rules are extensible, for example using parameterization, if the need does arise in the future.
Question is not whether I need specialization layer or not. Question is if I don't have any specialization requirement for the case type rule then what is the best practice for case type rule to be or not be in implementation/specialization layer? while my work class already in my specialization/implementation layer because I want to map implementation work class to different work table.
I'm facing the same problem. After digging around and almost giving up, I stumbled upon this - As of 7.31, there is an option of "Import Case Types" on the Case Designer screen (a drop down icon right next to "Add a Case Type") which brings up a modal window. On this modal window, we can select the Casetypes from Framework layer. I believe this will solve this problem.
Very interesting suggestion. Glad you brought that up.
You can definitely Withdraw the pyDefault Rule-Obj-CaseType rule for every case type within the Implementation layer. This will force the inherited Case Type rule for that class to be used.
Each withdrawn implementation Case Type rule will NOT be displayed in the "Case Types" view in the Implementation layer application -- which makes sense.
To modify the framework/template/model/blueprint case type rule you can either (1) switch to the built-on application or (2) locate the rule the App or Records explorer then launch it.
DCR should be used whenever possible. Unless fixed in newer versions (this reminds me to check), certain Shapes unfortunately do not support DCR for example when a workbasket is named within a Wait Shape.
If the workbasket should be different for each Implementation application, which it should unless multiple implementations are never hosted in the same database), then it is necessary to save the flow that contains the Wait shape to each Implementation to then be able to specify the appropriate workbasket.
The above-mentioned DCR issue only affects flows.
The case type rule supports DCR very well >> from the Designer Studio <<. For example when spinning off a subcase you can use: Other -> .AppExtension.<Some>Class
Because DCR is complex, though, it is not supported when using Pega Express. When building on an application, the New Application Wizard will automatically generate new Case Type rules. In Pega Express the "Other" option is not available when spinning off subcases.
Rather than "fight" this by switching to Design Studio you may come to the conclusion that it is simpler and more maintainable to simply copy and modify the framework/template/model/blueprint case type rule to each implementation layer application whenever a change is made to the framework/template/model/blueprint case type rule.
I believe better way is to create a casetype in Fw Layer,then extend the case type to Implementation layer,this will allow your design adapt for future,because in future if you were to create one more implementation layer but want to specialize ,we had similar requirement so we created a casetype in fw layer later imported the case type to implementation layer.