Links may not function; however, this content may be relevant to outdated versions of the product.
Understanding the Class structure and RuleSets generated by the Application Accelerator
The Application Accelerator generates an initial layered enterprise class structure and multiple RuleSets, based upon the input values you provide (and default values). This article presents:
- The layers, classes, and RuleSets created by the Application Accelerator for PRPC 6.1+ and 6.2+.
- Descriptions of the purpose of each layer
- An example scenario that illustrates the relationship between the values you enter into the Application Accelerator and the resulting generated enterprise class structure and RuleSets. The example scenario is similar to the business scenario described in the Building your first application tutorial.
- Generated enterprise class structure
- Layers in the generated class structure
- Generated enterprise classes and RuleSets (MyCo example)
- Globex company scenario
- Inputs to the Application Accelerator
- Globex example: Generated enterprise classes and RuleSets
- Questions commonly asked about the generated class structure
Generated enterprise class structure
Two large diagrams depict the layers and classes in the enterprise class structure generated by the Application Accelerator. Click to open a diagram in a new window:
| PRPC 6.1+:|
class structure diagram
| PRPC 6.2+:|
class structure diagram
This class structure enables multiple PRPC applications within the same system to co-exist, and supports effective reuse among the applications. For each PRPC release, the generated structure reflects best practices available in that release.
Layers in the generated class structure
The layers depicted in the enterprise class structure image are:
|Enterprise Reuse||For assets that need to be reused on an enterprise-wide basis. Such assets are rules for enterprise-wide business logic (such as standard properties, decision tables, Service Level rules) and enterprise-wide data assets (such as classes and rules for data stored in the system, and classes and rules for access to data in external systems, via connectors).
For example, the MyCo enterprise wants to reuse the property that holds an employee's serial number on an enterprise-wide basis, so that the various applications used by that employee across the enterprise can consistently rely on the same serial number property for the same employee.
|Divisional Reuse||For assets that need to be reused on adivision-wide basis. Such assets are rules for division-wide business logic (such as standard properties, decision tables, Service Level rules) and division-wide data assets (such as classes and rules for data stored in the system, and classes and rules for access to data in external systems, via connectors).
For example, a division wants to reuse a service level rule that defines the expected response time to a customer complaint in all of its applications, so that it can consistently enforce a focus on meeting its customer relationship commitments.
|Framework||Defines a common work-processing foundation that is extended by the specific implementations.
For example, the MyCo enterprise makes auto loans, and has an auto loan framework that is comprised of all of the assets needed for MyCo's standard auto loan process. Each division of MyCo extends that basic auto loan application to meet their specific divisional needs: the commercial business line division's auto loan application needs to handle loan requests distinct from that of MyCo's personal line division.
|Implementation||Defines an implementation of a framework that is customized for a specific division.
For example, the commercial business line's auto loan application reuses assets from the commercial business line division layer and from the auto loan framework layer, while the personal line's auto loan application reuses assets from the personal line division layer and the auto loan framework layer.
|PRPC Base Product||Consists of the PRPC system's built-in classes and rules necessary for processing cases and other work in PRPC applications, as well as for areas of PRPC itself.|
Using the same names that are depicted in the diagrams, the tables below illustrate the classes and RuleSets generated by the Application Accelerator for an organization called "MyCo", and demonstrate where the division, framework, implementation, and case/work type names are used in the class and RuleSet names.
|Class||RuleSet||Parent Class (Directed)|
|MyCo-Data-||MyCo||Data-||Data- (same as 6.1+)|
|MyCo-Int-||MyCoInt||Data-||Data- (same as 6.1+)|
|MyCo-Div1-Data-||MyCoDiv1||Data-||Data- (same as 6.1+)|
|MyCo-Div1-Int-||MyCoDiv1Int||Data-||Data- (same as 6.1+)|
|MyCo-FW-FrameworkName1-Data-||FrameworkName1||Data-||Data- (same as 6.1+)|
|MyCo-FW-FrameworkName1-Int-||FrameworkName1Int||Data-||Data- (same as 6.1+)|
|MyCo-Div1-Implementation1-Work||MyCoImplementation1||MyCo-FW-FrameworkName1-Work||MyCo-FW-FrameworkName1-Work (same as 6.1+)|
|MyCo-Div1-Implementation1-Work-Type1||MyCoImplementation1||MyCo-FW-FrameworkName1-Work-Type1||MyCo-FW-FrameworkName1-Work-Type1 (same as 6.1+)|
|MyCo-Div1-Implementation1-Work-Type2||MyCoImplementation1||MyCo-FW-FrameworkName1-Work-Type2||MyCo-FW-FrameworkName1-Work-Type2 (same as 6.1+)|
|MyCo-Div1-Implementation1-Data-||MyCoImplementation1||Data-||Data- (same as 6.1+)|
|MyCo-Div1-Implementation1-Int-||MyCoImplementation1Int||Data-||Data- (same as 6.1+)|
- Extending from Work-Cover- (not just Work-) is required for applications that leverage case management features. In PRPC 6.1+, the Application Accelerator provides an option to select Work-Cover- for a work type. For example, if that selection was made for the Type1 work type listed in the above table, the direct parent of the generated MyCo-FW-FrameworkName1-Work-Type1 class would be Work-Cover- instead of Work-Object-. In PRPC 6.2+, extending from Work-Cover- is the default (as indicated in the table) to make it easier for all newly generated applications to leverage case management.
- Each layer's Data- and Int- classes typically represent containers that stand by themselves and store data and interface classes used at that layer. It is rare to want the system to use class inheritance to reuse a data asset (for example, to reuse data classes from MyCo-Data- for data classes in MyCo-Div1-Implementation1-Data-). However, if your application requires extending from the organizational layers' Data- or Int- classes, modify the class rule for the framework or implementation class to set the needed directed parent class.
- When you create a new organization by running the Application Accelerator, the top-level class has a directed parent class of Work- (for PRPC 6.1+ systems) or Work-Cover- (for PRPC 6.2+ systems). However, when you create a new organization directly using the Organization Setup wizard instead, that wizard generates a top-level class (such as
MyCo) with a directed parent class of @baseclass. If you create a new organization using the Organization Setup wizard and want to reuse that organization when running the Application Accelerator, update the top-level class's inheritance (by manually updating the Parent class field in the class's rule form) to use the appropriate directed parent Work class, as shown in the preceding table.
|6.1+, 6.2 GA, and 6.2 SP1||6.2 SP2|
- In PRPC 6.2 SP2, the enterprise reuse RuleSet (MyCo) is included as a prerequisite RuleSet for the generated frameworkInt RuleSet. This provides support for the best practice of storing common rules at the enterprise level, because it gives the ability to reference those common rules from rules in the framework-level RuleSets.
- When you create a new organization directly using the Organization Setup wizard rather than the Application Accelerator, the wizard generates the organization RuleSet (such as
MyCo) with a prerequisite of Pega-ProcessCommander. If you create a new organization using the Organization Setup wizard and then reuse that organization when running the Application Accelerator, update the organization RuleSet to include the generated orgInt RuleSet as a prerequisite after it is created by the Application Accelerator.
Globex company scenario
In this example scenario, the Globex company has just deployed PRPC 6.2 SP2 for the first time within the company. Globex's IT department installed PRPC.
So that Globex's business analysts can log in and create the first application profile for the initial sliver of their first PRPC-based project, the IT department has created a temporary organization name
TEMP.com using the Organization Setup wizard, and then created operator IDs for the business analysts. (The official organization is created when the project team is ready to generate the first application.)
The overarching goal envisioned by the company is to automate and manage all of the Globex's processes involved in onboarding a newly hired employee. The first "sliver" that the team will implement is the sliver that handles requests and approvals for purchasing computer equipment and setting up workspace items for a new hire (
Equipment). The HR division is the first division that will use this sliver, and there are two case types: Workspace Request and Computer Request.
The business analysts have logged into the system and used the Application Profiler to capture the case types, processes, specifications, and requirements for this first sliver. These inputs are captured in the
Onboarding Version 1 - AP-1 application profile. The team is ready to use the Application Accelerator to generate the application structure based on this application profile.
Inputs to the Application Accelerator
Based on the goals of this sliver, the team uses the following values in the Application Accelerator:
|Organization||GLBX.com||Official name of the organization/company using the application. (The organization name is typically based on the four-character stock ticker of the company.)|
|Division||HR||Division using this particular sliver/implementation|
|Framework||OnboardingFW||Name for the base framework on which future slivers/implementations will be built, like those to handle work requests for Globex's new hires (such as Benefits, Payroll, etc.). The |
|Implementation||Equipment||Name for this particular sliver/implementation, because it handles requests for equipment (computer, workspace area) for Globex's new hires|
|Case type (1)||Workspace Request||Case type for requests of workspace items, such as cubicle location, desk, file cabinets, white boards, etc. (Specified in the application profile.)|
|Case type (2)||Computer Request||Case type for requests of computer equipment, such as laptop, monitor, printer, keyboard, etc. (Specified in the application profile.)|
A system architect starts the Application Accelerator, and in the Application Overview window, chooses the application profile the team created. To generate the application structure that supports both the framework and the equipment setup sliver, the system architect specifies a framework named
OnboardingFW and an implementation named
Equipment in the Application Overview window.
On the Base and RuleSets step of the Application Accelerator, the system architect replaces the displayed default organization and division values with the official ones:
HR, and keeps the default class structure of
Standard. The displayed values refresh to reflect the input values:
Clicking Preview displays the enterprise class structure that will be generated by the Application Accelerator given those input values:
Globex example: Generated enterprise classes and RuleSets
When the application is generated by the Application Accelerator in PRPC 6.2 SP2:
- Classes are created in the system, with names based on the input values.
- RuleSets are created. The class rules are stored in those RuleSets.
- The classes have directed parent classes according to the pattern shown in the following table (based on the Globex scenario).
|Class||RuleSet||Parent Class (Directed)|
Questions commonly asked about the generated class structure
Why do non-work classes, like Org-, inherit from Work- (in 6.1+) or Work-Cover- (in 6.2+)
Because of rule resolution, inheriting from Work- or Work-Cover- on those levels allows for increased sharing of case-management-related or work-related assets across multiple applications. For example, if a company creates two top-level classes for some reason (such as when two organizations do not currently work with each other and they want to develop applications independently), the applications can still share work-related assets.
Why does the Org RuleSet have the OrgInt RuleSet as a prerequisite (required) RuleSet?
So that business logic rules in the Org RuleSet have the ability to reference integration-related rules and classes stored in the OrgInt RuleSet.
Why doesn't the Application Accelerator generate MyCo-FW-FrameworkName1-Data- to directly inherit from MyCo-Data-? Why doesn't the generated MyCo-FW-FrameworkName1-Int- directly inherit from MyCo-Int-? Or for the rest of the Data- and Int- classes?
It is rare to want the system to use class inheritance to reuse a data asset (for example, to reuse data classes from MyCo-Data- for data classes in MyCo-Div1-Implementation1-Data-). However, if your application requires extending from the organizational layers' Data- or Int- classes, modify the class rule for the framework or implementation class to set the needed directed parent class.
This article has provided an overview of the enterprise class structure and RuleSets that are generated by the Application Accelerator, and an example illustrating the relationship between sample input values and what is generated.
Previous topic Introducing PRPC 6.2 - Implementation and Methodology Next topic DCO 6.2 and 6.3 - Creating Application Profiles and Discovery Maps