Question
Best approach to share Data between Org and Framework layer
When One creates Data on Org Layer what is the best approach when one needs to access or reference Work Objects coming from FW or Impl layers.
This is because in some situation one might need to access the FW layer work object (pyWorkPage) in the Data classes in Org Layer. For example when one displays Data Items from Org layer in the Section having Grid Layout in FW layer and invoke some Data transform then in such case, the Primary page defaults to the Data Class of the Org layer. But Org layer cannot see the Work Object Class from FW layer and has no visibility to the FW ruleset or FW layer.
I see several approaches to get this work or how its used in real life
1. Use Editable data Page to share data between 2 layers (FW and Org)
2. Use Ruleset Restriction in the Advanced setting of the Class in Data layer so as to include FW layer ruleset in the Class MyCo-Data-ClassA
( Also done in LSA exercise - although not a good practice but easier to achieve)
3. Extend Data class to FW layer . Create MyCo-FW-Data-ClassA ---(direct inheritence) --> MyCo-Data-ClassA. Once extended Data transforms can be created here (requires more work and additional classes)
4. Polymorphic pattern ( Not sure if the would work on different Ruleset)
Org Ruleset : --> Org Ruleset
MyCo-Data-ClassA
|--DataTransform needs to access pyWorkPage (MyCo-FW-Work-WorkClass ) ?
FW Layer: --> FW Ruleset
MyCo-FW-Work-WorkClass
Can someone suggest best approach to achieve this ?
Hi,
I have not decided to use FW class in Org layer. Perhaps you misunderstood the scenario. Also it is not a different app FW so inheritance would work.
This is rather a question about design pattern when 2 layers (org and fw) needs to interact. As already stated there are 4 approaches to solve this issue.
Let me explain you with a simple case where a User want to select a Product in his Case (pyWorkObject).
The Product is defined at Org layer (MyCo-Data-Product) and displayed in the Section (could be in Data or FW layer it is not important).
Now the important part is the Data is shown in the Grid Layout. So the when one selects the record (Product) in the Grid then the primary Page defaults to the Class of the Data Record (which in this case is MyCo-Data-Product) . This is a default behaviour in Pega. The Applies-To class of Data Transform also defaults to MyCo-Data-Product and not that of the Section. But the problem starts when Data transform needs Access to pyWorkPage since it needs to set the "selected" record or Product from the Grid.
Something like
Set pyWorkPage.Product = Primary
But pyWorkPage is not visible in Org layer in this Data transform .
If you check the LSA 7.1 exercise this is exactly the Scenario and uses the Solution 2 (Ruleset Restriction) approach.
At the Org layer a Data Transform can at most assume that the case extends either Work- or Work-Cover-
An Org-level Data Transform or Activity should define a Page-Name parameter named "WorkPage"; the class declared to be either Work- or Work-Cover-.
If the parameter value is not supplied, the DT or Activity can assume that Param.WorkPage = "pyWorkPage".
When the DT or Activity rule is overridden in some application layer. the class for WorkPage should at least be changed to the workpool class used by that application layer, namely, Org-App-Work.
It is also possible, in rare situations, to assume that the override is specific to one particular case type, e.g., Org-App-Work-Claim.
If the Org-App-Work application is specialized by yet another application, do the same thing, i.e., set the class for WorkPage at least equal to the workpool class used by the specialization application.
Nothing says that a specialization application always has to use a different class name + direct inheritance for case types.
For Data classes it is fine to use direct inheritance in a new layer -- but why always use direct inheritance for case types when Pega supports two other possibilities, namely pattern-inheritance and ruleset specialization?
When an application uses ruleset specialization it simply adds one or more rulesets to the "built on" application's stack.
The workpool class has not changed which is fine - meaning you can deliver an application to production and only specialize it if and when you truly need to. When you truly need to, lock down the "built on" application.
For the second specialization of the "built on" application ask where the new application will be deployed.
If deployed on the same database, direct inheritance can be used to achieve data storage isolation but so can converting the application to multi-tenancy.
A benefit of using MT is eliminating the need to use DCR to refer to different workbasket and workgroup names per extending application, plus not having to implement Security and other rules to prevent inadvertent access.
If the second specialization of the built on" application is intended to be hosted in a separate database, ruleset specialization will work perfectly fine once again.
Thanks for the answer. I got your point which is to basically pass WorkPage as Page name parameter in Org level Data Transform or activity and override it in some application layer. But the "Work-" being generic Object is almost not usable as it lacks certain properties not available in the concrete Work Object class defined in the App or FW layer.
What you described was similar to the solution I mentioned in my post before #3 which is to basically override the Data class in App or FW layer with direct inheritance from Org layer and override that Data transform . Only drawback is that we have to create that "extra" Class to override.
As I see from you response I conclude that there needs to be some Class at App or FW layer inheriting from Org layer to override DT or Activity . Let me know if my interpretation is correct ?
Case types that are reusable across an entire enterprise would typically have class names specific to an application, e.g., Org-App-Work.
The case type class name would not be Work-.
For single-case-type reusable applications, the class name would essentially be Org-CaseType-Work, or you could define a class name such as Org-Work-CaseType.
Either way, when (a) starting from a Org-reusable case type class and (b) wanting to allow higher layers to extend that case type, you do not need to create an "extra" case type class.
What you do not want to do in that situation is to define ruleset restrictions against class that you want to be specialized.
If you did define ruleset restriction on the case type class, then you would need to change the class name, using inheritance, to be able to create additional rules (Properties, Sections, etc.).
Where Work- comes into play is when you have an enterprise reusable Data class.
The Data class should not care what case types consume it.
Hence the Data class, its own ruleset, defines the API that case types would use to interact with the Data class.
A same-ruleset "API" can include Work- rules such as Properties, Sections, etc., with names unique to the Data class to avoid collision with other Data classes that potentially could be used in the same application.
Apologies because I'm not really going to answer your question, but rather question why you've decided to access a FW WO from an Org data class. If you inherited that Org data class from an app using a different FW then wouldn't that section fail to load? On first glance this seems more like a data model design issue rather than an implementation one.
If the section uses FW WO's then why don't you just apply the section within the FW?