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:
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:
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.
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.
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.
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?
(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.
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