a separate table for Framework Layer Work pool and implementation layer work pool
There are separate database table for framework layer work pool and implementation layer work pool. We created both FW and implemenation layer application by the wizard.
What are the best practices and design considerations to create work objects in FW layer even though there is an implementation layer?
Accepted Solution
Updated: 5 Oct 2016 19:05 EDT
Pegasystems Inc.
US
A "framework" is meant to be just that. You could say that "framework" is to "abstract" as "implementation" is to "concrete". Hence you would never create framework instances only implementation instances.
But are there truly any requirements to create a framework on which multiple implementations would eventually be built? If not, why have a framework layer at all? Why not simply tell the "New Application" wizard to create an "implementation"?
Suppose you wanted to define case types that are usable across an entire enterprise then build different applications that re-use those enterprise level case types?
To achieve this you would first use the "New Application" wizard to create an "enterprise implementation" then later use the "New Application" wizard to build an "implementation" on top of that previously created "enterprise implementation"
If later you discover that your new implementation has the potential to be a framework it is possible -- not saying it would be easy -- to "back-fill" a framework layer by inserting it between the "enterprise" layer and your previously created "implementation" layer.
By doing this, the pxObjClass for existing and future case instances would remain the same which is what you want. Otherwise reporting would be dramatically affected.
A "framework" is meant to be just that. You could say that "framework" is to "abstract" as "implementation" is to "concrete". Hence you would never create framework instances only implementation instances.
But are there truly any requirements to create a framework on which multiple implementations would eventually be built? If not, why have a framework layer at all? Why not simply tell the "New Application" wizard to create an "implementation"?
Suppose you wanted to define case types that are usable across an entire enterprise then build different applications that re-use those enterprise level case types?
To achieve this you would first use the "New Application" wizard to create an "enterprise implementation" then later use the "New Application" wizard to build an "implementation" on top of that previously created "enterprise implementation"
If later you discover that your new implementation has the potential to be a framework it is possible -- not saying it would be easy -- to "back-fill" a framework layer by inserting it between the "enterprise" layer and your previously created "implementation" layer.
By doing this, the pxObjClass for existing and future case instances would remain the same which is what you want. Otherwise reporting would be dramatically affected.
By inserting an FW layer after the fact, "all" you would change is what each existing case type extends. As opposed to extending Work-Cover-, each existing case type would extend a newly created FW- layer case type class.
To support a second implemenation that is Built-On on this new FW- layer you ideally would save the bulk of your existing "implementation" case type rules to the now-inherited FW-layer class then remove/withdraw those rules from your first implementation.
One problem is how to re-use your existing Data classes which presumably were defined in the same "implementation" ruleset as the initial case type classes.
You could have the second implemenation, instead, extend your first "implementaiton" cases, not bothering to insert any FW- layer. You would not have to copy any rules, plus the Data classes would necessarily have be there in the Application stack. The problem then, though, is - what if you want to make changes against the first implementation's case types?
Possible solutions:
(1) create a new ruleset for your first implementation placing that ruleset at the top of the Application stack. Make changes to flows, Sections, etc. to your first implementation there. You can keep the Case Type rules and Application rule in their original ruleset since the second implementation would be use its own Case Type rules and Application rule.
(2) Using Application-based ruleset validation it is possible to define an Application's Data- classes and Work-classes in different rulesets. Consider doing this from the beginning.
Pegasystems Inc.
IN
The framework layer is all about the process. This is what empowers an organization to achieve the majority of their reuse. Processes within an organization are often very similar between the different divisions. By placing this common process in a framework, we just have to build it once for all the different applications within that organization.
Frameworks should not be tied to a single line of business, as this limits their reuse, but instead should always look at the broad picture across the whole organization.
The kinds of rules most often encountered here are:
Case types
Flows
Flow actions
Sections
The implementation layer is where it all comes together. This layer is the application that a user leverages to perform their tasks. You can think of it as the ‘glue’ that holds together the rules from the framework, organization and division layers. The rules that are the most specific would exist here.
One key aspect to the implementation layer is that this is where any of our work classes should be instantiated. This allows the class to be the most specific and can then ensure it’s leveraging the appropriate rule in all instances. It also keeps the work for a particular division tied to that one division and avoids possible cross division contamination of work.
The kinds of rules most often encountered here are:
Class groups
SLAs
Routers
The framework layer is all about the process. This is what empowers an organization to achieve the majority of their reuse. Processes within an organization are often very similar between the different divisions. By placing this common process in a framework, we just have to build it once for all the different applications within that organization.
Frameworks should not be tied to a single line of business, as this limits their reuse, but instead should always look at the broad picture across the whole organization.
The kinds of rules most often encountered here are:
Case types
Flows
Flow actions
Sections
The implementation layer is where it all comes together. This layer is the application that a user leverages to perform their tasks. You can think of it as the ‘glue’ that holds together the rules from the framework, organization and division layers. The rules that are the most specific would exist here.
One key aspect to the implementation layer is that this is where any of our work classes should be instantiated. This allows the class to be the most specific and can then ensure it’s leveraging the appropriate rule in all instances. It also keeps the work for a particular division tied to that one division and avoids possible cross division contamination of work.
The kinds of rules most often encountered here are:
Class groups
SLAs
Routers
To conclude, the framework layer is for most of the rules in an application, whereas the implementation layer is for application rules that are specific to a division.
Hawaii Medical Service Association
US
Hi Gisela,
Thank you for your reply. We agree that mentation layer is that this is where any of our work classes should be instantiated. Could there be some reasons for the need to generate the work classes and corresponding work tables in FW layer while we create applications via wizard? When we create both layers, the system lets us create work objects in the framework layer as well. Therefore, I was wondering if there are any situations that business would be creating cases in FW layer.
Pegasystems Inc.
IN
Hi Dyan,
If the case / work applies to a buisness line, then it would be approriate to create workobjects at the framework layer. The more specialised it gets, we would then think of pushing them at the implementation layer.
Hope this helps!
Thanks,
Gisela
Accepted Solution
Updated: 5 Oct 2016 19:05 EDT
Pegasystems Inc.
US
A "framework" is meant to be just that. You could say that "framework" is to "abstract" as "implementation" is to "concrete". Hence you would never create framework instances only implementation instances.
But are there truly any requirements to create a framework on which multiple implementations would eventually be built? If not, why have a framework layer at all? Why not simply tell the "New Application" wizard to create an "implementation"?
Suppose you wanted to define case types that are usable across an entire enterprise then build different applications that re-use those enterprise level case types?
To achieve this you would first use the "New Application" wizard to create an "enterprise implementation" then later use the "New Application" wizard to build an "implementation" on top of that previously created "enterprise implementation"
If later you discover that your new implementation has the potential to be a framework it is possible -- not saying it would be easy -- to "back-fill" a framework layer by inserting it between the "enterprise" layer and your previously created "implementation" layer.
By doing this, the pxObjClass for existing and future case instances would remain the same which is what you want. Otherwise reporting would be dramatically affected.
A "framework" is meant to be just that. You could say that "framework" is to "abstract" as "implementation" is to "concrete". Hence you would never create framework instances only implementation instances.
But are there truly any requirements to create a framework on which multiple implementations would eventually be built? If not, why have a framework layer at all? Why not simply tell the "New Application" wizard to create an "implementation"?
Suppose you wanted to define case types that are usable across an entire enterprise then build different applications that re-use those enterprise level case types?
To achieve this you would first use the "New Application" wizard to create an "enterprise implementation" then later use the "New Application" wizard to build an "implementation" on top of that previously created "enterprise implementation"
If later you discover that your new implementation has the potential to be a framework it is possible -- not saying it would be easy -- to "back-fill" a framework layer by inserting it between the "enterprise" layer and your previously created "implementation" layer.
By doing this, the pxObjClass for existing and future case instances would remain the same which is what you want. Otherwise reporting would be dramatically affected.
By inserting an FW layer after the fact, "all" you would change is what each existing case type extends. As opposed to extending Work-Cover-, each existing case type would extend a newly created FW- layer case type class.
To support a second implemenation that is Built-On on this new FW- layer you ideally would save the bulk of your existing "implementation" case type rules to the now-inherited FW-layer class then remove/withdraw those rules from your first implementation.
One problem is how to re-use your existing Data classes which presumably were defined in the same "implementation" ruleset as the initial case type classes.
You could have the second implemenation, instead, extend your first "implementaiton" cases, not bothering to insert any FW- layer. You would not have to copy any rules, plus the Data classes would necessarily have be there in the Application stack. The problem then, though, is - what if you want to make changes against the first implementation's case types?
Possible solutions:
(1) create a new ruleset for your first implementation placing that ruleset at the top of the Application stack. Make changes to flows, Sections, etc. to your first implementation there. You can keep the Case Type rules and Application rule in their original ruleset since the second implementation would be use its own Case Type rules and Application rule.
(2) Using Application-based ruleset validation it is possible to define an Application's Data- classes and Work-classes in different rulesets. Consider doing this from the beginning.
Telstra
AU
Agree with PEDEL, framework should be treated as asbtract even though technically it's concrete. You'll have a table for framework work classes, but that doesn't mean that you should use the work classes to create cases (to store instances of these classes in table). This only applies for work classes, data classes are exempt and you can use FW data classes to store data like reference data