Field

Description

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

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

Field

Description

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 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 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.

Field

Description

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.

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.

• 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.

Field

Description

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.

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.

Field

Description

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 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 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.

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 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 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.

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.