Application form
Completing the Definition tab

  1. About 
  2. New 
  3. Definition 
  4. Cases and Data 
  5. Mobile 
  1. Documentation 
  2. Integration & Security 
  3. History 
  4. More... 

Use this tab to specify the rulesets and versions that make up the application, and to identify another application rule that defines prerequisite rulesets and versions.

The system uses this information during log-on to assemble a ruleset list for a user.

Built on Application

Field

Description

Built on Application

Specify another application rule, by its name and version, upon which this application is built. This other application is known as the "parent".

When you create an application using the new Application wizard , the system populates this value with the one you specify in the Built-on Application field on the Step 1 screen.

When assembling a user's ruleset list during logon, the system incorporates the parent's application ruleset Versions (specified in the Application RuleSets array in the parent's application rule form). In the user's ruleset list, the parent's application rulesets appear below the current application's rulesets (specified in the Application RuleSets array on this rule form). The Component and Shared RuleSets, and Production RuleSets arrays of the parent's application rule are ignored.

If your application depends only on standard Pega 7 Platform rulesets (those listed in the PegaRULES application rule), select PegaRULES and the highest version in your system. To build your application on Decision Strategy Manager (DSM), select PegaDM and the highest version in your system

Include Parent

Select this check box if you want rules from both the current application and its underlying (built-on) application to appear in developer tools and documentation. The underlying application is specified by the Built on Application name and version fields, and is considered the "parent" of the application defined by this application rule.

For example, when this check box is selected, the Automated Unit Tests tab displays test cases that reside in the parent application's rulesets, as well as rulesets from the current application's application rule.

Note: Some areas in PRPC do not display rules in rulesets that start with Pega-, regardless of whether the Include Parent check box is selected.

When selected, generated documentation includes specifications of the parent application (specified in the Built on Application fields by name and version), in addition to the specifications of the current application which builds upon the parent.

Some of the areas of the Designer Studio where rules from the parent are accessible (visible or selectable) when the Include Parent check box is selected are:

  • Application Document wizard
  • Automated Unit Testing landing page

About the rulesets arrays

Note: The Definition tab lists four sets of rulesets :

The order of the entries within these lists affects the assembly of a user's ruleset list and the operation of the rule resolution algorithm.

When assembling the ruleset list at sign-on, the system works from the top of each list down. rulesets appear in the following order, in two layers.

Formats for entries in the arrays

The order in which individual entries appear in the arrays determines the order in which they appear in the user's assembled ruleset list. When adding entries to these lists, ensure that the order matches the desired sequence for the user's ruleset list, with the most specific appearing first. You can rearrange the sequence of entries in an array by clicking and dragging an entry to a new position in the list.

The Application RuleSets, Production RuleSets, and Component and Shared RuleSets arrays list rulesets by ruleset name followed by a colon and version or initial portion of a version. For example:

Note: In entries to the Application RuleSets, Production RuleSets, and Component and Shared RuleSets arrays, specify distinct ruleset version numbers. A user or other requestor can access rules in only one major version of a ruleset; access to version 04-10-15 includes access to 04-10-14 and 04-04-11, but not to 03-01-01.

The Branch array displays defined development branches by branch name in a tree-like structure. To see the branch rulesets that are associated with a branch, expand that branch. Because branch rulesets only have one version (01-01-01), the version number is not displayed.

Rulesets

This group contains two arrays: Application RuleSets and Branch

Application RuleSets

Field

Description

Application RuleSets

The system enters the initial values in this array are added when you generate your application using New Application wizard. To add a ruleset:

  1. Click Array to add a new row.
  2. Specify a ruleset that has its Type set to Standard on the Category tab of its ruleset form. (All rulesets created in V5.3 and earlier are of the Standard type.)
  3. Complete the entry by entering a colon and ruleset version or initial portion of a version after the ruleset name. For example, an entry looks like OnboardingFW:01-01.

To create a new ruleset for a new entry, click magnifying glass in its row. To remove an entry from this list, click next to the entry.

To move an entry to a new position in the list, click and drag it to the new location.

Branch

Field

Description

Add Branch

Click to add a development branch to the current application.

When you click this button, the Add a Branch ID pop-up dialog opens. You can either create a new branch for your application, or add a branch from the system. Do one of the following:

  • Create a new branch by entering a name of between 3 and 16 characters. This value also provides the Branch ID key value for branched rulesets. A branch name must start with a letter and contain only alphanumeric and dash characters. A best practice for the name is to relate it to the planned development work taking place in that branch; for example, BUGFIX-Bug-42.
  • Select the name of an existing branch from the drop-down list. If the branch references branch rulesets, a message appears in the dialog indicating that they will be available in your application.

Click OK in the window to save the branch to the Branch tree.

To move a branch to a new position in the tree, click and drag it to the new location.

Note: You must save the application rule after adding a branch so that it appears on the list of available Branch ID values when you create a ruleset for that branch.

Branch

Displays the branches (by name) defined for this application in a tree-like structure. To see the branch rulesets already associated with a branch, expand that branch in the tree.

To see the rules in a branch ruleset:

  1. Expand the branch that is associated with that branch ruleset.
  2. Click the branch ruleset's name. The rule form for that rulesetappears.
  3. In the ruleset rule form, click the number displayed in the All Rules column. A window opens that lists the rules that are in that branch ruleset.

To associate a branch ruleset with a branch, create the branch ruleset using the Create Branch RuleSet button.

Actions The following actions are available:
  • Lock: Select to lock all of the branch rulesets associated with a branch. You cannot lock a branch if rules in any of the branch rulesets are checked out. To lock all of the unlocked rulesets in a branch, type the common password and then click Lock Branch.
  • Merge: Select to merge the rules in the branch rulesets in this branch to the base ruleset using the Merge Branches wizard. Typically, you merge the branch's contents when development on rules in a branch is stable or complete.
  • Package: Select to package all of the branch rulesets within a branch into a .jar file. Data instances tagged with the branch rulesets and the History of the rules are also included in the package. If rules within any of the branch rulesets are checked out, then the latest checked-in version of those rules is packaged.
  • Use for edit at runtime: Select to enable "edit at runtime" mode when using the Live UI tool. Alternately, use this menu to disable runtime editing from the selected branch
  • Delete from System: Select to delete the branch and its branch rulesets from the system. A confirmation pop-up dialog displays an array of branch rulesets that will be deleted, and summary counts of their rules and checked out rules. You cannot delete a branch if any of its rules are checked out or there are locked rulesets. Select the Save Branch contents in a JAR for download check box to create a .jar file containing the deleted branch content, which you can download after you delete the branch.
    Click Delete Branch to delete the branch and its RuleSets.
  • Remove from Application: Select to remove the branch and its rulesets from the application. The branch, its rulesets and rules remain in the system.

Create Branch RuleSet

Use this button to create a ruleset ruleset. There must be at least one branch in the system to create a branch ruleset. Typically, you use the Add Branch button to first create branches before creating rulesets for them.

Do the following:

  1. Click Create Branch RuleSet. The Create New RuleSet Version form opens.
  2. Select a Branch ID to associate this ruleset with.
  3. In the RuleSet to Branch field, select the ruleset from which the branch ruleset is based (the rulesetit is branched from). You can branch any ruleset in your ruleset list or is otherwise available to you, except for your personal ruleset.
  4. Click Quick Create or Create.
  5. Save the ruleset.

The system automatically updates the Branch array to show the association between the branch and the branch ruleset . By default, the format of the branch ruleset name is baseRuleSetname_Branch_branchID.

The RuleSet Type on the ruleset form's Category tab is set to Branch and cannot be changed.

Branch rulesets can have one version only (by default, 01-01-01). You cannot add versions to a branch rulesets .

See About RuleSet rules.

Security

To protect the application from being deleted or copied, and to prevent other operators from updating the rule's field values, do the following:

  1. Select the Require password to update application check box . When you select it, the Update Password button appears.
  2. Click the button to open the Update application password pop-up dialog.
  3. Enter a password in the Enter Password and Confirm Password fields and click OK. The password protection takes effect when you save the rule. The Password area containing the Supply a password to update field appears at the top of the rule form.

Note the fields and SmartPrompts in a protected rule are enabled. If you attempt to save, a warning message states that you must supply a password. Supply the password in the field to remove the warning and save the rule.

To remove password protection, clear the check box, enter the password, and save the rule.

Note: You can also lock and unlock the application using the Lock Application button in the Quick Actions area on the Application Overview landing page.

User Interface

These fields specify the skin you want to apply to the application and to determine browser compatibility.

Field

Description

Skin

Required. Specify a skin for this application. pyEndUser71 is the default skin. The list of available skins is based on your Profile.
You can override the application skin on the Skins tab of the Portal form. See Portal form — Completing the Skins tab.

Note: The list of available skins is based on your Profile and may include skins not available within the current application. If you save an application with a skin that is not available within the rulesets of the application, then the pyEndUser71 skin is used. To avoid this, log in using the application.

If you add a new ruleset to an application, save the application before specifying a skin included in the new ruleset. Follow this procedure:

  1. Add the ruleset and then save the application using an existing skin. Skin rules in the newly-added ruleset are now available to the application. You may need to logout and login for the application change and profile update to take effect.
  2. Select a skin from the list and then save the application.
Render in HTML 5

Select this check box to enable rendering this application in HTML 5 document type (standards mode). This enables the application to take advantage of the latest browser features.

HTML 5 document type is the default for new applications, beginning with Pega 7 Platform.

To enable HTML 5 document type for guardrail-compliant pre-Pega 7 Platform applications, select this check box. If your pre-7.1 application is not guardrail-compliant, access the HTML 5 Application Readiness page to determine if you need to upgrade harnesses or user interface elements to render your application in HTML 5 document type.

Note: The Document Type setting on the Advanced tab of the Harness overrides this setting. Ensure that the harness Document Type is set to Inherit from application rule or HTML5 (standards mode). When the harness Document Type is set to Inherit from application rule, the harness is rendered using the Render in HTML5 setting specified here.

Advanced

Note: Expand the Advanced group to display the Component and Shared RuleSets array and the Production RuleSets (Customization) array.

Field

Description

Production RuleSets (Customization) Optional. This array provides a list of rulesets (names and versions) that are then referenced as candidates for selection in an Access Group form. If this application rule is to be used by developers or other operators who update rules, identify here one or more versions of production rulesets. List at least some versions that are not locked. The order of entries in this array is not significant.

Specifying this list allows for making these rulesets available to different access groups for people who use this application to store custom rules in these rulesets. When rulesets are specified in this array in the Application rule form, you can select them within the Access Group form for a particular access group. The Access Group form has a matching Production RuleSets array that corresponds to this one on the Application rule form.

After the rulesets are specified here in the Application rule form, you can then open the Access Group form for an access group, and on the Access Group form's Layout tab, select one or more of these rulesets in the corresponding Production RuleSets array for that access group. As a best practice, specify in the Application rule form's Production RuleSets array all of those rulesets that you intend to specify in the access group form's Production RuleSets array. Otherwise, if you directly type rulesets into the Access Group form's Production RuleSet array that do not also appear in the corresponding array on the Application rule form, a warning appears when you save the access group.

To add a ruleset:

  1. Click Array to add a new row
  2. Specify a ruleset that has its Type set to Standard on the Category tab of its ruleset form. (All rulesets created in V5.3 and earlier are of the Standard type.)
  3. After selecting a ruleset, enter a colon and ruleset version or an initial portion of a version after the ruleset name. For example, an entry looks like MyReports:01-01.

To create a new ruleset for a new entry, click magnifying glass in its row. To remove an entry from this list, click next to the entry.

To move an entry to a new position in the list, click and drag it to the new location.

Component and Shared RuleSets

Optional. List any ruleset versions of component or shared rulesets here. (A component ruleset has the Type on the Category tab of the ruleset form set to Component. For a shared ruleset, the Type is Shared.)

To add a ruleset:

  1. Click Array to add a new row
  2. Specify a ruleset of the appropriate type (that has its Type set to Component or Shared in its rule form).
  3. After selecting a ruleset, enter a colon and ruleset version or initial portion of a version after the ruleset name. For example, an entry looks like OnboardingFW:01-01.

To create a new ruleset for a new entry, click magnifying glass in its row. To remove an entry from this list, click next to the entry.

To move an entry to a new position in the list, click and drag it to the new location.

Place properties on thread page only (5-4 or later) Note: This setting determines where the system maintains certain application property information. By default, this setting is enabled for application rules created in V5.4 or later, and disabled for application rules created in V5.3 or earlier.

When checked, at runtime the system looks at the Thread level (pxThread page) for the current values of certain system-maintained properties, that in V5.3 and earlier were maintained only on the pxRequestor page. For a partial list, see Atlas — Standard properties in the pxThread page (Code-Pega-Thread class).

When blank, for backwards compatibility, the properties are maintained on both the pxRequestor page and one pxThread page. However, only the pxRequestor values are accurate; the system looks at the requestor level (pxRequestor page).

In most cases, accept the default. Clear this box for rulesets created in V5.3 or earlier where development is complete (and all ruleset versions are locked) and you want to execute the rules in the ruleset in V5.3 compatibility mode as far as the location of these properties.

Note: If an application is built on another one on which the checkbox is not selected, you cannot select the checkbox on the child application.

Related Topics IconRelated information