1

Certification Material

2

Table of Contents 1. Introduction to BPM & BRE ................................................................................ 3 2. General PRPC Architecture .............................................................................. 12 3. Class Structures & Hierarchy Design............................................................ 31 4. Data Modeling...................................................................................................... 44 5. Process Flow ........................................................................................................ 50 6. Case Management ............................................................................................... 67 7. Activities .............................................................................................................. 73 8. User Interface ................................................................................................... 92 9. Decision Rules & Declarative Rules .............................................................. 115 10. Rule Management/Security .......................................................................... 126 11. Integration ....................................................................................................... 150 12. Implementation and Performance Tools ................................................... 179 13. Reporting .......................................................................................................... 191 14. Application Deployment ................................................................................ 203

3

1. Introduction to BPM & BRE

4

Business Process Management: A business process is a set of coordinated tasks and activities, conducted by both

people and equipment that will lead to accomplishing a specific organizational goal. Automation of business processes, in whole or in part, where documents, information,

or tasks are passed from one participant to another for action, according to a set of rules.

A business process is a logically related set of workflows, work steps, and tasks that

provide a product or service to customers. BPM is a mix of process management/workflow with application integration technology.

Business Process Management is a structured approach that models an enterprises,

human and machine tasks and the interactions between them as processes. BPM software provides users with a dashboard interface that offers a high-level view of the operation that typically crosses departmental boundaries. The dashboard integrates with all the applications that perform processes as well as related databases. It can be used to trigger the start of a unit of work, and it provides a single interface to the end user.

Advantages:

C Solution tailored to closely meet needs of business C Easy to build, easy to change C Ability to capture of objectives directly in system C Automates the programming and the work! C Ease of integration C Leverage BPM vendor's significant development investment

Disadvantages:

D May encounter cultural resistance as BPM fundamentally changes the way Business Users and IT work together.

Business Rules Engine: Business rules represent policies, procedures and constraints regarding how an

enterprise conducts its business. Organizations have policies in order to satisfy the business objectives, satisfy

customers, make good use of resources, and conform to laws or general business conventions

5

Business rules become requirements, that is, they may be implemented in a software system. BREs can be used alone or in conjunction with other technologies, like Business Process Management (BPM).

A business rules engine is a software system that executes one or more business

rules in a runtime production environment. BRE is the software that automates policies and procedures within an organization,

whether legal, internal or operational. The use of a rules engine (BRE) requires placing the company rules in an external repository that can be easily reviewed rather than buried inside the code of numerous applications. Instead of a program executing internal algorithms, it goes out to the BRE to obtain its business logic.

A BRE enables software changes to be implemented much faster than changing

source code. It can also ensure that the same rules are applied in all programs on all platforms across departmental lines. In addition, it supports platform changes. New software can be deployed knowing that the same business logic is going to be executed in the new programs.

This means that the rules engine is capable of getting data through services, process

the data with some business logic, and return results through services. It can also interact with other backend systems to get more information, validate data etc, but through services.

Advantages of Business Rules Engine:

C Quick development C Easy Rule move from one environment to another environment C Business Users can update the rule directly without IT help (Up to some level) C Lot of in build functionality. No need to write thousands lines of code (For

Example Parsing XML, Generating XML, Connecting external system.) BPM vs. BRE

BPM tools are made for process automation, workflow and routing. BRE's are made for decision management, can use inferencing, and are context

sensitive. A BPM application can be a type of B2C. A BRE application can be a type of B2B.

SmartBPM The latest generation of PegaSystems' industry-leading, rules-driven Business Process

Management (BPM) is a comprehensive suite intended to help businesses plan, build, and manage process-management solutions through their entire lifecycle.

6

SmartBPM is a process that blends your process and practice rules and helps you rapidly deploy and update solutions in response to changing circumstances.

SmartBPM Suite contains the below Components

1. PegaRULES Process Commander At the core of the SmartBPM Suite is PegaRULES Process Commander, Built on top of the PegaRULES enterprise rules engine, and employs a sophisticated common object model to deliver the power of process and practice integration, without the expense and resources associated with maintaining separate business process and rules databases, user interfaces, test environments, and production environments.

2. Process Analyzer Uses a data warehouse of both historical work and simulated data, with on-line analytic tools to continuously improve processes.

3. Process Simulator New business processes are simulated before they go live. Using "wizards," analysts can quantify and compare potential for increased service levels, as well as reductions in time, error, and cost.

4. Enterprise Integration PegaSystems' SmartBPM is built from the inside out with a services-oriented architecture (SOA). It offers an extensive library of enterprise connectors and adapters, including support for industry standards such as BPEL.

5. Case Management A smart case-management application is included as part of the SmartBPM Suite, and can be put to work immediately.

6. Content Management Integration The SmartBPM Suite can also integrate multiple image repositories and document- and content-management systems to manage global policies and processes for record retrieval and retention.

7. Portal Integration Businesses turn to web-portal technology to enable collaboration with their trading partners and to open up self-service to their customers.

What is SmartBPM Six Rs?

With PegaRULES Process Commander, Pegasystems provides the traditional BPM capabilities receiving, routing, and reporting on work across the enterprise, accomplishing these tasks automatically based on intent-driven rules and processes & completes work by researching, responding, and resolving, thereby eliminating most manual processing for completing work.

1. Receiving and controlling work regardless of the source or channel 2. Routing work based on worker skills and workload, and SLA-based priorities 3. Reporting and simulation based on historical, not just models 4. Researching by rules-driven data and image gathering 5. Responding automatically via multiple communication channels 6. Resolving by automating critical business decisions

7

SmartBPM Six Rs Drive Work to Completion

What is meant by Build for Change?

Build for Change Rapid development of solutions that support fast and safe real-time changes

Built-in versioning makes interactive change and selected pilots easy and safe to manage.

Solution Accelerator auto-generates solutions links to PegaSystems Process Simulator for what-if testing

Web-based tools provided for trace, debug rules and performance management Graphical decision trees with natural language expression Push-button documentation for project tracking and compliance requirements Portal interface for architects, developers, and business analysts Integrated Microsoft Visio for process and rule creation, as well as Visio flow

import Extensive array of fit-for-purpose forms to speed implementation and allow

business-user change

What is meant by SmartBuild?

SmartBuild Smart Design for Smart Systems

SmartBuild is the sequence of 14 steps for developing business process management (BPM) and Business rule engine (BRE) solutions with Process Commander. Each

8

step describes how to design and build specific components. You perform these steps and the associated tasks iteratively to deliver a fully functional solution. In short, SmartBuild is the design and development process for Process Commander Solutions.

PegaRules Process Commander (PRPC) Basics PRPC is a combination of BPM ( Business Process Management) and BRE (Business

Rules Engine ) Most Business Process Management (BPM) solutions provide workflow capabilities

receiving, routing, and reporting on work across the organization. Process Commander accomplishes these tasks automatically and goes beyond

traditional workflow management to complete work researching, resolving, and responding eliminating most manual processing for completing work.

Process Commander is the only BPM solution that automates both the business decisions and the business processes that drive work to completion.

Process Commander is shipped with 56 standard rulesets viz,

1. Pega-ProCom Supports business Process Management 2. Pega-InvSvcs Supports integration services 3. Pega-WB Supports portal infrastructure 4. Pega-Rules Supports rules engine and rule resolution 5. Pega-AppDefinition - supports the Direct Capture of Objectives features.

Services are interfaces from other systems to PRPC. Standard services that come in with PRPC are

1. Rule-Service-COM 2. Rule-Service-CORBA 3. Rule-Service-BPEL 4. Rule-Service-File 5. Rule-Service-HTTP 6. Rule-Service-Portlet 7. Rule-Service-DOTNET 8. Rule-Service-EJB 9. Rule-Service-Email 10. Rule-Service-JMS 11. Rule-Service-JSR94 12. Rule-Service-MQ

Connectors are interfaces from PRPC to other systems. Standard connectors that

come in with PRPC are 1. Rule-Connect-EJB 2. Rule-Connect-BPEL 3. Rule-Connect-File 4. Rule-Connect-HTTP 5. Rule-Connect-JCA

9

6. Rule-Connect-DOTNET 7. Rule-Connect-SQL 8. Rule-Connect-Java 9. Rule-Connect-JMS 10. Rule-Connect-SOAP 11. Rule-Connect-MQ

Process Commander supports a three-level organizational hierarchy consisting of organizations at the top level, divisions at a second level, and units as a third level.

An organization is an instance of the Data-Admin-Organization class. An

organization is the top level of the three-level organizational hierarchy available to all of your applications.

A division is an instance of the Data-Admin-OrgDivision class and is the middle

level of the three-level organizational hierarchy available in all applications. Divisions are below the organization level (Data-Admin-Organization class) and above the organization unit level (Data-Admin-OrgUnit class).

An organization unit is an instance of the Data-Admin-OrgUnit class. An

organization unit is the bottom level of a standard three-level organizational hierarchy available in every Process Commander application.

Operators are created through instances of Data-Admin-Operator-ID class. An operator ID can belong to only one primary access group. Important entries

while creating the operators are 1. Organization ( Mandatory) 2. Division ( Mandatory ) 3. Unit ( Mandatory ) 4. Workgroup ( Mandatory ) 5. Access Group ( Mandatory ) 6. Allow Rule Check Out ( Check box ) ( Optional )

Work group is an instance of the Data-Admin-WorkGroup class. A work group can identify a user who is a supervisor, together with a set of workers and workbaskets that report to that supervisor.

Access group is an instance of the Data-Admin-Operator-AccessGroup class. Access groups make a set of RuleSet versions available to requestors.

Access role is an instance of the Rule-Access-Role-Name class.Use an access role

name to convey permissions (capabilities) to a user or a group of users. Access roles can be referenced in requestor instances, Operator ID instances, in access group instances, in activities, and in queries.

10

Standard access roles (with names starting with PegaRULES:) define capabilities for below PRPC model users

a. Business Users 1. Business User : End user of the application 2. Business Manager : Who monitors the performance of users or user

groups

b. Developers and Implementers 1. Process Architect: A business analyst who defines and maintains

business rules, service levels, and flows 2. System Architect: An application developer who creates class structure

for the application and who builds the interfaces with external systems 3. System Administrator: System engineer who is responsible for

installation and setup, security, and high level configurations

RuleSet name is an instance of the Rule-RuleSet-Name rule type. Each RuleSet defines a major subset of rules in the PegaRULES database, because every instance of every rule type references or "belongs to" a RuleSet. Together with the RuleSet version, a RuleSet name is a major aspect in:

Access control Managing the rules Moving applications sets of rules from one Process Commander

System to another.

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.

RuleSet Format

LoanAppl 01-02-03 01- Version

02 Minor release within the version 03 Interim or patch release within minor release

Rule resolution is the sophisticated internal search algorithm that the system uses to find the best or most appropriate rule instance to apply in a situation. Rule resolution applies to most, but not all, classes derived from the Rule- base class.

Rule resolution uses as input values:

The name of the rule needed

11

Starting location in the class hierarchy RuleSet list Current date-time, which may cause time based rules to take precedence. Circumstance property and value The value of the as-of date property When to use directed inheritance and pattern inheritance.

Ten Guardrails for a Successful PRPC Solution

1. Adopt an Iterative Project Approach 2. Establish a Robust Foundation 3. Do Nothing That Is Hard 4. Limit Custom JAVA 5. Build for Change 6. Design Intent-Driven Processes 7. Create Easy-to-Read Flows 8. Monitor Performance Regularly 9. Calculate and Edit Declaratively, Not Procedurally 10. Keep Security Object-Oriented, Too

Questions:

1. Typically, the process architect maintains which of the following rules: a. Decision tables b. Decision trees c. Access roles d. Access privileges e. Correspondence f. Expressions

2. Typically, the system architect maintains which of the following rules: a. Properties b. User interface rules c. Services d. RuleSets e. Indexes

3. Typically, the system administrator maintains which of the following rules: a. Flows b. Portal access c. User IDs d. Activities

12

2. General PRPC Architecture

13

PRPC and JEE architecture PegaRULES has a flexible, open architecture. It allows you to execute the rules

engine in a variety of configurations and platforms. In addition, PegaRULES nodes can run concurrently on heterogeneous platforms. This capability provides flexibility to system administrators in configuring and deploying user accounts or execution models against a shared PegaRULES database.

The flexible architecture of PegaRULES Process Commander supports several

patterns that can be deployed with variations to fit the specific platform requirements of an enterprise business rules application and technology environment.

PegaRULES Process Commander Internal Architecture

As illustrated, the PegaRULES engine consists of a run-time environment, including

the forward and backward chaining inference engine. The engine maintains the rules and executes Pegasystems patented rule resolution algorithm. The environment also includes the clipboard containing XML objects that represent the work data for various users or requestors. The run-time environment also provides other essential capabilities such as performance monitoring, security management, context management, Java caching, and database access.

14

PegaRULES runs as a collection of loosely coupled nodes that bring the execution of

processes and rules in proximity to the requesting user or system. PegaRULES can support various architectural designs. The patterns shown in the following sections are examples of fundamental implementations.

Basic Multitier Pattern with Servlets PegaRULES runs as servlets within the Web container of a J2EE application server

(or a servlet container, such as Apache Tomcat). The rules engine runs self-contained within the Java Virtual Machine (JVM).

Multitier Java Architecture Portable and Powerful

A number of servlets are associated with PegaRULES including the PRServlet (the standard servlet) as well as servlets for system monitoring, rule tracing, and external services. PegaRULES servlets run within the Web container of a J2EE application

15

server (or a servlet container, such as Apache Tomcat). PegaRULES also supports server tier architectures and EJBs.

Process Commander is designed to run as a Web application, built in a Service Oriented Architecture (SOA) to support a Web services environment, such as SOAP and other industry-standard transports. While these architecture patterns are well served by the J2EE framework, two other primary integration methods batch and embedded are not. For certain high-performance applications, embedded or batch processing provides a better alternative. For this reason, Process Commander is built to run within the J2EE environment without inheriting its limitations.

In the multi-tier architecture, Process Commander sends HTML to the browser for

both business user and developer/administrator functions. HTML screens are managed using specialized HTML rules within the rules engine.

Embedded Java Application Pattern PegaRULES supports the JSR 94 standard rules application interface (API). The rules

engine can be invoked through the Java API and can execute within a rules engine application on the same Java virtual machine (JVM). With this pattern, client applications can embed the rules engine in the overall Java code of their applications.

Embedded PegaRULES Engine

16

Batch Processing Pattern The embedded Java application pattern can be used in processing large volumes of

business rule transactions through batch scripts. PegaRULES uses file listeners to support batch processing. With file listeners, a batch job (or any other application) can write files to a prescribed folder. The PegaRULES listener can then pick up and execute these files in high volume.

PegaRULES Engine in Batch Processing

The robust PegaRULES engine also supports other architecture patterns. However,

the patterns described in the previous sections provide the flexibility that system administrators and application developers need in deploying enterprise applications.

WAR and EAR Deployments

Overview of the Installation Procedure The following outline details the steps in the 5.1 installation process:

1. Prepare the Database server Create a database with a PRPC user and password Install the PRPC schema appropriate for your database vendor

2. Prepare the application server Configure the server environment Verify the Java environment

17

Create and verify the database connection Create a DataSource with the JNDI name of jdbc/PegaRules. Verify the PRPC Temporary directory 3. Deploy the PRPC components.

3. Install the Process Commander Rulesets Start the Process Commander Database Utilities application Upload the application files from the Process Commander distribution to

your application server Install the Process Commander application instances to the database

4. Configure Your PRPC system Optionally configure a Lucene search engine to support Rule and Work

Object searches in Process Commander Configure the Help and System Management applications Setup an initial user organization

You perform the first two steps with the database and application server administrator

tools, respectively. You use the Process Commander Database Utilities application (prdbutil) to upload and install the application files, and to set up the initial configuration of your Process Commander system.

To set up a Process Commander system, you deploy four software components in

your application server:

18

The deployment of a basic installation instance is shown in the diagram below:

Deployment of a basic installation instance Selecting the right core component for your platform The PRPC core application is packaged in five different versions to support the

deployment of PRPC into different J2EE environments. The following table summarizes all the packages provided and their use:

Type of deployment PRPC package to use All Tomcat deployments prweb.war

All new deployments on WebSphere 6.x or WebLogic 9.x, or Oracle Application Server 10g Release 3

prweb.war or prpc_j2ee14.ear

Note: The legacy packages listed below are provided only for existing customers to support backward compatibility. Contact customer support before deploying.

19

All new deployments on WebSphere 5.1. prweb.war

All new deployments on WebLogic 8.x prweb.war or prpc_j2ee13.ear

Existing deployments on WebSphere 6.x or WebLogic 9.x that used prweb.ear

prweb.war or prweb_j2ee14.ear

Existing deployments on WebSphere 5.x or WebLogic 8.x that used prweb.ear

prweb.war or prweb_j2ee13.ear

Components labeled j2ee14 should be deployed in application servers that conform

to the J2EE 1.4 specification. The components labeled j2ee13 should be deployed in application servers that conform to the J2EE 1.3 specification.

Tomcat and WebSphere 5.1 customers should install the WAR in all cases. WebSphere, WebLogic, or Oracle Application Server customers may also deploy the

WAR if they are not using functionality in either of the EAR packages. You must deploy the EAR file component if you intend to use any of the following container-managed features with your Process Commander application: Two-phase commit JMS message services Rule-Service-EJB J2SE security

When upgrading Process Commander, you should generally install the core

component package that is currently in use in your environment. That is, existing WAR deployments should deploy the 5.5 SP1 WAR component; existing EAR deployments should deploy the 5.5 SP1 EAR. However, if you upgrade the supporting platform components at the same time as Process Commander, or if your integration requirements have changed, you may need to change the PRPC core component and your system configuration.

Note: Please refer the Pega Installation Guide from the PDN site for any detailed Deployment procedure.

The prerequisites for installing Process Commander are:

An application server host computer with adequate memory and disk space for the installation. Process Commander requires a minimum of one GB of free memory. This is in addition to any memory allocated for the operating system or other applications on the server. The memory required for your system may need to be higher, depending on the number of users and your specific configuration.

A working installation of the application server. A configured relational database available for Process Commander use, and

support in your organization for the installation and configuration of relational databases.

20

Note: The database and application server platforms may be either UNIX or Windows systems. However, a Windows system is required for the Pegasystems developer and end-user clients and for some of the Pegasystems monitoring tools, specifically, PegaRULES Process Analyzer, Process Simulator and Autonomic Event Services. The environment for your initial Process Commander system should include at least one Windows platform.

Caching To allow the powerful Rule Resolution process to occur with the required

performance levels for enterprise-scale systems, PegaRULES has a series of caches. A cache contains data that has been copied out of one place and stored temporarily in another for easier access. In Process Commander, some caches are stored in the system memory (JVM), some are stored in the database, and some are stored on disk.

Caches stored in memory include: Rule cache Rules Assembly cache Conclusion cache

Caches stored on disk in the file system include: LookupList cache Static Content cache

Rule cache holds data about the reads done from the PegaRULES database for rule

classes. The first time a rule is requested from the database, the cache has no information about it. It passes the request on to the database, and the system attempts to retrieve the information from the database. If the data is available in the database, the system retrieves the rule, stores it in the Rule cache, and then sends the rule information back to whichever process requested it. The next time that information is required, it is retrieved from the cache instead of the database.

Rules Assembly cache is used to minimize Java code generation and compilation

mainly by tracking RuleSet lists and user entries. Rules assembly is the process whereby all the rules run by the Process Commander system are generated into Java code for the system to execute. Rules assembly, especially code compilation, is extremely resource intensive and comprises a series of processing steps.

A conclusion is an instance of a Java object (resulting from the Rules Assembly

process) that was generated, instantiated, and then persisted to the database for future use. The unique feature of conclusions that differentiate them from normal Java object persistence is that these classes also rebuild themselves in response to rule changes (just like all other types of rules). The benefit of conclusions is that they group a number of similar rules, and digest the information down to the minimum amount required at runtime.

21

Rules Assembly is the process whereby all of the rules which are run by the Process Commander system are generated into Java code for the system to execute. Since Rules Assembly is an expensive process (in terms of system resources), the process has been broken down into several steps to maximize performance and efficiency.

When the system calls a rule to be run, if that rule was never executed, the Rules Assembly process must: assemble the rule, including all the other rules required (for example, if this is an

activity rule, it may call other rules) generate the Java code for the rule compile the code load and execute the resulting class file Of these steps, the code compilation is the most expensive. Therefore, several Rules caches have been added to try to minimize Java code generation and compilation.

During Rules Assembly, one of the key factors is the users RuleSet List, as that controls which rules the user may see. Two users with different RuleSet Lists may call the same named rule, but due to their different Lists, the rules selected and the code ultimately generated may be quite different. Similarly, it is possible for two users with different-yet-related RuleSet Lists to call for the same named rule; because the rules are defined entirely in the RuleSets they have in common, the generated class is exactly the same. Due to these factors, a cache structure is maintained in memory, keyed by a combination of the RuleSet List and Rule Name (its purpose) that maintains a reference to the generated class files loaded instance.

Static Content Cache In PegaRULES, static content files contain information presented to users which

doesnt need to be constantly processed, such as form images or help files (example: the login splash screen, which will not be affected by changes to rules or to work items). In PegaRULES Process Commander, the main Rules which contain static content are: Rule-File-Binary Rule-File-Form Rule-File-Text

These rules are read from the database using the Rule Resolution process, and the files are cached to the server file system (not into memory). Since these files dont change rapidly and are expensive to read from the database, they can persist in the file system through system shutdown and startup, and be retrieved as a file, rather than spending the resources to constantly retrieve the data from the database. The static content data is actually cached in two places: on the client (each users PC) on the server

22

Static Content Cached on the Client is standard browser caching. Whenever a user requests static content (Rule-File- forms, Help forms, and other static content in the WAR file), that information will be cached in the browser on the client side. It is possible to set an expiration tag on this information, which will tell the browser to look first in its cache for data before asking the server again.

Static Content Cached on the Server: The first time information from a static file is

requested, the system searches the directory structure for the requested rule, in the following order:

Personal RuleSet subdirectories

(\rule_cache\webwb\RuleSethashname\PersonalRuleSethashname) RuleSet List directories (\rule_cache\webwb\RuleSethashname) the WebWB directory

(NOTE: Just as the Rules in the personal RuleSet override the Rules in the main RuleSets, so the static content in the Personal subdirectory overrides the static files in the main subdirectory.)

LookupList Cache LookupLists contain information that displays in dropdown boxes in Process

Commander. These are items (such as the SmartPrompts) which are built on a complex query that takes a long time to run (perhaps more than two seconds). Since this information is so expensive to produce, it is cached to improve performance.

The LookupList cache is stored similarly to the Static Content Cache, in the file

system. Files are put in the contextroot/webwb/llc directory, and grouped by classname.

Example:

prweb/webwb/llc/Rule-Obj-Fieldvalue prweb/webwb/llc/Rule-HTML-Harness

The first time a LookupList is requested, the system searches the directory structure for the requested rule, in appropriate class subdirectory under LLC. If the file is present, it will be returned. If the file is not already cached, the system will load the file from the database, and also write the file to the LookupList cache on disk.

Again, the LookupList cache should have to be cleared rarely, if ever. If something

that is done that modifies rules outside normal processing, such as importing rules using the PRImpExpServlet, then the cache must be cleared to pick up the new data. Also, if there was a problem with the system pulse, and data was not correctly propagated to the other nodes in the system, the LookupList Cache should be cleared (along with various other caches). The consequences of clearing the cache is that the system must check the cache before going to the database, and then cache everything again, which will slow performance until the caches are rebuilt.

23

When PegaRULES is installed on a multi-node system, then a copy of the various

caches are stored on each node, and each of those nodes must be updated with rule changes. This update process is managed by the System Pulse functionality.

Saving a rule change (update, add, or delete) to one of the Rule tables in the database

will fire a PegaRULES database trigger, which will then register the change in the pr_sys_updatescache table (in the same database). Each node records all their changes in this table; the types of event which are saved to this table include: Cache for any changes to the rule cache (changes to the rules) Index for Lucene changes DELLC when the lookuplist cache is deleted RFDEL for any rule-file- deletes

Once per minute, the pulse (which is part of the standard PegaRULES agent) on each node wakes up (independently) and queries the pr_sys_updatescache table. The query retrieves records which are not from this node (which this node did not create), and which have a timestamp which falls within the window of time starting with the last pulse (or system startup) and now. In this way, all of the changes originating on other nodes are selected, and the appropriate cache entries on this node are invalidated. The next time one of the rules which has been invalidated is called, it will not be found in the cache, and the updated version of the rule will be read out of the database and be eligible for caching again.

24

Agents Agents are internal background processes operating on the server that run activities

according to a schedule. Agents are autonomous and asynchronous. The activities they call run individually on their own schedules and one activity does not have to finish before another one runs.

Agents are implemented through two Process Commander objects: Agent queue rules Agent schedule data objects

Agent queue rules instances of Rule-Agent-Queue. These rules specify the

activities the agent runs and the interval, in seconds, at which it runs them. There can be no more than one agent queue rule in a RuleSet.

Agent schedule data objects instances of Data-Agent-Queue. Process Commander

generates these schedules for each node in the system, based on the settings in the agent queue rule. For each agent queue rule, one agent schedule is generated for each node in the system.

Two built-in master agents are background processes operating on each Process

Commander node that manage requestor sessions and agents defined through agents rules and agent schedule data instances. They are not defined by agents rules. (Technically, these are daemons, rather than full agents.)

The Master-for-Requestors (Requestor Manager) master agent monitors idle

requestor sessions to enforce automatic timeouts. By default, this occurs every 60 seconds. Your site can establish another value in the prconfig.xml file setting:

The Master-for-Agents (Agent Manager) master agent starts and monitors agents defined through agents rules and agent schedule data instances. By default, the Master-for-Agents master agent awakes every ten minutes. Your site can establish another value in the prconfig.xml file setting: where NNN is in seconds.

Process Commander relies on two standard agents:

Pega-ProCom Pega-RULES If your system is using the PegaDISTRIBUTION Manager application, Process

Commander also uses the Pega-IntSvcs agent.

25

The Pega-ProCom agent queue rule is configured to run two activities by default and two additional activities if you enable them: ProcessServiceLevelEvents compares the current time to the times specified as

the goals, deadlines, and late times of the current assignments. This activity is enabled by default and it runs every 30 seconds.

SendCorr sends notify messages to users about assignments and outgoing correspondence to work parties. This activity is enabled by default and runs every 30 seconds.

Email_CheckIncoming checks the inboxes of any incoming e-mail accounts that have been configured and if it finds messages, routes them according to the settings in the e-mail account. When enabled, it runs once every 30 seconds.

GetConvertedPDFsFromPDM checks the PDM Requests table to see if any Word documents have been converted to PDF files. You enable this activity only if you are using PegaDISTRIBUTION Manager and you want to use it to convert Word files attached to work objects into PDF files

The PegaRULES agent queue is configured to run three activities by default:

SystemCleaner removes stale entries from system caches once a day. SystemPulse synchronizes the system caches once every minute. SystemIndexer generates and updates the indexes that support the Find feature

once every minute. Agent vs. Activity Because the processing of an agent is completed through activities, the term agent

sometimes refers to the agent (the rule and/or the data object) and sometimes it refers to an activity the agent runs.

For example, sometimes the ProcessServiceLevelEvents activity is referred to as the

SLA agent. In another example, typically the SystemPulse activity run by the Pega-RULES agent is called, simply, the System Pulse.

Additionally, the Agent Management page in the System Management application

lists each activity specified in an agent queue rule as a separate entry. On that page, the term agent means an agent activity and queue means agent queue rule.

26

Interacting with the Database Persistence A persistent object is an object instance that was saved from a requestor's clipboard

into the PegaRULES database. It can be accessed and used by others requestors and remains in the database after the requestor session ends.

An object that is stored in the PegaRULES database is persistent. The object is available to other users, and remains after the requestor session that created it ends.

Q. What methods store persistent data objects in PegaRules database? a) Obj-List b) Obj-Save c) RDB-Commit d) None of the above

Q. The pages become persistent when they belong to both concrete and abstract classes. True False

The rules, transactions, and other data supporting a Process Commander system are

stored in one or more Oracle, IBM DB2 or Microsoft SQL Server databases. Q. The rule is an instance of concrete class only. True False

Classes that are mapped to the PegaRULES database are known as internal classes.

Concrete classes that correspond to rows of an external database are known as external classes. The Data-Admin-DB-Name class contains database data instances. Database data instances are always stored as rows of the pr4_base table

JDBC Connection Pool to use a connection pool defined by a Java Naming and

Directory Interface (JNDI) facility. Process Commander may open more than one connection to a database. When using WebSphere's pooled connection facility, a general guideline for production systems is to set the maximum number of connections for the PegaRULES database to about one-third to one-fifth of the number of simultaneous requestors and adjust the PegaRULES database settings to allow the same number of connections.

Note: Don't forget to count listeners and agents as requestors.

Database settings in prconfig.xml are as below:

27

Q. If the Database connections limit exceeds then what error will be thrown by PRPC? a) SQL exception b) Java Database exception c) Page level error d) None of the above

Q. What alert will be set to detect long database call waits? a) PEGA0001 b) PEGA0014 c) PEGA0026 d) PEGA0023

Sybase databases are accessible only through Connect SQL rules. Sybase is not

supported as a host for the PegaRULES database. If your PegaRULES database is hosted by Oracle 9, the Type 2 (OCI or thick client) driver is required; the thin client (Type 4) works with Oracle 10g.

Use Connect SQL rules (Rule-Connect-SQL rule type) to access relational databases other than the PegaRULES database. Tables and views in the PegaRULES relational database become visible through Database Table instances (Data-Admin-DB-Table).

Q. Do we need to undeploy and redeploy the PRPC configuration file prconfig.xml after any changes to Database setting? True False

Q. Which background process will save the User pages in PRPC? a) Clipboard b) Passivation daemon

Obj-Save method: Use this method to request that the system save a clipboard page

to the PegaRULES database or (if the page belongs to an external class) an external database. We can reverse the effect of an Obj-Save method if it has not yet been committed with the Obj-Save-Cancel or the Rollback method. It specifies that an object should be saved. By default, Obj-Save sets up a deferred write operation that does not occur until the next commit operation executes.

28

Using Obj-Save method system examines the page's pxObjClass property to determine its class. It uses the corresponding Rule-Obj-Class instance to find the Database Table name, Lock Key format, and so on.

Q. Can we save a page that is locked by another requestor? Yes No Q. We cannot save a page that your session does not hold a lock on True False Q. We cannot save pages of any class derived from the Code- base class or the Embed- base class. Such pages exist only on the clipboard. True False

Commit method: Use this method to commit all uncommitted database changes.

This method writes all the instances specified by one or more earlier Obj-Save methods to the PegaRULES database (for internal classes) and to external databases (for external classes). The Commit method operates on Thread pages. The Commit method has no parameters. Specifies that all operations currently on Process Commander's deferred operations list be written to the database. If any of the operations fail, the commit will end in a rollback: all the operations will be rolled back.

In a J2EE application server setting, the JTA transaction aspects of this method

depend on how the Process Commander system is deployed. If your system is deployed appropriately in the Enterprise tier of a J2EE application server, a Commit operation can be processed as a full Java Transaction API (JTA) transaction. This is useful when objects are saved to more than one database.

For example a single Commit operation may update both the PegaRULES database and an external database (made visible through the External Database Table wizard).

Obj-Save-Cancel: Use this method to cancel the most recent uncommitted Obj-Save

method, so that the instance is not written as part of a later Commit operation. You can also use this method to undo an Obj-Delete that has not yet been committed.

Rollback method: Use this method to cancel or withdraw any previous uncommitted

changes to the PegaRULES database (and to external databases accessed from an external class) from the current Thread. All pending Obj-Save and Obj-Delete methods are cancelled. Specifies that all operations currently on Process Commander's deferred operations list should be removed, or rolled back. Any objects with locks specified as ReleaseOnCommit are released with a rollback operation.

29

Generally speaking, activities that commit objects use the following pattern:

1. Commit the deferred operations list. 2. Evaluate the results of the commit step. 3. If the commit failed:

Report errors to the clipboard page and to the Pega log. Roll back the operations.

The Work-.commitWithErrorHandling activity also illustrates how to report errors when a commit operation fails.

Transaction Model The applications need to participate in distributed transactions, Process Commander

must be deployed as an enterprise application and must use a JDBC driver with XA support.

Q. What is the default transaction model of Process Commander? a) Bean-Managed b) Container-Managed

Bean-Managed transaction: When running in this mode, Process Commander is in

charge of the (distributed) transaction. Process Commander issues the begin statement and the final commit or rollback.

Container-Managed transaction: When running in this mode, an external J2EE

container starts and ends distributed transactions that Process Commander joins as one of the participating resources. When Process Commander finishes its work, it submits a list of operations to the resource manager(s) or it marks the transaction for rollback. Only the processing managed by certain Process Commander Service rule types (EJB, Java, and JMS) can participate in container-managed transactions.

Deferred Operations Model This method does not always cause the object to be written immediately to the

database. Often, developers use this method perform a deferred write operation. In such cases, later execution of the Commit method, in the same Thread, completes the database update.

The standard HTML rule @baseclass.DeferredOps interrogates system internals and

presents an ordered list of deferred (uncommitted) database operations for the current Thread. In addition to the object locking feature, Process Commander ensures data integrity by creating a deferred operations list during a business transaction rather than writing each change to the database individually.

30

Locking Object locking for work objects is enabled by default. Object locks are associated

with users' requestors. Requestors obtain a lock on a work or other object when the user opens an object for modification. While the requestor holds the object lock, no other requestor can make changes to that object. After the processing of the application causes the changes to be written to the database, the lock is released and the object is available to another requestor.

Object locks have a timeout interval that is set to 120 minutes by default.

Mechanisms provided by your database management system that control how/whether

operations access data at the same time. Database locking provides functionality such as preventing two write operations from committing changes to the same row at the same time.

A Java object that holds information about a user and that user's session. In Process

Commander, users are represented as requestors and object locks are associated with a user's requestor.

When selected, ReleaseOnCommit parameter instructs Process Commander to release the object lock on the item being opened when changes for the object are committed to the database.

Threading Model A PegaRULES Thread object is a named context of clipboard pages. Most processing

for a requestor is single-threaded. The first Thread for a requestor is named STANDARD. The pxThread page is a named top-level clipboard page sometimes referred to as the thread page. The class for the page is Code-Pega-Thread.

Q. What is Pega alert in case of number of threads exceed the limits? a) PEGA0011 b) PEGA0018 c) PEGA0026

A requestor can have multiple Threads, but the Threads are guaranteed to never run

concurrently. A daemon is a reserved background Java thread that executes as a BATCH requestor type. Ex: Passivation daemon Saves requestor sessions after timeout or other situations

The PEGA0030 alert is generated when the number of requestors logged onto the system (including agents and services) exceeds the alert threshold.

31

3. Class Structures & Hierarchy Design

32

Organizational Hierarchy

Process Commander supports a three-level organizational hierarchy consisting of organizations at the top level, divisions at a second level, and organization units as a third level. Each user (Operator ID instance) is associated with an organization, division, and unit.

Process Commander Application, group organizational data hierarchically, using

nested levels of organization, division and unit. The following structure shows a sample organizational hierarchy with one organization, three divisions, and four units.

Top Level: Organization - identifies the company entity. Second Level: Division - identifies the highest-level entities of the company. For

example, you might use the structure of your company's senior management team as a starting place for division-level entities.

Lowest Level: Unit - identifies the most specific level at which organization information is recorded (a cost center, for example).

Basic Organizational Hierarchy

When a user log in with an operator ID, their organizational affiliations grant them appropriate RuleSet access. The ID also identifies two additional affiliations: work group and access group.

Work Groups - Users and the work they do are tied to work groups, which fall

below units in an extended organizational hierarchy. Users working on a common set of items generally belong to a single work group.

Access groups - Users' application permissions, portal layout, and accessible work are controlled by access groups. Access groups may span multiple work groups, and typically mirror Process Commander job functions.

33

Example: The following Hierarchy shows an extended organizational hierarchy. The North America and Asia divisions each have Marketing and Sales units; each Marketing unit, in turn, has Marketing Communications and Product Management work groups. All work group managers are afforded additional privileges by belonging to the Managers access group.

Extended Organizational Hierarchy

34

Reusability is the ability for PRPC to share the same instance of a rule, RuleSet, and/or service so that it can be reused by other portions of the same application and/or other applications. Some examples of reuse that we see in PRPC are:

The Add activity defined at Work- that can be can be reused by many applications as-is without customization

Utility functions that are defined in a shared RuleSet so that they can be reused by multiple applications

The class structure provides you with a hierarchy in which rules can be placed. The higher a rule is in the hierarchy, the more potential reuse there is. However, a rule can only reference other rules at the same level in the hierarchy or higher. For example, a rule X at class A- cannot call Rule Y defined at A-B if no rule Y exists at A-.

Implementation Class vs. Framework Class:

An implementation class is a class that belongs to RuleSet that is one of your application RuleSets. Classes for the implementation are sometimes called the implementation layer.

A framework class is a class that belongs to RuleSet that is not one of your application RuleSets. Classes associated with the framework are sometimes called the framework layer. Example: Typically, work objects belong only to implementation classes (work types). To simplify, develop a list view and summary view reports. You can define reports in framework classes that, at runtime, execute with the corresponding implementation classes.

35

Class

Class defines capabilities (rules such as properties, activities, HTML forms, and so on) available to other, subordinate classes, or to instances of the class.

Classes are organized into a hierarchy. The ultimate base class named @baseclass is

at the top (or left). The base classes Data-, Rule-, Work- and others are immediate child classes of the ultimate base class. Other classes are derived from the base classes. Classes can be either Abstract or Concrete.

Abstract class cannot have any instances, appears at the top level of the class

hierarchy. An abstract class is a rule (an instance of the Rule-Obj-Class class) created to support the definition of rules, including other classes. A dash or minus character "-" as the last character in the class name indicates an abstract class.

A Concrete class, near or at the bottom of a class hierarchy can have instances

stored in the database. Concrete classes corresponding to instances saved in the PegaRULES database are

known as internal classes Concrete classes corresponding to a table in an external relational database (rather

than the PegaRULES database) are known as external classes.

Concrete class that is a class group:

36

Concrete class that belongs to a class group:

Concrete classes derived from the Rule- base class are known as rule types and those derived from the Work- base class are known as work types. Concrete classes dont end with a (dash).

The Rule- class and Work-Cover- class are abstract classes, while Work-Cover-General is a concrete class.

Custom classes that are immediate child classes of the ultimate base class are known as top-level classes. These are different from base classes.

Inheritance is a primary benefit of object oriented technology. Process Commander

offers multiple types of inheritance that can maximize reuse of your rules while allowing localized overriding as appropriate.

Inheritance allows a rule created for one class (possibly an abstract class) to be

applied to other classes that inherit from it. RuleSet version inheritance works using three-level version numbers. For

example, users who have a version 02-15-06 in their RuleSet list inherit rules in version 02-15-05, when no rule instance exists in 02-15-06.

RuleSet inheritance arises through the order of RuleSet names in the user's RuleSet list. Rule instances in a RuleSet at the top of the RuleSet list supersede others of the same name.

Organizational inheritance is implemented through a four-level assembly of privileges and RuleSet versions through the access group, organization unit, division, and organization.

Class inheritance searches for rules from a concrete, lower class, up the class hierarchy to find available rules.

37

Class inheritance uses a sophisticated algorithm to find the parent classes of a specific

class. Two types of class inheritance directed inheritance and pattern inheritance are available Directed inheritance allows naming a class choosing a name that's not related to

its parent's name. Pattern inheritance the name of the parent class is a prefix portion of the name of

the class, based on the dash (-) characters.

A class group instance causes the system to store the instances corresponding to two or more concrete classes that share a common key format in a single database table.

Class groups are primarily used to group a set of related subclasses of the Work- base

class; such class groups are also known as work pools.

The following benefits of having class group:

All instances of classes that are associated with a class group share a common key definition and common lock definition. This allows the database to save the instances as rows in one table in the PegaRULES database.

The common key format also ensures that the same database table is accessed when an instance is converted from one class (within a class group) to another class (in that same class group). For example, a work object may initially be entered incorrectly as a merchandise order, but later be reclassified as a merchandise return request. Both work types have the same key structure and belong to a common work pool (class group).

38

Class groups can help with database table management, backup, space, and reporting.

A work object is a primary unit of work completion in an application, and a primary

collection of data that a flow operates on. As an application is used, the work objects are created, updated and eventually closed i.e. it will be resolved. Every work object has a unique ID (property pyID), an urgency value, and a status (property pyStatusWork).

A work object ID is a permanent, external identifier of a work object, the value of property pyID. This value has an optional prefix portion, a number, and an optional suffix portion and is unique system-wide.

The standard activity named Work-.GenerateID uses the standard properties pyWorkIDPrefix and pyWorkIDSuffix in its computation. By convention, an ordinary work object ID has a prefix of W-nnnnn and no suffix, so W-9432 identifies such an object. Conventionally, a cover object ID has the format C-nnnnnn, and a folder object has the format F-nnnnn, where nnnnn is a system-assigned decimal number. Normally the system assigns a work object ID automatically as it creates a work object, using a prefix set in the model rule of the work type or work pool

The internal class Data-UniqueID supports work object numbering, and ensures that

work object IDs are unique system-wide, not just within an application or organization. The property Data-UniqueID.pyPrefix holds the prefix and is the key to instances of this class. The integer property Data-UniqueID.pyLastReservedID holds the highest assigned number. The property Data-UniqueID.pyOrganization, a key part, is not filled in by standard rules. This property value is left blank so that work object IDs are unique system-wide.

The Work Object ID is stored in the pc_data_uniqeid table. The standard property Work-.pyStatusWork defines whether the work object is

open or resolved. The value of this property is a primary indicator of the progress of the object towards resolution. Values are restricted and controlled, and are changed only through specific mechanisms.

Resolved work objects identify completed work and are ordinarily not modified by

any further processing, unless the work object is re-opened. The following are the standard work object statuses available: New not yet reviewed or qualified Open responsibility for processing is with the processing organization Pending responsibility for processing is currently with an external organization Resolved-Duplicate resolved, as judged to be a duplicate of another work

object Resolved-Rejected resolved, not accepted Resolved-Complete resolved, work completed

39

The HTML property rule WorkStatus supports localization of the status value on

displays, through field value rules.

Clipboard Viewer:

40

The Work- base class, one of thirteen standard top level abstract classes, is a superclass to all the classes that define work objects.

Properties, HTML forms, and flows in the Work- class are available to support the

behavior and appearance of all types of work objects, including Ordinary work objects, typically belonging to the a class derived from the

standard abstract class Work-Object- Covers, typically belonging to a concrete class derived from the Work-Cover-

class Folders, typically belonging to a concrete class derived from the Work-Folder-

class

The external key to all Work- instances is recorded in the pyID property, and typically consists of an alphabetic prefix, a dash, and an arbitrary but unique number.

Through directed inheritance, a subclass of the Work- base class may have a name

that does not begin with "Work." For example, the class PegaSample-CustomerRequest, part of the sample application, is a work type.

41

Questions:

Q1) In designing a class structure for an application, what should the first step be? a. Identify primary users b. Identify systems that the application will be interfacing with c. Identify major units of completed work d. Identify the key tasks that the application will perform Q2) In a class a. Both Pattern Inheritance and Directed Inheritance should be selected b. Pattern Inheritance is mandatory c. Directed Inheritance is mandatory d. Neither Pattern or Directed are selected Q3) In describing class inheritance in PegaRULES Process Commander, which of the following statements is false? a. Directed inheritance causes a class to inherit characteristics directly from the

specified parent class, regardless of any defined pattern inheritance. b. Pattern inheritance causes a class to inherit characteristics from classes that it

resembles, moving up the pattern class hierarchy. c. In pattern inheritance dashes are the delimiters for pattern matching. d. The developer must specify pattern inheritance; directed inheritance is optional

and if specified, takes precedence. Q4) Consider the following Data Tables and their classes Class Data Table Data- pr_data Data-Admin- pr_data_admin Data-Admin-XYZ pr_XYZ Acme- acme Now a class Acme-Data-ABC is created which directly inherits from Data- and a data table that belongs to this class is created. Five rows are added to this. In which of the above data tables are these five rows included a. pr_data b. pr_data_admin c. pr_XYZ d. pr_other e. acme

42

Q6) Which one of the following defines a work-pool a. Work-Group b. Work-Basket c. Class-Group d. Class-Pool Q7) About Concrete class (select 3) a. Must end with - b. It belongs to class group c. It may be a class group d. Must inherit from abstract class e. Have instances Q8) Class group should inherit from a. @baseclass b. Work- c. Work- Object- d. Work- Folder- e. Work- Cover- Q9) A concrete class which ends the Work- class like MyCo-HR-Loan-Work- means, a. Indicates the Class Group b. Indicates the Work Pool c. Developer can derive the Work- class Q10) Which type of inheritance allows the name of the parent class to be a prefix portion of the name of the class. a. pattern b. directed c. direct d. all the above. Q11) A top-level class a. Inherits from @baseclass b. Inherits from Work- c. Contains most of your business logic d. Is usually the same as a bottom level class Q12) Which of the following is not true a. Classes that end in - must be abstract b. Abstract classes can not have instances c. Concrete classes must belong to a class group d. A class group must always have at least one key

43

Q13) A class group a. Is any set of related work objects b. Causes the system to store the instances corresponding to two or more concrete

classes that have a common key format in a single database table c. Is unrelated to your applications requirements Q14) An implementation class is a class a. that belongs to RuleSet that is one of your application RuleSets. b. that belongs to RuleSet that is not one of your application RuleSets.

Q15) Concrete classes corresponding to instances saved in the PegaRULES database are known as a. Internal Class b. External Class c. Class Group d. None of the above. Q16) Concrete classes corresponding to a table in an external relational database (rather than the PegaRULES database) are known as a. Internal Class b. External Class c. Class Group d. None of the above. Q17) The standard property that defines whether the work object is open or resolved. a. Work-.pyStatusWork b. Work-.pyID c. StatusWorkObject d. WorkObjectStatus. Q18) The Work Object ID is stored in the a. pc_data table. b. pc_data_uniqeid table. c. pr_data d. pcv4_work_history

44

4. Data Modeling

45

Properties A property rule provides a name and characteristics for data in an object. Because a

property definition is a rule, it shares the benefits of versioning, inheritance, and access control that Process Commander provides to all rules. Properties are used to hold data in work objects, so it can be apart of your application Rule Set.

A property is an instance of the Rule-Obj-Property rule type. There are three types

of standard properties stating with the Index px, py, and pz.

Properties starting with px are computed properties that user can see on a form, but cant directly enter the values or change.

Properties starting with py can be used by the user or developer to enter or change via direct input

Properties starting with pz are reserved for internal process commander use. User cant see, enter or change the values of these properties.

Property Types Properties can be used in different types to determine the kind of data that values of

the property represent. There are 11 different types in the representation of a single property.

Types: Text, Identifier, Password, Integer, Double, Decimal, Date, DateTime, TimeofDay, TrueFalse, TextEncrypted.

Property modes are used to determine how the system represents the property data.

Every property has one of eleven property modes. This is a permanent feature of a property that cannot be changed after you save a property rule. The simplest

46

property mode is Single Value. A Single Value property contains text that can represent HTML, a date or time, an identifier, a number, or a Boolean true/false value.

Properties with a mode other than Single Value are known as aggregate properties.

All eleven properties modes can be divided into four categories based on the representation of the property data. The major categories are Value modes, Page modes, Java Object mode, and Java Property modes.

Value mode identify properties that can have none, one, or multiple strings as the

value: Single Value: Select Single Value to create a property that can contain a Single

text string value. Text, numbers, dates, Boolean values and amounts are stored in Single Value mode properties.

Value List: A Value List mode is an ordered, indexed list of strings, sometimes called an array.

Value Group: A Value Group mode contains one or multiple strings, in unordered manner and each identified by a unique text index value.

Page mode identifies properties for which the value has a single or multiple page

structure. Page: Page is a data structure that contains name-value pairs. Page List: A Page List mode property is a data structure consisting of an

ordered list of zero or more embedded pages, each identified by an integer index. Page Group: A Page Group is a data structure consisting of an unordered set of

pages, each identified by a string index value.

47

Java Object mode contains a reference to an instance of a Java object.

Java Object: Java Object is selected to indicate that this property holds on the clipboard a reference to an instance of a Java object.

Java Object List: Select Java Object List to indicate that this property can contain an array of Java objects.

Java Object Group: Java Object Group is selected to indicate that this property can contain an unordered group of references to instances of Java objects.

Java Property mode support the Java pages feature, which enables Process

Commander applications to interact with external Java objects as though they were pages and properties on the clipboard.: Java Property: A property rule provides a name and characteristics for data in an

object. Because a property definition is a rule, it shares the benefits of versioning, inheritance, and access control that Process Commander provides to all rules. Properties are used to hold data in work objects, so it can be apart of your application Rule Set.

Java Property List: Supports the Process Commander Java pages feature that enables your application to interact with Java objects as though they were pages and properties on the clipboard. Java Property List is selected to indicate that this property represents an array property of a Java class that defines an external Java object.

Using Prompts in Property we can define optional table edits for Single Value,

Value List and Value Group properties by enumerating the values that the property can assume, or identifying a place where a list of values is available at runtime.

There are six types of table edits. They are

1. None No table edits apply. 2. Local List Values are enumerated in this tab. 3. Field Value Values correspond to field value rules. 4. Class Key Value Values correspond to the first key parts of a known other

class. 5. Remote List Values are enumerated as elements of a List or Group within

a single Process Commander object. 6. Prompt List Values are enumerated as with a Local List, but for each

internal value, a different localized value appears on input or output. An embedded page is a clipboard page that has the value of a property of mode

Page. Any page on the clipboard that is not a top-level page is an embedded page. Process Commander uses a recursive page structure. Pages contain properties that can have single or multiple pages as their values.

48

Properties wizard are used to create one or more property rules with a common Applies To class by completing a single form. This is used only when to create several properties, using this wizard the all properties can be created faster than completing the Property form for each property.

Data Table Developers can use the Data Table editor to add, update, or delete instances of a

concrete class derived from the Data- class for which no form is defined, or other classes for which an Excel template rule is defined. This facility allows easy entry and maintenance of data instances for classes that have a simple structure.

Select Application > Data Tables to access a list of existing Data Tables in your

system. Click Add at the bottom of the form to create a new data table. We Can use the wizard to create an edit form for any class that meets these

requirements: Derived from the Data- base class Contains only properties of mode Single Value Does not require user input for properties inherited from any higher classes Contains a Single Value property that defines a unique key

If you add a property (column) to a previously created data table, you must open and

update the list rule (Rule-Obj-List rule type) to have the new property available to the Data Table editor. After generating the data table, edit the data table to enter the required data.

49

How to use data tables?

To make references using data tables: 1. Create a Data-Zzzzzz class. 2. In an activity, perform an Obj-Open on the instance that contains your system

details. 3. Pass the value into your application.

Model A model rule defines initial values for properties of a specific class. A model can be

applied to a new empty page of that class to set many property values in one processing step. Model is an instance of Rule-Obj-Model.

Using a model, the value of multiple properties can be easily to zero, to the null

string, to True or False, to a computed value such as today's date or the current time, a copied value such as your Operator ID, and so on. By convention, a model named pyDefault is available for most standard classes.

Using a model the value of multiple properties can be easily set to required values,

rather than setting the property values one-by-one in an activity, this improves runtime performance. Using a model also speeds development, because you can set values for many properties quickly.

Flow rules that create work objects use a model rule for a Work- class to set

initial properties for the work object. In Definition Tab of Model specify a target property or property reference to be initialized with the initial values.

Superclass Model causes the system at runtime to apply a model of the immediate

parent of this model's class with the same Model Name before it applies this model. Linking together several models is called as model chaining. Process Commander identifies the superclass to be called at the time you save the Model rule form, not at runtime.

Important Points

1. Process Commander identifies the parent of the current class using the Parent field in the class definition, not by following full class hierarchy searches

2. After identifying a parent class, the system uses rule resolution to find the model of the same name as the current model.

3. The model in the highest class is applied first. The current model is applied last.

50

5. Process Flow

51

Process Flow

Process Commander associates a flow rule with a Microsoft Visio diagram, which graphically represents a process. The diagram contains a network of shapes (tasks) and connectors (arrows).

A flow rule defines a business process or part of a business process. A flow rule

governs how work objects are created, progress through the system, and become resolved. A flow rule consists of a network of shapes and connectors (lines), each with associated parameters and values.

A flow rule is an instance of the Rule-Obj-Flow rule type. Flow rules are normally stored in

the PegaRULES database as rows of the pr4_rule_flow table. A work object is the primary unit of work completion in an application, and the

primary collection of data that a flow operates on. As an application is used, work objects are created, updated, and eventually resolved. Every work object has a unique ID, an urgency value, and a status.

A temporary work object is a work object that is created and resolved by a single

operator or through straight-through processing and never saved as a database object. To create a temporary work object, select the Creates temporary object checkbox in the flow that creates the object. Temporary work objects can be used in screen flows and regular flows.

Some of the features like reporting, history, and attachments are not available for

temporary work objects. Also the below points are important in terms of temporary work object: Temporary work objects do not have a work object ID. Temporary work objects cannot be members of a cover. The Where-Am-I? Display is not available for temporary work objects. History additions performed on such objects do not cause a flow to fail, but have

no effect.

Flow Editor Toolbar button ( ) is used to start Microsoft Visio 2002/2003 and edit

the flow. Click the Return button ( ) when you complete Visio editing. List of Flow shapes

FlowStart Identifies the start task of this flow. Every flow has one Start shape.

52

Connector Associates a task in the flow with another that may follow the first task. Connectors leaving assignment tasks may be flow actions. Connectors leaving other tasks such as decision or utility shapes may be when conditions.

Assignment Creates an assignment task associated with work object in a workbasket or worklist. The task must be completed by a person or the system before the flow can progress. It represents a pause or potential pause in the flow.

Optionally, after the assignment task is defined, you can associate a service level rule with it. A clock appears on the diagram, as shown here.

Utility Specifies an activity to run at that point in the flow to perform automated processing without any user assignment.

Fork Supports automatic selection of one connector from two or more.

Decision Identifies an activity that can make an automated decision about the progress of the work object through this flow.

Flow Identifies a subflow, which is a flow rule that is referenced in another flow. For example, add a Flow shape to your flow rule to start another flow and end processing of the current flow. The second flow is called a subflow of the first flow.

Router Sends an assignment to a user, workbasket, or agent other than the current user. Associate a Router task with an assignment task. This activity determines which worklist or workbasket is to contain the assignment.

Notification Notifies a work party by e-mail or correspondence about the status or progress of this work object as the assignment is created.

Comment Adds explanatory text comments anywhere on the flow diagram. Comments do not affect execution of the flow.

Ticket Marks a business exception that might arise at any point in the flow, such as a cancellation.

Integrator Identifies an activity that can connect to an external system to send or receive data.

Assignment-Service Passes control to an external system (for example, using a Connect BPEL rule). Flow execution pauses until Process Commander receives a service request of the appropriate type.

Spin-off Starts a new flow execution and does not wait for its completion.

Split-Join Sends the work object to two other flows, both of which must complete before the current flow resumes.

Split-ForEach Performs an operation or test on each element in a repeating group.

Pools and swim Lanes Identifies and groups tasks performed by separate organizational units within one division.

53

A few standard flow rules, harness rules, flow actions, and section rules are known as

templates. These rules have special characteristics and settings. If the Template field appears on the new dialog, you can select one to use as a base (similar to copying) for this rule. This can save time and typing.

Classic: Creates a flow rule using V4/5.2 shapes. These differ only in appearance

from the standard shapes introduced in V5.3. BPMN: Creates a flow rule using Business Process Modeling Notation and

terminology. CrossFunction: Creates a flow rule consisting entirely of tasks performed by two

or more distinct organization units in one division. See Flow Form Editing in Visio Swim Lanes.

PolicyOverride: Creates a flow rule to support policy override reviews. This flow calls the standard flow named FinishPolicyOverride as a final task.

ScreenFlowBPMN: Creates a screen flow rule using Business Process Modeling Notation and terminology.

ScreenFlowClassic: Creates a screen flow rule a sequence of assignments for one or a set of users that involves no automated processing tasks. Special restrictions apply; see Flow Form Editing in Visio Screen Flow Rules.

ScreenFlowStandard: Creates a screen flow rule using the Process Commander shapes

ScreenFlowStandardTabbed: Creates a screen flow rule using the Process Commander shapes & the tabbed work object forms

Standard: : Creates a Standard flow rule using the Process Commander shapes

A standard Business Process Modeling Notation (BPMN) will provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner.

Types of flows A flow rule that contains no assignments, and so can execute from start to end

without human input, is known as a straight-through process. A flow rule that contains assignments that apply only for unusual, rare situations also can be considered straight.

A flow rule that consists only of assignments or decisions and meets other criteria is

known as a screen flow. After submitting a form, the user is presented with another simple form (with more questions) that may depend on previous answers. At any point, the user can backtrack to review, or change, previous answers. Process Commander flow rules can support such interactions in Screen Flow mode.

A flow that creates a new work object is called a starter flow.

54

A flow that is called by another flow is known as a subflow, the calling flow is called

parent flow. Processing of a subflow is synchronous, meaning that the calling flow execution pauses for the duration of the subflow. A subflow, also called a subprocess, that is referenced in another flow rule, so that execution of the other rule may start execution of the subflow.

Description of Flow Shapes:

Every flow rule has a single Start shape ( ) with no incoming connectors. This marks the first shape of every execution of the flow rule. When you create a flow, the Start shape is already present. You rarely need to alter the Start Properties panel. You can enter or revise these fields:

Use comments to document your flow on the Visio diagram. Comments ( ) have no effect on processing.Drag and drop a comment symbol and type in your comment text.

A flow may contain none, one, or multiple FlowEnd shapes. When processing

reaches ( ) this shape, no further processing by this flow rule occurs. If this flow was called as a sub flow by another flow, processing continues in the calling flow. The work object may remain open when it advances to a FlowEnd shape. Processing in a separate flow may advance the work object farther toward eventual resolution. Flow processing automatically saves the work object (using the Obj-Save method) when a FlowEnd shape is reached, unless the work object is temporary.

Use the Ticket shape ( ) to mark the starting point for exceptions that may arise at any point in the flow, such as a cancellation. The ticket is a label for a point in a flow, much like a programming "GOTO" destination. An activity executing anywhere in your entire Process Commander application can set or raise this ticket by executing the Obj-Set-Tickets method with this ticket name as a parameter. A raised ticket causes the system to search for any executing flow (on the same or a different work object) that contains this ticket. If found, processing stops on that flow promptly, and resumes at the ticket point.

55

Connect a Notify shape ( ) to an assignment to cause your flow rule to send correspondence to a work party (identified in the work object) reflecting the creation of the assignment instance. Rule: Select a Notify activity. See Standard activities for flows for descriptions of a few Notify activities. The Notify shape attaches to the bottom of the Assignment shape. However, the activity associated with the notify task runs when the system creates the assignment, not later when the assignment is performed.

These standard Work- activities have an Activity Type of Notify. They can be used in

the Notify task, represented by the Notify shape ( ). Notify: Send an e-mail message as correspondence to a party identified through a

parameter. NotifyAll: Send a single e-mail message to each work party identified in the work

object. NotifyAssignee: Send an e-mail message to the Process Commander user who

received the assignment. If the assignment is in a workbasket rather than a worklist, an e-mail message goes to the first operator listed in the Contacts array of the Workbasket tab.

NotifyParty: Send an e-mail message as correspondence to a party identified through a parameter, but only send when a threshold urgency level is reached or exceeded.

NotifyAllAssignees: Send an e-mail message to the Process Commander user who received the assignment. If the assignment is in a workbasket rather than a worklist, an e-mail message is sent to each operator listed in the Contacts array.

Use the Assignment Service task

( ) in a flow to pass control to an external system using a connector (for example, Connect BPEL rule). Assignment Service tasks support asynchronous coordination with external systems, in contrast to the Integrator tasks, which support synchronous connections. Connect at least one incoming connector and at least one outgoing connector to the shape.

56

Use the fork shape ( ) to represent a point where the flow execution chooses one of a few different paths (connectors) based on tests on the work object. At runtime, the system evaluates the conditions on each outgoing connector, starting with the connector assigned the highest likelihood. The flow execution continues along the first connector that evaluates to True.

A router ( ) activity determines which workbasket, worklist, or agent is to receives an assignment. Associate a router activity with each assignment, unless the assignment is always to appear on the worklist of the current user (the one who is currently executing the flow rule).Rule: Select a router activity that determines which workbasket or operator worklist is to receive the assignment. See Standard activities for flows to read about a few standard router activities.

A utility task ( ) is an activity that can

update a work object without human input. It may perform computations, searches, retrieve data from another system, and make a decision affecting the course of the flow, and so on. Rule: Select a Utility activity to be executed when a flow execution reaches this shape. See Standard Activities for Flows for descriptions of a few standard Utility activities.Work Type: Select the name of the work type for the application that you want to link to the flow shape. The value of this field is referenced with the flow diagram in application documents.

Use the Decision task ( ) to reference a map value rule, decision table rule, decision tree rule or a Boolean expression that when evaluated produces a value that is the basis of branching in the flow.At runtime, the system evaluates the decision rule based on inputs from the flow and the work object, and chooses one of the outgoing connectors based on the result. No user interaction or input is required.Choose a decision rule Type: Map

57

Value, Decision Tree, Decision Table or Boolean Expression. Type: Map Value or Decision Tree or Decision Table or Boolean Expression. Rule: Select a map value rule, identified by the second key part.

An Integrator task ( ) identifies an activity that connects your Process Commander system to an external system to send or receive data. Integrator tasks use activities (with Connect as the Activity Type) that call connector rules (Rule-Connect- rule types). Rule: Select an activity with an Activity Type of Connect. Work Type: Select the name of the work type for the application that you want to link to the flow shape. The value of this field is referenced with the flow diagram in application documents. Service Level: Optional. Select a service level rule to apply to this task. For example, a service level can cause escalation processing when no response is