Question
Accenture
IN
Last activity: 16 Oct 2018 12:03 EDT
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
or
only FW layer.
Regards
Shankha
**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.
Pegasystems Inc.
US
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.
Accenture
IN
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.
Regards
Shankha
Pegasystems Inc.
IN
When you have a case in specialization/implementation layer, obviously case type rule exists in that layer. Otherwise we don't call that as a case , its a simple work type.
Thank You,
Surendra.PV
Pegasystems Inc.
US
There are two ways to specialize an application yet still use the original case type rule:
- Create a Wrapper Application **
- Circumstance the case type -- the original case type rule is the default so would still be used
Option 1 would be considered a new layer. Option 2 does not constitute a new layer.
** Simple process for creating a Wrapper Application:
- Create a new ruleset specifying "Add to Application rule"
- Save-As the existing Application rule to the new, just-added ruleset, giving it a name representative of its specialized purpose
- Open the new Application rule. Configure it as Built-on the original Application. Remove every ruleset except the one created in (1)
- Open the original Application again and remove the ruleset created and added in (1)
- Create new Access Groups that point to the new Application rule created in (2) and (3)
NTT Data
US
Case Type has to be in Frame Work Layer, if need implementation layer , then use Dynamic Class Reference Pattern to call the implementation layer rules from Frame Work Layer.
Pegasystems Inc.
US
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.
Pegasystems Inc.
US
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
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.
Virtusa
NL
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.