Applications consist of rules, rulesets, application data, system data, and other objects such as database schemas. As an application moves toward production, the application and its components must migrate among Pega systems. For example, you migrate the application from a development environment to a testing environment, and then finally to a production system. In some cases, you may want to migrate only specific application components such as updated rulesets or data types included in a patch release.
Consider the following scenario: If you move from one house to another house, you might create a manifest of household items that you want to move. You do not include things like cabinets, plumbing, or wiring, as these items are already in the house to which you are moving. You then load the items on the manifest list into a moving van. When the van reaches its destination, you take the items out of the van and unpack each item.
Like the manifest described in the previous example, you create a product rule that identifies the application components you want to move to a destination Pega Platform system. A product rule lists the rulesets, data, and other objects that make up an application. The product rule usually does not include standard rulesets and data because those components are built into all Pega Platform systems. A product rule is an instance of the Rule-Admin-Product class, also referred to as a RAP.
Note: You can find product rules in the Records Explorer > SysAdmin category.
You can access the Product Preview dialog from the Product rule to view a summary of application contents.
In the following image, click the + icons to learn about the Product Preview dialog:
Application Packaging wizard
Pega Platform uses the product rule to create an archive file that is used to export and import the selected contents. Like loading the moving van, you put the contents of the product rule into an archive file, also called a RAP file, that is compressed using either ZIP or JAR compression. You copy the archive file to the destination system and import the contents of the file into the system.
The following video highlights the basics of application migration:
Over the course of application development, an application usually moves across multiple environments. Generally, an application is developed in one environment, QAed in a different one, User Acceptance tested in another, and finally moved into a production environment when it is ready for release.
Transitioning back and forth between environments happens constantly in any development cycle. This fast pace, usually driven by a need for time-sensitive hotfixes and updates, can lead to issues during application migration. If not done correctly, applications could be migrated without certain features, user groups, external system data, etc. Planning a successful migration is easy with an integrated migration wizard that produces a consolidated package of all the essential components in your application.
Application packaging wizard
To avoid introducing errors when creating a product rule and generating a RAP file, Pega Platform provides a tool called the Application Packaging wizard that guides you through the creation of a product rule in a series of steps. The wizard identifies the items included at each step, which gives a developer the opportunity to identify missing components. For example, customized data instances that are associated with standard rulesets, like the Google API key, can be added manually. You can also modify the product rule from the rule form itself.
Associating data instances with rulesets
Associating data instances to a ruleset simplifies application migration and maintenance. When you package an application for migration, you include an application's rulesets. However, a ruleset corresponds to a collection of rules and does not include data instances such as operator IDs, access groups, database tables, and databases.
To help make packaging and migration of data instances easier, you associate data instances with rulesets. By doing this, you do not need to specify each data instance in the product rule. When you create the product rule, the system automatically adds the data instances to the archive file automatically.
As a best practice, associate data instances with rulesets. As you create data instances of certain classes, either manually or with a wizard, the system automatically associates the instance with one of the application's rulesets.
The associated ruleset appears in the rule header. The following example provides an access group that is associated with the Purchasing ruleset. You can change the associated ruleset by clicking Edit. Update the ruleset in the Associated RuleSet pop-up dialog.
You can remove the ruleset so that the data instance is not associated with any ruleset. For example, you may have created operators for development or testing only. You can remove the ruleset association from these operator IDs so that they are not automatically exported. Removing the associated ruleset results in a guardrail warning.
Associating a data instance with a ruleset does not affect or restrict any run-time behavior. The data instance remains available to all applications regardless of the associated ruleset.
Availability of imported rules
If you import rules in a ruleset that users can already access, the rules may begin executing immediately. These rules may run before all the rules in the same archive have been imported. Similarly, declarative rules begin executing immediately. This means that the declarative processes might fail if the elements or properties they reference have not yet been uploaded. This needs to be planned for when an archive is imported on a system with active users.
Note: To learn more about importing rules, see Using the Data Import Wizard.
Check your knowledge with the following interaction: