RuleSets provide security and version control, and the ability to deploy your application to a different Process Commander

environment. A RuleSet must be created before building an application. The term RuleSet, as well as referring to the name instance i.e. the name of the RuleSet, sometimes informally refers to the contents (the rules) of that RuleSet. RuleSets in PRPC consist of 2 rule types:
y y

RuleSet Name (Rule-RuleSet-Name). The name can be a maximum of 64 mixed case characters. Spaces are not allowed. RuleSet Version (Rule-RuleSet-Version). The version has 3 categories: Major, Minor and Patch. For example 01-01-01 means Major Version 01, Minor Version 01 and Patch Version 01.

Top

RuleSet Naming Conventions

y y y y y y

Use names that are short and catchy and clearly describe the RuleSet, avoiding obscure acronyms. Uniquely identify your company and the business purpose in the name. Do not use Pega or Pega- as a prefix for your RuleSet names as they are restricted. Use single word names with significant letters in uppercase. For example MycoLoan is better than mycoloan. Avoid using special characters such as dashes, underscores, plus signs or quotes. For a sandbox ruleset use a name that contains Test or Sandbox.

Top

Standard Rulesets in PRPC

PRPC comes with standard RuleSets. By using the Rules By Type Explorer one can view a list of RuleSets in the system. The table below lists the standard RuleSets in PRPC.

RuleSet Name CheckInCandidates PegaAppDefinition Pega-Procom

Specification Empty initially, it supports the Rule check-in approval process and is used only by developers. This RuleSet is not locked. Optional RuleSet. This is used for Direct Capture Of Objectives. This is the base RuleSet. Includes workflow support and portal facilities.

Pega-IntSvcs PegaWAI Pega-WB Pega-Rules

Supports interfaces including connectors and services. Supports accessibility. (Optional) Internal Pega Rules engine. Basic engine operations, activities, Java generation and rule resolution.

A RuleSet version is an instance of the Rule-RuleSet-Version rule type. The version number in the form NN-NN-NN, defines six digits in three groups that characterize the evolution and development of a rule instance, and of the application it belongs with. The three segments are known as the major version, minor version, and patch version. Over my last few years in PRPC development, I've seen each application team use its own strategy to version rulesets for development, bug fix and release. My team used increments of 5 at the start of each iteration, then each inbetween version was used as a bug fix. If you have folks who commit and release rulesets parallel to the development team, then you need to have additional strategies in place to make sure rule resolution at run time can pick the correct version of the rule for execution. Please share your experiences and strategies around RuleSet Version.

Different Enterprise Rules Used in Pega RULES

Unlike other BPM products, PegaRULES Process Commander manages complex work using both practice rules (rules that automate work) and process rules (rules that route and assign work), in addition to system rules. With over 70 built-in specialized rules, Process Commander provides these three major categories of business rules to achieve multi-step parallel processing, automated decision making, and rich human and system interaction. Practice Rules Represent business guidelines or policies that define and drive a business. For example, When shipping products to New York, apply New York state taxes, or When a purchase order for a personal computer exceeds $2,000, it must be approved by Finance, or When a preferred customer registers a product complaint, always offer that customer a rebate on future purchases. Practice rules are created by both business and IT staff, but are managed primarily by business staff. Process Rules Define the procedural steps or flow regarding how humans and systems complete work. For example, when shipping costs exceed $2000, an organization might employ the following processes: (1) a tracking number is electronically assigned, (2) a cost center manager receives an electronic assignment to approve or reject the shipment cost, and (3) once approved or rejected, an automated correspondence is sent to the requester to relay the decision. If the request is approved, the sender can then track the shipment through the delivery portion of the flow via the tracking number. Process rules are managed by business analysts or operation

managers. System Rules Dictate how data is presented, stored and transported from one system to another. For example, Allow only dollar amounts in this field, or Convert nine-digit zip codes into five-digit zip codes, or Fetch a Web Service from the suppliers intranet. System rules are created and managed by system architects. Through these rules categories, PegaRULES Process Commander provides robust work management capabilities for solving complex business issues such as supply chain management, expert systems, self-service models, transaction-centric processing, and real-time order fulfillment. These capabilities enable organizations to build smart BPM applications that generate increased return on investment. Practice Rules: Five commonly-used types of practice rules in PegaRULES Process Commander are described below. 1) Decision Tree Rule A practice rule that conducts fact-based inferencing (forward chaining). Through a single rule form, Process Commander provides the ability to create a complex decision flow of unrelated data and returns the appropriate response based on given facts. The use of forms to create "if-then" types of logic significantly reduces errors and management challenges generally associated with lines of nested if-then code. 2) Dimensional Decision Rule A practice rule that returns an answer or variable based on a single or multiple set of when conditions. At run time, a when condition evaluates a simple comparison of related values of properties. Process Commander safeguards an enterprise from failing to act on critical business operations when particular circumstances arise. 3) Declarative Expression Rule A practice rule used when the value of a numeric field needs to be computed during application run time. Expression rules ensure that the value of a property is updated automatically when any of its dependent properties change eliminating the need for business users to track changes and perform recalculations. 4) Declarative Constraint Rule A practice rule used to define conditions or limits on designated data entry fields. For example, if the maximum value of an entry field is $20 and the user inserts $30, Process Commander will alert the user with an automated error message that a constraint has been violated. Constraint rules ensure that values meet predefined criteria, and eliminate the need for the application to track changes to data and reapply editing criteria. 5) Activity Rule A practice rule that returns a command or a calculated figure based on given variables. Process Commander compares and contrasts multiple variables, and initiates an appropriate action based on the results. Unlike other BPM products, Process Commander does not require users to program lines of code to create custom automated responses or actions. Process Rules: Four commonly-used types of process rules in PegaRULES Process Commander are described below.

1) Flow Rule A process rule that manages, monitors and automates work as it is assigned throughout a flow. Microsoft Visio serves as the graphical front end to Process Commanders Rulebase, and dynamically communicates with the PegaRULES Enterprise Rules Engine where all rules are saved and executed at run time. By placing either out-of-the-box or customized Microsoft SmartShapes on a Visio worksheet, business managers can easily link activities together to create, view and update both the workflow diagram and its underlying processing logic. 2) Assignment Rule Process Commander includes numerous built-in rules associated with managing the assignment of work both within and outside the enterprise. These rules enable the assignment of work to individuals, to pooled workbaskets, and to occasional users. Other assignment-related rules enable goals and deadlines to be set for assignments, as well as automating correspondence. 3) Work Delegation Rule A process rule that engages and enables Process Commander to access entities outside the system (i.e., non-registered users such as suppliers, customers and partners). This rule enables Process Commander to send work assignments to users who require only infrequent access to the application. Process Commander sends an embedded assignment through an e-mail message that contains a URL link to a work object within a flow. The link is a one-time secure key to access the system. This capability extends the ability to perform work in Process Commander to all constituents throughout the extended enterprise, without the need of client-side software. 4) Service Level Agreement (SLA) Rule A process rule that monitors and ensures that work is completed in a timely manner. Each service level defines one or two time intervals, known as goals and deadlines, to indicate the expected or targeted turnaround time for the assignment (or time-to-resolve for the work object). When a service level time is reached before an assignment is completed, automatic processing occurs (such as escalation). Unlike other systems, Process Commander not only highlights and reports on delinquent work, but triggers escalation rules to ensure that work is completed as promised. System Rules: Three commonly-used types of system rules in PegaRULES Process Commander are described below. 1) Integration Rule A system rule that streamlines interfacing between two or more systems. Process Commander provides pre-configured rules for CORBA, COM, MQ, SOAP and Microsoft Dot NET, as well as enterprise databases eliminating the need to acquire third-party integration software. 2) Declarative Indexing A system rule that defines and stores relationship data between objects in the PegaRULES database. For example, where multiple rule instances exist with a data field entitled Zip Code, changing the title of the field to Postal Code would require a programmer to find all rules that correlate to this title in order to make the change. With Declarative Indexing, a report can be generated to display all related rule instances dramatically 3) Transformation Rule A system rule that automates data mapping and parsing between disparate systems. These rules promote reuse of data across the enterprise, enabling organizations to leverage and maximize the existing IT infrastructure.

How Someone gets Access to Pega:

Instances of the following provide users with access to rulesets and versions. Without defining the ruleset here, no one can access the particular ruleset.

1. 2. 3. 4.

Data-Admin-Requestor Data-Admin-Organization Data-Admin-OrgUnit Data-Admin-AccessGroup

In these instances, based on the Ruleset version, the versions will be available for the user. If a ruleset is entered along with the version information, all the lower versions will be available to the user and no major version will be available to him. If no version detail is entered, all the versions will be available to the user. The above said is the process of giving access to a group.

Rule Resolution gets the ruleset for the particular user based on the order specified above.

1. Login activity starts with the Data-Admin-Requestor instance for the browser requestor type and includes standard rulesets (Pega-Procom, Pega-WB, Pega-IntSvcs, and Pega-RULES).

2. After authentication, login activity goes to Data-Admin-Organization, Data-Admin-OrgUnit and then finally to Data-Admin-AccessGroup and gets all the rulesets and versions defined on them respectively.