bootcamp

Designing Your Application with SmartBuild

PegaRULES Process Commander

© Copyright 2005 Pegasystems Inc., Cambridge, MA

All rights reserved.

This document and the software describe products and services of Pegasystems Inc. It may contain trade secrets and proprietary information. This information should not be disclosed to third parties unless otherwise provided for by a contract or business agreement with Pegasystems. This document and the software are protected by federal copyright law, international laws, and/or applicable treaties.

This document is current as of the date of publication only. Changes in the document may be made from time to time at the discretion of Pegasystems. This document remains the property of Pegasystems and must be returned to it upon request. This document does not imply any commitment to offer or deliver the products or services provided.

This document may include references to Pegasystems product features that have not been licensed by your company. If you have questions about whether a particular capability is included in your installation, please consult your Pegasystems service consultant.

Other brand or product names are trademarks of their respective holders.

This document is the property of: Pegasystems Inc. 101 Main Street Cambridge, MA 02142-1590 (617) 374-9600, fax: (617) 374-9620 www.pega.com PegaRULES Process Commander Document: Designing Your Application with SmartBuild Software Version 4.2 SP2 SmartBuild Print Date: April 2005 Order #: @DPCDESB02

Overview

Before You Begin .....................................................................................................................1 Step 1: Roadmap to Building a Process Commander Application ...................................1-1 Step 2: Analyzing Requirements..........................................................................................2-1 Step 3: Getting Started — Prerequisites and Setup ...........................................................3-1 Step 4: Designing the Class Structure ................................................................................4-1 Step 5: Building the Class Structure and Reviewing Work Objects .................................5-1 Step 6: Adding Properties and Sample Data.......................................................................6-1 Step 7: Tailoring the User Interface .....................................................................................7-1 Step 8: Designing Flows and Identifying Flow Actions .....................................................8-1 Step 9: Creating Flow Rules and Adding Process Details.................................................9-1 Step 10: Adding Communications Capabilities ................................................................10-1 Step 11: Setting Up Access and Security..........................................................................11-1 Step 12: Configuring System Interfaces and the PegaRULES Database .......................12-1 Step 13: Deploying and Evolving Your Application .........................................................13-1 Step 14: Leveraging Reports and Quality Features .........................................................14-1 Quick Reference to Essential Design Principles ...............................................................A-1 Contacting Pegasystems.....................................................................................................B-1

iv Contents

Contents

Before You Begin .....................................................................................................................1 Who Should Read This Book ..............................................................................................2

Step 1: Roadmap to Building a Process Commander Application ...................................1-1 Identifying Application Opportunities ................................................................................1-2 Using SmartBuild — Smart Design for Smart Systems....................................................1-4 Understanding the Process Commander Object Model .................................................1-10 Identifying Components of an Application ......................................................................1-11 Understanding Process Commander Job Functions ......................................................1-16 Mapping SmartBuild to a Typical Project Structure ........................................................1-20 About the Examples .......................................................................................................1-22 Step 1 Completion Checklist ..........................................................................................1-23

Step 2: Analyzing Requirements..........................................................................................2-1 A Different Approach to Requirements Analysis ..............................................................2-2 What Is the Nature of the Work? ......................................................................................2-3 Who Performs the Work? .................................................................................................2-6 Do You Need to Localize the Solution?..........................................................................2-15 What Are the Major User Scenarios? .............................................................................2-18 Are You Building an Application or a Product?...............................................................2-20 Step 2 Completion Checklist ..........................................................................................2-21

Step 3: Getting Started — Prerequisites and Setup ...........................................................3-1 Using the Development Environment ...............................................................................3-2 Identifying the Top-Level Organization Class...................................................................3-5 Working with the Application Accelerator .........................................................................3-6 Planning RuleSets..........................................................................................................3-10 Creating the RuleSets ....................................................................................................3-15 Creating the Application Parent Class............................................................................3-18 Changing the System Name ..........................................................................................3-20 Configuring the Organization, Access Groups, and Users .............................................3-21 Step 3 Rule Type Reference ..........................................................................................3-25 Step 3 Completion Checklist ..........................................................................................3-27

Contents v

Step 4: Designing the Class Structure ................................................................................4-1 Important Terms and Concepts ........................................................................................4-2 Class Structure Design Process.......................................................................................4-8 Refining the Class Structure...........................................................................................4-17 Identifying Work Pools (Class Groups)...........................................................................4-18 Defining Work Object IDs ...............................................................................................4-20 Determining Work Parties and Sources .........................................................................4-23 Establishing Additional Repeating Groups .....................................................................4-27 Final Class Structure Check...........................................................................................4-30 Step 4 Rules Reference .................................................................................................4-31 Step 4 Completion Checklist ..........................................................................................4-32

Step 5: Building the Class Structure and Reviewing Work Objects .................................5-1 Important Terms and Concepts ........................................................................................5-2 Using the Application Accelerator Approach ....................................................................5-3 Using the Class Rule Form Approach ..............................................................................5-5 Creating a Work Parties Rule.........................................................................................5-10 Entering the First Work Objects .....................................................................................5-13 Step 5 Rules Reference .................................................................................................5-17 Step 5 Completion Checklist ..........................................................................................5-18

Step 6: Adding Properties and Sample Data.......................................................................6-1 Important Terms and Concepts ........................................................................................6-2 Identifying and Creating Application-Specific Properties ..................................................6-3 Creating Model Rules to Initialize Work Object Properties .............................................6-12 Declaring Dependencies Among Properties...................................................................6-17 Creating Application-Specific Data Classes ...................................................................6-27 Simulating Connectors Using Sample Data ...................................................................6-29 Capabilities to Consider in This Step..............................................................................6-31 Step 6 Rules Reference .................................................................................................6-35 Step 6 Completion Checklist ..........................................................................................6-36

vi Contents

Step 7: Tailoring the User Interface .....................................................................................7-1 Important Terms and Concepts ........................................................................................7-2 Selecting a User Access Technique.................................................................................7-4 Benefits of the Built-in, Rules-Driven User Interface ........................................................7-6 Understanding Components of Work Object Forms.........................................................7-8 Tailoring the Standard Forms.........................................................................................7-18 Capabilities to Consider in This Step..............................................................................7-32 Step 7 Rules Reference .................................................................................................7-36 Step 7 Completion Checklist ..........................................................................................7-37

Step 8: Designing Flows and Identifying Flow Actions .....................................................8-1 Important Terms and Concepts ........................................................................................8-2 Introducing Flow Design...................................................................................................8-3 Creating First Flow Shells ................................................................................................8-5 Six Basic Design Shapes ...............................................................................................8-10 Extending and Refining Flow Shells ...............................................................................8-20 Step 8 Completion Checklist ..........................................................................................8-31

Step 9: Creating Flow Rules and Adding Process Details.................................................9-1 Important Terms and Concepts ........................................................................................9-2 A Recommended Approach .............................................................................................9-3 Reviewing the Flow Shapes .............................................................................................9-4 Adding Process Details ..................................................................................................9-12 Verifying the Entry Process ............................................................................................9-28 Step 9 Rules Reference .................................................................................................9-29 Step 9 Completion Checklist ..........................................................................................9-30

Step 10: Adding Communications Capabilities ................................................................10-1 Understanding the Correspondence Model....................................................................10-2 Building Correspondence Capabilities..........................................................................10-10 Capabilities to Consider in This Step............................................................................10-13 Step 10 Rules Reference .............................................................................................10-15 Step 10 Completion Checklist ......................................................................................10-16

Contents vii

Step 11: Setting Up Access and Security..........................................................................11-1 Important Terms and Concepts ......................................................................................11-2 Security Implementation Checklist .................................................................................11-5 Granting Application Access ..........................................................................................11-7 Granting Access to Work Objects and Other Instances ...............................................11-10 Granting Access to Change Application Rules.............................................................11-24 Capabilities to Consider in This Step............................................................................11-26 Step 11 Rules Reference .............................................................................................11-30 Step 11 Completion Checklist ......................................................................................11-32

Step 12: Configuring System Interfaces and the PegaRULES Database .......................12-1 Important Terms and Concepts ......................................................................................12-2 Delivering Services to External Systems........................................................................12-5 Connecting to External Databases and Systems ...........................................................12-7 Capabilities to Consider in This Step............................................................................12-10 Working with the PegaRULES Database .....................................................................12-14 Step 12 Rules Reference .............................................................................................12-17 Step 12 Completion Checklist ......................................................................................12-18

Step 13: Deploying and Evolving Your Application .........................................................13-1 Important Terms and Concepts ......................................................................................13-2 Preparing the Application for Deployment ......................................................................13-3 Deploying the Application...............................................................................................13-7 Evolving the Application ...............................................................................................13-10 Capabilities to Consider in This Step............................................................................13-12 Step 13 Rules Reference .............................................................................................13-14 Step 13 Completion Checklist ......................................................................................13-15

Step 14: Leveraging Reports and Quality Features .........................................................14-1 Important Terms and Concepts ......................................................................................14-2 Business Activity Monitoring Capabilities .......................................................................14-3 Improving Quality through Rules ..................................................................................14-10 Step 14 Rules Reference .............................................................................................14-19 Step 14 Completion Checklist ......................................................................................14-20

viii Contents

Quick Reference to Essential Design Principles ...............................................................A-1 Ten Guardrails for Success............................................................................................. A-2 Monitoring Compliance with Guardrails........................................................................... A-6

Contacting Pegasystems.....................................................................................................B-1 Customer Support ........................................................................................................... B-2 Education Services.......................................................................................................... B-2 Documentation Feedback ............................................................................................... B-2 Office Locations............................................................................................................... B-3

Index ....................................................................................................................................... I-1

Before You Begin

This book shows you how to take advantage of PegaRULES Process Commander and its patented rules engine to deliver integrated business process management (BPM) and business rules engine (BRE) solutions. As you Build for Change™, use this book as your roadmap to delivering solutions that address today’s toughest process automation challenges, including rapid deployment and evolution. The SmartBuild approach for designing, building, and evolving Process Commander applications enables you to:

■ Analyze your requirements in the context of a Process Commander solution.

■ Apply best practices to design your application, including the class structure, data elements, forms, flows, process logic, and security.

■ Work with your data, including the underlying database and interfaces to other systems or data sources.

■ Take advantage of the reporting and quality improvement features that come with Process Commander.

The benefits to your business are agility for growth, productivity, and compliance.

2 Before You Begin

Who Should Read This Book If you are part of a team that is building a Process Commander application, read this book. It describes:

■ Defining requirements for the application you want to deliver

■ Creating, tailoring, and assembling the components you need

■ Taking advantage of the standard features and capabilities that come with Process Commander

■ Deploying and evolving the application, and managing ongoing changes

Successfully delivering any application requires a mix of business analysis and application development resources. This book is intended primarily for Process Commander project team members who are responsible for business process design and application development. However, it also provides information to assist system and database administrators in project/resource planning. Specific project roles are described in Step 1: Roadmap to Building a Process Commander Application.

How to Use This Book If you have not already done so, review the Quick Start. Use it as a self-paced tutorial to get acquainted with Process Commander. It introduces many fundamental concepts that you will find helpful as you begin developing applications.

This book is structured to provide useful information for both new and experienced Process Commander application developers:

■ If you are new to Process Commander: Follow the chapters in order as you develop your first few applications. These chapters provide examples to illustrate the SmartBuild steps and concepts. Each chapter concludes with a list of rules that you worked with and a checklist of completed deliverables.

■ As you become familiar with Process Commander: Use the rules and deliverable checklists at the end of each chapter to stay on track with SmartBuild. Refer to Appendix A for the Ten Guardrails for Success. Each guardrail summarizes important SmartBuild principles and guidelines.

Who Should Read This Book 3

Related Documentation The following PegaRULES Process Commander documents are available:

■ PegaRULES Process Commander Introduction — provides an overview of the architecture, concepts, and features of Process Commander.

■ PegaRULES Process Commander Quick Start — provides a tutorial with standard elements used in configuring a Process Commander application and guides you in creating and interacting with a simple application.

■ PegaRULES Process Commander Administration and Security — describes how to perform the initial startup, setup, and day-to-day administration.

■ PegaRULES Process Commander Integrating with External Systems — supports IT professionals who plan, design, build, and test the interfaces with other systems that can be used with a Process Commander application.

■ PegaRULES Process Analyzer User Guide — describes how to install and use Process Analyzer, an optional component that provides online analytical processing (OLAP) data for PegaRULES Process Commander.

■ PegaRULES Process Simulator User Guide — describes how to install and use Process Simulator, an optional component that provides simulation of PegaRULES Process Commander business processes.

■ Application Developer Help — provides contextual information about Process Commander. Access help by clicking the Help link on the Portal or on the toolbar.

■ Installation Guide (located on the installation CD) — describes how to install Process Commander.

■ Pega Developer Network (a section of the Pegasystems Support Network located at www.pega.com/support) — provides technical notes and tips for using PegaRULES Process Commander.

For information on installing or working with third-party applications, such as Microsoft Visio, consult vendor documentation.

Step 1: Roadmap to Building a Process Commander Application

Welcome to PegaRULES Process Commander. This chapter describes the first step of SmartBuild, the key approach to rapid development and successful deployment of Process Commander applications. This first step includes how to:

■ Recognize good application opportunities.

■ Learn about the SmartBuild process for designing and developing applications.

■ Select a project methodology.

■ Identify components of a Process Commander application.

■ Structure your project team with the appropriate resources.

Who Does This: Project managers and business analysts typically work together to perform these tasks.

1-2 Step 1: Roadmap to Building a Process Commander Application

Identifying Application Opportunities Process Commander is designed to complement, not replace, other information systems and technologies that you use in managing your business. You can use it to build standalone applications, or easily integrate Process Commander applications as components of existing legacy systems. Its flexibility and features are applicable to a wide range of business process automation solutions. The following types of business scenarios are ideally suited to leverage Process Commander’s strengths:

■ Wherever business-driven change is frequent, such as enterprise marketing programs, customer service, or cross-selling situations.

■ With internal or distributed parties that perform service or product fulfillment, such as loan appraisers, insurance adjusters, or subcontracted suppliers.

■ For processes with handoffs or parallelism, that often accompany distributed workforces and outsourced processes.

■ If centralized expertise must be captured and propagated, such as with credit decisions or dispute processing.

■ For supporting partners within the company, such as driving administrative processing for purchasing, legal, or human resources.

Choosing an Initial Project — the Quick Win A Quick Win opportunity allows you to demonstrate the value and return on investment (ROI) of the initial Process Commander project by delivering tangible results to the business. Rapid delivery with overwhelming success on the first project is the key to incremental projects that collectively and ultimately deliver the “big win.” Identifying the right gap to fill with your first project is important to achieving the proven advantages of a Quick Win.

Before assembling the team and structuring the project as described in this chapter, choose a Quick Win business opportunity from possible application opportunities. By definition, a Quick Win can be delivered within 60 to 90 days, offers standalone return on investment, and involves high-volume work that uses easily available data sources.

Identifying Application Opportunities 1-3

To identify a Quick Win opportunity, consider the following:

■ Where do you need to address process execution gaps between management objectives and business operations? For example, look for existing characteristics such as high staff turnover or training costs, high error or rework rates, human-intensive processes, and poor service/customer attrition.

■ Where would you like to improve or achieve better results? For example, look for desired characteristics such as increased throughput, reduced cost, faster turnaround, and improved tracking/accountability.

■ Where could you automate critical processes? For example, look for characteristics such as manual or paper-based steps, areas where data is copied from one system to another, and repetitive semi-automated processes such as customer correspondence generation.

■ Where do you have opportunities to remove “black holes”? For example, look for areas where work ownership/accountability is poorly defined or relies on manual processing.

■ Where do you have opportunities to digitize policy and process rules? For example, look for decision-critical knowledge residing on paper or in the heads of highly skilled individuals: processes that are regulatory driven (exception/dispute handling, corporate compliance), calculation intensive (tax or fiscal requests), and industry driven (policy requests or claim processing).

Quantify the possible opportunities in terms of financial and/or productivity metrics. Assess each opportunity in terms of business impact and system integration complexity, and select a Quick Win. Spend no more than a few hours on this task. If you need longer, you are defining requirements rather than assessing solution magnitude.

What You Completed Identified application opportunities and a Quick Win initial project.


Using SmartBuild — Smart Design for Smart Systems SmartBuild is the sequence of 14 steps for developing business process management (BPM) and business rules engine (BRE) solutions with Process Commander. Each 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. This book is your guide to SmartBuild.

The foundation of SmartBuild is a philosophy of iterative development, object reuse, and rapid deployment — all key principles of object-oriented design. The SmartBuild philosophy extends beyond the technology itself to the holistic concept of the smart system — that is, a system with the ability to drive (not just record) the work. Smart systems have business-driven flows and rules that impose specialized requirements on the design and development process. Addressing this process requirement is an integral dimension of SmartBuild.

This combination of process and philosophy is a critical differentiator that makes it possible to deliver solutions quickly and evolve them easily as the business dictates — in other words, it is how SmartBuild actively promotes the ability to Build for ChangeTM.

Fundamental SmartBuild Design Principles Process Commander is an object-oriented development environment. You can use many popular object-oriented techniques to analyze requirements and document the design. For example, you might prefer use case diagrams and/or unified modeling language (UML) tools. Regardless of the technique you use, follow these SmartBuild principles for a successful design effort:

■ Define objects first; then define process flows. Individual categories of work (or work objects) form the foundation of a Process Commander application. For example, a check or credit card exception, a medical or insurance claim, and a purchase order are work objects. They drive all other aspects of your application — behavior and data. You start the design process by defining the basic work objects that your application will handle. These work objects form the skeleton of your class structure, which defines data and

Using SmartBuild — Smart Design for Smart Systems 1-5

design element relationships. Finally, you define the process paths (or flows), along which the work objects progress.

■ Reuse and iterate. Reuse is a timesaving advantage of object-oriented design, and iteration is the key to reuse. Always start simply and add complexity gradually. For example, don’t try to identify all work object properties in one step. Use the standard objects and properties that come with Process Commander. Then refine the structure by adding specialized work objects, properties, and other design elements. Each time you add something new, first check if something similar exists or whether it can be shared with other existing objects. SmartBuild design capabilities make this approach quick and easy.

■ Start with a standalone application; connect with other systems later. Interfaces to and from other systems typically present analysis, development, and security challenges. Many of these characteristics change as your design evolves. To avoid significant delays and later rework, create sample data in the Process Commander database as a placeholder for future automated interfaces to and from other systems.

Based on these themes, Figure 1-1 on the next two pages illustrates the SmartBuild process and provides a checklist for designing Process Commander applications. For more information on design principles and guardrails for success, see Appendix A.

1-6 Step1: Roadmap to Building a Process Commander Application

Figure 1-1. SmartBuild � Smart Design for Smart Systems

Using SmartBuild � Smart Design for Smart Systems 1-7


What SmartBuild Is Not — the Role of a Project Methodology A logical design/development process and philosophy are not enough. The tasks of designing and building the application components are only part of delivering a solution. You also need business requirements, project management, documentation, and testing, as well as a range of other critical efforts. To delineate and coordinate all of these aspects, most software projects employ a project methodology to structure the project with milestones/deliverables and guide the implementation from start to finish.

SmartBuild is not a project methodology. In keeping with the open architecture of Process Commander, SmartBuild can work with current types of project methodology. Your team follows SmartBuild steps iteratively within a project methodology. SmartBuild neither requires nor promotes the use of a specific project methodology, deferring the choice to project or organizational standards. It doesn’t impose a project structure or document templates. Instead, its component steps map smoothly to most project structures.

Why Choosing an Iterative Project Methodology Is Important Follow a project methodology that supports the SmartBuild philosophy of iterative design/development and rapid deployment. For maximum benefit and efficiency, the goal is to identify a Quick Win business opportunity, implement an initial solution quickly, and evolve it incrementally. Look for guidelines that emphasize active user involvement, iterative design methods, and frequent, smaller deliverables, rather than an old-fashioned waterfall approach.

An iterative project methodology leverages the object-oriented principle of reuse, delivers incremental and measurable results faster, and emphasizes small deliverables based on regular managed inspection and adjustment of requirements. In most IT environments, an established best practice is to use an iterative methodology to keep pace with business needs.

Using SmartBuild — Smart Design for Smart Systems 1-9

For more information about this type of methodology, here are some options to consider:

■ IBM Rational Unified Process® (RUP) (www-306.ibm.com/software/rational/)

■ Scrum (www.controlchaos.com)

■ Extreme programming — XP (www.extremeprogramming.org)

■ Spiral model (www.ieee.org)

■ Naked objects (www.nakedobjects.org)

■ The New Methodology (www.martinfowler.com)

How SmartBuild Delivers Results Better and Faster The Process Commander development environment includes hundreds of BPM-appropriate objects, rules, and capabilities that are ready for immediate use no additional development required. You can quickly get a basic, working application (not just a prototype) up and running by making small changes to adapt these features for your business needs. Process Commander also includes easy-to-use accelerators, such as the Application Accelerator, which can significantly reduce your application setup time once you have done the upfront design work.

SmartBuild shows you when and how to use these tools and incorporate components for optimal results. By following SmartBuild in sequence and iterating over steps where appropriate for your project, you automatically take advantage of all the built-in design and implementation tools. SmartBuild will save you work, your solution will be up and running sooner and the architecture will readily accommodate business-driven change. As the Process Commander platform evolves, your solution will naturally take advantage of the newest technology.

What You Completed Reviewed the SmartBuild process for designing and developing

applications.

Selected an iterative project methodology, if not already adopted.


Understanding the Process Commander Object Model Familiarity with the concepts, benefits, and terms of object orientation is helpful as you design and build Process Commander applications. Based on the Java programming language, Process Commander incorporates inheritance, reuse, information hiding, and encapsulation. However, some distinctions are important to understand. Figure 1-2 contrasts object orientation concepts (found in Java and similar languages) with similar features of Process Commander.

Figure 1-2. Contrasting Process Commander and Conventional Object-Oriented Concepts

In Java, classes, attributes (fields), and methods are defined through code, created and tested by software developers. A single form of class inheritance is dominant.

In Process Commander, two types of inheritance are supported. Developers work by creating rules and using RuleSets. Process Commander converts rules into corresponding Java code to execute the corresponding rules. Because many types of rules — including flow rules that implement business processes — do not require programming skills, business analysts and others who are not IT professionals can participate in the application development effort.

Identifying Components of an Application 1-11

Identifying Components of an Application The following sections provide a preview of the components of a Process Commander application

■ What you create to develop the application

■ What you configure to identify users and implement security

■ What standard quality management and reporting features to incorporate

■ What database management and system integration capabilities to configure

Rules to Define the Appearance and Logic of the Application Every Process Commander application consists primarily of a collection of rules as well as other components. What you need to develop or tailor depends on your business process. To automate simple processes, applications need only a few custom-built elements, while complex processes usually require many more. Figure 1-3 describes components of your application defined by rules.

Component Description

One or more RuleSets Containers for the rules in your application.

A class structure, including a top-level class

Foundation of your application. Your classes and properties, combined with those in the standard Process Commander class structure, define the work being done and the data being captured.

HTML-based forms, tailored for your work

Face of your application — what business users and managers see and interact with when using the application.

One or more flows, created using Microsoft Visio

Traffic directors for your application — to control how work moves through a business process.

Activities and decision rules Muscle of your application — to add the automation to process work based on business rules.

Flow actions Forms that record user input and decisions to advance work through a flow.



Correspondence Communication channels (such as e-mail) to and from your application to inform other people or systems automatically about work status.

Services Requests from external systems for information and processing performed by your application

Connectors Requests from your application sent to external systems (or external databases) for information or processing.

Figure 1-3. Typical Application Components Defined by Rules

Standard Rules to Provide Reusable Building Blocks You don’t need to start from scratch to build an application. Process Commander includes hundreds of useful building blocks, known as standard rules, for you to use as a starting point. For example, the application user interface consists of a set of HTML-based forms that you tailor for your application.

Many standard rules require little or no modification for use in an operational application. Of course, you also create your own application-specific objects and rules as needed. Your own library of reusable rules suited to your environment will grow over time as you build more Process Commander applications.

In this book, the words create, update, and edit are used to describe your development process in building and evolving rules. In the context of Java development, the corresponding term is instantiate. Technically, creating a property rule is equivalent to “instantiating a persistent instance of the Rule-Obj-Property rule type.”

For data objects, the verb configure is often used as an alternative to create. The content of data objects may change more often than the content of rules. The verb tailor is a shorthand term for overriding a standard rule by copying it and customizing the copy. The term application-specific rule means any nonstandard rule, a rule your team creates in support of your application.


Data Objects to Identify Situational Values and Implement Security In addition to the rules that you create or tailor, a Process Commander application as it operates relies on basic information about your business for identification and security purposes. Some of these elements are specific to your application, while others are shared across all applications in your Process Commander environment. They are not rules or processing logic, but data objects, instances of classes derived from the Data- base class. The task is to configure — record and manage — such information.

The security model lets you control access at different levels, including RuleSet, organization hierarchy, job function, user, and class. Figure 1-4 shows what an administrator needs to configure for a typical application.

Component

Shared Across Applications?

Description

Organization hierarchy

Yes Business structure of your organization, including application developers and users.

Users Yes People in your organization who build, use, or evolve any Process Commander application.

Access groups

Yes Groups of people who perform similar job functions in applications. Access groups control portal layout and application access.

Access roles No Designated process responsibility within a specific application. Access roles refine application access by operation and class.

Calendars Yes Identifies the workweek and business holidays for a year,

Figure 1-4. Typical Application Components Configured Using Data Objects


Standard Quality Management and Reporting Features Process Commander includes features that support continuous improvement and process management. These features can provide valuable quantitative data to help supervisors and managers identify opportunities for improving your business processes. You can take advantage of these basic building blocks in your application without significant development effort (Figure 1-5).


Quality management features

Tools that promote process improvement. You can easily add service level rules, statistical sampling of completed work for quality review, and process cost calculations to your application.

Reporting features Tools that support business process management. Dozens of standard reports and graphs help you analyze work progress and quality. You can also design custom reports using the Report wizard or third-party tools.

Figure 1-5. Standard Quality and Reporting Features


Databases and System Interfaces Process Commander is based on an open database architecture that works with Microsoft SQL Server, Oracle, and IBM UDB/DB2 database software. See the Platform Support Guide PDF document (located on the Pegasystems Developer Network) for the latest list of supported platforms, application servers, and databases. Process Commander stores rules, work objects, and other objects in a database known as the PegaRULES database. More information about working with this database is provided in Step 12: Configuring System Interfaces and the PegaRULES Database.

For some applications, you may need to modify the PegaRULES database, access it with third-party reporting tools, or exchange data with other systems. These development tasks are typically done towards the end of your application development effort. Figure 1-6 lists data-related components that you may need to work with as part of developing your Process Commander application.

Component What to Do

PegaRULES database Modify tables or columns based on your class structure and reporting needs.

Services Implement interfaces initiated by other systems to access your Process application.

Connectors Implement interfaces initiated by Process Commander to access external systems.

Figure 1-6. Database and System Integration Components

What You Completed Reviewed the components of a Process Commander application.


Understanding Process Commander Job Functions Before assembling your project team, make sure you understand the Process Commander job functions:

■ Business user — a person who uses the application you build to receive, process, and resolve work.

■ Business manager — a person who uses the application you build to monitor/approve work performance and quality for one or more groups of business users.

■ Developers and implementers — three types of people who build and evolve Process Commander applications:

− Process architect — a business analyst who defines and maintains business rules, service levels, and flows or processes.

− System architect — an application developer who creates the class structure for your work with supporting automation capabilities, and implements interfaces with external systems.

− System administrator — a systems engineer who is responsible for installation and setup, security, and other operational functions.

Step 11: “Setting Up Access and Security” discusses in more detail how the security model controls access to information and features that are appropriate for a user, and how to apply it in your application. Basically, users automatically see portal layouts specific to their job function when they log in to Process Commander. See the Administration and Security book for more information. It is important to make sure that each function is represented on your project team.

Understanding Process Commander Job Functions 1-17

Recommended Skills Consider the guidelines in Figure 1-7 as you assign project team resources to Process Commander roles. For a successful project, you need some people with Process Commander training and certification credentials on the team. In addition, experience and aptitude for learning new tools/skills are important attributes of team members.

Development Team Role Preferred Experience

Process architect ♦ Business process flowcharting ♦ User interface design ♦ Business logic definition ♦ Some familiarity with scripting or application

macro tools (HTML and JavaScript preferred)

System architect ♦ Data modeling and relational databases ♦ Object-oriented and modular design ♦ Moderate level of programming expertise (Java

preferred) ♦ System connectivity and interfaces

System administrator ♦ Hardware and operating system administration for your platform

♦ User and network management tools ♦ Database management tools for your database

platform

Figure 1-7. Development Team Roles and Skills


Assembling a Project Team As with any business process management solution, you need the following resources on your Process Commander project team.

Project Management Resources ■ Project manager with business and technical expertise relevant to the

application purpose to run the project.

■ One or more trained and experienced Process Commander guide/facilitators, typically either from Pegasystems or an authorized partner.

Business Resources

■ Two or more people who work in the business area (at least one business user and one business manager) to test your application.

■ Business analyst to provide business requirements.

■ Process architect — a business or process analyst for business process definition and maintenance. Familiarity with HTML is helpful but not required.

Technical Resources ■ System architect — an application developer with Java experience to handle

complex design tasks and interfaces with external systems.

Note: You may need more than one system architect, for example, one system architect with Java experience, and one or more system architects with experience setting up interfaces to other systems.

Understanding Process Commander Job Functions 1-19

■ System administrator — a systems engineer with experience on your selected platform to handle software installation, security, and maintenance.

■ Database administrator — experienced with your selected database to handle database installation (if necessary), setup, and maintenance.

The number of people you need depends on the size of your organization and the complexity of your business process. As a guideline, a project team of this size —one person per job function, or approximately eight people — is adequate for developing and deploying a Process Commander application that supports as many as several hundred users. Obviously, the amount of dedicated time expected for each resource depends on the size and complexity of your application.

What You Completed Identified the project team, including trained/certified Process Commander

resources and additional training requirements.

Assigned the standard Process Commander functions to appropriate team members.


Mapping SmartBuild to a Typical Project Structure As a starting point for your project planning, Figure 1-8 shows how SmartBuild maps to the phases of a generic project structure. Following an iterative project methodology, start small and deliver an initial application with the core capabilities needed to support your business process. Then evolve the application over time. Use quality management features to identify opportunities for process improvement. This approach supports most process scenarios and promotes rapid development and deployment.

Phase Key Job Functions Description

Define Business analyst Process architect

Analyze your business process and map its characteristics to a Process Commander solution (Step 2).

Design and Build

System administrator System architect Process architect

♦ Set up your Process Commander development environment. Design the class structure for your work and identify the data elements (Steps 3 — 6). Iterate as needed.

♦ Tailor the user interface and implement flows with process details (Steps 7 — 9). Iterate as needed.

♦ Add communications and security features. Configure any external system interfaces (Steps 10 — 12). Iterate as needed.

Test Business users Business managers Process architect

Select several business users to use the functions of all workflows (Step 13).

Deploy Process architect System administrator

Move the completed application to your production environment and make it available to users (Step 13).

Improve / Evolve

Business analyst Process architect

Use your application as the basis for continuous improvement. Use reports and graphs to assess work and process quality, and then add new capabilities and work groups (Steps 13 — 14).

Figure 1-8. SmartBuild Within a Generic Project Structure

Mapping SmartBuild to a Typical Project Structure 1-21

How Iteration Applies to SmartBuild Each iterative project methodology and project team has its own approach for segmenting a project into a series of iterations and releases. You can map the SmartBuild steps to your iterative approach, without changing the step sequence.

For example, Figure 1-9 illustrates the project structure and duration for delivering a Quick Win with SmartBuild. This approach is the simplest form of an iterative project. First you identify something with standalone business value that you can deliver within 60 to 90 days, which is typically a subset of a larger business process. Then perform Steps 1-14 in order and release the initial application for production. Depending on the nature and complexity of the work, you may also need to iterate over related segments of SmartBuild (Steps 3 to 6, 7 to 9, and 10 to12) and seek business feedback. Subsequent projects (or iterations) would address other defined parts of the business process.

Figure 1-9. Delivering a Quick Win with SmartBuild

What You Completed Mapped SmartBuild to your project methodology.

Established the project structure and high-level project plan.


About the Examples This book uses the following examples to help you get started building Process Commander applications:

■ PegaSample includes basic components for resolving work (Figure 1-10).

■ The application called PegaRP is a basic task management product with capabilities for tracking development projects and related tasks.

■ YourCoLoan is a loan request application with capabilities for accepting and processing various types of consumer loans.

The Sample Work Application The sample application named Sample Work includes the basic components that you need to create and resolve four types of work, as shown in Figure 1-10.

Figure 1-10. Entering New Work in PegaSample

This application is available to any user who has PegaSample listed in the All Class Groups of Work in an access group. (PegaSample is by default available to operators created by the Initial Setup wizard). Users can select the application and enter work to become familiar with the default user interface. Users can create and examine rules to see the elements of a simple Process Commander application.

Step 1 Completion Checklist 1-23

Step 1 Completion Checklist After finishing this SmartBuild step, check that you have the following components before continuing.

Application opportunity and Quick Win first project identified (prerequisite for the other components).

Overview of the SmartBuild process for designing and developing applications.

Iterative project methodology selected.

Understanding of the components that are part of a Process Commander application.

Process Commander job functions in relation to individuals on the team.

Project team selected and assigned to job functions, including trained/certified Process Commander resources and additional training requirements.

SmartBuild steps mapped to your project methodology.

Project structure and high-level project plan established.

Step 2: Analyzing Requirements

After you have a team and a high-level plan in place, Step 2 of SmartBuild involves assessing the requirements of your application. This step describes what you need to know about the business process you want to automate:

■ What is the nature of the work, including the business purpose and primary units of work?

■ Which organizations, people, and interested parties are involved?

■ Does the work involve existing systems or data sources?

■ Do you need to localize the solution (for example, for language and currency)?

■ What are the major, high-level user scenarios?

■ Are you building an application or a product?

This step also introduces how this information applies to a Process Commander solution, including key concepts and terms.

Who Does This: Business analysts and/or process architects typically perform these tasks.

2-2 Step 2: Analyzing Requirements

A Different Approach to Requirements Analysis In contrast to the classic waterfall development approach and many other methodologies, SmartBuild does not require or promote extensive initial effort and time in developing requirements. Because Process Commander includes a set of building blocks, known as standard rules for business process management applications, you are rarely starting from scratch. For example, its predefined forms have built-in, functional behaviors and work properties. You can extend these components to suit your business needs and add more at any time.

The most direct and rapid route to an operational application is to use these building blocks, making only modest changes at first. Then extend these elements further as you become familiar with their characteristics. In this context, you tailor existing components to your requirements, rather than build everything you need from scratch. This approach also simplifies your analysis:

■ For best results, keep your upfront analysis restricted and object-centric. Follow the guidelines in this step and resist the temptation to define in detail at this time how work is entered or processed. For now, treat a process as an interface and think only of the object (or class) of data returned. This approach lets you deliver consistent application results faster, and avoids rework later.

■ Describe completed work, rather than the underlying process that produces it. Assume that you are researching an issue at some time in the future by examining an archive of completed work. This technique streamlines your analysis process. Object analysis occurs at the beginning because its purpose is to establish the class structure that is your application foundation. Detailed data analysis is done later.

■ Most importantly, become familiar with the standard objects, behaviors, and properties. Consider tailoring the existing elements first before defining your own design elements. This approach reduces both upfront analysis and the scope of custom development.

With these guidelines in mind, you can begin analyzing the requirements for your solution.

What Is the Nature of the Work? 2-3

What Is the Nature of the Work? Moving forward with the recommended design approach, start by defining what your application does and then move on to how. A logical place to begin your business analysis is to establish the type of work the application will manage. Because Process Commander is object-oriented, this task consists of identifying the fundamental objects that represent work in your application:

■ Describe the primary business purpose (or work process) that the application will manage. Include what part of your business the application supports.

■ Describe the major units of work (or work objects) that the application will handle. Categorize them, if appropriate. Together, they form the major classes and subclasses in your class structure.

Your objective is to establish the basic purpose and structure of your application’s work classes, not a detailed design. Plan to spend no more than several hours on this task, even for complex applications. At this stage, don’t try to create a detailed requirements document. A realistic goal is a one- or two-page description, ideally with phrases and lists. In keeping with an iterative design approach, refine these decisions as you create the class structure.

Note: For rapid development, limit your initial analysis to the primary types of work objects. This approach keeps your class structure simple and easy to manage at first. You can always add work objects later.


PegaRP Example Figure 2-1 describes the work that the PegaRP example application supports.

What You Need to Define As Defined for PegaRP

Purpose of the work Record, track, and manage the effort associated with developing and supporting a Process Commander application or product.

Completed units of work that can be represented as work objects

♦ Software tasks to perform (such as a support request). ♦ Projects that group related tasks.

Figure 2-1. Description of Work in PegaRP

Helpful Hints

■ If you’re familiar with other object-oriented design tools, you may be tempted to define your work objects in detail now. Instead, follow an iterative approach to top-down design, focusing on the high-level objects only.

■ For now, don’t think about defining all characteristics (or properties) of work objects. Process Commander includes an extensive set of standard work properties that you can reuse for efficiency. However, you can easily extend them to suit your needs. You learn about extending properties in Step 6, “Adding Properties and Sample Data.”

■ As a guideline, a work object should be an entity for which you want to drive data entry, priorities, deadlines, and reporting. Its name should be a noun. For example, Code meets these criteria in the PegaRP example and is thus an appropriate type of task work object. However, problem severity might be better defined as a property of a work object, rather than creating separate classes of work objects for the different severity levels.

What Is the Nature of the Work? 2-5

■ In defining work objects, consider only completed work in your application. Review your object names for clues:

− Avoid defining work objects with names that reflect process state (such as DeferredTask or ClosedTask), or with names that don’t transcend work completion (such as NewTaskRequest). Deferred, closed, and new describe the state of an object. Thus, these names would be status properties of the object, not separate objects.

− Avoid objects with names that are too generic (such as Task). Instead, use object names that reflect a specific type of task (such as Code, Rule, or Documentation).

■ Process Commander provides other features such as service levels to address detailed processing and quality requirements. For more information, see Step 14: “Leveraging Work Reports and Quality Features.”

What You Completed Described in a few sentences or phrases the business purpose and primary

work process for your application.

Identified the major types of work objects in the application, including subcategories.


Who Performs the Work? After you identify the type of work managed in the application, you need to determine who performs the work. This task consists of identifying the business groups and people that compose the user community for your Process Commander application:

■ Determine which business areas will use the application. These entities are part of the organization hierarchy for your Process Commander environment, which mirrors your business reporting structure. The hierarchy is built on the nested levels of organization, division, and unit. Division names must be unique within the organization, and unit names must be unique within a division. You can also use work groups to group related people across the hierarchy for matrix management requirements.

■ Identify the key people who will develop and use the application, including their job function (such as business user, system architect, etc.) and process responsibilities. Operator IDs enable these authorized users to access the system, access groups reflect their job function, and access roles reflect their process responsibilities.

Note: This task applies only to the people who directly do work in the application. For now, you need not identify other interested entities and people (or work parties) that are impacted by, but not directly responsible for, the work process. Identifying work parties is the next task.

Your objective is to identify the business areas and individuals that are the primary users of the application. You can add to the organization structure at any time, so you don’t need to define the structure completely at this point. However, organization information is shared across all applications on a Process Commander system and is also the basis for security features that control what users can see and do. Considering these issues early can save time because they affect other aspects of your analysis and design.

Who Performs the Work? 2-7

Defining the Organization Hierarchy Internal organization structures tend to be dynamic, especially when viewed over several years. This factor is significant for BPM solutions, as resolved work typically persists over time to support historical analysis. Additionally, most companies today have existing systems for managing the details of their organization structure.

Process Commander is designed to record only the essential details that uniquely identify the work-relevant organizational entity in a way that is not redundant with existing systems of record. Thus, the Process Commander organization hierarchy consists of exactly three levels (as represented by unshaded boxes in Figure 2-2).

■ Organization — top level, which identifies the company entity. It is especially useful for segmenting work in environments where a single system processes the work of more than one company (such as at service bureaus).

■ Division — second level, which identifies another high-level entity of the company (sometimes a sub-company). For example, you might use the structure of your company’s senior management team as a starting place for the entities at the division level.

■ Unit — lowest level, which identifies the most specific level within the division.

Figure 2-2. Process Commander Organization Hierarchy


In Process Commander, the most important level for work identification purposes is the lowest level (the unit). In reality, a particular unit number (or other identifier) might not be unique without the associated organization and division values. For example, two different divisions of a large company might both have an Accounts Payable unit or a #2534 unit. Using a three-part identifier consisting of the organization, division, and unit therefore ensures its uniqueness.

Obviously, organizations commonly have many levels between the second and lowest levels (division and unit), as represented by the shaded boxesin Figure 2-2. Recording all possible levels in Process Commander would impose redundancy with other data sources. It would also introduce maintenance issues (especially for large organizations) associated with frequent unit reorganization within the larger reporting structure. Therefore, Process Commander doesn’t require or use the interim levels.

In contrast, organization units (and cost centers, which can also be recorded in Process Commander) tend not to change as frequently or significantly.

What to Do Now Using either paper or a software tool of your choice, create an organization chart diagram that illustrates your hierarchy as it is to be recorded in Process Commander.

Depending on your company, your organization hierarchy can range from simple to complex. Most companies create a single organization for ease of maintenance. You must also have at least one division and one unit. A small company might have only a few entities at each level in the hierarchy, while larger companies might require many entities at all levels.

Initially, identify only the business areas that will either be the primary users of your application or interested work parties. For example, you might decide to exclude the marketing department for now if it isn’t directly involved in or impacted by your application work process.

The organization hierarchy is shared across all applications on a Process Commander system. To avoid confusion and promote reuse, make sure that the entities you define


accurately reflect the fundamental business structure of your company. If you are building a product for resale, you also need to define a separate sample organization that represents an expected customer implementation.

Note: Following a top-down approach helps you establish a structure for your organization hierarchy that is scalable across applications.

Figure 2-3 shows a typical hierarchy, which is a good starting point. Note that the Information Systems and Sales and Service divisions both have an Operations unit, each of which can be uniquely identified by the organization, division, and unit.

Figure 2-3. Typical Organization Hierarchy


Identifying the People Who Perform the Work After establishing the business areas that use the application, you next identify the people who perform the work. Think about people who use Process Commander applications in two dimensions:

■ An access group represents a person’s job function and allowed actions in a Process Commander environment. It controls the applications, portal layout, and groups of work (or work pools) you can access. Access groups typically mirror Process Commander job functions.

■ An access role represents a person’s authority level relative to part of the work process. It controls access to specialized application capabilities. Access roles often pertain to a specific process, but can be shared across applications if defined appropriately. Several roles may collectively define the overall responsibilities for an individual.

Your objective is to describe the application users based on these categories. You can list the known people first and then map them to access groups and identify any necessary roles. Alternatively, you can map roles to access groups first and list the people later.

PegaRP Example Based on the PegaRP example, Figure 2-4 illustrates the typical access groups and roles.

Access Group

Description

As Performed in PegaRP (Function and People)

Need Custom Access Role?

Business user

Anyone who enters new work in PegaRP

♦ Application users ♦ Design and development

staff

No

Business manager

Managers who assign work and monitor progress in PegaRP

♦ Design manager ♦ Development manager ♦ Documentation manager ♦ QE manager

Yes — restrict the ability to assign/report on work


Access Group

Description

As Performed in PegaRP (Function and People)

Need Custom Access Role?

Process architect

Business analysts who perform work (business rule changes) in PegaRP

Design and development staff with an assigned worklist

No

System architect

Application developers who perform work (system rule changes) in PegaRP

Development staff with an assigned worklist

No

System administra-tor

System administrators who perform work (system administration tasks) in PegaRP

Operations staff with an assigned worklist

No

Figure 2-4. PegaRP Access Groups and Roles

Helpful Hints

■ Restrict your initial analysis to the primary application users as you can always add more users later. However, keep in mind the overall structure of your company.

■ While the organization hierarchy must be shared across all applications on a Process Commander system, access groups may be shared if that makes sense.

■ When you identify the people who use the application, include the people who are responsible for developing and maintaining it.

■ Think of an access role as the ability to selectively grant access to actions in a process. Use them sparingly for ease of management.

■ System administrators are typically responsible for setting up and maintaining the organization structure (including individual people). Creating a spreadsheet is helpful in compiling and organizing the organization information for administrators.

What You Completed Identified primary groups of people that use the application, organized by

business structure.

Identified primary individuals that perform work in the application, including their job function and any specialized roles in the work process.


How Does the Work Impact Other Entities or People? Process Commander supports the concept of work parties, which identify entities and/or people impacted by the work. Work parties are interested in the progress and resolution of a particular work object, but do not perform work in the application. Typical work parties to consider include:

■ Customers (typically the primary party in applications that support customer-facing processes such as call centers).

■ Staff members who are interested in or impacted by, but not directly responsible for performing, work that is managed in the application.

■ Related external organizations (such as service providers, partners, government agencies, and regulatory bodies) or people.

■ Affected facilities in your company.

Next identify the work parties for your application. Process Commander includes several work party types you can use as a starting point. More information about work parties is included in Step 4, “Designing the Class Structure.”

PegaRP Example The PegaRP example uses two of the standard work parties (Figure 2-5).

Work Party As Defined for PegaRP

Person An external customer for whom someone originates a work object in PegaRP.

Operator An employee who is interested in the work object resolution, but is not responsible for performing the work.

Figure 2-5. PegaRP Work Parties

What You Completed

Identified work parties that are impacted by, but not directly responsible for performing, the work managed in the application.


Does the Work Involve Other Systems? Process Commander applications usually complement, not replace, other systems and technologies that you may already have in place for doing work. You can use these applications as standalone solutions or components integrated with legacy systems. Using integration services (Step 12), your application can access both data and processes in both directions. The next task in your analysis is to establish whether the application needs to interact with existing systems.

In evaluating integration requirements, consider these scenarios:

■ Create and populate a work object in a Process Commander application directly from an existing system, perhaps with customer details from a Customer Relationship Management application from Pegasystems or Siebel Systems (using SnapStart, a desktop data import facility, to access Process Commander).

■ Access data or processes in the original system of record by dynamically reaching out from a Process Commander application (using connectors).

■ Access data or processes in a Process Commander application from an existing system, such as SAP R/3 or Oracle PeopleSoft (using services).

Your objective is to identify any other systems involved (such as SAP R/3) and the type of information needed (such as a product list). You don’t need to define integration mechanisms, file layouts, or data fields now. Process Commander has integration services for this purpose (see Step 12: “Configuring System Interfaces and the PegaRULES Database”).

PegaRP Example The PegaRP example doesn’t require access to or from other systems. All supporting data are recorded directly in the application.

What You Completed

Identified existing systems or data sources that may share data or processes with the application.


What External or Predefined Reports Are Required? For some applications, reporting requirements in specific formats are mandated by government, regulatory agencies, or corporate departments. These may require specific data elements or computations that are not otherwise captured during the course of completing the work.

As part of requirements gathering, identify such needs, and review the source and value of each reporting need. Typically, the primary focus of Business Process Management applications is completing the work effectively and efficiently, not gathering data for external use. Process Commander applications automatically gather data about the business process itself — as described in Step 14 — but this data may not meet external reporting needs.

List each report (or external data feed) needed as an output of the application. Review carefully the definitions underlying each external or mandated report format so that the business process and if necessary the work object forms of your application can support capture of the needed data elements.

When external reporting requirements are mandated, project sponsors need to note the following: gathering data needed only to support reporting requirements, rather than data needed to process the work efficiently, may add to processing costs.

Do You Need to Localize the Solution? 2-15

Step 3:

Step 4:

Step 5:

Step 6:

Step 7:

Do You Need to Localize the Solution? Localize means to build solutions that are suitable for use in one or more specific locales (languages, countries, and cultures). Building such applications requires specialized capabilities. When you follow SmartBuild to build a Process Commander application, you can add support for additional locales if needed. The SmartBuild steps involved in localizing an application include:

Dimensions of locale and built-in support

Setting and changing the user locale

Defining an alternate business calendar

Presenting the user interface in different languages

Handling currency

Who Does This: Process architects, system architects, and system administrators each perform different aspects of these tasks.

Important Terms and Concepts The following terms and concepts relate to localizing an application:

■ Locale refers to the features of the user’s environment that depend on language, country, and cultural conventions, including aspects such as date and time format, currency symbol and format, and character sorting order.

■ The Unicode Standard, developed and maintained by the Unicode Consortium, establishes a universal scheme for handling text in all character sets.

■ Process Commander incorporates industry-standard Java libraries (International Components for Unicode, or ICU) to present currency, dates, time, and other regional information in the most appropriate way for each locale.

■ The International Organization for Standardization, commonly referred to as ISO, is a coordinated network of national standards institutes that establishes a


wide range of international standards for business, government, and society. ISO standards related to localization include date/time formats and currency codes.

With an overview of the work and the participants, next consider the localization requirements for your solution. First determine whether you plan to implement the solution primarily in a single locale (such as the east coast of the United States) or across multiple locales (such as New York, London, Paris, and Zurich). Then evaluate the key dimensions of the locales you need to accommodate, as shown in Figure 2-6.

Dimension Considerations

Geography ♦ Where are you primarily building and maintaining the solution? ♦ Where is the work performed? ♦ If users interact with external customers, where are they located?

Language ♦ In what language(s) do the participants primarily perform work? ♦ If users interact with external customers, what languages do they prefer to speak?

Currency ♦ Does the work involve any monetary amounts? If so, in what currencies? ♦ If the work involves multiple currencies, do you need to be able to convert between

them (or simply store/display them)?

Figure 2-6. Localization Requirements

Basic locale support is built in and requires no development. To deliver a localized solution, you design and build the application for one locale. Follow the process in this book, as you would for a solution that doesn’t require localization. You then add rule-driven presentation capabilities for each additional locale, without significant recoding.

PegaRP Example PegaRP is designed for use in a single locale. The work does not involve currency values and the user interface is currently single-language (US English).

Do You Need to Localize the Solution? 2-17

For More Information For more information about localizing a Process Commander application, see “Guidelines for Localizing Your Application” at www.pega.com/support. You can also find a wide range of printed and online sources about localization. Here are some options to consider:

■ For an overview of localization: eBusiness Globalization Solution Design Guide by IBM www.redbooks.ibm.com/redbooks/pdfs/sg246851.pdf

■ For more information about Unicode: www.unicode.org

■ For more information about ICU: www.ibm.com/developerworks/oss/icu4j/index.html

■ For more information about ISO standards that apply to localization: www.iso.org

What You Completed Identified the primary locale(s) that the solution needs to accommodate.

http://www.pega.com/support

http://www.iso.org/


What Are the Major User Scenarios? As discussed earlier in this step, you can defer the detailed definition of work entry and flow requirements. This approach helps you take advantage of (rather than inadvertently duplicating) the many built-in capabilities in Process Commander. You have established the nature of the work in the application, the entities and people who are involved with it, other systems that might be impacted, and the primary locales (or geographies) where the users are located.

The remaining dimension is to establish how people will interact with the application. Defining this information now is useful for several reasons:

■ It influences some of your earliest design decisions regarding the class structure (or foundation) for your application.

■ It supports the development of scenario-based test cases to support pre-implementation application testing.

■ It clearly defines the high-level business perspective, which is critical to validating the resulting application.

Your objective is to describe the major business usage scenarios in general terms. Think in terms of business functions (people) and common scenarios (interactions), rather than properties, states, or authorization levels for individual tasks.

What Are the Major User Scenarios? 2-19

PegaRP Example The PegaRP example is designed to support the following user scenarios:

■ A business user enters a new work object in PegaRP:

− A project, which may group several related tasks. Projects can be one of several types — enhancement, inquiry, problem, or research.

− A task, which can be one of several types — code change, documentation change, support request, etc.

■ A business manager (triage manager, development manager, documentation manager, QA manager, etc.) reviews new projects and tasks, and takes one of the following actions:

− For a project, enters supporting tasks (if necessary) and assigns the project and any tasks to staff members for resolution.

− For a task, associates it with a new or existing project (if necessary) and assigns it to a staff member for resolution.

− Corrects the project or task type, and takes one of these actions.

− Decides to reject the project or task, and resolves it without further assignment or action.

■ Application development team members (process architects, system architects, and system administrators) perform and resolve tasks that appear on their worklists.

■ Business managers review work statistics in the standard reports and graphs to evaluate the effectiveness of the team.

While not reflected here, this example could also support an external system user scenario. For example, you could add a service to record a new work object based on an issue sent from a remote system.

What You Completed Summarized key user scenarios for developing test cases.


Are You Building an Application or a Product? In the final part of your requirements analysis, your last task is to characterize the application type. Because of its flexibility, you can build two distinct categories of Process Commander applications:

■ Applications that are specifically designed, used, and evolved by a specific organization. This category includes applications that you develop for your own use, and applications that Pegasystems or its authorized partners develop on behalf of their customers.

■ Commercial products that are built for a particular business need and intended for distribution to and individual adaptation by many different organizations. This category includes packaged solutions available directly from Pegasystems, as well as those offered by its authorized partners. It also covers solutions that are designed for a multi-customer or application service provider (ASP) environment.

While this dimension may seem a minor part of your analysis, it is important to take a few minutes to consider it now. Your decision drives several of your early design choices, as described in the next few chapters.

Process Commander offers many features for balancing design flexibility and intellectual capital protection. For example, you make a series of decisions concerning RuleSet organization, class structure, work pool segmentation, and rule availability. Defining these fundamental components effectively at the beginning avoids significant time and effort in future rework.

PegaRP Example The PegaRP example represents a solution that a wide range of customers can implement and tailor for their environments in different ways, so it represents the product scenario.

What You Completed Decided whether you are building an application or a product.



A few sentences or phrases describing the business purpose and primary work of the application.

A list of the major types of work objects in the application, including subcategories.

A list of the primary groups that use the application, organized by business structure. A simple organization chart is a useful format for organizing this information.

A list of primary individuals that use the application to do work, including their Process Commander job functions.

A list of additional work parties (entities and/or people) that are impacted by, but not directly responsible for performing, the work managed in the application.

A list of existing systems and data sources that may share data or processes with the application.

A list of primary locales to accommodate.

A high-level summary of the key user scenarios for developing test cases.

A few sentences describing whether you are developing an application or a product.

Step 3: Getting Started — Prerequisites and Setup

With your high-level requirements defined, you are ready to begin developing your application. Because Process Commander operates in a shared server environment, many people can use or develop different applications at the same time. This chapter walks you through SmartBuild Step 3, which consists of setting up the development environment for your application:

■ Logging in and becoming familiar with the development environment.

■ Understanding how the Application Accelerator streamlines initial application development.

■ Defining one or more RuleSets for your application.

■ Defining the top-level class of your class structure.

■ Setting up the system name, organization hierarchy, access groups, and key users.

Who Does This: System architects typically perform these tasks, with assistance from system administrators on the last task.

3-2 Step 3: Getting Started — Prerequisites and Setup

Using the Development Environment The portal provides a single, integrated environment for building, testing, and using applications. You do not need separate design and runtime tools or environments. In addition, the open authoring feature means you can use the most effective tool for the task (such as Microsoft Visio for creating flow diagrams, Microsoft Excel for importing small amounts of data, or Eclipse for writing HTML and Java) to evolve your Process Commander application.

Saving your design elements also automatically stores the rules in the PegaRULES database, which the rules engine uses to automatically generate Java for execution as necessary. Rule updates are immediately available for testing in your application. In addition, other helpful features are a single click away:

■ Run built-in accelerators and wizards to streamline many tasks that you perform while building and administering your applications (in the Dashboard home layout in the Accelerators and Wizards section of the workspace).

■ Add rules or design elements to your browser Favorites for quick access.

■ Click the Help button on the Manage Rules toolbar to access the Application Developer Help system.

■ Import lists of properties or other information from Microsoft Excel directly into the appropriate rule in Process Commander.

■ Access additional developer tools from the Tools bar.

Logging In You can access Process Commander from any Microsoft Windows® 2000 or Windows XP workstation using Microsoft® Internet Explorer 6.01. To develop applications, you also need Visio 2002 or Visio 2003 (also called Visio XP) Standard Edition and Adobe System’s SVG Viewer, a free plug-in available from www.adobe.com.

http://www.adobe.com/

Using the Development Environment 3-3

Figure 3-1 describes the components of the Process Commander URL for browser access.

Figure 3-1. Process Commander URL

Enter the URL in the Address bar to display the Welcome page (Figure 3-2).

Figure 3-2. PegaRULES Process Commander Welcome Page


What you see next depends on your operator ID. Users see different layouts of the Process Commander Portal when they log in to Process Commander, depending on their job function. To provide quick access to frequently performed tasks, the content in the navigation panel on the left and the workspace of the right varies depending on your job function. In this book, the text and images correspond to a system architect role in Process Commander version 4.2 SP2.

What You Completed Logged in to Process Commander as a system architect.

Portal Layout for System Architects For most of the tasks in this book, you log in to Process Commander as a system architect. When you first log in, you should see the Dashboard home layout for system architects (Figure 3-3). Look at the details in your Profile, which is located at the bottom of the Dashboard bar on the navigation panel. If the Portal Layout value is something other than SystemArchitectDD, ask your system administrator to update your operator ID.

Figure 3-3. Dashboard — System Architect Layout

Identifying the Top-Level Organization Class 3-5

Identifying the Top-Level Organization Class After installing Process Commander, your system administrator normally runs the Initial Setup wizard to prepare the environment for application development. This wizard configures the prerequisite elements for logging in to Process Commander and building applications, including:

■ A skeleton organization hierarchy.

■ A core set of operator IDs and access groups associated with the Process Commander job functions.

■ A baseline RuleSet (such as YourCoAll) with a top-level class (such as YourCo-) for the organization, to be shared across applications.

Ask your system administrator for this information for your environment.

Note: Refer to the Administration and Security book for more information about the Initial Setup wizard.


Working with the Application Accelerator Process Commander provides the Application Accelerator to streamline the process of setting up the foundation of your application. It guides you through the process of specifying and then automatically creating the basic components. Think of the Application Accelerator as a jump start to a simple operational application.

You can also perform these initial development tasks manually, which you may prefer to do when building very complex solutions. However, you will find that the Application Accelerator saves time and reduces effort, especially for simple applications that have a single RuleSet.

In keeping with the SmartBuild process, start small with a core set of business requirements and add components iteratively. First use the Application Accelerator to create the foundation for your application. Then use the Process Commander Portal to expand the application as your design progresses.

The first step in building a Process Commander application consists of designing its foundation — key elements such as the RuleSet, class structure, and type of work. You learn how to design these components in this and the next several chapters. Once you have designed the components, you can use the Application Accelerator to implement them quickly and easily.

The Application Accelerator automates key early steps in the SmartBuild process by implementing your application design based on the parameters you supply. The Application Accelerator replaces the tasks of defining and creating the components individually. This guided approach significantly decreases training and development time. Visual indicators record your progress, while the ability to review the results of completed steps is only a click away. You can pause or save your work at any time and resume later at the same point.

Working with the Application Accelerator 3-7

To run the Application Accelerator, open the Dashboard home layout. Find the Accelerators and Wizards section of the workspace and click Create New Application. Figure 3-4 shows the first of several forms that prompt for information about your application design in the proper sequence.

Figure 3-4. Application Accelerator

Note: Don’t confuse the steps you follow when using the Application Accelerator with the SmartBuild methodology steps presented in this book. The sequences are related, but the step numbers are not identical. The Application Accelerator requires only six numbered steps.

What the Application Accelerator Creates The Application Accelerator automates the tasks of creating the following basic components, which are required for all Process Commander applications:

■ A RuleSet and version for the application, added to your access group

■ Simple class structure, including covers and work-related classes

■ Class group (work pool) and supporting database table


■ Work object and cover prefixes

■ Properties and models

■ Work parties rule

■ Work object forms (harness and section rules) with your application properties added

■ One or a few basic flows

■ Workbaskets, worklists, and work groups

For simple applications, a significant part of your structural development is done once you complete the steps in the Application Accelerator. More complex applications may benefit from expanding these components, adding capabilities such as communications (for example, e-mail, fax, or letter), or integration with other systems. Steps later in the SmartBuild process address how to design and implement these additional components, as well as how to deploy and evolve your application.

Helpful Hints

■ Follow the SmartBuild design principles and naming conventions described in this and the following chapters.

■ Document your decisions as you design your application. To use the Application Accelerator effectively, have the design documentation available for reference when you begin.

■ You don’t need to complete all the Application Accelerator forms in a single session. You can pause, save your work and resume work later, either in the same or a new session.

Working with the Application Accelerator 3-9

■ Your system administrator creates a top-level class (such as YourCo-) and a division class (such as YourCo-FinDiv- to be shared across all applications in your division. You need to know the name of these class before you begin.

The Application Parent is the top-level class for your application: For most applications, the appropriate value is a class consisting of the top-level class followed by plus a division name (such as YourCo-FinDiv-).

■ The Application Name is the business purpose for the application. It also becomes a segment in the class group name.


Planning RuleSets As a container for components of your application, a RuleSet stores a related group of business rules. A RuleSet is what you deploy in your production environment or ship to a customer. RuleSets provide security, version control, and the ability to deploy your application in a different Process Commander environment. Each application uses a RuleSet to identify its rules.

Understanding RuleSet Names and Versions Every RuleSet has a name and a version to help you identify and manage its contents and deployment.

■ The rules engine uses a combination of the rule type, purpose, RuleSet name and version, class structure, and security model to determine the correct business rule to apply in each situation as work is processed. Optional date and customer circumstance conditions may also apply. This process is called rule resolution.

■ When you modify a rule instance, you can save your changes to a higher-numbered version of the RuleSet without impacting the current version. You can then make the modified version of the rule available to a subset of users for testing, without affecting the rest of the user community environment.

■ You can also control how an individual rule is applied during rule resolution by changing the rule availability.

■ When a development iteration is completed, you can lock a RuleSet version to prohibit subsequent changes.

Planning RuleSets 3-11

Figure 3-5 describes the name and version format for a RuleSet.

Figure 3-5. RuleSet Name and Version Format

RuleSet Naming Conventions ■ Use short, easily remembered names.

■ Avoid obscure acronyms. The name should clearly describe the RuleSet. For example, CityMortgage is better than CMLS (short for City Mortgage Loan System).

■ Begin your RuleSet name with something that uniquely identifies your company and the business purpose. This convention also prevents potential RuleSet collisions if the application is later installed on other Process Commander systems.

■ Don’t use Pega or Pega- as a prefix for your RuleSet names. These values are restricted.

■ Avoid special characters such as dashes, underscoring, plus signs, or quotation marks.

What You Completed Defined RuleSet naming conventions.


How Many RuleSets Do You Need? The next task in setting up the development environment is to decide how many RuleSets you need. Simple applications require a single RuleSet, created by the Application Accelerator. For more complex applications, organizing features into two or more RuleSets improves access and distribution control. Consider work complexity and application type to make this decision.

In most cases, your environment includes a baseline organization-wide RuleSet, containing the few rules that apply throughout the organization. This RuleSet, created by the Initial Setup wizard, is not included in the count of RuleSets you may need as part of your application.

Note: Keep your application simple, with as few RuleSets as possible.

Work Complexity ■ A set of business processes that is managed and used by a centralized group

typically requires a single RuleSet. The PegaRP example involves a few types of similar work performed by related work groups. It has one RuleSet.

■ A complex process that involves many distinct types of work, or has rules that are modified by several groups, can benefit from two or more RuleSets. For example, an application for handling home mortgages on a national scale could involve significantly different types of work performed by different work groups. You might want two RuleSets (one each for receiving and processing a mortgage), or multiple RuleSets (to reflect geographic regions with different processing).

Application Domain (Single-Use Application or Product) ■ Applications — application to be installed in one organization typically has a

single RuleSet with multiple versions for controlling ongoing changes. For example, an internal purchase request application might have one locked

Planning RuleSets 3-13

RuleSet version, with additional unlocked versions for developing new features.

■ Products — applications to be installed in several organizations — often benefit from multiple RuleSets to accommodate the needs of different customers. Product developers can group common features that are shared across a product suite, but separate the features that are specific to each product tier. For example, a loan processing product with modules for different loan types (mortgage, auto, credit line, etc.) might have several RuleSets — separate ones for defining the classes associated with each major loan type, plus a shared one for processing.

Process Commander includes four RuleSets that provide work management capabilities. Your RuleSets inherit the rules in these four RuleSets, and supplement them as needed for your application. First, you need one or more master RuleSets for your application or product. You may need RuleSets for development and divisional customization. Figure 3-6 shows an effective RuleSet architecture for a large enterprise with multiple divisions.

Figure 3-6. Multi-Division Rules Management


Helpful Hints

■ Use the organizational RuleSet (created by the Initial Setup wizard) to contain rules that apply to all applications and all users throughout the organization. (For example, a company logo image, stored in a binary file rule, belongs to an organizational RuleSet)

■ In large organizations, create an additional RuleSet for each division, to allow for divisional variations in rules (and provide a place for rules that apply to all the applications in a division).

■ Use the Application Accelerator to create the first RuleSet needed for each application.

■ A RuleSet can inherit features from other, prerequisite RuleSets and also from lower-numbered versions of itself.

■ When you make application changes (such as adding new features or rules), use a higher-numbered version of the production RuleSet.

■ Use multiple RuleSets to accommodate user community differences (such as by geography or division). In contrast, when you want to customize an application for different categories of work parties (such as preferred customers), use the concept of circumstance instead.

■ If you are developing a product, expect to have at least two RuleSets in each customer implementation. Your product is delivered to the customer in a locked RuleSet. After the product is installed, customers create another RuleSet that inherits from yours, so they can make local changes.

What You Completed Identified the number and relationships of RuleSet(s) needed.

Creating the RuleSets 3-15

Creating the RuleSets If your development strategy is to use the Application Accelerator to start development, enter the application RuleSet in Application Accelerator Step 2 (Figure 3-7).

Figure 3-7. Application Accelerator Step 2

The Application Accelerator creates the RuleSet and a corresponding version (01-01-01). You need to access the RuleSet form (Rule-RuleSet-Name rule type) or the RuleSet Version form (Rule-RuleSet-Version rule type) only to review or update these created rules, or to create additional RuleSets or versions.

As a best practice, update the RuleSet Version rules created by the Application Accelerator to identify Pega-ProCom:04-02 as a prerequisite to each of your application RuleSets. Additionally, update the RuleSet rule by checking the Requires Check-Out box, to enable facilities that help coordinate development activities within the project team.


Determining Who Can Access a RuleSet When it completes, the Application Accelerator automatically adds the created RuleSet to your own access group. Your system administrator can update the access groups of other development team members as necessary so that they can view, execute, and add to the rules in that RuleSet. When your application is deployed, RuleSet and version access can be provided through multiple means, reducing the need to update individual access groups.

The RuleSet list, assembled for each user upon log in, consolidates RuleSet and version information from four sources:

■ Requestor Type (Data-Admin-Requestor class)

■ Organization (Data-Admin-Organization class)

■ Division (Data-Admin-OrgDivision class)

■ Access Group (Data-Admin-Operator-AccessGroup class)

Granting Access for Organization Use During application rollout, an administrator typically grants access at the organization level for applications that are intended for general usage. As a result, everyone in the organization can use the application. For example, you would grant access to the following RuleSets at the organization level:

■ Pega-ProCom, one of the standard RuleSets that come with Process Commander.

■ An internal purchase order application for use across your organization.

Granting Access for the Division Level Alternatively, you can restrict business-specific applications to one or more business areas by granting access at the division level instead. For example, you might choose this approach for an application that is intended only for human resources staff.

Creating the RuleSets 3-17

Controlling Access by Job Function You can further refine RuleSet availability based on job function by using access groups. RuleSets that are specified in an access group appear at the top of the RuleSet list in the user’s profile and are applied first during rule resolution. A common reason for using this method is to selectively control access to new features or applications. For example, you might create an access group to grant access to the latest development version of your RuleSet only to your system architects.

As a shortcut, create an access group for your own use and specify your RuleSet as the default for development. However, you need appropriate access groups to make the RuleSet available to your project team and test users.

What You Completed Identified the parts of the organization and individual people who will need

access to your RuleSet when the application is deployed.

Identified the appropriate organization hierarchy levels and access groups for you and the project team (with assistance from your system administrator).


Creating the Application Parent Class The next task in setting up your development environment is to choose a name and starting place for the application class structure. You learn more about the Process Commander class model and how to create your own class structure in the next chapter.

An application top-level class is an abstract class with two name segments, such as My-Co-HR-

■ The organization top-level class, created by the Initial Setup wizard (for example, MyCo-)

■ A segment identifying the domain or division of the application (for example, HR)

When it completes, the Application Accelerator creates additional classes derived from the application class, but does not create other rules directly in the application top-level class. Two or more applications can share the same application top-level class.

Naming Conventions You read about naming conventions earlier in this chapter in the section on defining your RuleSets. As you become familiar with Process Commander, the benefits of adopting good naming conventions for all objects in your application will become obvious:

■ Short names are easy to remember when locating a specific object.

■ Descriptive names are easy to find when reviewing a list of objects.

■ Similar names make it easy to locate related objects.

In many cases, you may find it useful to define the top-level class as the company name and/or division. Make the owning division and/or the business purpose a subclass, and derive all other classes from it. This option is useful if you have

Creating the Application Parent Class 3-19

many Process Commander applications, or if your application uses supporting data in processing work. All applications can share the top-level class properties.

Some Examples

■ For the PegaRP example, the RuleSet is PegaRP and its top-level class is PegaRP-.

■ Suppose you are building two applications, YourCoPO and YourCoAP, for the Finance division. In a shared RuleSet, create a top-level class (YourCo-) for company use and a second level (YourCo-Finance-) for division use. Then create the work-related classes (YourCo-Finance-PO-, YourCo-Finance-AP-) in the application RuleSets. Define common elements once (such as your logo for YourCo- and division-specific rules for YourCo-Finance-), so YourCo-Finance-PO- and YourCo-Finance-AP- can inherit them.

Guidelines for Creating an Application Parent Class To create a parent class for an application, create a rule of type Rule-Obj-Class in your RuleSet. Make the class abstract, and inherit (through directed inheritance) from the top-level class for the organization. When you use the Application Accelerator, enter this class in the Application Parent Class field in Step 2 (Figure 3-7 on page 3-15).

What You Completed Defined top-level class naming conventions.

Created a top-level class in your RuleSet for use in the Application Accelerator.


Changing the System Name The system name can identify a single Process Commander installation. Its default value is wfe (for workflow engine), although your system administrator can specify a different value at installation. All users see the same system name when accessing any application on a server.

To determine your Process Commander system name, click the Dashboard bar and then click Full Profile (Figure 3-8).

Figure 3-8. Process Commander Operator Profile

After installation is complete, you can change the system name to something more descriptive. This name appears on the History tab of every rule created, and so helps identify which rules were created on which Process Commander system. Choose a name that reflects applications (such as loan processing), business functions (such as customer service), or geography (such as the Northeast). For example, for a dedicated development server, you might set the system name to MyCoDev.

Work with your system administrator to change the Process Commander system name. See the Administration and Security book for instructions.

What You Completed Changed the system name (optional), with your system administrator.

Configuring the Organization, Access Groups, and Users 3-21

Configuring the Organization, Access Groups, and Users The last task in setting up your development environment consists of configuring the components that will enable people to use your application. Using the Process Commander security model, you can grant different levels of feature access to specific groups or individuals. This model is both powerful and flexible, with a combination of options for controlling what users can access:

■ Organization hierarchy levels of organization and division represent business group affiliation and grant RuleSet access.

■ Access groups represent job function assignment (including your portal layout) and further refine RuleSet access.

■ Operator IDs represent authorized users and assign organization levels and access groups to individual people.

These components are shared across all applications on a Process Commander system. If you have other applications running in your environment, take advantage of things that already exist. You may only need to slightly extend the existing organization levels, access groups, and users.

Note: If you’re building an application for resale or distribution, you need to create two organization hierarchies — one for your development environment and one for a sample customer environment.

System administrators are typically responsible for setting up and maintaining both the organization structure and security. However, you also need to understand these concepts because you provide the business requirements for their setup. Refer to the Administration and Security book for detailed information on setting up the organization structure and security.


Setting Up Your Organization Hierarchy The Initial Setup wizard creates a skeleton organization hierarchy. An administrator can then set up additional levels in your organization hierarchy based on the business structure you identified in Chapter 2. The administrator does not need to set up the entire structure at first and can always extend it later as needed. For now, only create enough of the organization structure so you can test your applications.

The administrator configures instances of the following classes:

■ Data-Admin-Organization, which defines the top level of the hierarchy.

■ Data-Admin-OrgDivision, which defines the second level, known as a division.

■ Data-Admin-OrgUnit, which defines the lowest level of the hierarchy.

The administrator can also create instances of the Data-Admin-WorkGroup class to create an additional level for matrix management within the organization. Work groups can define organizational relationships that do not align with the hierarchy. You use them for work assignment and processing. For example, you might use a work group to associate people who report to different business areas, but have similar process responsibilities.

By convention, the organization name is your company name in Internet domain name format (for example, YourCompany.com or YourCompany.co.uk).

Setting Up Access Groups As discussed in Chapter 1, Process Commander uses a set of standard job functions (such as process architect and system architect) for building and using applications. Depending on their job function, users see different portal layouts and have different application responsibilities. Access groups define these characteristics.

After installing Process Commander, your system administrator runs the Initial Setup wizard and creates a set of access groups (one for each standard Process

Configuring the Organization, Access Groups, and Users 3-23

Commander job function) to get you started. They are instances of the Data-Admin-Operator-AccessGroup class, which defines the portal layout and application access for a group of people that perform the same job function.

What to Set Up Now Use the requirements you defined in Chapter 2 to determine if you need any access groups in addition to those created by the Initial Setup wizard. You assign an access group to a subset of users who perform similar job functions, regardless of where they work in the organization. For example, in the PegaRP example, all people who develop applications would be in the same access group (such as [email protected]). Consider the sets of business functions to be performed when determining what access groups you need in testing

■ From a business perspective, consider the distinctions among business users, managers, and specialized functions such as legal or regulatory departments.

■ From a development perspective, include testing, application development, and system administration functions. You may want to set up one or more additional access groups for testing purposes.

Setting Up Operator IDs for Your Project Team Work with your system administrator to set up additional operator IDs for the project team members. By convention, user names are in standard Internet e-mail format. Process Commander uses this value for security and identification, so it must be unique across your organization. User names consist of a unique name to identify the person, plus your organization name:

■ The person’s name is a good choice. It is unique, recognizable, and easy to remember (for example, [email protected] or [email protected]).

■ Because operator IDs for representative test users are typically based on job function, you might want to use a name that identifies the function (for example, [email protected]).

mailto:[email protected])

mailto:[email protected]


Follow any existing user naming conventions in your organization. However, avoid special characters such as plus signs, quotation marks, and dashes for legibility and ease of use.

What to Set Up Now At this point, you don’t need to set up the entire user community for the application. Instead, focus on the subset of people who are working with you on the application:

■ Business and technical members of your project team for use in developing the application. Operator IDs for the project team should identify each person by name, and each person should have a unique ID. These people will make design and rule changes that are tracked automatically by the system.

■ Representative test users for use in testing the application. Operator IDs for test users should identify business tasks. People using these IDs will be performing work in the application. The application records, in work object history instances, which users performed which processing. For testing purposes, you want to be able to track this history by individual and task.

Make sure that you have assigned each standard Process Commander job function to someone on your team.

What You Completed With assistance from your system administrator, you:

Created the basis of your organization hierarchy, including the organization and at least one division and unit level.

Created access groups and operator IDs for all Process Commander job functions.

Created operator IDs with appropriate access groups for the business and technical members of the project team, and representative test users.

Step 3 Rule Type Reference 3-25

Step 3 Rule Type Reference At the end of each chapter, a table summarizes the rule types and data classes designed or developed in the corresponding SmartBuild step.

The right column of the table identifies a category. Each rule type belongs to one of ten categories. Rule types in a common category are similar or interrelated. To work with the Explorer tools on the portal, first select a category, and then the rule type within that category. For example the Process category contains twelve rule types including flow rules (or formally the Rule-Obj-Flow rule type), correspondence rules, correspondence fragments, flow actions, and eight others (Figure 3-9).

Figure 3-9. Process Category in the Application Explorer


You work with the following rule types and data instances in SmartBuild Step 3.

Task Rule Type or Data Class Explorer Category

Rules

Create a RuleSet Rule-RuleSet-Name Rule-RuleSet-Version

SysAdmin

Create a top-level class Rule-Obj-Class SysAdmin

Data

Modify the system name (optional) Data-Admin-System SysAdmin

Set up the organization hierarchy and grant access to RuleSets

Data-Admin-Organization Data-Admin-OrgDivision Data-Admin-OrgUnit

Organization

Create access groups and set your default RuleSet for changes

Data-Admin-Operator-AccessGroup Security

Create operator IDs and assign access groups

Data-Admin-Operator-ID Organization



The Process Commander URL for your environment.

An authorized operator ID that allows you to log in as a system architect.

RuleSet and top-level class naming conventions defined.

Number and purpose of RuleSet(s) identified.

One or more RuleSets and versions. Check that the names are useful and meaningful based on the guidelines.

Name of the baseline RuleSet and top-level class for your organization.

A list of users who need access to your RuleSets.

System administrators are typically responsible for setting up the following components, based on the business requirements you provide.

Modified system name (optional).

The basis of your organization hierarchy, including the organization and at least one division and unit level.

A baseline RuleSet with a top-level class to be shared across all applications in the organization.

Standard access groups and operator IDs covering all job functions.

Operator IDs with appropriate access groups for the business and technical members of the project team, and representative test users.

Your RuleSets specified in the organization hierarchy and access groups.

Step 4: Designing the Class Structure

You have now finished analyzing your solution requirements and setting up a development environment. Step 4 of SmartBuild consists of designing your class structure, which defines work characteristics and becomes the foundation for your application. This chapter describes how to approach this effort:

■ Understanding the standard, built-in work and data classes.

■ Defining and refining a class structure that reflects the work in your application.

■ Identifying a class group to establish a work pool.

■ Identifying work parties and other repeating groups.

Don’t rush through this step. It’s important to think through your design before creating anything in your application. A solid class structure is critical to effective rule resolution and an efficient Process Commander application.

Who Does This: System architects typically perform these tasks.

4-2 Step 4: Designing the Class Structure

Important Terms and Concepts The following terms and concepts are important as you begin designing the class structure for your application:

■ When designing the class structure of your application, you define classes that are derived usually from three standard Process Commander base classes:

– Work- classes define the data structures for processing work. You use them as the starting point for the work-related classes in your class structure. Every application requires at least one concrete class derived from the Work- base class. These classes are known as work types.

– Data- classes define the data structures for supporting information that the application uses to process the work support repeating groups (also called arrays). You use them as the starting point for your data-related classes, if any.

– History- classes, created automatically, hold instances that track changes to instances of other classes. The History- classes you need are created automatically as a byproduct of the creation of other classes.

■ Your classes inherit, or automatically include, characteristics from these base classes. You can add application-specific data elements (or properties) and other rules to your classes.

■ Your class structure determines the path of rule resolution for your application. Once your class structure is in place, your team can create rules at the appropriate place in the class hierarchy to define your business policies, practices, and process. Rule resolution follows the hierarchy and inheritance to find the correct rules to apply for each work object and assignment.

■ A work pool represents a collection of work objects of related types. Work pools control how you present work to users who enter and select work objects for processing from one or more designated work pools.

Important Terms and Concepts 4-3

■ To set up one work pool, the Application Accelerator creates a class group (Data-Admin-DB-ClassGroup instance). Process Commander simplifies object management and reporting by storing all work objects in a class group in one physical database table.

■ A work object ID uniquely and permanently identifies a work object within the work pool. You need to specify the numbering format, as well as an optional prefix and suffix, which together represent the unique key.

Class Inheritance To facilitate finding the most appropriate rule to apply, Process Commander supports class inheritance in two directions:

■ Pattern inheritance causes a class to inherit characteristics from classes that it resembles in name, moving up the visible class hierarchy. Look at a class name to determine its pattern inheritance. Dashes are the delimiters for pattern matching. For example, for a class named ABC-DEF-GHI, pattern inheritance searches exactly the following classes in the following order, stopping when it finds what it seeks: ABC-DEF-GHI ABC-DEF- ABC-DEF ABC- ABC Consequently, it would never find classes named AB, AB-, ABC-D, or ABD-DE.

■ Directed inheritance causes a class to inherit characteristics directly from a specified parent class, regardless of any defined pattern inheritance. No class name relationship is involved; look at the class rule form to identify directed inheritance. For example, the class named ABC-DEF-GHI could have a combination of pattern inheritance as described and directed inheritance from Work-.


Pattern and directed inheritance work together for efficient rule resolution. If both are specified for a class, the pattern inheritance search occurs first, followed by directed inheritance. Consider this process from the perspective of the rules engine. To find Rule X, the rules engine follows the class inheritance tree to locate the rule (similar to a Java classpath specification).

The dual approaches to inheritance — directed and pattern — give you more control over how and when business rules apply. Use directed inheritance to leverage standard Process Commander features or define your own core application features. Use pattern inheritance to apply cosmetic or local customizations without affecting the baseline application.

Note: Think of directed inheritance as providing functions and behavior, and pattern inheritance as ensuring consistency across multiple solutions.

Figure 4-1 illustrates how pattern and directed inheritance work together in a class structure.

Figure 4-1. Pattern Inheritance and Directed Inheritance

For a complete presentation of the class inheritance algorithm with examples, see Rule Resolution in Process Commander V4.2, a technical note in the Pega Developer Network area of the Pegasystems Support Network.


Supporting Multiple Customers of an Application in a Single System The two kinds of class inheritance provide an additional advantage when one Process Commander environment hosts two or more instances of one application. You can use inheritance in combination with top-level classes to segregate application processing. For example, assume you are an outsource vendor or service provider who wants to host a loan processing product for several banks who are competitors. For each bank, you can deploy a separate application instance based on your product:

■ For each bank, create a separate RuleSet with a unique top-level class that inherits from your overall product RuleSet using directed inheritance.

■ Make bank-specific changes (such as logos or product lists) in each bank’s top-level (or most general) class. Other classes inherit from the top-level class using pattern inheritance.

Figure 4-2 illustrates a typical class structure for this scenario. The product vendor uses YourCoProduct- for cross-product features and YourCoProduct-ProductX- and -ProductY- for product-specific features. You use ASPCustomerX- and ASPCustomerX-ProductX for customization.

@baseclass

YourCoProduct- (@baseclass)YourCoProduct-ProductX- (pattern and Work-)YourCoProduct-ProductY- (pattern and Work-)

ASPCustomer1-ProductX (pattern and YourCoProduct-ProductX-)

ASPCustomer2-ProductX (pattern and YourCoProduct-ProductX-)

ASPCustomer3-ASPCustomer3-ProductX (pattern and YourCoProduct-ProductX-)ASPCustomer3-ProductY (pattern and YourCoProduct-ProductY-)

Figure 4-2. Sample Class Structure for Multi-Instance Environments


Contrasting Work Objects and Data Objects In contrast to many BPM solutions, Process Commander treats work and data as distinct entities that you define and handle differently from the perspective of class structure. Understanding the difference — and defining work and data classes properly — is critical to designing an effective class structure and an efficient application:

■ Think of work as objects that the application advances through the business process to final resolution, such as a loan request, a software bug report, or a credit card dispute. Standard Work- classes provide many built-in work-related characteristics commonly used in BPM solutions.

■ Think of data as objects that are referred to in the course of resolving the work, such as a list of lending agents, products, or credit card account numbers. Standard Data- classes — such as Data-Party-Person —provide basic data table characteristics without added work-related detail, providing a clean foundation.

Consider the questions in Figure 4-3 as you design your class structure.

Object Type Typical Indicators

Work ♦ Is the object stateful? During the business process, will you track its progress through new, in process, and resolved states?

♦ Will someone perform an action on (or as a result of) the object, such as to approve a loan request, fix a bug, or credit an account?

♦ Will you track service level conformance for the object, such as the length of time open and the desired resolution timeframe?

♦ Will you monitor throughput statistics for a collection of objects, such as how many items are handled by a work group over time?

Data ♦ Is the object commonly attached to a stateful object, such as a list of line items (data) in a purchase order (work object)?

♦ Once initially created, is the object relatively static? ♦ Is there another system of record for the object?

Figure 4-3. Choosing Between Work and Data Classes


Understanding the Work Model Before you begin designing your class structure, you need to understand three types of work objects:

■ Basic work objects capture and process evolving information about an individual unit of work, including supporting attachments.

■ Cover work objects tightly coordinate processing of several other subordinate work objects. Each covered work object belongs permanently to a single cover work object.

■ Folder work objects loosely package many related work objects, covers, and other folders for further review and analysis outside their mainstream processing.

Process Commander creates and manages supporting assignments that advance work objects through the business process. Figure 4-4 illustrates these concepts and the relationships between them.

Figure 4-4. Work Model


Class Structure Design Process Use the following steps to create the first version of your class structure:

■ Clarifying which objects in your application correspond to work — the results of a business process — rather than to data.

■ Identifying collections of work objects that benefit from cover or folder capabilities.

■ Choosing names for each class.

Identifying Work Objects, Covers and Folders For each work type you identified in Step 2, you need to make two fundamental choices for each work-related class. You need to plan:

■ What type of work it represents (the class and its properties).

■ How your application processes that work (the work object and its behavior).

To simplify these decisions, Process Commander includes three classes that each supports a common type of work. Each has predefined user interfaces, behaviors, and properties. Each Work- class in your application should inherit rules (through pattern inheritance) from one of these three:

■ Work-Object-, which defines the simplest type of work object. It represents the basic work unit in Process Commander. Think of a work object as “what gets done or changed.”

■ Work-Cover-, which defines a cover work object. It tightly groups for coordinated processing a small number of subordinate work objects, which are related by a shared end result. Think of a cover as “why these work objects need to be done.”

■ Work-Folder-, which defines a folder. Similar to folders in Microsoft Windows Explorer, it loosely groups many work-related objects. Think of a folder as “why these work objects are temporarily related.”

Class Structure Design Process 4-9

The standard property Work-.pyEventID can link associated related work objects if you don’t need the built-in behaviors of covers or folders. This alternative is useful if you want to relate a group of work objects to a particular common event, such as everything originating from a single phone call that may involve multiple accounts, customers, and issues.

Figure 4-5 compares the features and behaviors for each standard data structure to guide you in defining your work-related classes.

Data Structure Features and Behaviors Consider Alternatives for …

Work Object Basic unit of work. Represents work that is processed individually, with these features: ♦ Easy-to-adapt user interface for capturing

specialized work details. ♦ Common business process management

features, such as service levels and urgency. ♦ Can be grouped within covers or folders.

♦ Coordinating processing of two or more work objects (use covers).

♦ Simultaneously reviewing or analyzing work objects as a group (use folders).

Cover Tightly couples a small number of work objects for processing as a group, with these features: ♦ Coordinated processing of covers and the

associated work objects (or covered objects) for control over process-related communications. For example, the cover object may contain totals or other values that depend on properties of the covered objects.

♦ Locking of covers and covered objects against simultaneous update while a user is performing an assignment that should be coordinated with others.

♦ Resolution tracking for covered objects supports consolidated notification upon resolution of all the covered objects.

Apply business process management features (such as service levels and urgency) independently for a cover and its objects.

♦ Grouping a large number of work objects — locking precludes massive parallel processing (use work objects).

♦ Adding multiple levels of covers, folders, and work objects (covers can only group work objects, and a work object can only be covered by one cover).


Data Structure Features and Behaviors Consider Alternatives for …

Folder Loosely affiliates a few or many objects of any type for closer scrutiny as a group, with these features: ♦ No built-in processing or locking. ♦ Ideal for analytical or business review

outside the primary work flows, such as finding work objects which have a common industry, geography or product feature

♦ Applying BPM features such as service levels and urgency — not used for folders (use covers or work objects).

♦ Capturing details used in processing the object — folder not visible (use covers or work objects).

Figure 4-5. Work-Related Structures

Helpful Hints

■ See Step 6, “Adding Properties and Sample Data,” for more information about the pyEventID property and working with properties.

■ When choosing the appropriate data structure for a class, consider what human behaviors the work represents in the business process:

– If the unit of work fits the description of “someone actually performs this work,” use a work object.

– If the unit of work fits the description of “this is the reason someone needs to perform this, and perhaps other, work,” a cover or folder might be better.

– Before you finalize your class decisions, carefully consider the names of the units of work in this context to help ensure appropriate underlying data structure.

■ If you have work objects that represent groups of things, use either covers or folders:

– If the work objects must stay together or they require coordinated processing and resolution, use a cover.

– If more than one person needs to process a work object at the same time, or if you need to process many work objects either in parallel or simultaneously, use a folder.


■ When deciding whether to use a cover, review the projected volume of work objects that will be created. As you begin designing your class structure, the following table is useful for organizing and analyzing this information:

Work Type Description # of Covered Objects # of Instances Per Day

■ Follow these general size/volume guidelines when choosing between using a cover, a folder, or a work object:

– If you want to take advantage of coordinated cover processing and expect to have between 2 and 10 covered objects, a cover is a reasonable choice.

– If you expect to have 20 or more covered objects, a folder is a better option. The locking features that support coordinated cover processing could produce a bottleneck.

What You Completed Identified which of three standard work classes (Work-Object-, Work-Cover-,

and Work-Folder-) are needed as parents to the work types in your application.

Deciding Where to Define the Class Structure Process Commander includes an extensive class structure. Many classes support internal processing and other operations. However, the classes you create in your class structure typically inherit many rules from a Data- or Work- branch.

Design your class structure from the top down:

■ Always start the class structure for your application with an application parent class (such as MyCo-MyDiv-MyApp). This is a subclass of a division-level class (MyCo-MyDiv-) which itself is a subclass of the organization top-level class (MyCo-), created by the Initial Setup wizard. (In a large organization,


these three classes should belong to distinct RuleSets, corresponding to organization rules, division rules, and application-specific rules).

■ Use the Application Accelerator to add the application level-class (MyCo-MyDiv-MyApp), which is also the class group, and the work types. These have both directed inheritance from a standard Work- class (such as Work-Object-) and pattern inheritance from MyCo-MyDiv-.

■ Use the Class form to add other subclasses that typically have pattern inheritance only.

Figure 4-6 shows how four work types in a typical application fit into the hierarchy of standard classes (shaded boxes). The solid arrows identify directed inheritance; the dashed arrows identify pattern inheritance. Numbers show the sequence of classes that may be searched when a rule is needed for the work type MyCo-MyDiv-MyApp-Type2. The concrete class MyCo-MyDiv-MyApp corresponds to a class group holding all four work types in a single work pool.

Figure 4-6. Typical Application Structure for Work Classes


Figure 4-7 shows a portion of a class structure that includes an application data class, MyCo-Data-MyData, using the same notation as Figure 4-6. Some application classes may be directed to standard classes derived from Data- rather than to the Data- base class itself. Similarly, some application classes may apply only at the division, application, or work type level rather than to the whole organization.

Figure 4-7. Application Structure for Data- Classes

Choosing Class Names and Relationships The next task is to begin designing the class structure. The easiest way to start is to design offline, either on paper or in a Unified Modeling Language (UML) tool. You can analyze the evolving structure and make changes easily. Review the requirements you defined in Chapter 2. Then follow these steps to design your work types and other classes:

1. List the major types of completed work in your application. Think in terms of work output. Categorize them into related types of work if appropriate. These items correspond to your work object classes.


2. List the primary groups of coordinated work in your application, if any. These items are your cover and folder classes.

3. Identify the inheritance for each class, including the appropriate Process Commander data structure.

4. Document your design as you go.

At the beginning, use an outline format to capture your evolving class structure. This provides visual clues to identify potential sources of later confusion, including inconsistent naming, unclear terminology, and structural parallelism. As your class structure evolves and becomes larger or more complex, a tree diagram can be helpful.

Once you’ve identified each unique type of work, consider any relationships that might require coordinated process. Update your class structure to include cover and folder functionality as needed. At first, base your work on individual work objects and limit the number of relationships (for example, covers and folders).

Class Naming Conventions

■ Adopt logical, descriptive naming conventions for your class structure. Classes represent units of work, so class names are generally nouns to distinguish them from actions and processes.

■ Class names are visible labels in rule forms, developer tools, and other areas of an application. Use class names that are self-explanatory and reflect the purpose of the work. Avoid using class names that reflect status or action instead of a unit of work.

■ As in naming RuleSets, use single-word names with significant letters in uppercase for legibility. Case is significant; use only letters, digits, and dashes. Start each segment (after a dash) with a letter.

■ Keep class name segments short. The total length of a class name is limited to 64 characters. (This restriction is derived from limits in Microsoft Windows directory pathnames.)


■ Choose class names that support pattern inheritance as well as directed inheritance.

■ Abstract class names end with a dash character; concrete class names do not.

■ Choose class names that clearly convey pattern inheritance. Subclasses must include the names of all parent classes (including the top-level class), separated by dashes. For example, if the parent class YourCo-FinanceDiv-LoanRequest has subclasses for mortgage and car loan applications, name them YourCo-FinanceDiv-LoanRequest-Mortgage- and YourCo-FinanceDiv-LoanRequest-Auto-.

Class Structure Guidelines

■ Think in terms of work output — focus on completed work in the application. Avoid defining a class structure that forces the user to understand an underlying process in order to enter a work object.

■ For applications that are to be distributed as products, use TopLevelClass-BusinessPurpose-DataStructure-WorkType-ClassPurpose as a structural model. For applications, use Company-OwningDivision-DataStructure-WorkType-ClassPurpose.

■ When choosing the location of a Data- class, consider whether the data is used by the entire organization or other applications in the division (place it higher) or supports a single work type (place it lower).

■ Define classes based on the structure of the work objects, rather than purpose/state (use properties) or access (use security mechanisms).

■ Consider projected volume in deciding whether a type of work should be a class of its own or merely a property of another class. If you think there will be many work objects, create a separate class. If you think there will be relatively few work objects, create a property for an existing class to differentiate them.

■ For ease of management, a class structure with fewer levels is better. If you are adding many subclass levels, consider using additional parent classes instead.

■ With every class decision, review its impact on the existing structure. Validate and revise your class model as it evolves. Start to think about data, properties,


and business scenarios to differentiate between classes. Consider how classes relate to each other — what they have in common and how they differ.

■ If you’re building an application to be distributed as a product, first define a full set of abstract classes. This approach gives you the ability to extend and ship the classes without worrying about customer impact. Customers copy the abstract classes and deploy them as concrete classes in their environment, without affecting the abstract class definitions.

■ Consider creating a separate class for a particular work object if you want to differentiate the following capabilities:

– Different types of notification regarding progress and completion.

– Different routing based on critical work properties.

– Different service levels for work completion.

– Different work processing restrictions.

What You Completed Defined class naming conventions.

Identified the work types and other classes in your class structure.

Designed and documented your class structure, including work and data classes and the inheritance of each.

Refining the Class Structure 4-17

Refining the Class Structure After you have defined your class structure, step back and review the class diagram as a whole to identify additional refinements:

■ Ask your business users whether the outline form of your class structure makes sense in the context of the business process. If it is not clear to them, continue to refine the structure before proceeding.

■ Check whether each class layer adds value. If you can’t explain the added level of control or definition, the extra layer may not be useful.

■ If you can’t distinguish two peer subclasses in terms of properties, the subclasses probably don’t need to be separate. For example, car loans for imported and domestic cars have the same data, so the separate subclasses (such as YourCo-Loan-AutoImported- and YourCo-Loan-AutoDomestic-) are unnecessary.

■ Look for opportunities to combine classes, especially among peer classes which have no subclasses. For each set of peer classes, make sure the distinctions are clear and meaningful; if not, consolidate them or eliminate some. Check that you haven’t defined essentially the same work multiple times. If you seem to have many similar classes, identify the properties that might be different.

■ Expect to add concrete classes as your design and development efforts progress. However, if you find yourself adding many abstract classes later, this probably indicates a problem in the original class structure.

■ Consider whether rule resolution will find properties and other rules as intended when searching through the class tree. Remember to consider the contributions of first pattern inheritance and then directed inheritance.

■ Look for similar properties listed in multiple places. If you find any, find a place higher up in the class structure where you can define the property once.

In object-oriented terminology, refining class hierarchies is known as refactoring; formal techniques are available. To learn more, visit the Refactoring Home Page at www.refactoring.com.


Identifying Work Pools (Class Groups) With the class structure designed, you need to think about how to group work types in your application. Process Commander uses work pools for this purpose. A work pool is the visible representation of a collection of related work that is routinely numbered, managed, and reported together. Users enter, select, and perform work in one or more designated work pools, as defined by their application access.

Each application has a work pool, although some applications require more than one. A work pool is defined by a class group instance (Data-Admin-DB Class Group) Instances of all classes in the scope of a class group are stored in one physical database table, which improves the performance of reporting on related work.

Class groups can also provide an enhanced level of security by allowing you to segment information in the database. For example, assume you are developing an application to manage work performed on behalf of different customers in a shared environment (for example, a service bureau that processes transactions for several bank credit card issuers). For each customer, you can create a unique top-level class that includes a distinct class group. This class structure provides control over both work pool and database access.

Applications Requiring Two or More Work Pools The Application Accelerator creates a single class group instance corresponding to the Application Parent Class. The class group includes all work types in a single work pool. If this approach is suitable to your application, you can skip ahead to the next section of this chapter. If your class structure includes many work types, folders, covers, or unusual reporting requirements, you may design additional class groups.

Follow these guidelines to define how many class groups you need:

■ Work types that are similar in definition and purpose belong in a single class group. For example, define one class group for purchase requests and purchase orders created by employees, but a separate one for customer orders.

Identifying Work Pools (Class Groups) 4-19

■ Put work types in a common class group if users want to easily see all the types of work in a single report, or if you want users to be able to choose among the work types when entering or searching for work. For this reason, put folder and cover classes in the same class group as any associated work object classes.

■ If your application needs to convert work objects from one work type to another or search for duplicates, put the work types in a common class group.

■ Assume you are developing an application for service providers to use on behalf of a few competing external customers (such as industry service bureaus and shared operations centers). For each customer entity, define a unique top-level class with a distinct class group.

Identifying Where Class Groups Belong in the Hierarchy If your application requires two or more class groups, you next need to determine where in your class structure each class group is to reside. The decision controls which classes belong to the class group. Following pattern inheritance only, subclasses belong to the same class group as their parent class. Consider this decision carefully, as you may need to refine your class structure as a result:

A class group is a data object, an instance of the Data-Admin-DB-ClassGroup class. However, as name of a class group is the same as the name of the class that is the (pattern) parent of the classes assigned to the class group, a class group is often thought of as a location within the class structure.

Helpful Hints

■ Consider using bold type to make class groups easily visible in your class structure outline or diagram.

■ If you’re building an application to be installed in multiple systems as a product, allow a level for class groups once deployed. For example, the product RuleSet for the PegaRP example has only abstract classes. However, the RuleSet to be deployed includes a class group for the work objects defined at PegaRP-Sample-Work. During deployment, a special wizard assists in creation of the customer-specific classes.


Defining Work Object IDs Process Commander assigns a unique key (or work object ID) to identify each entered work object. This work object ID consists of an alphanumeric prefix, followed by a dash and a sequence number, and optionally followed by a dash and a suffix. You specify the prefix during development; a standard Process Commander activity Work-.GenerateID assigns the number.

Work object IDs are unique within work pool and organization. As a best practice, use different prefixes or suffixes for each work pool. If you follow this practice, work object IDs do not change when work objects are converted between work types (within one work pool). If necessary, however, you may choose different prefixes or suffixes for each work type rather than each work pool.

Note: If the standard approach doesn’t meet your application needs, your application can override the GenerateID activity with your own activity.

Once assigned, the work object ID is a permanent part of the work object, and (together with the work type) forms the database key of the object. Process Commander uses the work object ID as a label in many places, including worklists and electronic links to other objects. Choosing a unique and descriptive prefix is important:

■ Worklists can display work objects from more than one application. Well-selected work object IDs help users see at a glance which application generated the work object.

■ Work object ID prefixes ordinarily are one to five characters long. Use them to define work object IDs that clearly identify your application and/or business purpose. This decision is especially important for settings where users work in multiple different applications.

Defining Work Object IDs 4-21

When you use the Application Accelerator to create an initial version of your application, enter the prefixes (with no final dash character) for individual work objects and for cover objects in Step 2 (Figure 4-8).

Figure 4-8. Application Accelerator — Work Object Prefixes


Helpful Hints

■ As an example, assume you have an application that has one class group for purchase orders created by employees and a second class group for customer orders. This application also has work objects, covers, and folders in both class groups. Figure 4-9 illustrates a work object ID numbering scheme that identifies both the class group (EMP or CUS) and the object type (work object, cover, or folder).

Object Employee Orders Customer Orders

Work objects EMPPO-# CUSPO-#

Covers EMPCV-# CUSCV-#

Folders EMPGP-# CUSGP-#

Figure 4-9. Work Object ID Numbering Scheme

■ Using a distinct prefix for each work pool is especially helpful if people use many different applications, but it is critical for service bureau situations.

■ Using a distinct prefix for each class (each work type) may be appropriate in some situations. However, this type of numbering scheme quickly becomes confusing if your application includes many work types.

What You Completed Identified the work pools (class groups) in your application.

Identified work object ID prefixes.

Determining Work Parties and Sources 4-23

Determining Work Parties and Sources The next task is to identify the classes that describe the primary work parties (people or entities, such as facilities or regulatory agencies) that might be interested in the progress and/or disposition of that work. Review the requirements you defined for parties in Chapter 2 before proceeding.

Note: This part of your design does not apply to people who perform work in the application. Those people are identified based on their roles as system users.

Standard Work Party Features Work parties are important elements of any business process management application. Process Commander has several features to simplify how you define and implement them:

■ For each work party, you define a name for the party role (such as lender or customer), the party type (such as a government agency, business entity or individual), and the class that holds instances of people or entities with that role.

■ Work objects include a Page Group property (similar to a repeating group structure in many programming languages) for handling work party information, which allows users to specify multiple work parties of different classes for a work object.

■ You can create a list of work parties and the associated people or entity class instances to choose from, without changing the database schema.

■ For each party in a work object, Process Commander maintains a universal resource identifier (URI) (property pyWorkPartyURI) and a party role (property pyWorkPartyRoleURI). This feature means you can identify a party in two ways, one that is generic to the application (such as customer ID) and one that is specific to the role that that party plays in a work object (such as account or VISA card number).


■ Whenever a user changes the work party URI or party role URI for a work object, a standard activity (Data-Party-.WorkPartyRetrieve) refreshes the party information.

■ To support work party selection and reporting, Process Commander also automatically synchronizes the work party index using a standard Declare Index rule named Work-.PartyURI (see Step 12 for more information). This rule creates an index instance to allow, for example, quick retrieval of all the open work objects that contain a specified customer.

Identifying Work Party Classes Process Commander includes five standard classes that have predefined properties for common types of work parties:

■ Data-Party-Com defines a corporation or other commercial entity.

■ Data-Party-Gov defines a government agency.

■ Data-Party-Operator defines staff members who are also Process Commander users.

■ Data-Party-Org defines an organization entity.

■ Data-Party-Person defines any person who is not a Process Commander user.

You can use these classes as they are, extend them in your RuleSet to suit your needs, and also define other classes that inherit from Data-Party. If you create new classes, create and name them appropriately in your class hierarchy. For example, in the medical industry you might create the Data-Party-Medical class to collect information specific to a hospital or doctor (properties, sections, etc.) when processing a claim.

Note: Update your class structure diagram to include any additional Data-Party classes you need for work parties.

Determining Work Parties and Sources 4-25

Figure 4-10 suggests a format for defining work parties.

Role Type Process Commander Class Data Source

Lender Company Data-Party-Com Banking application

DeptManager Staff Data-Party-Operator Process Commander

ExtCustomer Person Data-Party-Person Customer database

Figure 4-10. Format for Defining Work Parties

When you use the Application Accelerator to start application development, identify the work party roles and classes in Step 3 (Figure 4-11).

Figure 4-11. Application Accelerator — Entering Work Parties


In this example, the Originator work party is the Process Commander user who enters the work object. Other work parties identify a vendor corporation (Data-Party-Com class), a sales contact, and an inspector. The final row allows information for one or more “interested” individuals to be recorded in the work object. Conventionally, an interested party may receive news about a work object, but the party has no legal rights or responsibilities and lacks authority to provide information or make decisions affecting the progress of the work object.

What You Completed Identified the primary work parties that are interested in the process,

including the data source for people or entities.

Identified the standard work party data structures (Data-Party classes) and any custom work party classes needed in your class structure.

Establishing Additional Repeating Groups 4-27

Establishing Additional Repeating Groups The last task in designing your class structure consists of determining whether your work object structure needs repeating groups (in addition to the Page Group for work parties). If so, you may need to design additional classes into your class structure to represent or support these data structures.

■ Choose a concrete class derived from the Data- base class if there is a need to save instances of the class separately from the work object, and each instance has a unique key.

■ Choose an abstract class derived from the Embed- base class if there is no requirement to save instances of the class separately from the work object itself.

Re-examine your work object structure as it is currently defined. Consider whether any work objects (when they are resolved) might contain multi-valued properties where a repeating group would be useful. For example, if you are building a purchasing application, you may want a repeating group for capturing items selected for purchase. If you are building an application that requires varying types of research to resolve a work object, you may want to use a repeating group to capture the research steps.

Make the following decisions for each proposed repeating group you need:

■ Name and purpose of the repeating group.

■ Properties within the repeating group.

■ Data sources if data resides currently in another system.

Include a Data- or Embed- derived class placeholder in your class structure design for each identified repeating group. You learn more about data classes in Step 6: Adding Properties and Sample Data.


Additional Ways to Reference Information in Work Objects Process Commander offers multiple ways to store data that is associated with a work object. Consider the space requirements, memory requirements, frequency of access when choosing the best approach for each substructure. You can:

■ Maintain the data only in the work object, as for work parties. Because the data becomes part of the work object, it is not shared with other work objects, unless explicitly copied.

■ Store the underlying data outside the work object, in other instances of other concrete classes and then store in the work object a key or reference. Because the data is stored separately, it can easily be shared by multiple work objects.

■ Store the information as an attachment to the work object, accessed only upon request of a user rather than routinely, each time the work object is accessed.

■ Create a concrete class derived from the Link- base class and special activities to maintain and follow links.

In general, large or infrequently accessed data is best stored as a separate object with a reference, for system performance reasons. Step 7: “Tailoring the User Interface” provides more information on attachments and links. For now, decide whether you need additional repeating groups, and assess the storage and performance implications. Figure 4-12 compares these options.

Feature Repeating Group Attachment Link

Description Embed data as a repeating group in the work object.

Attach data to the work object.

Create a standalone class for the data, with a directional pointer (or link) that references it.

Requires Another Class?

Sometimes — may require a Work-, Data-, or Embed- class.

Yes — inherits from Data-WorkAttach- class.

Yes — inherits from Link-Attachment class.

Retrieves Data with Work Object?

Yes — always, even if not requested. No additional database reads, but can slow displays.

No — on request only. No — on request only.

Establishing Additional Repeating Groups 4-29

Feature Repeating Group Attachment Link

Requires Additional Key?

No — not applicable. No — automatically created based on the work object key.

Yes — explicitly create the key in your application. Simplifies information sharing between objects.

Requires Data Duplication?

Yes — associated only with the work object where embedded. Must duplicate to associate with more than one work object.

Yes — permanently attached to a single work object. Must duplicate to associate with more than one work object.

No — multiple work objects can point to or from the data without duplication.

Best for Source Data that is …

♦ Viewed frequently. ♦ Relatively small

(<2,000 bytes). ♦ A manageable number

of records (dozens or fewer).

♦ Viewed occasionally.

♦ Relatively small. ♦ Associated with

only a few objects.

♦ Viewed occasionally. ♦ Divided into many

subgroups. ♦ Relatively large. ♦ Associated with many other

objects.

Figure 4-12. Comparing Data Structure Options


Final Class Structure Check Before moving on to the next step, take a few minutes to evaluate your class structure for efficiency. Revisit the criteria for work objects. Then check for the following opportunities for refinement:

■ Does your structure contain any repeating groups that would be better as covered objects, in order to benefit from the associated business process management features?

■ Do you have any covered objects that would be more efficient as a repeating group because they don’t need the added processing (such as extra fields and work object IDs)?

What You Completed Identified additional repeating groups, including selected presentation

options.

Identified standard data-related data structures (Data- or Embed-) needed in your class structure.

Refined your class structure for efficiency and optimal use of repeating groups or covers.

Step 4 Rules Reference 4-31

Step 4 Rules Reference In this chapter, you designed your class structure either on paper or a UML tool. While you did not create any rules or data instances, you worked with the following standard classes in this SmartBuild step.

Task Class

Define a class that inherits from the standard work object class Work-Object-

Define a class that inherits from the standard cover class Work-Cover-

Define a class that inherits from the standard folder class Work-Folder-

Define a class that inherits from the standard work party class Data-Party-Com Data-Party-Gov Data-Party-Operator Data-Party-Org Data-Party-Person

Understand alternatives for presenting repeating groups Data-WorkAttach- Link-Attachment

Define a class that inherits from the standard data class (instances stored in database)

Data-

Define a class that inherits from the standard embedded object class (instances not stored in database)

Embed-



A list of data structures to be used in your class structure: – Work (Work-Object-, Work-Cover-, Work-Folder-) – Stored data (Data-) – Embedded, but not stored, data (Embed-) – Work party (Data-Party-)

Naming conventions for your class structure and class groups.

A list of new classes in your application, organized hierarchically.

The number of work pools in your application.

Work object ID prefixes.

A list of class groups, including their position in your class structure.

A list of primary work parties that are interested in the process, including the standard or custom work party class to inherit from and the data source for people or entities. A table is a useful format for organizing this information.

A list of needed repeating groups, including the selected presentation options and supporting Data- or Embed- classes if needed.

Class structure refined for efficiency and optimal use of repeating groups or covers.

Design documentation for your class structure with both Work- and Data- classes, showing inheritance. Outlines and tree diagrams are useful formats for organizing and presenting this information.

Step 5: Building the Class Structure and Reviewing Work Objects

In SmartBuild Step 5, you create the class rules (Rule-Obj-Class rule type) in your RuleSet that implement the structure designed in Step 4. You also research standard properties in the Work- class to identify those your application can incorporate directly. This chapter describes how to:

■ Create the class structure, including class groups to establish work pools.

■ Set up work parties.

■ Add basic flows for processing work.

■ Enter and review the first work objects.

This SmartBuild step highlights the advantages of building on standard rules. By the end of this chapter, you will be able to enter and review simple work objects.

Who Does This: System architects and process architects typically perform these tasks.

5-2 Step 5: Building the Class Structure and Reviewing Work Objects

Important Terms and Concepts The following terms and concepts are important as you begin to create the class structure for your application:

■ By following a top-down approach to creating the class structure, you establish a place to store properties and other rules that apply across several leaf classes. For example, to create the YourCo-CustService-Loan class, you need to create its parent classes — first YourCo-, then YourCo-CustService-, and finally YourCo-CustService-Loan.

■ The Explorer tools are helpful for navigating and reviewing your class structure as it evolves. Click the Manage Rules bar in the navigation panel to access them.

■ The standard property Work-pyID holds the unique identifier of each work object. All classes derived from Work- inherit this property. Always use pyID as the key for classes derived from the Work- base class and for class groups.

■ For keys of concrete classes other than work types, use any property or properties with values that makes each instance unique.

■ Locking prevents multiple users from simultaneously updating an object. Always use locking for work-related classes, specifying the same key parts for the lock and the class.

Note: Other Explorer tools display different combinations of classes, rules, or data instances. Refer to the Application Developer Help for more information about using the Explorer tools.

Using the Application Accelerator Approach 5-3

Using the Application Accelerator Approach If your application design contains only a few work types and a single work pool, the Application Accelerator can create the required class rules (one for each work type) and the class group (for the work pool). Even for more complex application designs, you can employ the Application Accelerator as a starting aid. After the Application Accelerator completes, you can adjust the classes it created and use the Class form to create additional classes as needed.

When you use the Application Accelerator to create an initial application, enter a label and a class name segment for each work type in Step 2 (Figure 5-1).

Figure 5-1. Application Accelerator — Work Types

In this example, the Application Accelerator is instructed to create classes for three work types:

■ ACME-Finance-Post with Post Invoice Detail as the label.

■ ACME-Finance-Reconcile with Reconcile to Bank as the label.

■ ACME-Finance-Closing with Closing as the label.


These three classes are all derived from the Work-Object- class. A form that appears later in the Application Accelerator accepts similar information for a cover work type, to create a class derived from the Work-Cover- class (Figure 5-2).

Figure 5-2. Application Accelerator — Cover Classes

The remainder of this chapter provides guidance for entering more complex class structures than the Application Accelerator creates, such as those involving folders or multiple work pools.

If you start with the Application Accelerator, continue with “Entering the First Work Objects” on page 5-13. The Application Accelerator also creates the other rules described in this chapter:

■ Work parties rules.

■ Basic flows.

Using the Class Rule Form Approach 5-5

Using the Class Rule Form Approach If you choose to build the class structure using rule forms rather than with the Application Accelerator, the sequence is important. The following sections provide guidance on:

■ Sequence for building the class structure.

■ Completing the class form.

■ Identifying class groups.

Sequence for Building the Class Structure Follow this sequence if you are creating application components manually, or if you add classes or class groups later. These guidelines summarize how to complete this process:

1. Work from the Application Parent class down.

2. Create all the classes that derive from Work- before those that derive from Data-

3. To create a class that corresponds in name to a class group, select “is a class group” on the Basics tab of the Class form. When you save the form, Process Commander creates a corresponding data instance (Data-Admin-DB-ClassGroup) automatically. These are known as container classes.

4. After creating a class group, create the additional classes that belong to the class group. The names of subclasses contain the class group name as a prefix. They inherit the key and locking features of the class group.

5. Repeat steps 3 and 4 for each class group in your application.

6. Work with a system administrator to map each class group to a database table in the PegaRULES database as needed. For work types with names that do not begin with Work-, an administrator must create an instance of Data-Admin-DB-Table that maps the class group to the pc_work table (the table that by defaults holds work objects) or to another suitable database table. See the Administration and Security book for more information.

7. Create the class rules for classes derived from Data-, such as for work party types, repeating groups, or other supporting data.


Helpful Hints

■ Use your class structure diagram as a reference.

■ Use the Application Explorer during and after the process to check that the structure reflects your design. When you’re finished, confirm that all leaf classes are concrete.

■ Start with a core class structure and add complexity (for example, number of classes and layers) in planned phases. You can expand the class structure at any time. However, reworking a complex class structure to address a mistake takes more time and effort.

■ If you are building an application to be installed as a product with multiple distinct customers on one system, make sure your class structure includes an abstract class placeholder at the appropriate level for the class group, to support customer deployment. (Step 4 compared the class hierarchy differences between products and applications.)


PegaRP Example Figure 5-3 shows the sequence for creating classes for the PegaRP example.

Figure 5-3. Creation Sequence for the PegaRP Class Structure

Because PegaRP represents a product, all classes are abstract. Notice the PegaRP-Work- class. Here, the class name includes the generic term “Work” instead of something more descriptive. This naming approach clearly distinguishes work classes from data classes, yet encourages customers to change their corresponding class name to reflect their environment. While the class is abstract, it is also a placeholder for the start of a class group. You create a separate for-deployment RuleSet with a class group and concrete classes for customers to deploy. For more information see Step 13: “Deploying and Evolving Your Application”.

Completing Class Rule Forms Using your design as a reference, you can now build the individual class rules in your application RuleSet. For now, focus on creating the classes that are derived from the Work- and Data- classes. With these classes in place, you will be able to


preview a functioning initial application, by entering and reviewing a default work object. This approach fosters a productive review of user interface requirements with business team members.

Note: You can also create classes that are derived from Process Commander base classes other than the Work- and Data- base classes, including Embed-, Index-, Link-, and Assign-. These are addressed later in this book.

Helpful Hints for Work Pools

■ Always use the pyID property as the key for class groups that define work pools.

■ Because instances that belong to a class group are stored in a single database table, they have a common key structure. You can specify key properties only for the class that corresponds to the class group, rather than individually for each class.

■ An administrator must update the access groups for your team to reference each work pool in the application. This makes the work pools visible on the portal. Work with your system administrator to perform this task. Affected users must log out and log back in to make this change effective.

Helpful Hints for Classes

■ Make sure your class hierarchy is well designed before you create the class rules in Process Commander. Making major structural changes to a class hierarchy later in application development can be time consuming and error prone.

■ Use the New toolbar button or the Application Explorer new rule function to create a class, so that you start with an empty Class form. If instead you copy an existing class, you may overlook fields on the Class form that you should enter, and they can be time consuming to fix later.


■ Use directed inheritance to inherit from the Work- classes (Work-Object-, Work-Cover-, or Work-Folder-) at the appropriate places in your class structure (typically parent classes).

■ On the Locking tab of concrete classes derived from the Data- base class, record the properties that form keys. Because these properties link the class to the database, you can’t change the list of properties once you save the class form.

■ If you make a mistake with a class key, delete the class rule and create a new one. However, you cannot delete a class when other classes or rules (for example, properties and flows) refer to it. You must first delete the referring rules or subclasses.

What You Completed Built the class structure, including a container class that starts each class

group and the class group itself.

Updated the appropriate access groups to include your class groups, with assistance from your system administrator.


Creating a Work Parties Rule Step 5 is almost complete. Next, identify which work parties are to be referenced in which work types, by creating work party rules.

Understanding Work Party Components For each of the five classes derived from the Data-Party- class, Process Commander provides many properties, displays, and other features, defined through standard rules. Your application can take advantage of these features by linking the work parties you identified in Step 4 to these Data-Party- classes.

A work party rule (of type Rule-Obj-WorkParties) defines the list of parties and roles for one work type. This rule determines what fields appear for each party on work object forms, which roles are required or optional, and whether a role may appear more than once.

Creating a Work Parties Rule 5-11

By default, work object forms present work party roles (defined by a rule named Default) in a selection box (Figure 5-4). As users select one role from the list, the associated fields for the party appear on the form. Alternatively, your application can choose to display the fields for a work party automatically (as shown by the Customer fields ) without requiring users to select the party type.

Figure 5-4. Fields for Customer Work Party

Entering a Work Parties Rule The Application Accelerator automatically creates a work parties rule for each work type in your application. You can also create a set of work parties by completing the Work Parties rule form.

Work Parties rules are of type Rule-Obj-WorkParties, which belongs to the Process category in the Explorer tools.

■ To take advantage of standard work party features, enter Default in the New form as the name for every work parties rule.

■ The simplest method is to associate work parties with the top-level application class (such as YourCo-CustService-). This makes the list available to all work types. You can move it lower in the hierarchy later, as well as create sets of work parties for other work types.


Figure 5-5 shows the rule form that defines a set of work parties. Refer to Application Developer Help system to identify what to enter in each field.

Figure 5-5. Work Parties Form

What You Completed Created one or more work parties rules in your RuleSet.

Entering the First Work Objects 5-13

Entering the First Work Objects Before you can enter and review work objects, you need to add one or more flow rules to your application.

Adding Flow Rules for Experimentation Flow rules are a key part of your application. They define how work of a particular class moves through the process to resolution. Flow rules are presented and developed in Steps 8 and 9. The flow rules needed for Step 5 support experimentation and learning only. They do not yet reflect your business process.

When you use the Application Accelerator to create an initial version of the application, you choose (for each work type) one standard flow to copy into the RuleSet from a short list of standard flows. The choice you make is not crucial as it is likely that extensive editing and revisions are needed eventually, regardless of your choice, to the copied flow

If you do not use the Application Accelerator, you can add one flow rule now to each concrete class, by copying the standard flow named Work-.NewWork. This simple flow supports the basic tasks common to any business process — creating, entering, performing, and resolving a unit of work.

When you create flows, you create rules of type Rule-Obj-Flow in your RuleSet. As you copy the Work-.NewWork flow, choose a Short Description for the copy that describes the work type, such as Loan Request.

You have reached the final and easiest part of Step 5. At this point, your RuleSet includes everything necessary to enter a work object.

Note: Even for large projects, expect to reach this point in the design process within a week or two of the project kickoff. If your team has taken much longer, refine your requirements to focus on the core features.


Entering Work Objects of Each Type To enter and review a new work object in your application, follow these steps to run the flow rules you just created:

1. Access the Dashboard home layout and click the Processes for Application section in the workspace (see Figure 5-6). Select the flow from the selection box, and then click Start Process.

Figure 5-6. Processes for Application Section

Note: This list displays the value entered in the Short Description field for each flow.

2. A default New Work form appears, as shown in Figure 5-7. The form includes a default Parties section if you did not create a work parties rule.

Figure 5-7. Entering a New Work Object for Your Application

Entering the First Work Objects 5-15

Note: The form title (in this case, New Loan Request) consists of New plus what you selected from the selection box. This value is the Short Description for the flow you selected.

3. Click Create.

4. You have created the first work object in your application. Don’t enter any information yet. Click the Expand All button (located in the upper-right corner) to fully expand the form. Print the form for reference and analysis.

5. Repeat for other work types.

What You Completed

Entered and printed a standard work object in your application.

Reviewing the First Work Objects Your next task is to become familiar with standard Work- properties. Process Commander provides properties and behaviors that are common to BPM applications, freeing you to focus on application-specific needs. After you understand the standard facilities, you can identify additional properties needed and add them to your RuleSet. The next chapter provides details on creating new properties.

For now, follow these suggestions to get the most out of reviewing the default work objects:

■ Enter at least one work object for each work type in your application.

■ Note that each form consists of several distinct elements known as sections. Process Commander provides behaviors and computations for each section. As you consider additional properties for your application, organize your thinking around the standard sections.

■ Start to think about how to document a propertygap analysis for each work type. This analysis is typically recorded in a table or spreadsheet.


Note: Involve your business analyst and other business members of your team in this review, so they also become familiar with the standard forms and properties. Business expertise is critical for success as you move into the next step in the design process.

What You Completed

Printed a copy of each entered work object, with your notes for additional properties.

Reviewed standard properties on work object forms, noting their overlap with your requirements.


Step 5 Rules Reference You work with the following rules and data instances in this SmartBuild step.

Task

Rule Type or Data Class

Explorer Category

Rules

Create classes that inherit from the standard Work- base class

Rule-Obj-Class SysAdmin

Create a set of work parties Rule-Obj-WorkParties Process

Create one or more basic flows based on NewWork Rule-Obj-Flow Process

Data

Review or update a class group (created automatically) that establishes a work pool

Data-Admin-DB-ClassGroup SysAdmin

Map a class group to a database table if necessary Data-Admin-DB-Table SysAdmin

Grant access to a work pool Data-Admin-Operator-AccessGroup

Security

Create classes that inherit from the standard Data- base class


Create classes that inherit from the standard Data-Party- work party class




Class structure created in your RuleSet, including a class that starts each class group and the class group instance itself (created automatically).

A work party rule or rules created in your RuleSet.

Basic flows created in your RuleSet.

One or more work objects entered in your application. Be sure to enter at least one work object of each work type.

A printed copy of each entered work object, with your notes regarding additional properties that are needed on the form.

Review of the standard properties on work object forms, noting the overlap with your requirements.

Work with your system administrator for the following components.

Access groups for your application updated to reference your class group.

Class groups for your application linked to appropriate database tables.

Step 6: Adding Properties and Sample Data

After the application class structure is in place, you can focus on the data elements — property rules, in Process Commander terms — of your application. SmartBuild Step 6 consists of creating application-specific properties and other data-related components:

■ Identify which standard, built-in properties your application can use.

■ Create additional properties as needed, to supplement the standard properties.

■ Create model rules to initialize property values for each work type.

■ Create declarative rules to constrain or automatically compute the value of selected properties.

■ Identify and create classes to hold supporting data, if needed.

■ Simulate external system connections with sample data, if needed.

Who Does This: System architects typically perform these tasks.

6-2 Step 6: Adding Properties and Sample Data

Important Terms and Concepts The following terms and concepts are useful as you begin creating additional properties and sample data for your application:

■ Process Commander includes standard properties for use in your application. Each property has a class that it applies to, a name, a mode (such as Single Value or Page), and often a type (such as Integer, DateTime, or Text).

■ A property definition is a rule (an instance of the Rule-Obj-Property rule type) and so can be part of your application RuleSet, subject to rule resolution.

■ The names of standard properties begin with px, py, and pz, and have standard behaviors (described later in this chapter).

■ Process Commander uses XML-based, in-memory objects called pages for transferring data between the application and the database. The clipboard is the collection of current pages for a given system and user (process or person). Activities use the clipboard to retrieve and set the value of properties.

■ Process Commander uses dot notation syntax, similar to notation in the Java programming language, to identify property values on the clipboard.

■ Process Commander uses models as starting points for creating new objects (analogous to constructors in the Java programming language). You create a model to specify default values for properties. Models are also useful for simulating data sent to or received from external systems.

■ Some properties benefit from formula-based or event-driven recalculation or other follow-on actions. Declarative rules define calculations that the rules engine applies whenever it detects a change in a tracked property.

■ An expression is a formula that Process Commander evaluates to produce a scalar value. Expressions look similar to formulas in Microsoft Excel, but are based on Java language conventions.

■ Classes that inherit from Data- define supporting information that an application uses to process the work, such as lists of items from which users select a work object. You may need Data- classes in your class structure if your application requires persistent data structures other than work objects.

Identifying and Creating Application-Specific Properties 6-3

Identifying and Creating Application-Specific Properties Process Commander includes hundreds of standard properties that are commonly used in BPM applications. Use these properties to jumpstart your development effort. Because your work types inherit from the Work- base class, these properties are available to your application. Use these standard properties or copy them and make changes to the copy in your own RuleSet.

You can also add new properties to suit your application needs. Follow these steps to identify the standard properties that can support your application and the application-specific properties you need to add:

■ Review standard properties and their use.

■ Identify and choose names for application-specific properties, including properties for arrays and repeating groups.

■ Create the property rules you need, using the Application Accelerator and the Property rule form.

Reviewing Standard Work- Properties Standard properties in the Work- base class can be grouped by purpose (Figure 6-1). Consult Application Developer Help for a description of each standard Work- property.

Purpose Description

Controls and Audits

Maintain the identity and history for an object, including aging calculations (such as pxCreateDateTime and pyID).

Facts and References

Describe the type, attributes, and contents of an object (such as pyDescription, pyEventID, and pyStatusWork).

Flows Track starting and active flows for an object, including user actions and optional costs (such as pyFlowName and pyTotalFlowActionCost).

Internals Support internal processing, especially regarding covers and covered objects (such as pxCoveredCount and pyClassName).


Purpose Description

Organization Identify who is performing the work, including name and business affiliation (such as pyOrigUserID and pyOrigUserDivision).

Parties Capture the list and identity of associated parties for an object (such as pyCustomer and pyWorkParty).

Quality and Effectiveness

Measure how well work is being performed, including service levels (such as pxUrgencyWork and pyElapsedPastDeadline).

Figure 6-1. Purposes of Standard Work- Properties

Names and Usage of Standard Properties For ease of recognition, the names of standard properties begin with a px, py, or pz prefix. These prefix values are reserved; you can’t create a custom property with a name starting with px, py or pz (except for a special case, when overriding a standard property).

Standard properties with the same prefix share some behaviors, as shown in Figure 6-2. For example, the value of special properties can be updated only by a declarative rule or an activity, not through user input.

Prefix Description

px Computed properties that can be displayed to users, but which users cannot directly enter or change (such as pxCreateDateTime). These are known as special properties.

py Properties that users can enter or change by typing in a value (such as pyDescription).

pz Properties that are reserved for internal system use (such as pzInsKey). Users cannot see, enter, or change pz properties.

Figure 6-2. Standard Property Prefixes

By definition, you can’t create standard properties. However, in many cases you can override standard properties that begin with px or py (although not pz) by making a copy in your RuleSet and tailoring the copy to your needs. For example,


the standard property Work-.pyElapsedPastGoal automatically records how many seconds a work object remains unresolved after a goal completion time. In your application, you may prefer to present this value as hours or days rather than seconds. You can override the standard property (using Save As…) by creating a copy in your own RuleSet with the same name, a different Applies To class, and a different HTML presentation.

What You Completed Reviewed standard properties to find those which can support your

application.

Reviewing Rules with the Explorer Tools The Explorer tools provide many options for reviewing properties and other rule types. You can easily examine the standard properties, as well as application-specific rules you create in your class structure. Use the Application Explorer to review custom properties in your application. Use the Class Explorer to locate and examine standard properties (Figure 6-3).

Figure 6-3. Reviewing Standard Work- Properties in the Class Explorer


Identifying and Naming Properties Next you can finalize the list of properties you need, in preparation for adding them to your application. As with the class structure, doing this design work outside Process Commander (either with paper and pencil or a UML modeling tool) is the simplest way to get started. You can more easily analyze property placement in the hierarchy, adjusting as needed for efficiency and rule resolution impact. After the paper design is firm, you can then proceed to create the new properties at the appropriate level in your class hierarchy.

Property Naming Conventions

■ Property names are case-sensitive. Start each property name with a letter, and use only letters and digits.

■ As with naming RuleSets and classes, use single-word property names with significant letters in uppercase for legibility (e.g. CustomerName).

■ Establish property naming conventions for your application to avoid confusion. Use nouns to reflect that properties are things, not actions.

■ Use property names that are descriptive and meaningful, so the property contents are obvious. For example, LoanNumber is a good choice for a numeric account number, while LoanID is a better choice for an alphanumeric account number.

■ When choosing property names, consider whose perspective the data reflects. For example, the term DebitAmount might have a different meaning in different departments.

■ On the Application Explorer displays and in the Manage Rules workspace, lists of properties appear in alphabetical order. Choose similar names for related properties so your development team can quickly find them. For example, suppose you need three properties to describe a loan — one for the type, one for the duration, and one for the application fee. LoanType, LoanDuration, and LoanFee are names that reflect the purpose of each property, as well as cause them to sort together.

■ Don’t use the same property name to represent different things for different classes.


■ You can’t create custom properties that apply to the Work- class. Choose an Applies To class that is part of your application.

Identifying Properties Follow these steps to identify custom properties for your application and determine where each belongs in the class hierarchy:

1. Use the class diagram and the requirements you defined at the end of Step 5 for reference.

2. Decide how to document property requirements. The following table or spreadsheet format may be helpful:

Used in Class

Parent class 1

Property Description

Property Name

Use a Standard Property?

Child class 1

Child class 2

Child class 3

Child class 4

Applies To Class

3. In the “Used in Class” column, enter your classes as subcolumn headings. You may want to use a separate table for each parent class.

4. Enter the properties you need to add as row titles, including both the description and name.

5. For each property, mark the column for each class that uses the property.


6. Decide where the property belongs in your class hierarchy, and then fill in the last column with that class name. Use the following guidelines in making these decisions:

– Look for clusters of properties, especially at the leaf classes. Properties that are used by many classes belong higher in the hierarchy (often at the parent-class level), while those that are used by only a few classes belong lower.

– Avoid duplication across classes, especially across parent classes. Don’t define multiple properties that serve the same purpose for different classes if you can define them only once at a higher level in your class structure.

– Watch for opportunities to streamline your class hierarchy. For example, combine two or more classes that share a significant number of the same properties.

– If you are building an application to be installed into multiple systems as a product, consider whether you need to maintain design control over any of your properties. If so, define these properties for abstract classes.

– Use your organization top-level class for properties that may be shared across many applications (such as a company logo).

7. Check your list against the standard properties. In the “Use a Standard Property” column, note any that are the same as or similar to standard properties. The standard properties are candidates to use or to override with minor changes in your RuleSet.


Identifying Properties for Repeating Groups If your application requires custom properties for repeating groups, you have one additional step to perform. You need to name the properties that will hold the repeating groups, as well as the embedded properties within the repeating group. Follow these steps:

1. Before you begin, have your class diagram and the repeating group requirements you identified in Step 4 available for reference.

2. Decide how to document your repeating group requirements. The following table or spreadsheet format may be helpful:

Repeating Group Description

Property Name

Mode (Page List or Page Group)

Embedded Properties

Applies To Class

3. Enter the repeating groups you need to add as row titles, including both the description and name.

4. Enter the following information for each repeating group:

– Mode (whether it is a list or a group).

– List of repeating properties.

– Class derived from Data- or Embed- that defines the repeating group.

What You Completed

Defined naming conventions for properties.

Identified properties and repeating groups to add.

Refined your class structure as a result of added properties.


Creating Properties Once your properties are identified and designed, you can build the corresponding property rules in your application.

When you use the Application Accelerator to create an initial version of the application, choose names, labels, modes, and types for custom properties in your work types during Application Accelerator Step 4 (Figure 6-4).

Figure 6-4. Application Accelerator — Defining Properties

If you do not use the Application Accelerator, you can define properties using the Property rule form.


Previewing Properties During Design On the Property form, you specify many different values and rules that control the appearance, behavior, and data content of a property. Small changes to the rule that defines a property can cause a significant change in how the property appears on a user input form. To simplify property design, you can preview a property directly from the rule form (Figure 6-5). Click Explore to view associated Field Value or Declare Expressions rules, or click Preview to check the property input and display modes.

Figure 6-5. Buttons for Property Design Assistance

Helpful Hints

■ Follow a top-down approach to creating properties. Create properties for higher-level classes before lower-level ones, and for abstract classes before concrete ones.

■ The quickest method of creating a new property is to copy an existing property or use the Quick Create option to create a single value property.

■ You can read more about the user interface in Step 7: “Tailoring the User Interface”. For now, note any related rules that support property display capabilities:

– Rule-Obj-FieldValue (for Field Value lists)

– Rule-HTML-Property (for custom display options on forms)

– Rule-Edit-Input (for converting user input into an internal format)

What You Completed Created application-specific properties. Identified any additional property-related rules you need to create.


Creating Model Rules to Initialize Work Object Properties If your application includes custom properties in a class derived from the Work- base class, you need to decide which of these properties require initial values. Models (Rule-Obj-Model rule type) serve this purpose.

Process Commander includes a standard work model (Work-.pyDefault), but you can create a model for any class, including the work types in your application. You can define multiple models for each work type, one of which is executed (or equivalently applied) when a user or automated process enters a work object.

If you are familiar with Java terms, model rules are analogous to constructors in Java; they define a set of initial values for properties. Each model rule lists properties in a left column, and values (literal constants, source properties or expressions) to be assigned in a right column.

Completing the Model rule form requires familiarity with the dot notation used to identify properties, described next.

Referencing Properties and Values in Rules Developers work extensively with properties in building models and other rule types into an application, for example:

■ Specifying values to display on forms (Rule-HTML-Harness, Rule-HTML-Section, Rule-Obj-FlowAction, Rule-Obj-HTML).

■ Defining initial property values in models (Rule-Obj-Model).

■ Setting values in activities (Rule-Obj-Activity).

■ Evaluating values automatically in declarative rules (Rule-Declare-Expressions).

In these and other rule types, you use a Java syntax called dot notation to identify properties. To retrieve, refer to, or set the value of a property, precede the property name with a period (or dot). For example, you enter .pyID to refer to the standard work object ID property.

Creating Model Rules to Initialize Work Object Properties 6-13

You set and retrieve property values using pages on the Process Commander clipboard, an XML-based structure in memory. Use the Clipboard tool to examine and work with pages and properties (Figure 6-6). This tool is accessed from the Tools panel.

Figure 6-6. Viewing Property Names and Values with the Clipboard Tool


Understanding the Default Work Model Review the standard model rule named Work-.pyDefault to understand its contents before deciding how to use it in your application (Figure 6-7).

Figure 6-7. Standard Model Named Work-.pyDefault

Your application can include a model rule (for each work type) that links to the Work-.pyDefault model — the simplest method. Alternatively, you can copy the Work-.pyDefault model into your RuleSet and modify the copy. Finally, you can create model rules from scratch.

As a best practice, name your model rule (in each work type) that is most often used to initialize new work objects pyDefault, and check the Call superclass model? check box. In your model rule, only set values to that override or supplement those set in the standard Work-.pyDefault model.

Creating Model Rules to Initialize Work Object Properties 6-15

Model Rules Created by the Application Accelerator The Application Accelerator automatically creates a model rule for each work type. When you use the Application Accelerator to create an initial application, initial values you enter in the form for Step 4 of the Application Accelerator are recorded in a model rule (Figure 6-8).

Figure 6-8. Application Accelerator — Initial Values

Creating Model Rules Using the Rule Form You can create or update a model rule using the Model rule form. You can link your model rule to the standard Work-.pyDefault model by:

■ Choosing pyDefault as the model name

■ Checking the Call superclass model? check box

Models to initialize work types should either link to the Work-.pyDefault model or define values for each of the properties initialized in Work-.pyDefault. Step 7: “Tailoring the User Interface” presents more information about how the properties in a work object relate to user interface forms.


Setting the Work Object ID In Step 4, you selected work object ID prefixes for your application. A work work object ID has two or three parts:

■ A prefix, usually one or a small number of characters (required). The default value is W- for work objects, C- for covers, and F- for folders, with the dash appended automatically.

■ A sequential number that is unique within an organization and prefix (required). In most applications, Process Commander automatically generates this value.

■ An optional suffix.

The standard activity named Work-.GenerateID is called automatically whenever a flow execution needs a new work object ID. The standard model Work-.pyDefault sets the prefix to W and omits a suffix. To establish a work object ID scheme for your application, set the values of the pyWorkIDPrefix and pyWorkIDSuffix properties in the pyDefault model rule for each work type as desired.

Helpful Hints

■ In the Model form, list properties in alphabetical order. While not required, this convention simplifies model review and maintenance.

■ Work object IDs are shared across all the applications used by an organization. Two separate organizations can both have a work object numbered W-432.

■ If two applications use a common work object prefix and both use the normal numbering mechanism, each application’s sequence of work object ID values may contain gaps. This may be confusing, but is not an obstacle to processing.

■ A user’s worklist can contain assignments from many applications that the user works with. Typically, a user can recognize which application produced an assignment from the work object prefix.

What You Completed

Created model rules for each work type, defining work object ID prefixes.

Declaring Dependencies Among Properties 6-17

Declaring Dependencies Among Properties Model rules set the initial value of properties whenever a new work object is entered. Thereafter, your application can explicitly set or check property values in a variety of ways, including activities, user input, and validation. These techniques are addressed in the next few chapters.

Declarative rules offer another way to set or restrict property values. At this point in the SmartBuild approach, consider dependencies between properties and the possible benefit from dynamic calculation. Examine the list of properties you added. Decide whether the value of one property depends on other properties or static values, or could benefit from dynamic calculation or follow-up processing based on changes in the values of the related properties. Consider the following options:

■ Checking the state of a property (that is, whether it meets predefined conditions) automatically based on changes in its value or the values of other properties.

■ Calculating and recalculating the value of a property automatically based on changes in the values of other related properties.

■ Running a specified activity automatically whenever the value of a property changes, either immediately or upon the next database commit operation.

Declarative rules provide these capabilities by dynamically retrieving the necessary data for the situation. These rules reduce the need for complicated procedural logic and exception handling. These rule types make complex processes significantly easier to automate, delivering time and cost savings for both business process management (BPM) and business rules engine (BRE) solutions.

Before proceeding, review what declarative rule types are available and how they work.


What Are Declarative Rules? Most programs, as well as most Process Commander rule types, are based on a procedural model. As the developer, you decide when processing needs to occur. Then you write the code or create the rule. Finally, you explicitly call the code or the rule in the appropriate situation to invoke that processing at the time and place it is needed.

In addition to procedural rules, Process Commander offers rule types that are based on a declarative model, which automates the decision of when to perform the processing. As a developer, you define (or declare) what processing to perform in a declarative rule. Thereafter, Process Commander automatically invokes that rule whenever appropriate, depending on the rule type. Because the rules engine is change-oriented, it automatically detects changes in property values and uses those changes to determine which rules to apply — without requiring explicit instructions to do so.

Example — Using Declarative Rules in a Loan Application Consider a loan application that supports several types of loan requests, including mortgages. Figure 6-9 lists typical properties this application might include, along with relationships to other properties.

Property Definition and Dependencies

AccountID Current loan account number for an existing customer. When the information is filled in, retrieve the customer contact information for inclusion in the work object.

LoanAmount Requested loan amount.

LoanAmountPlusCosts Loan amount plus estimated closing costs, including varying fees for any applicable points (CostPoints), appraisal fees (CostAppraisal), and miscellaneous costs (CostMisc). Recalculate automatically if any component amounts change.

FeeLoanOrigination Loan origination fee based on a fixed percentage of the total amount (LoanAmountPlusCosts) plus an applied discount (FeeCustomerDiscount) for existing customers. Recalculate automatically if any component amounts change.

MaxLoanAmount Maximum amount for loan requests.

Figure 6-9. Examples of Property Definitions and Dependencies


A diagram is useful for presenting property relationships and dependencies, as shown in Figure 6-10.

Figure 6-10. Sample Property Dependencies

Two approaches for implementing these dependencies are available:

■ You can create individual activities to perform the calculations and value checks, explicitly invoking each activity for the appropriate class. The associated processing happens every time your application invokes that activity, regardless of whether any dependent properties have changed. In some situations, this behavior is exactly what is needed; in others, it simply adds processing overhead.

■ An alternative approach is to create declarative rules that define dynamic evaluations for the appropriate class:

– Check the value of the Account ID property and run an activity to retrieve contact information for an existing customer.

– Check that the LoanAmount property doesn’t exceed the maximum allowable amount (MaxLoanAmount property).

– Calculate the value of the LoanAmountPlusCosts property.

– Calculate the value of the FeeLoanOrigination property, which itself depends on another calculated property.


Declarative rules are quicker to implement and, as in this example, often a more appropriate choice when you have dependencies between properties. Each time the value of a tracked property changes, Process Commander automatically applies the declarative rule, obtains the necessary data, and performs the defined processing. A change to the value of any dependent property results in a series of individual cascading changes to all other dependent properties

Because the processing is automatic, these calculations are easier to set up and execute, and more robust than procedural changes. The result is higher performance and efficiency, as rule-defined processing happens only when necessary (instead of with every interaction with an object of the class).

Understanding Forward and Backward Chaining Process Commander supports two types of declarative processing. Forward chaining provides the ability to proactively obtain data needed for processing by resolving a series of triggered dependent property value changes. Backward chaining provides the ability to detect and obtain any missing data needed for forward chaining to occur. Process Commander automatically detects and coordinates the entire chain of dependent lookups and changes.

Described simply, declarative processing works as follows:

■ You create declarative rules that represent dependencies between properties in your application.

■ Process Commander performs the following operations automatically (and invisibly to you):

– Creates/updates a series of dependency networks that capture the relationships between properties, as defined by the declarative rules in your application.

– During application processing, automatically detects changes in tracked properties and selects the right declarative rules to apply for the situation.


– Invokes forward and backward chaining as needed (either automatically or programmatically induced) to obtain the data necessary to perform both explicit and dependent calculations.

– Uses its built-in inference engine to perform the defined calculations based on the dependency network.

■ Process Commander then completes the processing defined in the selected declarative rule(s).

To help you understand and debug declarative rules processing, the Dependency Network Analysis tool provides a graphical display of the dependency networks for your application Figure 6-11. This tool is located in the Dependency Network Analysis section of the Manage Rules workspace.

Figure 6-11. Dependency Network Analysis Display


Understanding When Declarative Rules Execute With a declarative rule, properties are evaluated and/or changed automatically as a result of an event. A change in any of the dependent properties forces a reevaluation of the target property. Process Commander evaluates its dependency network to look for changes in the values of tracked properties at the following points:

■ At the conclusion of input processing, when a form is submitted but before activity execution.

■ At the end of each activity step, after invoking the method but before any transition step. If the step repeats, evaluation occurs once per iteration.

■ During flow execution, as process control advances from one task (one shape on the Visio flow diagram) to another.

■ At the conclusion of a flow transition, when the work object advances from one shape to another and within connectors (if the property is set).

■ Upon database commit, when any object is saved to the database (Declare Trigger rules only).

■ When indicated by the Calculate Value setting for the rule (Declare Expressions rules only).

Declarative processing occurs only through a change in the value of a tracked property. Opening objects onto the clipboard or examining clipboard values during processing does not change property values and so does not trigger declarative processing.

What You Completed Identified properties that could benefit from dynamic reevaluation.


Declarative Rule Types Four types of declarative rules represent relationships between properties, as shown in Figure 6-12. On the Explorer tools, these rule types appear within the Decision category. (A fifth type, Rule-Declare-Index, supports database searching and reporting for embedded properties. Declare Index rules are presented in Step 12: “Configuring System Interfaces and the PegaRULES Database”.)

Rule Type Purpose

Rule-Declare-Expressions Compute the value of a property based on a formula that combines other properties and static values. The target property is automatically recalculated when the value of any dependent property changes.

Rule-Declare-Constraints Check whether a property meets defined criteria and, if not, flag the property with an error message. The target property is automatically rechecked when its value or the value of any dependent property changes.

Rule-Declare-OnChange Run a specified activity during processing when the value of a target property changes.

Rule-Declare-Trigger Run a specified activity upon database commit when the value of a target property changes.

Figure 6-12. Declarative Rule Types

To create declarative rules, complete the forms for the rule type. The rule forms all share these common elements:

■ A target property (or properties) to watch or update

■ Values or tests that influence when evaluation occurs and whether forward or backward chaining is to occur

■ What processing is to occur, defined by a single expression or an activity call.


Creating Declare Expression Rules To centralize computations and reduce the need for application-specific activities (which require programming skills to develop and maintain), use Declare Expression rules to record computational relationships among property values. See Appendix A for more about Guardrail 5 and the benefits of this approach.

Complete the Declare Expression rule form (Figure 6-13) to define when and how a single property value is recomputed. Use the built-in Expression Builder to guide you through the process, choosing elements and values to construct the expression from lists of business-friendly terms. This option is helpful for process architects and other business users who typically maintain the logic in declarative rules.

If you are familiar with Java operators (such as !, || and ==) and Java statement syntax, you can type in an expression directly. System architects and experienced programmers may prefer this approach.

Figure 6-13. Declare Expression Rule Form

Helpful Hints

■ Process Commander includes standard declarative rules of various rule types. Examine them as a basis for using declarative rules in your applications.

■ Declarative rules are part of the Decision category in the Explorer tools.


■ Declarative rules follow the same inheritance patterns as standard rule resolution. However, circumstances and date/time range features (presented in Step 14) do not apply to declarative rules.

■ If a declarative rule applies to several classes, define it at the parent class level.

■ The Applies To key part of a declarative rule must correspond to a top-level clipboard page, which is where change tracking in declarative processing occurs. Because Process Commander does not track changes to properties on embedded pages, declarative processing does not apply.

■ Click the Run toolbar button ( ) to test declarative rules.

■ Avoid defining declarative rules with @baseclass as the Applies To class. Some rule type and property combinations could cause a declarative rule to be run every time the property is read, resulting in a serious performance impact.

■ Declarative rules that result in many database reads or writes can be expensive in terms of performance. Choose the appropriate rule type for the properties involved and desired behavior, and design the logic carefully.

■ Use the Performance tool to monitor declarative rules processing and performance. Open the Tools panel and click the Performance link.

What You Completed Created one or more declarative rules (Constraints, Expressions, OnChange,

or Trigger) in your RuleSet if needed.


Checking Performance of Your Declarative Rules Because evaluations of declarative rules happen automatically, it may be difficult at first to understand when and how often each declarative rule you create is evaluated. Minor changes in the computation conditions or Applies To key part may in some situations cause significant changes in the processing load generated by declarative rules.

During Step 7, begin to use the Performance tool to assess the processing demand of your application even though it is not yet complete. This tool provides extensive data about the processing, response, memory, and input-output load placed by one requestor session on your Process Commander environment. The Performance tool only makes visible information already maintained within the system; its use does not add to the overall processing workload.

Although your application is not yet complete, capturing initial performance information now provides a baseline for comparison later, as other rule types (beyond declarative rules) contribute to overall processing demand. See Appendix A for more information about Guardrail 8 and performance monitoring.

Creating Application-Specific Data Classes 6-27

Creating Application-Specific Data Classes Next, consider whether your application requires any custom classes that inherit from Data-. These classes define supporting information that the application uses to process the work.

You learned about one reason to use the Data- class with work parties, which are defined by Data-Party classes. Other reasons include:

■ If your work objects include an embedded page that contains one instance out of thousands of items, you also need to know additional information about each item. For example, a purchasing application might need a property for the list of products that users can order. In addition, the application needs to record the cost, size, color, and other characteristics for each item.

Note: If you don’t need to store the information contained in the embedded object, you can create a class for the embedded object that inherits from Embed- (instead of from Data-). For example, you might choose an Embed- class if the information does not need to be stored separately from the work object for reporting after the work object is resolved, or if the information is needed only temporarily.

■ Your application needs to access information from an external system, either directly in real time or through a data feed. Create a concrete class that inherits from the Data- base class to hold the information. You may also need to create sample data as a placeholder, as described in the next section.

■ Your application includes any situation in which having a data structure may be appropriate. For example, a customer complaint management application may need a product inventory data structure, or a banking application may need a structure to contain accounting records.

If your application needs any custom classes that inherit from the Data- base, create them and their properties now.


Deferring Import of Live Data To avoid potentially significant rework, wait until Step 12 to populate the application-specific data classes. Steps remaining in the design process can influence the structure and change the nature of the data you need. For now, consider the source (if any) of this information as part of preproduction planning.

Process Commander includes various tools to simplify populating your Data- classes on a one-time or ongoing basis. Consider these alternatives:

■ A database administrator can import data from an external database on a one-time basis, prior to production.

■ Your application can use connectors to access data from an external database or system on an as-needed, real-time basis.

■ Your application can use services to import data from files or push data from an external system into your Process Commander environment on a scheduled basis.

■ Users can access the Data Table wizard to import and maintain moderate amounts of data from Excel spreadsheets.

For more information about integration services, see Step 12: “Configuring System Interfaces and the PegaRULES Database”.

What You Completed

Created one or more classes that inherit from Data-, if needed.

Created one or more classes that inherit from Embed-, if needed.

Simulating Connectors Using Sample Data 6-29

Simulating Connectors Using Sample Data If your application needs to access information in external systems, you can complete one more task in this step. Automated interfaces to and from other systems are often complex and time consuming to implement. To allow your design and testing to progress before the interface is built, use one of the following approaches.

Creating Static Data Objects

1. Create a class in your class structure that inherits from Data-. Create a sublevel that reflects the system and another level that reflects the type of data. For example, you might create a class called YourCo-CustService-Data-SAP-Inventory to represent inventory data that is stored in your SAP R/3 system.

2. Define properties for the information you expect to get back. Focus on the data you need, rather than how the data is transported.

3. Create a model for the class to set values for each property to use for testing.

4. Name the model SampleXXXX, where XXXX is a unique value that reflects the data source (such as SampleSAP1).

5. Process Commander includes a standard Data- class activity called ConnectSample that creates a new page on the clipboard and saves it as an instance of your data class. Open this activity, and click Execute to start a dialog to create the sample data.

6. Repeat these steps for each external system connection.

Using a Connector Simulation Data Object The standard class Data-Admin-IS-Simulation provides a good simulation of the external system interface, but requires more development setup. Consider this simulation approach once you know the protocol or technology (such as SOAP, Enterprise JavaBean, or relational database) to be used to connect to the external system.


Thereafter, as the development and testing of the actual interface progresses, you can turn on and turn off simulation for parts of the interface. The simulation can even be useful in a production setting, to isolate components that may be failing from other, correctly working components.

Whichever approach you employ, use the sample data to assist with validating properties, forms, and flows in your application. Later, you can implement direct real-time links or feeds to and from external systems using integration services.

What You Completed

Simulated one or more external system connections with sample data, if needed.

Capabilities to Consider in This Step 6-31

Capabilities to Consider in This Step The optional features and capabilities described in this section may add to the effectiveness and value of your application. Step 6 is an appropriate place to assess how and where these features can be used:

■ Property qualifiers (Rule-Obj-Property-Qualifier rule type)

■ Property aliases (Rule-Obj-Property-Alias rule type)

■ Enumerated text values

Consult Application Developer Help for additional information.

Adding a Qualifier to a Property When you create a property rule, you specify a mode, a data type, and other details that control the format and behavior (such as length, presentation in the user interface, and input validation rules). Some property rules require additional information to further define (or qualify) their content. Qualifier rules (Rule-Obj-Property-Qualifier rule type) serve this purpose. You use property qualifiers to add one or more facts to the value of a property. For example, you can:

■ Qualify a date property as being a specified number of days in the future.

■ Qualify a Decimal property as having a specified number of places of decimal precision. Process Commander includes a standard qualifier (pyDecimalPrecision) for this purpose.

■ Qualify a Decimal property as holding an amount of a particular currency. Process Commander includes a standard qualifier (pyCurrency) for this purpose. This approach matches that used in most relational databases, which use two fields for representing currency, one for the amount (such as 1,234.56) and one for the currency code (such as USD for United States Dollars).

Examine the list of custom properties you have designed to assess whether any can benefit from qualification. Consider how each property will be used in your application. In some cases, you may find that you have proposed a custom property where a qualifier to another property might be a more efficient choice.


Alternatively, you may find some overlooked or assumed fact about a property that is not explicitly represented.

Property Qualifier rules are of type Rule-Obj-Property-Qualifier, which is in the Property category. After you create a qualifier rule, you can assign that qualifier to one or more properties (using the Property form).

Qualifiers provide property metadata. Validation rules (Rule-Edit-Validate and Rule-Edit-Input rule types) and display rules (Rule-HTML-Property rule types) use property qualifiers to apply additional facts to the value of a property. Therefore, if you create property qualifiers, you also need to create validation and display rules in order to apply the qualifiers.

Adding an Alias to a Property Property naming conventions make sense to application developers and database administrators who regularly work with the database. However, these conventions typically are not intuitive to business users. For example, Process Commander includes a standard customer property named .pyCustomer (following the Java convention), referred to with a preceding period. The prefix .py indicates the object and property type to an application developer, but a business user would expect to select Customer from a list of properties to include in a report.

Property aliases address this discrepancy. You create an alias for a property to establish an alternate name that is more recognizable to the user community for your application.

Implementing Enumerated Text Values Process Commander offers various means to restrict the value of a property that represents a code or is limited to one of a fixed list of values. For example, one property may contain only values that correspond to United States state codes. Another property may contain only values for international currency codes.


For value mode properties (Single Value, Value List, or Value Group), you can specify a list of valid values in a table (Figure 6-14).

Figure 6-14. Table Edit Tab on the Property Form

Some table types require additional supporting rules or data:

■ For short-to-medium lists that change infrequently or require technical skill to update, choose Local List as the Type of Table. Enter each text value into the Property form. Typically, properties with a Local List use the PromptSelect HTML property rule for formatting. To create a list that displays one value (such as New York) but stores another form of the value internally (such as NY), choose PromptList. System architects make these changes.

■ For short-to-medium lists that change often, choose Field Value as the Type of Table. Store the values in rules of type Rule-Obj-FieldValue. Typically, properties using Field Value rules for values use the standard HTML property rule named PromptFieldValue for formatting. After the application is deployed, business analysts can easily update the set of values lists.

■ For long lists (such as product catalogs or customer names), choose Class Key Value or Remote List. You then identify or create a concrete class that inherits from the Data- base class, and then create instances of that class to store the values.


Presenting Selection Lists in Alternate Languages If your application will be used by workers who prefer a language other than English, you can use the locale feature together with Field Value rules to present selection lists in their preferred language.

For example, assume a property named BumperColor has text values White, Silver, Black, and Red that appear in a selection list on a work object form or flow action form. A worker who prefers Italian can select Bianco, Argentato, Nero, or Rosso from the list for this property. An international locale code (in this case, IT_it) associated with the operator ID instance works with locale-specific RuleSets to retrieve and display the Italian terms. (If the Italian user selects Rosso for the property, your application stores Red in the work object, so that reporting and other users of the data continue to operate correctly.)

Locale-specific selection lists address only one aspect of internationalization. Correspondence, dates and times, field labels, and other materials can be presented in user-selected languages and formats through supplemental rules that do not duplicate processing logic. Consult the Application Developer Help system and the Pegasystems Support Network for more information.



Task

Rule Type

Explorer Category

Rules

Create a property Rule-Obj-Property Property

Create a property qualifier Rule-Obj-Property-Qualifier Property

Control property appearance in forms (referenced in Rule-Obj-Property)

Rule-HTML-Property Property

Create and maintain a list of valid values for a scalar string property (referenced in Rule-Obj-Property)

Rule-Obj-FieldValue Property

Convert user input into required internal format (referenced in Rule-Obj-Property)

Rule-Edit-Input Property

Create a model for work or data Rule-Obj-Model Technical

Create declarative rules to automatically reevaluate a property value

Rule-Declare-Constraints Rule-Declare-Expressions Rule-Declare-OnChange Rule-Declare-Trigger

Decision

Data

Create a class that inherits from the Data- base class Rule-Obj-Class SysAdmin

Create a class that inherits from the Embed- base class Rule-Obj-Class SysAdmin



Naming conventions for properties.

Design documentation for properties and repeating groups you need to add, including where they belong in the hierarchy and standard properties to use. Tables and spreadsheets are useful formats for organizing and presenting this information.

Refined class structure as a result of added properties.

Application-specific properties created in your class structure.

One or more property qualifiers created in your RuleSet (optional).

One or more property aliases created in your RuleSet (optional).

A list of additional property/qualifier-related rules you need to create (Rule-Obj-FieldValue, Rule-HTML-Property, Rule-Edit-Input, and Rule-Edit-Validate) when you tailor the user interface.

One or more models created in your RuleSet (optional).

One or more declarative rules created in your RuleSet (optional).

One or more classes that inherit from Data- (optional).

One or more simulated connections (services and connectors) with sample data to represent integration with external systems (optional).

Step 7: Tailoring the User Interface

In SmartBuild Step 7, you create rules that tailor the Process Commander user interface to suit the purposes of your application. This chapter addresses the following tasks:

■ Reviewing user access and user interface alternatives.

■ Understanding how the standard user interface works.

■ Tailoring the standard work object forms for your application.

■ Defining field formats and other property formatting.

■ Linking supporting data to work objects using attachments

Who Does This: Process architects typically perform these tasks, with assistance from system architects.

7-2 Step 7: Tailoring the User Interface

Important Terms and Concepts The following terms and concepts are important as you begin tailoring the user interface for your application:

■ Work object forms are HTML-based, so you can create and change them in place as needed, without compiling any code. You define the layout, and Process Commander generates the basic HTML to display the form. Forms are assembled from rules of five types:

– Harness rules (Rule-HTML-Harness rule type) define the form structure and layout, specifying the sections and other elements to be assembled.

– Section rules (Rule-HTML-Section rule type) define an area or segment of a harness rule. Sections can be presented as horizontal strips or as a set of tabs, one of which appears in front of others.

– HTML Property rules (Rule-HTML-Property) define the appearance and behavior of a Single Value property presented on a work object form.

– Flow action rules (Rule-Obj-FlowAction), presented in Step 8, record user decisions and facts to advance the work object through the flow.

– HTML rules (Rule-Obj-HTML) provide additional forms and displays.

■ Standard harness and section rules are available for the Work-, Work-Cover-, and Work-Folder- classes. These rules define and control the associated user experience — appearance, content, and behavior. Like most other standard rules, you can copy them and tailor your copy.


■ Your work types, derived from Work-Object-, Work-Cover-, or Work-Folder- inherit the appropriate harnesses. Because the associated forms are subject to rule resolution, you tailor them in your RuleSet for your application work classes.

■ The standard forms include many standard properties. In your tailored versions of the harness and section rules, you can add the application-specific properties you defined in Step 6 as needed, and remove any standard properties not relevant to your application.

■ HTML code in Process Commander uses JavaServer Page tags, which are extensions to HTML. You can use JSP tags such as pega:reference or pega:include in source HTML to perform common functions. Because most HTML code is generated as you save a section or harness rule form, you typically need to write HTML code directly only for advanced processing. (An older notation with similar capabilities to JSP tags, known as directives, is used in some HTML code.)


Selecting a User Access Technique Process Commander provides a single, integrated environment for designing, building, testing, and using applications. You can copy and tailor the standard harness and section rules to suit the needs of your application. This approach is the fastest way to get your application up and running.

Process Commander also supports other options to accommodate other scenarios, as described in the last three rows of Figure 7-1.

User Access Technique Development Tasks

Built in Start Process Commander directly from Internet Explorer

Tailor harness and section rules to define the user interface. Adapt the Process Commander portal to access and manage work.

SnapStart Start Process Commander from another desktop application

Add an HTML form to your desktop application. Configure SnapStart — the desktop integration facility — to start a Process Commander session and create a work object without retyping. Tailor harness and section rules to define the user interface. Adapt the Process Commander portal to access and manage work. The SnapStart interface supports this form of access (see Step 12).

JSR 168 Start Process Commander from a portal (such as your intranet)

Add links to your Web site or Intranet portal to connect to Process Commander. Tailor harness and section rules to define the user interface. Adapt the Process Commander portal to access and manage work. Alternatively, tailor the standard user interface for your application and open a work object or other portal objects (such as a worklist) in a frame on your own portal using JSR-168 style access. The Rule-Service-Portlet rule type supports this form of access.

Other Service Type

Use integration services to access your application

Use the Process Commander portal to develop the rules (including integration services) for your application. Define and build a user interface using other technology, and call the Process Commander application through services such as SOAP or Enterprise JavaBeans.

Figure 7-1. User Access Alternatives

Selecting a User Access Technique 7-5

For some applications, the primary method of user access may be through services. Even in cases where your technical environment or business process needs point to this scenario, the Process Commander user interface is still beneficial for selected tasks:

■ You can easily perform application development using the facilities provided within the portal.

■ A professional and effective user interface is useful for reviewing work objects and debugging your application as it evolves.

■ You may also find this user interface helpful for reviewing the application with business users.

■ You can take advantage of business process management features, such as service levels, process costs, and work management reports.

■ Auditors may require interactive review and access to promote control and visibility of important information and processes.

What You Completed Identified external elements required to access the application from a

portal or another system if needed.


Benefits of the Built-in, Rules-Driven User Interface Unlike less sophisticated systems, Process Commander employs rules technology to construct the user interface by aggregating and resolving the appropriate rules for each situation. Rule resolution and versioning apply to harness and section rules, just as they apply to other types of rules.

When an application user accesses a work object, Process Commander dynamically assembles the HTML sent to the Internet Explorer session based on the user's RuleSet list and other rule resolution parameters (such as circumstance and date range).

Using proven user interface design principles, harness rules provide a solid structure for your application by:

■ Separating the presentation layer from the logic (following the Java model-view-controller pattern), applying the power of rules and rule resolution to define the user interface.

■ Providing a consistent user interface that is easy to learn and easy to use, without requiring additional development.

■ Delivering a rich set of features out of the box:

– The most visible (and often the most time-consuming) part of any application is its user interface. The harness rules provide attractive forms with built-in behaviors that you can quickly and easily tailor to meet the specific needs of your application.

– Work advances through a series of common stages as it progresses towards final resolution — new, in process, and resolved, and so on. Harness rules match this progression by reflecting fields and data that are contextually appropriate to each stage.

Benefits of the Built-in, Rules-Driven User Interface 7-7

– BPM applications share a set of key properties (such as who created a work object and when, current work status and assigned owner, and age of work object, and more.). Standard harness and section rules already include these standard properties, even if you are not initially aware that your application will need them.

– Work management solutions depend on key tracking capabilities (such as maintaining and displaying an audit trail and flagging errors). The harness and section rules support such business activity monitoring (BAM) requirements.

– Standard out-of-the-box forms automate correspondence generation driven by user-selected content types, templates, and recipients.

This interface incorporates proven principles of BPM solution design, while providing as much as 90 percent of typical user interface forms and elements. By tailoring the harness and section rules, you can quickly get your solution up and running.

Advantages of a Section-Oriented Layout The work object form layout using collapsible horizontal sections is based on a familiar extensible document model. This model is recognized as optimal for data-intensive environments when it is important to predetermine which information fields are visible simultaneously. Such section-oriented forms are most effective for knowledge workers, especially when the work object contains dozens or hundreds of fields. These support productivity by:

■ Segmenting information into logical sections (either expanded or collapsed by default) based on content and typical usage.

■ Providing layered access to work, allowing users to collapse and expand layers to see the correct combination of sections needed to complete the form.

■ Presenting “smart” bars that indicate the content of the section.

If you prefer, your application can present section rules as tabs ( ) rather than horizontal areas ( ).


Understanding Components of Work Object Forms The appearance and behavior of work object forms are highly visible aspects of your completed application. Careful evolution of these forms to promote clarity, ease of use, productivity, and accuracy has a direct payoff in user productivity and satisfaction. Review these terms and concepts to understand more about how the user interface works:

■ Standard harness rules are available for each work object type (simple work object, covered object, cover, and folder).

■ Users can interact with work objects in four ways. They may create work objects, review work objects (without changing any data), update work objects by performing an assignment, and reopen a resolved work object. Each mode of user interaction may require a distinct presentation of the work object. For example, when a new work object is entered, the work object ID is not yet assigned and so does not appear. After the work object is entered, the system-assigned ID appears in display-only mode.

■ Your application requires a work object form for each combination of work type and user mode

■ Each form is defined by multiple other rules and elements.:

– The harness rule defines the form structure in terms of included sections, layout, and behavior.

– Section rules define the contents of individual sections, which provide summary and detailed information about the work object. Sections can include other sections, streams, and fragments.

– HTML rules define class-specific content to be included in sections.

– Text rules contain static text that you include in streams or fragments, such as HTML style sheets for form appearance or JavaScript.

– Binary file rules contain images such as logos or other business-related images.

– HTML Property rules define the appearance of individual properties when presented in display-only mode or input mode.

Understanding Components of Work Object Forms 7-9

■ When you save a harness or section rule, Process Commander automatically generates the HTML source code.

■ In the flow rule for a work type (Step 8), you specify the harness and model to use for creating new work objects.

Harness, section, and HTML rules apply to a class and are subject to rule resolution. To tailor the forms for your application, you overlay selected standard rules by copying them into your RuleSet and modifying the copy as needed.

Tools for Harness, Section, and Property Rules A work object form presented to a user may incorporate the HTML defined through dozens of rules of several types in combination. Several tools help you understand the structure of each work object form and determine the names and type of the rules that together define the final browser presentation:

■ The Explorer tools (on the Manage Rules workspace) provide quick access to harness and section rules (part of the Process category), HTML stream and fragment rules (part of the Portal-and-HTML category), and property and HTML property rules (part of the Property category).


■ Harness rules that use the SmartFrames capability (introduced with Version 4.2 SP2) provide a high-fidelity preview directly on the Layout tab. A wire-frame preview mode identifies the names of rules referenced in this rule (Figure 7-2).

Figure 7-2. SmartFrames Presentation of Harness Rule


■ The Rules Inspector tool on the Tools bar can display interactive links to referenced section, HTML, property, and declarative rules. Figure 7-3 shows a section of a form as presented with the Rules Inspector, displaying links to the harness and section rules (marked with H) and property rules (marked with P).

Figure 7-3. Rules Inspector Display

■ You can click individual shapes within the Diagram tab of a flow rule (presented in Step 9) to identify the harness rule associated with that assignment.

■ The Preview button on the developer toolbar lets you see in advance the runtime appearance of a harness, section, HTML, or flow action rule, using a split panel.

■ The Preview button on the Property form lets you see in advance the runtime appearance of a property value, formatted for input and display.


Harness Rule Names Figure 7-4 shows several harness rules to illustrate that the name of a harness rule indicates its purpose.

Rule Name Includes Purpose New Creating work objects

Perform Performing assignments on existing work objects

Confirm Confirming a recently completed processing action

Review Reviewing open on resolved work objects

Reopen Reopening resolved work objects

Figure 7-4. Harness Rule Naming Conventions

To tailor a standard harness rule for your application, you save a copy of the rule (retaining the name) in your RuleSet and modify the copy.

Note: As a best practice, retain the Purpose key part – the name – when you copy a standard harness rule. Choose different names only for harness rules that have a function unique to your application.


Section Rule Names

Figure 7-5 lists the primary sections of the standard harness forms, which are defined in section rules (of type Rule-HTML-Section). Some section names vary slightly among standard harness rules to reflect context. For example, while Work-.Review contains the Header section, Work-.New contains the NewHeader section.

Section Rule Contents

WorkObjectHeader Summary information that identifies the object, its history, and current status. Includes the following section: ♦ Header

WorkObjectInfo Core information that describes the object contents, including resolution tracking. Includes the following sections: ♦ CoreSummary ♦ CoreParty

- PartyDisplay (repeated for each specified work party) ♦ Detail

- EffortAndCharges - Responsiveness - Ownership - Resolution

For optimal performance, the Detail section is rendered for display only when expanded.

Action Section that displays flow actions list and fields presented by a selected flow action. Part of Perform harness only.

Flows Reserved. Enables starting an allowed flow on the object. Part of the standard Review and Reopen harness rules only.

Figure 7-5. Standard Sections


To tailor a standard section rule for your application, you save a copy of the rule retaining the Stream Name key part into your RuleSet and make the necessary modifications. You can also create new sections and add them to the appropriate harness rules.

Structure of the Review Harness The example in Figure 7-6 shows the structure of a form used to review resolved work objects. The form is defined by the standard harness rule named Work-.Review. Start with this harness as you plan the user interface. The approach follows this design principle: focus first on completed work in your application.

Figure 7-6. Work-.Review Harness Structure

The diagram illustrates the relationship between the primary sections of the assembled form and the included sections or other elements. Bold text indicates a section rule. Plain text indicates an HTML rule.

For optimal results and ease of maintenance, work within the basic structure of the standard harnesses. As you can see, this structure consists of a header section and a work information section, organized into contents intended for immediate display


and on-demand retrieval (the Detail section). Add your properties and any new sections to one of the primary sections. You can also indicate which icons and buttons should appear and when they should be visible.

To continue the example, Figure 7-7 shows a Review form with the top-level sections expanded for a resolved work object. The standard Work-.Review harness conditionally displays the appropriate contents for covered and non-covered work objects. (Work object W-2 in this figure does not belong to a cover work object.)

Figure 7-7. Work-.Review Form Appearance

Note: Plus signs (+) indicate to users that they can expand a section or part of a section, while minus signs (–) indicate that they can collapse it. You specify the title and initial presentation (expanded, collapsed, or tabbed) of each section in the harness rule.

The properties in this example are built into the standard harnesses and are also used in processing and reporting. In a copy, you can add your application-specific properties and/or sections for the appropriate classes, to make your user interface functional.


Flow Rules Reference Harness Rules Flow rules (addressed in Steps 8 and 9) are a key part of your application. You use flows to define the tasks and sequence of your business process. They also provide the connection between the harnesses and your application.

On the Process tab of the Flow form, you identify which harness rule users employ for creating work objects (Figure 7-8). The default value is New.

Figure 7-8. Flow Form — Process Tab


Flows can contain assignments that represent a required user or external system interaction with a work object. Each assignment includes a property that determines a harness rule to use. By default, assignments have this property set to a harness rule named Perform (Figure 7-9). However, you can specify a different harness rule.

Figure 7-9. Connecting a Harness to an Assignment


Tailoring the Standard Forms Follow these steps to create work object forms for your application:

■ Select properties to be added or removed from each forms.

■ Refine the presentation format of individual fields

■ Optionally, use the Application Accelerator to create initial harness and section rules

■ Use the SmartForms Layout tab to refine the structure, styles, layout, and contents of the harness and section rules

Selecting Properties To help you get your application up and running quickly, standard work object forms include many of the standard Work- properties. If a property is not needed in your application, you can override the harness, section, or HTML rules that reference that property and remove references to the property. However, use caution before deleting a property, as many standard Work- properties support quality reporting and management reporting.

Other standard properties support the PegaRULES Process Analyzer product, an optional business analysis facility that presents Online Analytical Processing (OLAP) charts in Microsoft Excel.

The following tactics are useful for this task:

■ Work with the forms printed in Step 6.

■ Use the Explorer tools to review all sections for a specific class and harness (such as Work-.New) or compare one section (such as Header) across classes.

■ Scan through the HTML source code on the HTML tab of the rule.

Tailoring the Standard Forms 7-19

Note: In the HTML source code, references to properties appear within curly brackets {} for directives, or angle brackets <> for JavaServer Page tags. For example, the following HTML displays the standard property pyID : <font class="titleBarDataStyle">

<pega:reference name=”.pyID” /></font>

What You Completed Reviewed the standard properties used in the harnesses for each work

object type, identifying those to retain and those which may be removed.


Application Accelerator Approach When you use the Application Accelerator to create an initial version of your application, the accelerator creates tailored sections automatically, based on the labels and formats for the properties you provided in Step 3 (Figure 7-10).

Figure 7-10. Application Accelerator — Property Formats


Rule Form Approach Common changes to work object forms include:

■ Adding or removing sections, or updating sections including layout, content, and button changes.

■ Adding or removing properties or changing their field formatting.

■ Modifying text formatting such as typeface, style, and color.

■ Adjusting screen formats, such as table formats and line breaks.

If you don’t use the Application Accelerator to start application development, you can work directly with the harness and section rule forms, using either the SmartFrames format or an older legacy format of the Harness form. Although formats offer roughly comparable capabilities, the SmartFrames format provides a more intuitive, direct development approach.

Planning and Design

■ Decide which properties you need to add to the harnesses, noting where they belong in the class structure. To capture or report on a property, you also need to add the property (or others that together allow it to be computed) to one or more harnesses. Include any properties needed to support external reporting requirements.

■ Also identify any new sections that you may need, such as for repeating groups or new types of work parties you added.

Note: Every harness rule references a standard PartyDisplay section for displaying work party information. If you create a new Data-Party class, also create a corresponding HTML rule (of type Rule-Obj-HTML) named PartyDisplay for that class.

■ Identify any cosmetic changes, such as adding or changing text formatting or emphasis, or including a company or product logo.


■ After reviewing each work type, list the work object forms that require changes. Determine whether you need to change the harness rule itself and also identify which sections to change.

■ Compile a list of other rules you need to modify, describing the necessary changes.

■ You may want to adjust your class structure again. The need to repeatedly add the same properties to the same section for different work types suggests that you should consider defining the properties higher in the class structure.

Using the Layout Tab (SmartFrames Format) Beginning with Version 4.2 SP2, the Layout tab of a Harness rule form provides a high fidelity, integrated preview of the appearance of an entire harness.

Using Windows drag-and-drop operations and interactive dialogs, you can adjust the elements through direct manipulation. When you save the Harness rule form, Process Commander also saves any changes to the included section rules.

These controls are available on the Layout tab:

■ Drag and drop the control to place a container on the Layout tab. Every harness includes one or more containers, which can provide a visual border that groups sections. Containers have no effect on processing.

■ Drag and drop the control to place a section rule on the Layout tab, or within a cell of a table.

■ Drag and drop the control for a layout (a grid of rows and columns)

or the control for a repeating layout (where each row corresponds to values from a Page List repeating group). Every section contains one or more layouts.

■ Select a layout element and click grid controls such as Insert Row Above ( ), Delete Row ( ), and Merge Right ( ) to control the number, size, and order of layout elements.


■ Drag and drop the button control ( ), icon control ( ), or URL control to place the corresponding control on the form.

■ Drag and drop the Label control ( ) to add a text label or the Field control ( ) into a cell in a layout to present a property for display or input.

For each control, a panel appears that allows you to define the contents and presentation, including Cascading Style Sheet styling such as fonts and colors.

You can use the SmartFrames Layout tab to display section rules which are in the older legacy format or which have the Auto-generate HTML? box cleared. However, you cannot modify these sections from the Layout tab.


Using the Layout Tab (Legacy Format) In Version 4.1 the Layout tab defines the contents and appearance of harness and section rule forms through tables and fields. For simple changes such as updating a section to include or delete a property, you can interact with a preview of the harness form and use the Windows drag-and-drop operation, (Figure 7-11).

Figure 7-11. Updating a Section Rule using Drag and Drop


For more complex changes, update the section rules and, if required, the harness rules using the legacy Layout tab.

If your application accesses harness or section rules that use the legacy format but you prefer to develop using the SmartFrames approach, click the Upgrade button to convert the rule (or a copy of the rule) to the new format.

Procedure The following example walks you through the process of tailoring the user interface, and applies to both the newer SmartFrames version and legacy version of the Layout tab. As an example, it shows you how to approach adding loan application properties (such as loan type and loan amount) to the work object forms:

1. Decide where in the class structure to tailor the form. Because these properties apply to all loan types and child classes, assume that you defined them for the YourCo-YourDiv-CustService-Loan, the application parent class. You need to change the forms for this class. Properties that apply to only one or two child classes belong in forms lower in the class structure.

2. Determine which harnesses apply. The class YourCo-YourDiv-CustService-Loan inherits from Work- so it inherits the Work- harness rules, not Work-Cover- or Work-Folder- harness rules.

3. In your RuleSet, copy sections or harness to override the standard rules. For example, copy and save CoreSummary in your RuleSet and set the Applies To key part to the YourCo-YourDiv-CustService-Loan class. Retain the Purpose key parts in the copies.

4. Use direct manipulation to add properties and adjust the layout. Start by adding the properties to a copy of the Review harness, which defines the form for updating/reviewing work objects. In most situations, add them to the CoreSummary section because they represent core information about the work object. Properties that represent supporting details about the work process that are infrequently used (such as a scanned image of a paper loan application)


belong in a new section in the Detail section, which is typically retrieved only on when it is displayed.

5. Identify any other affected forms. In order for users to enter these properties, you also need to add them to the harness for entering new work objects (Work-.New or Work-.NewCovered). Add them by overriding the standard Work-.CoreSummary section, as described next.

6. Test and refine. In this example, add the loan application properties defined in your class structure to the Layout tab of your CoreSummary section rule.

What You Completed Listed all harness, section, and other presentation rules to be tailored or

created, including the necessary changes.

Notes on working with Harness Rules Harness rules are of type Rule-HTML-Harness, which is part of the Process category in the Explorer tools. You define the form structure on the Layout tab of the Harness form. After saving the rule, click the Preview toolbar button to see the appearance of the form. The HTML source code, which Process Commander generates based on the contents of the Layout tab, appears on the HTML tab.

■ To take advantage of future enhancements to the harnesses, retain the Purpose key part of the rule name when you overlay a standard harness rule.

■ For optimal results and ease of maintenance, work within the structure of the standard harness rules. Add any new sections to one of the primary sections.

■ Use the Scripts and Styles tab to specify custom scripts or HTML style sheets.

■ You can conditionally display form elements based on the role of the user or the mode of interaction. Use a combination of privilege rules (Rule-Access-Privilege rule type) and when conditions (Rule-Obj-When rule type) or Boolean expressions to control the display of individual elements of a form.


Notes on Working with Section Rules Section rules are of type Rule-HTML-Section, which is in the Process category in the Explorer tools.

You define the section structure on the Layout tab. After saving the rule, click the Preview toolbar button to view a simulation of the section. The HTML source, which Process Commander generates based on the contents of the Layout tab, appears on the HTML tab. To prohibit direct editing of the HTML — that is, to always regenerate the HTML code from information on the Layout tab — check the Auto Generated HTML setting on the HTML tab (Figure 7-12).

Figure 7-12. Auto-Generated HTML Setting

As a best practice, retain the Stream Name key part when you override a standard section rule. Choose a new name only for sections that are unique to your application.

■ Your application can conditionally display or hide section elements based on the mode of interaction. Use when condition rules (Rule-Obj-When rule type) or Boolean expressions to control the display of elements of a section.

■ For optimal results and ease of maintenance, work within the basic structure of the standard harness rules. Include any new properties or sections in one of the existing sections.

■ In unusual situations, you can modify and extend the generated HTML. Save the harness rule once to generate HTML from the Layout tab information. On the HTML tab, clear the Auto-generated HTML? check box and click the pencil icon to start your HTML editor. This advanced capability is to be used only when necessary by developers skilled in HTML and JavaScript. See Appendix A for guidelines on this feature.


Working with HTML Rules and HTML Fragment Rules HTML streams are rules of type Rule-Obj-HTML and HTML fragments are rules of type Rule-HTML-Fragment, which are both in the Portal-and-HTML category in the Explorer tools. These two rule types are not directly referenced in harness or section rules. However, in rare situations, you may want to use HTML or HTML Fragment rules to achieve the following results within a section:

■ Create dynamic selections. Based on a supplied set or JavaScript functions named DynamicSelect, this technique presents a selection box with contents that are determined by the value in another field. For example, suppose you want a MailingOption field to display a selection box with the choices of US Mail or FedEx:

– If the user chooses US Mail, you want the MailingType field to display a selection box with the choices of First Class, Priority, or Express.

– If the user chooses FedEx, you want the MailingType field selection box to present the choices of Express or Ground.

■ Support dynamic displays through client-side scripting. For example, you can use client-side scripts to enable and disable fields or automatically update fields based on the contents of other fields. These scripts are executed without server interaction. This feature is an advanced programming technique that is usually performed by developers skilled with JavaScript, VBScript, or similar technologies.

Working with Text and Images Two additional rule types are useful for tailoring the user interface:

■ Rule-File-Binary — stores a graphics file such as an image (GIF, JPG, PNG, etc.). This rule type is useful for including images such as a corporate logo in your forms.

■ Rule-File-Text — stores static text such as an HTML style sheet or JavaScript source code.

These rule types are in the Technical category in the Explorer tools. Both are class-independent and can be shared across applications.


You use these rule types to assemble other HTML components such as images, cascading style sheets, or JavaScript code. Process Commander automatically extracts the appropriate binary or text file from the database upon first use. Subsequent accesses (for the same element) are served directly as a file, as occurs in an ordinary Web site.

Helpful Hints

■ Start by tailoring the harnesses for reviewing completed work (Work-.Review). Then decide which adjustments you also need to make to the harnesses for entering new work (Work-.New or Work-.NewCovered).

■ If you add a property to a work type and want a value for the property, add an input field to a section rule, or create an activity that sets the property.

■ By definition, users cannot input values for special properties. However, work object forms can present the value of a special property in display-only mode.

■ If you tailor a section for reviewing or updating work objects, consider whether you need to adjust a corresponding section for entering new work.

■ Standard button labels (such as Create and Submit) are defined in HTML fragment rules to facilitate sharing across forms and localization. These fragments have a prefix of HarnessString to simplify identification.

■ If you add an input field to a form for one class (e.g., YourCoLoan- Request-Mortgage), consider whether that field also applies to any peer classes (e.g., YourCoLoan-Request-Auto). If so, consider making the change at a higher level in the class structure (e.g., YourCoLoan-Request-).

■ For optimal results:

– Do tailor the existing sections by adding properties or other elements and including new sections.

– Do not modify the harness structure, which consists of a header section and a work information section that is organized into contents intended for immediate display and on-demand retrieval (the Detail section). If you need a significantly different form structure, create a new harness rule instead to distinguish it as an application-specific harness.


What You Completed Created or modified the harness, section, and other presentation rules.

Formatting Fields on Forms As described in the previous chapter, you use HTML Property rules to define the field format for a property. HTML Property rules are of type Rule-HTML-Property, which is in the Property category in the Explorer tools. You reference this rule in the HTML Property field on the Property form.

Note: Do not use an HTML Property rule to record a fixed list of field values. Use Rule-Obj-FieldValue or TableEdit/LocalEdit instead to simplify maintenance, as described in the next section.

Standard HTML Property Rules The simplest way to format a property on a form is to reference one of the many standard HTML Property rules. You can choose from a variety of common field formats, such as:

■ Several types of date and date-time formats (such as Date-Calendar, DateTime-Calendar, Date-Full, Date-Short, etc.).

■ Check boxes (such as CheckBox or CheckBox-Small) and selection boxes (such as PromptSelect or PromptFieldValue).

■ Common prepopulated value lists (such as PickState or PickTitle).

■ Expandable text fields for data entry (such as TextAreaWithExpand and TextAreaWithExpandExpanded).

To become familiar with the available formatting options, start by examining the properties that appear in the harnesses. HTML Property rules define the formatting for many standard Work- and Data-Party properties.

To support unusual presentation needs, you can create application-specific HTML Property rules to accommodate your requirements.


Updating Property Rules After you have changed the standard forms to include your properties, you can decide on their field formats. Identify and/or create the HTML Property rules you need, and update the corresponding property rules to reference the HTML Property rules.

What You Completed Reviewed the standard HTML Property rules provided for field formatting.

Created additional HTML Property rules if needed for custom formatting.

Updated properties to reference the most appropriate HTML Property rule.


Capabilities to Consider in This Step Step 7 provides an opportunity to review the following features that can add power, ease of use, and flexibility to your application:

■ Restricting the value of a field to items on a list of distinct values, stored in rules.

■ Converting user inputs from a format attractive to users to a format needed for other processing.

■ Creating custom attachment types.

■ Creating custom attachment categories.

Defining Field Value Rules for a Property When you specify a check box or selection box field format for a property, you also need to define the values that appear in the list. System architects and database administrators typically maintain these types of lists.

You can also create lists of field values that business analysts can easily maintain. Field Value rules are of type Rule-Obj-FieldValue, which is located in the Property category in the Explorer tools.

Create one Field Value rule for each value to be displayed in the list. Update the Table Edits tab of the Property form to reference the Field Value rules.

Design Guidelines ■ To simplify creation and maintenance, use Field Value rules instead of

recording list values in a Rule-HTML-Property rule. The latter approach complicates updates.

■ The Field Name key part links the value to the property. If these names do not match, Process Commander cannot locate the list values for the property.


■ You can’t update an existing field value rule. Instead, delete the rule with the value you don’t want and create a new rule.

■ The pyStatusWork property references field value rules, allowing you to create additional status values.

Converting User Input to an Internal Format The input format for a field that is easiest for users to type may not be the best format for the property when processed later. When needed, your property rule can reference an Edit Input rule, which automatically converts one input format to another format. You reference this Edit Input field in the Property form.

This feature is useful when data is expected in a specific format, such as a format required by an external system. For example, you may want to strip leading spaces from what users enter, or change all characters to lowercase.

Edit Input rules are of type Rule-Edit-Input, and belong to the Technical category in the Explorer tools. Each Edit Input rule defines a Java function that converts a single value to another format.

What You Completed Created Java-based Edit Input rules to perform data format conversions, if

needed.

Supporting New Attachment Types An attachment is a named small file, screen snapshot, URL, or text note that a user or an activity has associated with a work object. The last task in this chapter is to create rules to support application-specific attachments. Depending on how you want the attachment created, you may also need to create sample data to use as a placeholder when reviewing the user interface with business users. It is also helpful when conducting a business review of your flows.


You can either use one of the five standard attachment types that come with Process Commander or define your own custom attachment types:

■ File (an instance of the Data-WorkAttach-File class) for a file of any file type.

■ Note (Data-WorkAttach-Note) for text typed or pasted in.

■ Scanned document (Data-WorkAttach-ScanDocument) for a TIFF format image produced by a scanner.

■ Screenshot (Data-WorkAttach-ScreenShot) for a GIF format image of a window on the workstation.

■ URL (Data-WorkAttach-URL) for a Uniform Resource Locator.

The standard harnesses for entering, updating, and reviewing a work object include an Attach action icon that opens the Work-.HistoryAndAttachments form.

Some applications may also require additional types of attachments. For example, an application for investigating customer complaints about credit card or bank statements may need the ability to attach the relevant statement. That statement would typically exist as a separate record data structure, retrieved from another system.

Your application can include a custom attachment type, and control when and how the attachments of that type are added and displayed. Attachments can be added by an interactive user process or automatically by a background agent process.

Supporting Attachment Categories Attachment types identify the format and data structure of an attachment. In contrast, your application can use attachment categories to label the business object contained in an attachment.

For example, a work object may grow to contain many attachments of type Scan Document, representing a scanned letter from the customer, a copy of an invoice, a copy of a check, and so on. Attachment categories such as Check, Original Customer Letter, Invoice, and so on allow users to record, in business terms, the


content of an individual attachment. Attachment categories are defined through Field Value rules.

Note: For more information on attachments, see the Application Developer Help.

Customizing the Process Work and Monitor Activity Workspaces Work object forms, defined through harness, section, property, and other rule types, are the most visible and heavily used aspect of the user interface of your application. However, the portal itself — its appearance, layout, styles and fonts, labels, and behavior — is also defined by rules. Your application can override standard rules to add, delete, rearrange or label elements and links as appropriate to your user needs and experience.

For example, you can determine which report links appear in the Monitor Activity workspace, or remove elements from the Process Work workspace that are not useful or functional for your user community. You can change the logo in the navigation panel, link to an application-specific help system, or remove the Launch link.

Portal rules (Rule-Portal rule type) operate with access roles, HTML rules, JavaScript functions, and cascading style sheets (CSS files) to implement the portal. Portal rules are part of the HTML-and-Portal category in the Explorer tools. HTML and JavaScript skills are needed for most changes to the portal. Consult the Application Developer Help system and Pegasystems Support Network for more information and procedures.


Step 7 Rules Reference You work with the following rule types in this SmartBuild step.

Task

Rule Type

Explorer Category

Rules

Create or tailor harnesses or sections Rule-HTML-Harness Rule-HTML-Section

Process

Create or tailor a class-specific HTML stream Rule-Obj-HTML Portal-and-HTML

Create or tailor an HTML fragment that can be shared across classes

Rule-HTML-Fragment Portal-and-HTML

Hold an image to include in a harness or section Rule-File-Binary Technical

Hold a static text file, such as an HTML style sheet Rule-File-Text Technical

Use, create, or tailor property formats Rule-HTML-Property Property

Define input formatting for a property Rule-Edit-Input Property

Define portal layout and contents Rule-Portal Portal-and-HTML

Create or tailor text value lists for a property Rule-Obj-FieldValue Property

Create a class for custom attachments that inherits from the standard Data-WorkAttach class, if needed




A list of external elements needed to start the application from an external portal or external system (optional).

A list of harness rules for each work type.

A list of harness and section rules to be tailored or created, identifying the necessary changes.

A list of additional user interface rules to be created, if needed.

New HTML rules, fragments, text files, or binary files, as needed.

HTML Property rules for custom field formatting.

Field value rules created for check box properties, selection box properties, or other properties.

Application-specific portal rules (optional).

Edit input rules for any custom field input conversions.

Property rules updated to reflect field formats.

Rules to support attachment types and attachment categories.

Step 8: Designing Flows and Identifying Flow Actions

The next step in application development is to design the flow rules that control how work progresses through a business process to final resolution. Process Commander integrates the power of Microsoft Visio for intuitive process and flow design. This chapter describes SmartBuild Step 8:

■ Understanding the flow design model and tools.

■ Creating and iteratively revising flow shells.

■ Identifying flow actions, rules that specify choices presented to application users.

It is important to think through your flows before building flow rules for your application. A carefully planned flow design is essential to efficient processing in a Process Commander application.

Who Does This: Process architects typically perform these tasks.

8-2 Step 8: Designing Flows and Identifying Flow Actions

Important Terms and Concepts The following terms and concepts are important as you begin designing the flow rules:

■ Flow rules specify how work objects are initiated and how they proceed through a process to resolution. Flow design is an iterative process, which you can do by creating flow shells in a UML design tool (such as Microsoft Visio) or on paper.

■ Flow rules route work objects that require human intervention into shared workbaskets, or onto worklists associated with individual users.

■ Flow action rules specify the choices available to users when doing an assignment. As a user selects what to do next, the application runs a flow action rule to initiate the processing.

■ Agent rules define background processing, including a trigger or wake-up interval and the activities to execute upon wake-up. For example, you can use agents to route assignments waiting in a workbasket for an external event to occur. Agents also typically initiate processing associated with date/time thresholds, for example to enforce service level goal and deadline events.

■ Three properties record three distinct status values:

− Work object status (the Work-.pyWorkStatus property) reflects the current state of a work object based on its position in a flow. A flow rule can update this status as the work object progresses through a flow towards resolution.

− Assignment status (the Assign-.pyAssignmentStatus property) records the user’s judgment about an assignment on the worklist. Typical values include Unknown, Next, Soon, and Current, although your application can use other values.

− Activity status (the Code-Pega-Thread.pxTaskStatus property) reflects the outcome of a Utility or Flow shape.

■ A when condition rule (Rule-Obj-When rule type) is a Boolean expression based on the values of properties on the clipboard. Flows use when conditions to determine which of several defined paths is appropriate for a work object.

Introducing Flow Design 8-3

Introducing Flow Design Flows define the processing sequence that your application applies to accepting new work objects and managing their journey through resolution. Process Commander leverages Microsoft® Visio® drawing and diagramming software to provide a powerful, visual representation of flows in a format that is meaningful to business analysts and management.

Designing your flows offline, outside of Process Commander, is the best way to begin. You can easily identify similar patterns across flows or optimize the sequence of steps within a flow without significant rework. This chapter guides you through the process of designing and creating flow shells, which you use as the basis for creating flow rules in Process Commander in the next chapter.

Note: Flow design is an art and an iterative process, not an exact science. Use this chapter as a guide and adopt an approach that works best for your team.

Tools for Developers The SmartBuild approach requires that you develop flow shells using Microsoft Visio. It makes sense to use the same tool for creating flow shells that you later use to create flow rules in Process Commander. You can import the completed Visio diagram files (VSD files) directly into Process Commander to use as a starting point for the flow rules of your application.

A Visio stencil named Process Commander Flow Shell.VSS is provided to help you:

1. Obtain this stencil file from Pegasystems Education Services or the Pegasystems Support Network.

2. Copy the stencil to your Visio solutions directory, which is typically C:\Program Files\Microsoft Office\Visio\Visio11\1033.

3. Use the Visio File menu to add the stencil.


Recommended Approach In this chapter and the next, your objective is to design the flow rules for each of your work object classes. Starting with your list of work types, design the flows that create a work object and manage it through final resolution. The design process is iterative:

1. Select three work types that you believe have flows that can be adapted for the remaining work types.

2. Complete the tasks in this chapter to create flow shells for these three work types.

3. Complete the tasks in the next chapter (Step 9) to create the flow rules in Process Commander.

4. Repeat Steps 2 and 3 for the remaining work types.

Use the following list first as an introduction to the flow design process and later as a checklist for reference.

■ Start by capturing high-level details about the start and end of your process. For each work type, identify the ways work objects can be created and all possible states for them when resolved.

■ For each work type, create a flow shell for the primary flow in Visio that reflects the major steps in the process.

■ For each assignment in the flow shells, define what user actions are possible. List the corresponding flow action rules, including both standard ones and custom ones you need to create.

■ For each flow shell, define additional process details. For each automated step, identify additional processing and capture the details in a separate, linked drilldown page as a placeholder.

■ Incorporate the drilldown pages in your primary flow shells, or convert them to secondary flow shells.

Creating First Flow Shells 8-5

Creating First Flow Shells A flow shell is a simplified Visio diagram that initially pulls from a library of six shapes, to represent a business process. During the course of Step 8, you create initial flow shells and then review them to add detail and clarify relationships and actions. Later in Step 8, you expand and refine the flow shells to more closely match the notation and shapes of flow rules that become part of your application.

Construct your first flow shells based on these tasks:

■ Capturing high-level process elements based on information from business experts regarding the steps to resolution for each work object

■ Drawing the simplified shells with Microsoft Visio 2002 or 2003/XP

■ Clarifying each flow shell diagram

Capturing High-Level Process Elements To begin designing flows, you need some high-level information about the start and end of each business process. For each work type, gather the following information:

■ List all the means through which information about new work can arrive (referred to as channels). For example, a channel can be a person filling out a Web form, or receiving an automatic data feed from a trusted external system.

■ List the resolved states (final outcomes) for each type of work object. The resolved states should not depend on how (by which channel) the work object arrived. Make this list as complete as possible, so you have the right framework later for evaluating the flow shells. Emphasizing the final outcomes helps the development team focus first on the end objective of a business process rather than the means (the process).

Note: Select at most three representative work types to start with. You need not complete the tasks in this chapter for all work types at once.


What You Completed Identified channels through which new work object arrive.

Defined resolved states for work objects.

Identifying Flow Shells You need to create up to three sets of flow shells:

■ Opening flows describe processing that creates work objects. This processing may be channel-specific.

■ Primary flows define the sequence of processing that applies to most or all work objects of this type. This processing is ordinarily not dependent on the channel from which the work object was created.

■ Secondary flows define supporting processing capabilities that your primary flows may apply to work objects only under certain conditions.

Starting with the primary flows (rather than opening flows) focuses attention on the work to be processed and helps ensure that the work objects are channel-independent.

Typically, your application includes one primary flow for each work type. In some cases, you may need to create more than one primary flow if more than one driving process applies in the business setting.

Opening Flows A channel provides input to an opening flow. Work objects may arrive through any of multiple channels, such as fax, e-mail, paper forms, incoming telephone calls, unstructured letters or notes, services, and so on. In most businesses, processing does not depend greatly on the channel; so the work objects created by an opening flow should be channel-independent. (In practice when implemented, opening flows often turn out to be implemented by activity rules rather than flow rules.)


For now, limit the scope of the Step 8 effort by identifying, not describing in detail, the channels through which work object information arrives. Examples include:

■ An automated message from another system inside your company, such as a point-of-sale device.

■ An automated, file-based feed from a trusted business partner.

■ An HTML form filled out by one of your company’s call center operators or back-office staff.

■ An HTML form filled out by a visitor to your company or department Web site.

■ A paper-based form scanned by an OCR (Optical Character Recognition) reader.

Your application can accept new work objects arriving through multiple channels. These Process Commander facilities support work object entry or capture:

■ Harness forms allow users to create work objects by entering information.

■ Services allow external systems to create work objects by sending input using SOAP (Simple Object Access Protocol), Java™ Message Services, WebSphere®

MQ messages, or other protocols.

■ Incoming e-mail messages can be parsed automatically to identify the fields needed to create a work object.

■ Paper documents can be scanned to create work objects.

For example, the standard flow rule named Work-.StandardClassify defines an opening flow. This flow presents a standard harness rule (Work-.New) to a user, who enters only a few facts about a new work object.

In an application that includes the StandardClassify flow, services can also create work objects by receiving requests as messages from other applications. The service first authenticates the channel or sender, and then creates a work object from information in the incoming request.

A work object created from a SOAP service can provide exactly the same properties as a work object created by keyboard input; this approach lets the business deliver channel-independent processing.


Primary Flows A primary flow execution starts after a trusted system or a user creates a work object. A primary flow accepts a channel-independent work object as input and defines the processing that your application applies to objects of the work type. Each work object either has or inherits one or more primary flows.

Secondary Flows Secondary flows (also called subflows) promote reuse or increase clarity by isolating steps that are rare or out of the mainstream. They provide supporting processing capabilities and do not stand on their own. A secondary flow is called from within another flow, which may be another secondary flow, a primary flow, or an opening flow.

Use of secondary flows helps achieve modularity. An application that contains multiple flow rules, each containing fewer elements, is easier to understand and maintain than the same functional capabilities implemented through fewer, but larger and more complex flow rules.

Looking Ahead to the Flow Explorer As an aid to naming and planning flow rules, consider how they will appear in the Flow Explorer area of the portal after you enter them (in Step 9).

To simplify access to flow rules, the Manage Rules workspace presents a chart known as the Flow Explorer. For example, the SampleWork application includes five flow rules (Figure 8-1).


Figure 8-1. Flow Explorer for PegaSample

In this application, the four flow rules at the left each create new work objects. These are known as top-level or starter flows. Each of these four also defines the primary processing for a work type, so these four can all be viewed as primary flows.

The Customer Feedback, at the right, is a subordinate flow (or subflow) called by the Customer Request flow.


Six Basic Design Shapes Figure 8-1 presents the shapes in the Flow Shell stencil.

Shape Description

Comment Descriptive information about a step or connector. Use sparingly.

Assignment Pause, or potential pause, in a flow. Indicates that a person or an external system must act on a work object before the flow can progress. Label ♦ Who (or what, in the case of an external system) performs the work. ♦ Brief description of the work to be done. ♦ Two lists of activities that users can perform within the assignment:

– Local flow actions. – Connector flow actions.

Connector Unidirectional link between two shapes. Label ♦ If a single connector emanates from a shape, label it ALWAYS. ♦ For now, if there are multiple connectors, label each with a short description of

the work to be done in the path.

Flow Start of a flow. Label ♦ Top section contains the class name. ♦ Bottom section contains the flow name and any comments about the

prerequisite state of work objects entering the flow.

FlowEnd End of a flow.

7 56

121110

8 4

21

9 3

End

Six Basic Design Shapes 8-11

Shape Description

Processing One or more automated steps in a flow. The flow continues when all steps within the Processing shape have completed. Label ♦ Top section is typically a bulleted list of functions that need to be done inside

the Processing shape. ♦ Bottom section lists all outcomes that can be returned from the Processing

shape.

Figure 8-2. Flow Shell Stencil Elements

Drawing Flow Shells with Visio You have completed the design work for opening flows by identifying the channels through which new work objects are created. Next, create flow shells for the primary and secondary flows in the application. Using Visio, create each flow shell in two phases:

■ Create an initial flow shell with the major steps in the process, as described in this section.

■ Drill down to add details, as described in the next section.

These guidelines walk you through creating a flow shell for a primary flow. Later, you can perform the same tasks to create flow shells for secondary flows. Follow this process to create a flow shell:

1. Open an empty Visio diagram based on the Process Commander Flow Shell stencil.

2. Drag a single Flow shape to the top center of the page. Enter the work type of the work object to be created on the first line and a name for the flow on the second line.

3. Drag a single FlowEnd shape to the bottom of the page. This reinforces a natural tendency to read a flow from top to bottom.


4. Change the name of the Visio page (the tab on the bottom left) to the flow name and save your work. For easy reference, use the work type as the file name.

Note: Follow this guiding principle when creating flow shells: Keep it simple and add complexity later.

Guidelines for Quicker Progress Your progress will be faster if you create your initial flow shell to reflect high-level stages only. Don’t try to separate details into individual steps. Instead, think of your flow shell as a series of rows (approximately 1.5 inches or 4 centimeters each) from the top of the page to the bottom.

First and Last Rows: The first row contains only the Flow shape and the last row contains only the FlowEnd shape.

Row 2: Add one Processing or Assignment shape to represent the first step in the flow. Within the shape, enter high-level information about the work to be done. Use your knowledge of the business problem to choose the appropriate shape.

Then add a connector from the Flow shape in Row 1 to the single shape in Row 2. Label this connector ALWAYS.


Also consider the following guidelines:

■ For Processing shape descriptions, use action verbs such as Do or Create. If verbs such as Wait For or Pause Until seem more appropriate, you may have identified an assignment step, not a processing step.

■ You may find you need more than one shape in Row 2, with multiple connectors from the Flow shape that produces a major division in the flow. Such major divisions can be manifestations of different work types. If so, consider adding to your application class structure to include additional, refined work types.

In the following example, assume that the work is Gamma-Finance-Account. The flow shell quickly separates into two sections, for Accounts Payable objects and Accounts Receivable objects. Creating subclasses for two new work types (for example, Gamma-Finance-Account-AccountsPayable and Gamma-Finance-Account-AccountsReceivable) may significantly simplify the flow shell.

Row 3: This row contains only the connectors emanating from the shape in Row 2. Draw and label each connector and leave its termination point floating in Row 3 for now. Include all possible paths, including paths to handle error conditions.


Row 4 (If Row 2 Contains a Processing Shape): For now, terminate each connector in Row 3 either at the FlowEnd shape at the bottom of the page or at an Assignment shape.

For each connector that terminates in an assignment, create and label an Assignment shape. Then attach the connector to it. You can attach more than one connector to an Assignment shape.

Terminate all other connectors at the FlowEnd shape. Label each connector with the work to be done in the path.

Row 4 (If Row 2 Contains an Assignment Shape): Some connectors may indicate that processing within this flow is complete. Terminate these at the FlowEnd shape.

Decide whether the other connectors should terminate at an Assignment or Processing shape. Create each Processing and/or Assignment shape in Row 4, label it, and then terminate the connectors in Row 3 at the shapes in Row 4. You can attach more than one connector into a Processing shape.

Row 5: This row contains only the connectors emanating from the shapes in Row 4. Draw and label each connector, and then terminate each connector either at the FlowEnd shape or at another shape in Row 4.


Business Review Checkpoint At this point, review the flow shell with business experts and revise it as necessary. However, use only the level of detail described above. This keeps your first flow shells focused on high-level stages. You add more detail later.

Helpful Hints

■ Start a flow shell at the top of a Visio page, and end it at the bottom.

■ Write a few sentences that summarize one or two examples of the work to be done in the flow and include them at the top right corner of the flow shell. This description captures the major objective of the flow. For crowded flow shells, place the summaries on a separate Visio page.

■ Use the full class name to refer to a work type. This facilitates referring to other project documentation.

■ For connectors:

− To maximize readability, link connectors from the bottom of one shape to the top of another shape.

− Where multiple connectors emanate from one shape, preface the connector label with a number to indicate an order of evaluation, if the order of evaluation is significant.

■ For Assignment shapes:

− Use short phrases that describe a single purpose in the label, such as Wait for check to clear and Escalate to manager for approval.

− List all possible outcomes of the assignment. Consider all possible error conditions, as well as results when service level objectives are not met.

■ Make each flow shell easy to scan. Strive for no more than ten Assignment or Processing shapes per flow shell.

■ Avoid using the word or in the description of a Processing or Assignment shape. If you need to use or, you may have combined two distinct steps.

■ To simplify the diagram:


− Where multiple processing steps happen in series, use a single Processing shape with a description that includes all steps.

− Try to keep labels inside the corresponding shapes. If you need to provide more information than comfortably fits within a shape, use a comment.

■ A Processing shape may have one, two, or many possible outcomes. Make sure that the set of connectors leading from the Processing shape together cover all the possible outcomes.

■ For Processing and Assignment shapes, take the time to list all possible flow actions and outcomes to ensure that your opening flows don’t miss important processes.

What You Completed Identified actions and outcomes from each step of your business process.

Created simple flow shells for primary and secondary flows.

Reviewed flow shells with key business users and obtained approval to continue.

Clarifying Flow Shells Two rounds of review and editing, known as clarification and refining, are applied to the initial flow shells. This section describes exercises you can apply clarify the flow shells, eliminating common sources of confusion or error. Later in this step more rigorous refining is applied, replacing each Processing shape with one or more shapes that are more precise.

To clarify the flow shells, review the following examples for some common mistakes to avoid.


Define Processing Shapes Correctly This clarification is known as the “two processing box” rule — a connector should not directly link two Processing shapes.

■ Mistake — The flow shell includes two different Processing shapes in sequence because information is needed from two unrelated legacy applications.

■ Solution (Figure 8-3) — Processing shapes reflect the work to be done, not the way it is done. Combine both entries into a single Processing shape.

Figure 8-3. Combining Processing Shapes


Insert Assignments Appropriately

■ Mistake — A first shape describes processing, after which some work objects require a manager’s approval before other processing continues in a second shape. To model this requirement, the flow has one path from the first processing shape, through the Assignment shape, to the second Processing shape, plus another path with a connector that directly links the two Processing shapes.

■ Solution (Figure 8-4) — Assignments define a pause or the possibility of a pause. Delete the connector that directly links the two Processing shapes. There are other ways to model the bypass, presented later in this step.

Figure 8-4. Connecting Assignments and Processing


Duplicate the Processing That May Be Identical

■ Mistake — Within one Processing shape, five bullets describe the processing to be performed. Assume that later you discover that processing represented by three of these five bullets also needs to be performed within another flow path. Instead of duplicating the bullets in the other path, you divide the processing across two shapes. The original path directly connects the two shapes; the second path connects only to the second shape.

■ Solution (Figure 8-5) — In a high-level flow shell, it is usually premature to decide that processing identified in the three bullets is identical in the two cases. At this stage, duplicate these bullets in a second shape. You can revisit this decision as you continue to refine the flow shell.

Figure 8-5. Duplicating Processing for Future Paths


Extending and Refining Flow Shells To complete Step 8, your team must evolve each initial flow shell created thus far into a more detailed shell that uses only the shapes that appear in Process Commander flow rules. For each connector that extends from an assignment, you must identify a standard flow action rule or choose a name for the application-specific flow action rule.

Identifying Flow Actions A flow action rule specifies a choice, at a specific assignment in the flow, available to a user to perform work on the work object. Flow actions drive the user interface of your application. After a user decides what to do next, the user selects a word or phrase from a list (Figure 8-6). Each entry on the list corresponds to a flow action rule. Typically, the selected flow action presents additional fields for the user to complete, as defined in the flow action rule.

Figure 8-6. User Presentation of Flow Action List

There are two types of flow action rules:

■ Connector actions advance the flow, to move processing towards completion. They are associated with a Visio connector that exits an assignment shape, so selecting them causes the flow to advance along the path defined by that connector. In Figure 8-6, Resolve this work is a connector flow action.

Extending and Refining Flow Shells 8-21

■ Local actions allow a user to update a work object, but not advance the flow. After the update is complete, the flow execution remains paused at the same assignment shape. In this example, the Save and Transfer flow actions are local actions.

Your application can use standard and custom (application-specific) flow action rules as necessary.

At this point in the SmartBuild approach, your objective is to list the flow actions you need for each assignment. Update the flow shell, identifying the local flow actions to be available inside each Assignment shape. Label each connector line that leads from an assignment shape with a connector flow action name.

At this point in the SmartBuild process, identifying all possible outcomes of an assignment is more important than limiting user choices. Later, you’ll need to evolve the flow shell so that users in most situations must decide among at most five mainstream ways (five connector flow actions) to complete an assignment. A flow is intent-driven if it meets this constraint. See Appendix A for more information about intent-driven processing.

Standard Flow Actions Process Commander includes many standard flow action rules. For example, the Work-.AttachAFile action allows a user to attach a file to the current work object. TheWork-.Resolve flow action completes the current assignment and resolves the work object.

Review the standard flow actions to determine which can meet your needs or can serve as a starting point for a custom flow action. Flow actions are rules of type Rule-Obj-FlowAction, part of in the Process category in the Explorer tools.

What You Completed Identified the standard and custom flow actions you need.


Additional Shapes At this point, you have completed initial flow shells for the primary flows and obtained approval from business sponsors. The next step is to add more processing detail. First, you need to understand additional flow design shapes and then apply more rigorous definition (as marked by the shaded text) to the shapes you have already used (Figure 8-7).

Hereafter, discontinue use of the Processing shape. In initial flow shells, the Processing shape serves as a placeholder for other shapes presented in this section. As you refine the flow shells, replace each Processing shape with either a Utility shape or a secondary flow. (Two specialized shapes, known as Swim Lanes and Assignment-Service, are available in Process Commander 04-02 but not included in the flow shell VSS file.)

Note: This chapter uses the default shapes for Process Commander flow rules. Your team may already be familiar with the Business Processing Model Initiative (BPMN at www.bpmn.org) or other Business Process Management standards such as BPEL (Business Process Execution Language). Process Commander includes Visio stencils or other features which support these evolving BPM community standards, with full access to the business process features described here. In addition, you can create a custom Visio stencil using shapes already familiar to your organization and user community.

This book presents the default shapes and terms.

http://www.bpmn.org/


Shape Description

Assignment Pause, or potential pause, in a flow. Signifies that a person or an external system must act on a work object before the flow can progress. Label ♦ Who (or what, in the case of an external system) performs the work. ♦ Brief description of the work to be done. ♦ Two lists of activities that users can perform within the assignment:

– Local flow actions. – Connector flow actions.

♦ Work object status when the assignment first appears on a worklist or in a workbasket (typically Open or Pending).

Valid Connectors FLOW ACTION. These connectors limit the visible actions from each Assignment shape — only connector actions that have a flow action connector are visible. Be sure that you have a flow action connector for every connector action in the assignment.

Connector Unidirectional link between two shapes. You also define decisions that influence the processing path and choices presented to users. The connector type and label depend on the shape it emanates from. Label ♦ ALWAYS connectors. If a single connector emanates from a shape, label it

ALWAYS. ♦ WHEN connectors represent the result of a when condition rule. Label with

WHEN, how often the path will be taken, and the expression to be tested. – If multiple when conditions evaluate to true, the object follows the path

with the highest associated percentage. – If more than one condition is true and the conditions have identical

percentages, the path taken is non-deterministic. – For more control over execution order, use the Fork shape.

♦ STATUS connectors are based on the status returned by the shape it’s connected to (not the work object status). Label with STATUS, followed by the status value.

♦ ELSE connectors represent the path to be taken if no other connectors are satisfied. Label with ELSE.

♦ FLOW ACTION connectors represent a connector flow action. Label with the name of the connector flow action.

7 56

121110

8 4

21

9 3


Shape Description

Decision

Map one value, or a pair of values, to a small set of returned text results. ♦ For a single value, the returned result is based on a series of if tests. For

example, if a purchase request is less than $1000, return no approval necessary; otherwise return approval required.

♦ Two values are treated as a matrix. The returned result is contained in the cell defined by the row containing the first value and the column containing the second value.

♦ For either case, one returned value is typically default. Label ♦ Brief description of the decision and properties that are input values. ♦ For values involving two values, consider describing the matrix on a separate

Visio page. Valid Connectors STATUS. You must have a connector for each possible returned status value.

Flow Start of a flow. ♦ Top section contains the work type (class name). ♦ Bottom section contains the flow name and any comments about the

prerequisite state of work objects entering the flow. Valid Connectors ALWAYS.

Fork Split a connector into multiple decision paths, with each decision path based on a when condition rule. Label None. Valid Connectors WHEN and ELSE.


Shape Description

Invoke Flow

Called Flow (synchronous )

Spinoff Flow (asynchronous)

Start another flow execution from within the current flow execution. Use the Called Flow shape if you want the current flow execution to pause until the other flow execution completes. Use the Spinoff Flow shape if you want the current flow execution to continue without waiting. Label ♦ Flow name. Use a name that uniquely identifies how the secondary flow is

used at this point in the calling flow. ♦ Work object for the secondary flow to operate on:

– Current object (the calling flow’s current work object) — Specify the flow to invoke and either current or another clipboard page for the secondary flow to use as its primary page (also known as its interest page).

– Different object — Specify the flow to invoke, the class (work type) of the different work object, and the property name in the current object that contains the different object.

♦ Any parameters to pass to the other flow. Valid Connectors ALWAYS, WHEN, and ELSE.

Integrator

Connect to an external system or database to send or request information. Label ♦ Direction. To. ♦ System. Name of the external system. Valid Connectors ALWAYS, WHEN, and ELSE.


Shape Description

Split-ForEach

Spawn multiple, parallel flow executions of a single flow rule. Each flow execution operates on a different interest page (a page within a Page List property). Label ♦ When to join:

– All: after all flow executions have completed. – Any: when the first flow execution completes. Other parallel flow

executions are cancelled as soon as the first completes. ♦ Connector flow actions. ♦ Type of page, usually embedded. Page List properties are also supported, but

rarely used. ♦ Object class of the embedded or property list page. ♦ Property in the current page that references the embedded page, or name of

the property list. ♦ Flow to invoke (must be of the same class as page referenced above). ♦ (optional) A when condition with the same class as the page referenced above.

The when condition is evaluated for each page, and flows are created for pages that meet the when condition.

Valid Connectors ALWAYS, WHEN, and ELSE, emanating from the bottom triangle.

Split-Join

Split processing into two or more independent secondary flows that operate in parallel. Label In the top triangle, enter when the primary flow execution is to continue: ♦ All: after all secondary flow executions have completed. ♦ Any: after any one of the secondary flow executions completes. Other

secondary flow executions are cancelled after one completes. Valid Connectors WHEN, ELSE, and ALWAYS for both top and bottom triangles.

Ticket Event-driven override to normal sequential processing of a flow, for exception handling. Each ticket as a name, and one name can appear in multiple flows, but only once in each. Label Ticket name. Valid Connectors None.


Shape Description

Utility Automated activity. The flow execution continues after the automated activities in the Processing shape complete. Label ♦ Utility name. ♦ Applies To class name. ♦ Brief description of the work to be performed. ♦ Input and/or output parameters. ♦ List of status values that can be returned from the utility. Valid Connectors ALWAYS, WHEN, ELSE, and STATUS.

Figure 8-7. The Additional Shapes

Refining Flow Shells At this point, you can refine the initial flow shells. When this task is complete, the updated flow shells contain only shapes that directly correspond to the standard Process Commander Visio stencil.

Each Processing shape in your primary flow is a candidate for additional detail. At this point, introduce more detail where needed by creating separate, linked Visio pages in your flow shell document as placeholders. Later, you incorporate these pages into your flow shells.

Working from the top down, follow this process for each Processing shape in the primary flow that needs more detail:

1. Select the shape (the source) in the primary flow.

2. Add a new page in Visio to create a drilldown page for this primary flow. Name the page in a way that summarizes the processing it represents.


3. Copy the shape from the primary flow to the top of the new Visio page to serve as a placeholder. It provides a reminder of the steps to be done on this page and a visual cue back to the primary flow.

Note: For ease of reference, also add a Visio hyperlink from the source shape in the primary flow to the drilldown page.

4. At this point, you don’t have enough information to decide whether the drilldown page represents a secondary flow or a series of steps to be incorporated into the primary flow. For now, treat the placeholder as the starting flow for the page, with a single ALWAYS connector emanating from it.

5. Working from the top down, create a flow shell for the drilldown page. Follow the same process for creating flow shells for drilldown pages as for primary flows, with the following important differences:

Try to use only Process Commander shapes and labeling conventions for all shapes on drilldown pages. Replace the Processing shape with more specific shapes whenever possible.

6. Your initial flow shell may include some Processing shapes if they make the drilldown page easier to understand. If so, create additional drilldown pages for them. Continue iterating in this way until your drilldown pages contain no Processing shapes.

7. Return to the primary flow shell and repeat this process for all Processing shapes.


Helpful Hints ■ As you refine the flow shell, you may discover that a Processing shape is more

accurately modeled by an Assignment shape.

■ Create connectors to handle possible business error conditions.

■ A primary flow may contain Processing shapes that have similar labels and appear to have the same functions. During your first iteration, treat each shape separately. Once the details are clear, look for opportunities to combine drilldown pages with identical functions.

What You Completed Revised the flow shells to include only Process Commander design shapes,

creating flow shells for drilldown pages as needed.

Finishing Touches The next step is to link the drilldown pages to primary flows. First, determine whether each drilldown page is better implemented by a secondary flow, or is included as steps in another flow shell. If any of these tests apply, a drilldown page should become a secondary flow:

■ The processing on the drilldown page is called from multiple primary flows or multiple other drilldown pages.

■ The processing on a drilldown page applies to a work type that is not the same as the work type of the current the work object.

■ Inserting the processing on the drilldown page into another flow shell would make that flow shell difficult to understand.


Converting Drilldown Pages into Secondary Flows:

1. Note the placeholder at the top of the drilldown page. You originally copied this shape from a primary flow or another drilldown page. It provides a visual reference back to the flow shells that need to invoke this new secondary flow.

2. Replace the placeholder with a Flow shape and enter a label for the shape.

3. Change the name of the Visio page to match the flow name.

4. In each primary flow or drilldown page that contains a reference to a drilldown page, replace the reference with one of the two Invoke Flow shapes. Determine whether you want to start the secondary flow execution as a Called Flow (and wait for it to complete) or as a Spinoff flow (which executes in parallel to the current flow). Enter and label the appropriate shape.

Including Drilldown Pages as Steps in Other Flows: To include drilldown pages as steps in other primary or secondary flows, copy the shapes in the drilldown page into the flow shell. Then delete the drilldown page.

Identifying Screen Flow Candidates A business process that contains only assignments, flow actions and decision shapes can be implemented as a Screen Flow, a restricted flow rule used only as a secondary flow. When executed, such flow rules present to users a series of choices, often phrased as questions, each requiring a decision and answer. Screen Flow rules provide an attractive approach to structuring the user interface when complex, interrelated decisions are involved.

Review your secondary flows and note any that can be structured as Screen Flow rules.

What You Completed Linked any drilldown pages into the primary flows.



A list of work object creation channels to define opening flows.

A list of resolved states for each type of work object.

A list of outcomes from each step of your business process.

A list of flow action rules for your application, including standard flow actions and application-specific flow actions you need to create.

Primary and secondary flow shells that represent your work object processing, containing only valid shapes.

Step 9: Creating Flow Rules and Adding Process Details

After you have designed and documented your flow shells, your team can build the flow rules in Process Commander. You may also need to create activities and other types of rules to support the flows. SmartBuild Step 9 includes:

■ Creating flow rules that correspond to the processes recorded in flow shells.

■ Creating decision rules, to add logic tests to the application.

■ Creating flow action rules, which allow users to advance work through a flow.

■ Creating activity rules that assign, route, and validate work.

■ Setting work object status values and tickets.

Who Does This: Process architects work with system architects to perform these tasks.

9-2 Step 9: Creating Flow Rules and Adding Process Details

Important Terms and Concepts The following terms and concepts are important as you begin creating flow rules:

■ Flow rules (Rule-Obj-Flow rule type) consist of shapes and connectors, each with associated parameters and values. As the fundamental rules representing business processes, flows specify how work objects are initiated and then proceed to resolution. They specify who works on work objects in what sequence, what conditions apply to the work, which aspects of the work occur automatically or manually, and other governing principles.

■ Activities (Rule-Obj-Activity rule type) are reusable units of automated processing. Activities contain structured steps that specify the underlying logic and conditions. You create activities in the context of the work objects they operate on. Flows reference activities defined in or inheriting from the Work- base class. Activities are categorized into types; each Shape Properties dialog in Visio lists activities of the appropriate type.

■ Tickets (Rule-Obj-Ticket rule type) enable flows to bypass normal processing in response to unusual events.

■ Agents (Rule-Agent-Queue rule type) define units of background processing that operate on the server. They can monitor conditions and perform specified processing on a periodic basis.

■ Workbaskets are named containers for assignments. Typically, several application users can each take an assignment to perform next from a workbasket. Workbaskets can organize queued assignments that a user eventually performs, or act as holding bins for assignments awaiting an external event.

■ Worklists are lists of the assignments routed to one application user. Assignments are presented on the portal display sorted by urgency. Each user has a worklist.

A Recommended Approach 9-3

A Recommended Approach In the previous chapter, you created Visio files known as flow shells to represent the design of your flow rules. Step 9 involves turning these flow shells into flow rules.

■ In Step 8, if you identified additional properties or work types, or changes to the class structure and properties already created, update these class and property rules before proceeding with the steps in this chapter.

■ Work with business experts, process architects and system architects on your team. Process architects can enter flow rules, but system architects create the workbaskets and activities that flow rules reference.

■ Create flows using a top-down approach. Create primary flow rules first, and then any secondary flows.

■ Use Draft mode for flows that reference specific rules of other rule types (such as decision rules, flow actions rules, and activities) that do not yet exist.


Reviewing the Flow Shapes To create flow rules, you use the same design shapes as used in creating flow shells, but with greater rigor and specificity. As you work with these shapes in Visio, each design shape prompts for appropriate parameters.

The standard stencil includes two shapes that are not used with flow shells (Figure 9-1).

Shape Description

Router

Use with Assignment shapes to specify the operator or agent for the assignment. Must be attached to one of the top Visio handles for the Assignment shape.

Notify Use with Assignments shapes only. Notify a work party, the assigned operator, or someone else by e-mail of the current state of this work object. (See Step 10 for more information.)

Figure 9-1. Additional Flow Shapes to Use with Assignments

Note: See Step 8 for a complete list and description of other flow shapes.

Three Ways to Build Flow Rules Three approaches are available to build the flow rules you designed and documented as flow shells during Step 8. The flow rules can be obtained by any of these approaches, and your interactions with Visio are generally the same for each approach. You can:

■ Update a flow rule previously created in your application RuleSet by the Application Accelerator so that it matches a printed version of the corresponding flow shell.

■ Import a flow shell VSD file directly into a newly created Process Commander flow rule, taking advantage of the shapes and connector lines contained in the shell. This approach is known as rule harvesting.

Reviewing the Flow Shapes 9-5

■ Copy a selected standard flow rule into your application RuleSet. Then evolve the copy using Visio to match a printed version of the corresponding flow shell.

Application Accelerator Approach If you decide to use the Application Accelerator to create an initial version of your application, pick one of six available standard flow rules (identified as process templates) during the last step, for each work type (Figure 9-2).

Figure 9-2. Application Accelerator — Flows for Each Work Type

The Application Accelerator step lets you choose the Short Description label presented for each work type and the pyFlowName value (the Flow Type portion of the flow rule key). These two text values appear in the Process Label and Process Name columns of the form.


Choose a template that approximates the corresponding shell, if you find one. For example, the template Standard Basic Work (from the Work-.StandardBasicWork flow rule) contains two assignments and three final work object states (Figure 9-3).

Figure 9-3. Standard Basic Work Flow

If none of the flow templates appears similar to the flow shell you designed, you can make an arbitrary choice. Regardless of your choice, you must later use Visio to edit and revise the flow rules created by the Application Accelerator so they match the corresponding flow shell diagrams.


Rule Harvesting Approach You can import a flow shell VSD file directly into Process Commander as a starting point for the corresponding flow rule.

1. Locate the Accelerators and Wizards area of the Dashboard workspace. Click the Create a Rule from a File link to start the rule harvesting wizard.

2. Enter the flow name (pyFlowName value) in the Rule Purpose field. When prompted, select Flow as the rule type and complete additional wizard fields.

3. Upload the VSD file, which becomes attached to the new flow rule as a special Custom Field value, visible on the History tab.

4. Save the new flow rule. You can begin Visio-based editing to evolve and refine the flow shell structure, updating Shape Properties panels as necessary.

Direct Approach You can also create flow rules from scratch, transcribing information from printed copies of your flow shells into the Flow form, and using Visio to update the diagram on the Diagram tab.


Working with Flow Rules Flow rules are easy to maintain because Process Commander is tightly integrated with the diagramming capabilities of Microsoft Visio. You create a flow rule in the portal and then start Microsoft Visio to edit the diagram presented on the Diagram tab of the Flow form.

Flow rules are of type Rule-Obj-Flow, part of the Process category in the Explorer tools. Figure 9-4 shows the form for creating and modifying flow rules. Refer to the Application Developer Help system for information about how to use this form and what to enter in each field.

Figure 9-4. Flow Form


On the Process tab (Figure 9-5), you specify settings to control whether the flow creates a work object, what model rule to use, what harness rule is used when a new work object is created, whether the new work object belongs to a cover, and what privileges are needed to run the flow. (More about privileges appears in Step 11: “Setting Up Access and Security.”)

Figure 9-5. Process Tab of Flow Form


Using Draft Flows To edit a flow rule, drag shapes from the Process Commander stencil onto a Visio diagram. As you drop or select a shape, Visio prompts you for the required rules, parameters, and properties required for each shape. When you exit from Visio and save a flow rule, Process Commander validates that all shapes are properly defined.

You can create fully validated flow rules that are ready for testing, or draft flow rules that are incomplete and therefore not validated or executable. Designating a flow as a draft allows you the flexibility to experiment with flow design, so you can:

■ Lay out your flow diagrams quickly without defining the required details for every included shape.

■ Add design shapes to a flow without specifying every parameter.

■ Include shapes in a flow, even if the activities, flow actions, and other supporting rules do not yet exist.

■ Save an incomplete flow rule and resume work on it later.

To mark a flow as a draft, click the Draft button on the toolbar. You can make changes, save the flow, and resume working later. To remove draft status and force validation of Shape Properties and other form elements, click the Draft button again.


Helpful Hints

■ For a starter flow (a flow that creates a work object), choose the value for the Short Description carefully. This text appears in the New selection box on the Process Work navigation area, where users choose the type of work they are creating.

■ Use the Flow Explorer on the Manage Rules home view to review all flows for your application, including relationships between starter flows and subflows.

■ You must check the Creates a new work object check box on the Process tab in order for a flow to appear in the New selection box on the Process Work navigation area.

■ Assignment shapes not linked to a router shape cause an assignment object to appear on the worklist of the current user. This may not be the desired behavior. To route an assignment to anyone except the current operator, add a router task to the assignment task.


Adding Process Details To complete Step 9, use these capabilities to refine and extend your flow rules:

■ Decision rules — determine one path among a set of choices

■ Tickets — support exceptions

■ Flow actions — define user choices

■ Activities — define procedural processing

– Routing activities send assignments to a worklist or to a workbasket

– Utility activities automate processing that requires not user interaction

– Notify activities send correspondence automatically

■ Work status — records progress and state

Using Decision Rules to Add Logic Tests Your flow rules may contain decision shapes (Figure 9-6). A decision shape causes processing to continue along one of a set of connectors, depending on the outcome of an evaluation of a decision rule.

Figure 9-6. Decision Shape Example

Adding Process Details 9-13

Three types of easy-to-maintain decision rules test and return values based on defined input parameters:

■ Map value rules (rules of type Rule-Obj-MapValue) define decisions based on one or two explicit input values. For example, you can define a value rule map that returns an appropriate correspondence format based on the desired response mode (Figure 9-7).

Figure 9-7. Map Value Rule Form

■ Decision trees (rules of type Rule-Declare-DecisionTree) define decisions based on if-then logic. For example, you can define a decision tree that determines the next approver for a purchase order based on dollar amount — if less than $10,000, then the Vice President is the next approver; if less than $25,000, then the Chief Operating Officer is the next approver; and so on.

■ Decision tables (rules of type Rule-Declare-DecisionTable) define decisions based on a series of test conditions to be evaluated, also known as if-else logic. For example, you could define a decision table that determines the automobile insurance rate based on driver characteristics such as age, state, and type of car.

These types of rules are all part of the Decision category in the Explorer tools. You reference them in Decision shapes within a flow.


Using Tickets Effectively Tickets are used to respond to event-driven exceptions that interrupt the likely process flow. Tickets override to the normal, sequential processing of a flow execution. On a flow diagram, a ticket shape marks the starting point of processing after the ticket event occurs. Each ticket shape links to a ticket rule.

Ticket processing is analogous to such programming language facilities as GOTO (in Basic) or On Event (in JavaScript). Because tickets manage business process interruptions, their number should be limited.

One ticket rule may appear in multiple flow rules. However, a flow rule can contain only one ticket shape referencing a single ticket rule. Tickets are set — turned on — by the standard flow action named Work-.SetTicket, the standard activity Work-.SetTickets, or custom activities. Ticket events have object scope — that is, they impact all flow executions for the current work object. When a ticket shape appears in a flow rule, you refer to the flow as sensitive to that ticket.


For a work object, at the time a ticket is set:

■ Any executing flows that are not sensitive to this ticket are not affected.

■ Any executing flows that are sensitive to this ticket are immediately interrupted and resume executing at the ticket’s location in the flow.

■ Any flows started on this work object after the ticket has been set are unaffected.

Tickets are rules of type Rule-Obj-Ticket, part of the Process category in the Explorer tools. Figure 9-8 describes three standard ticket rules.

Ticket Description

Work-Cover-.AllCoveredResolved

Set automatically as soon as all work objects within the cover have been resolved.

Work-.Withdraw Cancel the work object. Set in the Withdraw flow action.

Work-.StatusRevolved Set when the work object status changes to Resolved.

Figure 9-8. Standard Tickets

Guiding User Input with Flow Actions Flow action rules present users with choices for completing an assignment.

In Step 8, you reviewed standard flow action rules and identified any custom flow action rules needed by your application. Before creating a custom flow action rule, always check whether a standard flow action rule meets your requirements. If none is suitable, determine whether one of the standard flow action rules can serve as a starting point for one you need to build.


Most standard flow actions follow a naming convention that categorizes them by function. Each name contains a verb that suggests its purpose (Figure 9-9).

Verb Purpose Example

Attach Add an attachment to the work object Work-.AttachAFile

Change Change work object and/or assignment property values

Work-.ChangeOwnerOrg

Engage Initiate a new flow to involve another party Work-.EngageManager

Notify Generate correspondence Work-.NotifyExternal

Transfer Change responsibility for assignment Work-. TransferToManager

Figure 9-9. Naming Conventions for Standard Flow Actions

Note: For clarity and ease of maintenance, adopt a similar naming convention when naming your custom flow action rules.

Working with Flow Actions By referencing flow action rules in an assignment shape in a flow rule, you determine the choices available to users as they perform an assignment. Assignment tasks may require local flow actions such as Save or Transfer. They may also require connector actions emerging from the assignment, indicating how the flow advances after the assignment is completed.

Flow actions are rules of type Rule-Obj-FlowAction, part of the Process category in the Explorer tools.


Each flow action rule includes a Short Description text (visible to users in a selection box), HTML for display, a validation rule to edit user input, and a type (Local, Connector, or both). A more complex flow action can include HTML that provides instructions to the user (a form of application-specific, context sensitive help).

Through optional privileges fields, developers can restrict which users can select and execute the flow action. A flow action can identify activities to be run before and/or after processing.

Helpful Hints

■ Choose a name for each flow action rule that clearly identifies its purpose. For clarity and consistency, place a verb first and use uppercase letters for important words. For example, use TransferToLegal for a flow action that transfers work objects that require review by the Legal department.

■ Check again that most assignments have no more than five simultaneously available connector flow actions leading from them, to simplify decisions by users. Where more than five connector flow actions appear, consider restructuring the flow to contain two or more cascading assignments, each with no more than five connector flow actions, so that user decisions are progressive and staged. See Appendix A for more information on this design objective.

■ Create flow action rules with the appropriate Applies To class. To share the flow action among multiple work types, consider which work types need to use the flow action. Then create the flow action for the common parent class.

■ To restrict access to a flow action to only selected users, create a privilege rule (Rule-Access-Privilege rule type, addressed in Step 11) and reference the privilege rule on the Security tab.

■ To restrict use of the flow action to specific situations (rather than to selected users), reference a when condition rule (Rule-Obj-When rule type). If the specified when condition is not true when a user accesses the assignment, the selection box on the work object form omits that flow action from the choices available.


Adding Automation with Activities Activities are among the most powerful types of rules. Activities specify automated processing, defining the logic and conditions in a sequence of structured steps. Flow rules directly reference activities of certain types; activities of other types provide general capabilities. Activity steps invoke Process Commander methods, which are atomic operations that:

■ Compute and update property values on the clipboard.

■ Retrieve data from the database.

■ Save data from memory to the database or to external systems.

■ Manage the process flow-of-control.

Reviewing Standard Activities Activities are rules of type Rule-Obj-Activity, part of the Technical category in the Explorer tools. Process Commander includes dozens of standard activities that support work object processing. A good way to see how activities work is to examine the standard activities that apply to the Work- base class.

Your team can build activities to automate tasks specific to your application. After becoming familiar with standard activities, you can determine when to use a standard activity directly or as a starting point for a custom activity. Look for a standard activity that approximates the processing your application requires. Copy the standard activity into your RuleSet and customize the copy as needed.

Developing Activities To create an activity rule, define the steps and parameters in the Activity form. When you save the form, Process Commander converts this definition into Java code for later runtime execution.

The design, development, and testing of activities require programming skills and use concepts and notation similar to the Java programming language. However, system architects can create and debug many activities without extensive Java experience.


Note: Some skilled software developers may attempt to perform too much application processing in activity rules, rather than in declarative rules, when condition rules, flow rules, and so on. This approach can undermine the Built- for-Change benefits of Process Commander and can be costly in terms of schedule and team resources.

Using too many custom activities and too few rules of other types in an application severely affects the ability of non technical staff to maintain and evolve the business rules. To build for change, limit the number and complexity of custom activities, and encourage use of other rule types. Appendix A provides additional information about this SmartBuild guideline.

Understanding Activity Types Each activity rule has one of the types shown in Figure 9-10.

Type Purpose Example

Activity Perform general processing that is not referenced directly from a flow shape.

Work-.New

Assign Initiate assignments. Reference in the Assignment shape.

Work-.Worklist

Connect Interface with an external system by calling a Connect rule. Reference in the Integrator shape.

(None)

Locate Search for and open a referenced page. (None)

Notify Send correspondence and notifications. Reference in the Notify shape.

Work-.CorrSend

OnChange Perform processing that is executed by a Declare OnChange rule.

(None)

Route Route assignments. Reference in the Router shape.

Work-.ToWorkbasket


Type Purpose Example

Trigger Perform processing that is executed by a Declare Trigger rule.

Data-Admin-Operator-ID.TriggerCheckCache

Utility Perform automated processing that requires no user input. Reference in the Utility shape.

Work-.GenerateID

Validate Validate user input. Work-.Validate

Figure 9-10. Activity Types

Specifying an activity type ensures that only the appropriate activities appear for your selection in Visio Shape Properties dialogs. For example, as you add a Routing shape to your flow, the Shape Properties dialog lists only routing activities.

Generating and Reviewing Activity Descriptions The Steps tab of an Activity form includes a Describe this Rule button (Figure 9-11).

Figure 9-11. Describe This Rule Button

When you click this button, Process Commander translates the activity logic and configuration into a structured English summary of the rule (Figure 9-12).


Figure 9-12. Activity Description

You can generate this description (as an HTML page) for any activity. Activity descriptions document what an activity does. Click any links in the description to open a rule referenced in the step.

Monitoring Performance of Activities Activities, like traditional programming elements, can contribute to the overall computational demand placed on your Process Commander environment. Sound software principles of modularity, limited searching and looping, and code review apply to activities to help provide good performance.

Use the Performance tool to monitor the effect of your activities (and flows) on the computational demand of a typical user. Record the results of specific tasks from time to time as your application evolves, to assess any increases in computational resources that may prevent scaling to production volumes. Use the Tracer tool, Clipboard tool and System Console to gain in-depth understanding of activities that may become performance bottlenecks.

For more about performance monitoring, see Appendix A.


Building Activities for Routing A router shape within a flow rule (Figure 9-1 on page 9-4) can route an assignment to one of five types of destinations:

■ Worklist — a list of assignments (instances of the Assign-Worklist class) to be performed by a specific user of the application.

■ Workbasket — a name for a shared pool of assignments (instances of the Assign-Workbasket class) from which multiple users can fetch.

■ External Operator or System — a destination that is outside of Process Commander.

■ Agent — a background process for use with workbaskets, such as routing assignments from workbaskets to other destinations upon a certain event or signal.

■ Connector — a synchronous processing step where the flow connects to an external system or database and waits for information in a response.

Standard routing activities support the first four destination types. If your application requires a custom routing activity, copy a standard router activity into your RuleSet and modify the copy.

Evaluating Workbasket Needs Whether you need one, two, or a dozen workbaskets depends on the structure of your organization, the types of assignments to be made, the processing to be performed, and the management reporting desired. For example, your organization may benefit from having one or more workbaskets per division or organizational unit. Alternatively, for one line of business, assignments may be routed to individual worklists, but to workbaskets for another line of business.

Administrators can create additional workbaskets as needed by completing the workbasket form. For example, suppose the application is to route all product-specific complaints to a common workbasket for centralized handling.


An application can have workbaskets dedicated to work objects involving human resource issues and legal issues (using access roles to limit access only to employees in the corresponding departments).

After a workbasket is configured, you can specify in the relevant flow rules that workbasket name as a parameter to the standard routing activity Work-ToWorkbasket.

Workbaskets are instances of the Data-Admin-Workbasket class, part of the Organization category in the Explorer tools. Because workbasket instances are in a Data- class, not a Rule- class, workbaskets are not rules; rule resolution does not apply. Accordingly, your Process Commander environment cannot contain two workbaskets with the same name.

Note: Choose a name that clearly identifies the purpose of each new workbasket. By convention, workbaskets follow a naming convention similar in format to an e-mail address. For example, [email protected] can identify the workbasket to which product-related issues are routed.


Standard Routing Activities A few standard routing activities are listed in Figure 9-13. By convention, routing activity names begin with the prefix To for quick identification.

Routing Activity Purpose

ToAgent Route to agent entered in parameter.

ToCorrPartyRole Route to correspondence party role.

ToCostCenterManager Route to operator designated as the manager of the cost center.

ToDefaultWorkbasket Route to the current operator’s default workbasket.

ToDecisionTable Route to the result of a decision table rule.

ToDecisionTree Route to the result of a decision tree rule.

ToLeveledGroup Route to the operator in the work group who has the skills needed for the assignment and least amount of work.

Figure 9-13. Standard Routing Activities

You can create custom routing activities as necessary. For example, a routing activity can send assignments to one of ten work group members based on the final digit of the customer account number.

Create routing activities for the appropriate Applies To class. To share a routing activity among two or more work types, assess which flow rules need to reference the routing activity. Create the routing activity in the lowest class that is parent to the Applies To classes of these flow rules.


Building Activities for Notification Notifications are the second activity type commonly referenced within flow rules. Each Notify shape (Figure 9-1 on page 9-4) references an activity of type Notify. Your flow can call one of the standard activities of this type, or you can copy a standard activity and modify the copy as appropriate (Figure 9-14).

Notification Activity Purpose

Work-.Notify Send an e-mail message as correspondence to a party identified through a parameter.

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

Work-.NotifyAssignee Send an e-mail message to the user who received the assignment.

Work-.NotifyParty Send an e-mail message to the user who received the assignment.

Figure 9-14. Standard Notification Activities

Building Utility Activities Utility activities perform computations without requiring additional user input. Activities of this type operate synchronously when processing of a work object advances to an oval Utility shape in a flow. In contrast, similar computations recorded in a declarative rule (addressed in Step 6 of this book) are performed automatically, whenever needed.

Create utility activities only when rules of another type cannot provide the capabilities you need. Activities offer substantial benefits to your application by automating processing previously performed by staff, but they also require technical skills to write, test, and maintain.

As with other activities, review the many standard activities in the Work- base class for suitability or adaptation to you needs.


Restructuring Large Flows for Clarity and Modularity Although many business processes are complex and are accurately modeled by correspondingly large Visio diagrams, it is important for many reasons to limit the size and complexity of each flow rule.

■ Smaller, simpler flows are easier for managers, business analysts and users to learn and follow, and for application developers to test

■ Exceptions and low-volume error-handling tasks can be moved to a subflow.

■ High-level flows which call subflows (with Split-ForEach or Split/Join) may achieve higher throughput through parallel processing.

Accordingly, this is a good time in the development to shift the focus from somewhat from function completeness of the flows to clarity of the flows. Restructing one flow into several, so that each fits on a single page and contains no more than 15 shapes (not counting connectors, Notify, and Router shapes) promotes modularity and clarity. Such restructuring need not reduce the scope or power of your application; it makes the application easier to learn and maintain. Appendix A summarizes this design principle.

Understanding and Using Work Status The work object status property (Work-.pyStatusWork) reflects the overall status and other aspects of a work object. Whenever the values of this property change, Process Commander automatically calculates several related Work- properties, using Declare Expression rules.

Values for this property are defined through Field Value rules. For the pyStatusWork property, choose only new values that start with one of these four words and a dash:

■ New — identifies work objects that have arrived or been entered, but which are not yet researched or qualified; little or no resources have been expended so far to advance the work object towards resolution.

■ Open — indicates that responsibility for advancing this work object belongs with the current processing organization.


■ Pending — indicates that primary responsibility for advancing this work object rests with an external organization or event rather than the current organization.

■ Resolved — indicates that all processing on this work object is complete.

For example, a standard Field Value rule defines a work object status value of Resolved-Completed. Similarly, an insurance claims application can include a work object status of Pending-Claimant.

Note: To change the status of a work object, include the standard utility activity Work-.StatusUpdate in flow rules, or call this activity from a custom activity. Do not attempt to change the value of the pyStatusWork property directly through other means.


Verifying the Entry Process Your last step in creating flow rules is to connect opening flows to primary flows. (In practice, an opening flow is often implemented by an activity that is sensitive to the channel through which work arrives; it is not a true flow rule.)

When a work object is entered, the value of the pyFlowName property identifies which flow rule to start for the work type. (The model rule for each work type sets a value for the pyFlowName property.)

An activity can start execution of a top-level flow by either of these approaches:

■ Including a model rule named pyDefault for the work type that sets the value of the pyFlowName property to a primary flow.

■ Copying and tailoring the standard Work-.Add or Work-.AddCovered activities, adding a step that sets a value for the pyFlowName property.

At this point, your work object entry processing is complete enough for testing.

Helpful Hints During tests of work object entry processing, if users encounter an error message indicating that the starter flow cannot be found, a likely cause is the model rule. Perhaps you created a new model for that work type but did not include a valid value for the pyFlowName property.



Task


Explorer Category

Rules

Create activities to automate processing in a flow Rule-Obj-Activity Technical

Create flow rules Rule-Obj-Flow Process

Create flow actions to add user control options to a flow Rule-Obj-FlowAction Process

Create decision rules that return values based on supplied parameters

Rule-Declare-DecisionTree Rule-Declare-DecisionTable Rule-Obj-MapValue

Decision

Create tickets to add event-driven processing to a flow Rule-Obj-Ticket Process

Define basic field validation for HTML forms Rule-Obj-Validate Process

Create when conditions to define the appropriate path for a work object in a flow

Rule-Obj-When Decision

Data

Understand how Process Commander uses workbaskets for assigning work

Data-Admin-Workbasket Organization

Understand how Process Commander uses worklists for assigning work


Create and use workbaskets for routing work Data-Admin-Workbasket Organization



Flow shells from Step 8 translated into Process Commander flows, with no remaining placeholders.

All supporting objects created and included in flows:

– Activities

– Decision rules

– Tickets

– Flow actions

– Workbaskets

– Routing activities

– Work object status

Opening flows connected to primary flows. Complex flows reorganized into multiple, simpler flows that fit on a single page.

Work object entry and flow initiation verified.

Step 10: Adding Communications Capabilities

Most business processes require the organization to communicate with a variety of outside people and entities. In this chapter, you learn about SmartBuild Step 10, including how to incorporate communications capabilities into your application:

■ Correspondence

■ Inbound and outbound e-mail

■ Notification by phone, text or pager

■ Directed Web Access

Who Does This: Process architects typically work with system administrators to perform these tasks.

10-2 Step 10: Adding Communications Capabilities

Understanding the Correspondence Model To build for change, Process Commander correspondence facilities are implemented as rules:

■ Correspondence rules — define the content and structure of outgoing messages, analogous to a form letter.

■ Format preferences — allow your application to send outgoing messages in whatever format is preferred by the party receiving the message.

■ Generation alternatives provide flexibility:

– Flow action rules allow users to control whether correspondence is sent, to whom it is sent, and to compose or edit the contents of the message.

– Utility activities can automatically assemble, format, and send out correspondence at designated places in the flow.

– Agent rules can produce correspondence on a schedule (for example, reporting by e-mail on progress and status to an important customer at midnight each business day.)

■ Media — Correspondence types (Rule-CorrType rule type) include fax, letters, text messages, and e-mail.

■ Printing — Users can print each item of correspondence when it is generated, or send the correspondence to a supporting application (PegaDISTRIBUTION Manager) for background printing.

Note: To provide background printing support for your system, install the optional PegaDISTRIBUTION Manager product. For more information, see Step 12: “Configuring System Interfaces and the PegaRULES Database.”

These options provide a flexible framework for sending correspondence and similar notifications from your application.

All use of correspondence is optional. Some applications do not directly communicate with external parties. However, most business processes involve communication with multiple inside and outside parties to obtain needed information

Understanding the Correspondence Model 10-3

or decisions, to notify others of progress and status, or to fulfill legal or contractual commitments.

Your application can send correspondence to any work party present in a work object. The frequency, media, content, and language of each correspondence item can be adjusted to suit the needs of both sender and recipient.

How Correspondence Is Assembled To produce an item of correspondence from the rules, Process Commander assembles clipboard pages containing the needed property values. Correspondence text is assembled from HTML text stored in correspondence rules and correspondence fragments.

The correspondence rules contain JavaServer Page tags (or directives) that control the assembly process that merges property values from the clipboard with HTML code. Final formatting depends on the media, such as Microsoft Word, HTML-formatted e-mail, text-only e-mail, or phone text.

Viewing Previous Correspondence as Attachments Process Commander retains details of the correspondence processing path as a permanent part of the work object history. It also retains the correspondence item as an attachment to the work object, so it can be displayed later and resent if necessary. Users have full access to correspondence history in the appropriate format. This allows users to examine all outbound communication about a work object in context.


Correspondence Capabilities and Design Options As you design and build correspondence capabilities, you can determine:

■ Where within a flow correspondence is created.

■ Whether users can select the content and can revise the content of the correspondence message.

■ Whether a second user must review and approve certain correspondence.

Automatic Generation in a Flow By calling an appropriate utility activity, a flow can send out correspondence automatically, without user interaction. For example, Figure 10-1 shows part of a flow rule that calls the Work-.EmailToManager utility. In this example, after entering a new work object, users can decide either to continue working on the new work object or transfer it to a co-worker or to a workbasket. When a user chooses the first option — self-assignment — the flow sends an e-mail to the user’s manager.

Figure 10-1. Automated E-mail Correspondence in a Flow

Such automatic notifications can occur without disrupting processing, informing work parties or others whether various milestones thresholds have been met, or whether service level deadlines were met.


User-Initiated Correspondence Flow actions can allow users to create correspondence. This design approach is useful, for example, when the user needs information from a work party to complete an assignment (Figure 10-2). By selecting a correspondence-related flow action, the user creates and sends inquiries to whichever party is most likely to supply the information.

Figure 10-2. Flow Actions Supporting Correspondence

Restricting or Allowing User Changes Correspondence rules can allow users full edit access to the content of a message. For example, when you enable user editing in a correspondence rule, an edit option allows users to open the correspondence item in Microsoft Word (Figure 10-3).

Figure 10-3. Editing Correspondence in Microsoft Word


Alternatively, a correspondence rule can prompt users only for specific pieces of information that are needed to complete the correspondence item. For example, in Figure 10-4, a form prompts only for the subject and personal message lines needed to complete an e-mail message. The rest of the message is assembled automatically, without user review or editing.

Figure 10-4. Prompt for Correspondence Details

Verification Before Sending When legal or financial commitments are conveyed in correspondence, it is common to require that a second person review and accept or revise correspondence composed by a subordinate or co-worker. In the banking industry, this process is known as verification. As suggested by Figure 10-5, standard flow rules and utilities allow managers to check each item of correspondence before it is sent.

Figure 10-5. Verification Routing in a Flow


Standard Rules Supporting Correspondence Process Commander includes standard rules that you can use or adapt for correspondence. This section identifies and summarizes them:

■ Correspondence rules (Rule-Obj-Corr rule type)

■ Activities (Rule-Obj-Activity rule type)

■ Flow Actions (Rule-Obj-FlowAction rule type)

■ Flow rules (Rule-Obj-Flow rule type)

Standard Correspondence Rules Correspondence rules are of type Rule-Obj-Corr, which is part of the Process category in the Explorer tools. Correspondence rules simplify the process of setting up consistent correspondence by predefining a layout and content:

■ Some correspondence rules such as Work-NewAssignment and Work-ResolutionSample are top-level rules. They serve as master templates that include other elements.

■ Other correspondence rules such as Work-.Details and Work-Footer define individual segments or sections to be included in the master templates.


Standard Flows for Correspondence Three standard flow rules support correspondence operations (Figure 10-6). They can provide the infrastructure for correspondence generation. Your application can call or branch to one of these flows to initiate correspondence. Alternatively, you can implement correspondence capabilities within your own flows, using flow actions and Notify activities.

Flow Purpose

Work-.Notify Generate an item of correspondence (a notification) based on a user-selected format and type.

Work-NotifyQuick Generate an item of correspondence using a format designed for rapid entry of brief text.

Work-SendCorrespondence

Generate and send correspondence, waiting for verification if necessary.

Work-.VerifySendCorr Checks generated correspondence items for errors and verification requirements and routes them accordingly.

Figure 10-6. Standard Flows for Correspondence

Standard Activities Supporting Correspondence Standard activities support correspondence creation and processing (Figure 10-7). Your application can call any of the standard activities, or you can save a copy of the activity rule in your RuleSet to use as a starting point.

Activity Purpose

Work-.CorrNew Generate correspondence in flows in situations where the flow execution can advance asynchronously, not waiting for the correspondence item to be sent. This activity calls the Work-CorrCreate activity.

Work-CorrSend Generate correspondence in flows where processing continues only after the correspondence is complete.

Figure 10-7. Standard Activities Supporting Correspondence


A standard activity named Send is available for each Data-Corr- class (for example Data-Corr-Email.Send and Data-Corr-PhoneText.Send). These activities define the processing that sends out the correspondence item and updates work object properties and work object history.

Standard Flow Actions Supporting Correspondence Standard flow actions supporting correspondence are available (Figure 10-8). Use them as they are, or save a copy in your RuleSet to use as a starting point.

Flow Action Purpose

Notify Generate an item of correspondence (a notification) based on a user-selected format and type.

NotifyExternal Generate an item of correspondence to a party external to Process Commander.

NotifyQuick Generate an item of correspondence using a format designed for rapid entry of brief text.

Figure 10-8. Standard Flow Actions Supporting Correspondence

The Notify flow action provides users with a wide range of choices, listing all correspondence rules of the selected correspondence type that are available to the user (Figure 10-9).

Figure 10-9. User Interface of Notify Flow Action


Building Correspondence Capabilities Follow these guidelines to design and build correspondence into your application:

■ Identify which standard flow actions, flows, and correspondence rules are most relevant to your application. Flow actions are relevant only for user-initiated correspondence

■ Determine which work parties (based on their role) are to receive correspondence, and the purpose of each item or message.

■ Choose naming conventions for correspondence rules, according to conventions described later in this section.

■ Determine the events or places in each flow at which an item of correspondence may be produced. For each, decide whether generation is automatic or requires user selection, user parameters, or user editing.

■ Compose the boilerplate text that is to become the content of each message. If one message may be sent in any of multiple formats (depending on the recipient’s preferences), create versions of the text suitable for each format.

■ Identify the property that is to provide the source value for each variable element. Examine the flow and processing to verify that the properties are likely to have a value at the time the correspondence is produced.

■ Create correspondence rules. For maximum reusability and minimum maintenance, use fragments and embedded correspondence rules as described below.

■ Update the flow rules to add flow actions, utility activities, notify activities, or called subflows that allow or produce correspondence.

■ Test correspondence generation.

Building Correspondence Capabilities 10-11

Designing Correspondence Elements for Reuse Three rule types define the correspondence format and content (Figure 10-10). They are part of the Process category in the Explorer tools:

■ Correspondence rules (of type Rule-Obj-Corr), which serve as templates for generating correspondence. To reduce maintenance, one top-level correspondence rule often serves as a master template that incorporates other correspondence rules (such as static paragraph text, boilerplate, and conditionally included material).

■ Correspondence Fragments (of type Rule-Corr-Fragment), which define supporting elements to be included in correspondence rules. Because correspondence fragment rules do not apply to a single class, they can be used in correspondence for any work type.

■ Correspondence Types (of type Rule-CorrType), which define the intended media format (such as letter, e-mail, or fax) for the correspondence.

Figure 10-10. Example Correspondence Structure


Controlling the Places and Extent of User Interaction Decide whether, when, and how users of your application can interact with correspondence facilities:

■ Your application can require manager verification, allow users to send correspondence directly, or create correspondence items and attach them to the work object, but never send them.

■ You can prohibit, allow, or require interactive user editing of generated correspondence — or allow read-only review.

■ If a correspondence rule prohibits user editing, your application can nonetheless prompt users for selected input, copy the provided text into the generated correspondence, and assemble the document.

Naming Conventions Adopt naming conventions for correspondence rules that clearly identify their purpose and content. For clarity and consistency, start each name and each embedded word in a name with a capital letter. For example, you can enter FooterResolution for a rule that contains the footer text for a notification sent when a work object becomes resolved.


Capabilities to Consider in This Step The optional capabilities described in this section can enhance the power and value of your application and the productivity of your user community. Assess whether they are useful in your application during Step 10, and implement them if desired.

■ Outbound e-mail, as correspondence to a work party identified in a work object

■ Inbound e-mail, processed automatically to create attachments or work objects

■ Directed Web access, to allow trusted outside parties who are not Process Commander users to provide decisions or facts for an assignment through e-mail

Your application can:

■ Generate e-mail correspondence to work parties.

■ Send e-mail notifications to stakeholders when a work object arrives at specified processing thresholds.

■ Create a work object and start a flow execution automatically upon receipt of an e-mail message. The arriving message becomes an attachment to the work object.

Note: Work with your system administrator to configure e-mail functions. See the Administration and Security book for instructions.

Outbound E-mail Correspondence rules designed for outgoing e-mail messages have a Type of Email. Work with your system administrator to set up e-mail accounts (instances of class Data-Email-Account) that identify the e-mail servers, user IDs, and passwords to send and receive e-mail.


Converting Inbound E-mail Messages to Work Objects Your application can automatically create work objects and route assignments from information in an incoming e-mail message. An agent checks an e-mail server periodically to download e-mail routed to specific accounts.

For each arriving e-mail message, the agent also calls an activity that creates a work object, based on a work type and model rule specified in the e-mail account rule. The e-mail message becomes an attachment to the work object. The activity starts execution of the flow specified in the model.

Delivering Services Using E-mail Transport Your application can accept and respond to e-mail messages sent by an external system. For example, an e-commerce application may use structured e-mail messages (rather than SOAP-over-HTTP messages) to convey orders and order status. Service Email rules (Rule-Service-Email rule type) provide this capability. Integration Services are addressed in Step 12.

Enabling Directed Web Access for External Users Use the Directed Web Access feature to engage people who do not directly use Process Commander and involve them in only the portions of work object processing that require their input. Nonregistered users receive an e-mailed assignment link that they use once to access the application. Directed Web Access enables them to provide the requested information, after which their interaction is complete.

Directed Web Access provides a single restricted point of access from the outside world into your application. You can further secure your system at the system level by restricting access to HTTPS servers and adding firewalls as necessary.



Task


Explorer Category

Rules

Tailor or create correspondence rules Rule-Corr-Fragment Rule-CorrType Rule-Obj-Corr

Process

Tailor or create flows that create correspondence Rule-Obj-Flow Process

Tailor or create activities that support correspondence Rule-Obj-Activity Technical

Tailor or create flow actions that support correspondence

Rule-Obj-FlowAction Process

Use an agent to process inbound e-mail Rule-Agent-Queue SysAdmin

Configure Directed Web Access for external users Rule-Obj-Flow Rule-Obj-Activity

Process Technical

Data

Review Data-Corr- classes for correspondence examples

Data-Corr-* N/A

Configure inbound and outbound e-mail Data-Email-Account SysAdmin



Correspondence rules created for each correspondence type, typically consisting of:

- One top-level Correspondence rule (of type Rule-Obj-Corr), plus one or more included section-level correspondence rules.

- One or more Correspondence Type rules (of type Rule-CorrType).

- Correspondence fragments (of type Rule-Corr-Fragment).

Correspondence flows created, if needed.

Correspondence flow actions created, if needed.

E-mail accounts created for inbound and outbound e-mail.

Agents created for inbound e-mail configuration.

Initial flows and models for work objects created by inbound e-mail, if needed

Additional flows and activities defined for Directed Web Access to external users, if needed.

Step 11: Setting Up Access and Security

After Step 10, the primary components of your application are in place. In this step, you define additional components that control access to the facilities and objects that your application provides. The Process Commander security model is both powerful and flexible, and has multiple dimensions for layered control. This chapter describes how to build security into your application in SmartBuild Step 11, including:

■ Understanding how security works.

■ Granting access to applications.

■ Granting and refining access to work and data object classes.

■ Granting access to specific rules.

■ Testing for and troubleshooting security.

Consult the Administration and Security book for detailed procedures that implement the security facilities described in this chapter.

Who Does This: System architects typically work with system administrators to perform these tasks.

11-2 Step 11: Setting Up Access and Security

Important Terms and Concepts The following terms and concepts are important as you design and implement security features in your application:

■ All users (both people and systems) that connect to a Process Commander server run as requestors, and each requestor has an associated type. People typically connect with a requestor type of Browser.

■ Security capabilities require both data objects and rules. Evolution of the rules that define security in your application is a development task. In contrast, maintenance of the data objects is an ongoing administrative responsibility, as they convey capabilities to individuals and external systems.

■ The fundamental premise is that access is denied by default and must be explicitly granted.

■ An access role represents a business-oriented position with a distinct level of authority in the application. You use access roles to control access to instances by class, for groups of users who have similar authority.

■ An application rule lists RuleSets and Versions that together define an application. Application rules are referenced in access groups, and may also be referenced in organization and division data instances.

■ An access group specifies a set of access roles and an application rule, as well as the portal layout to display. Administrators use access groups to grant application access to groups of users who have similar job responsibilities and functions.

■ An operator ID identifies a person, and associates that individual with the organizational hierarchy and one or more access groups.

■ A privilege rule represents the authority to execute a specific rule. Privileges convey fine-tuned capabilities, more focused than access roles.

■ Each Process Commander environment has a production level. This parameter allows your application to provide access in production systems that differs from access in test or development systems.


How Security Works The Process Commander security model combines authentication of users (who they are) with role-based authorization (what they can do):

■ Authentication requires users to enter a valid user ID and password matching an operator ID data instance. After a user is authenticated, Process Commander builds a user profile that grants access to one or more applications.

■ Authorization is based on access roles with access controls and privileges, which govern access to objects (such as work objects, classes, and rules). Your application must explicitly grant access to objects as needed. This approach is more secure, scalable, and manageable than other approaches that allow access by default.

The security model operates as layers, combining authentication and authorization:

■ For all users, whether authenticated or unauthenticated guests

− Which applications and access roles are available to this requestor type?

■ For authenticated users

− Based on your operator ID, which organizational structure and access group do you belong to?

− Based on your requestor type, organization, division, and access group, what applications can you access?

− Based on your access group, what access roles do you have?

− Based on your access roles, what classes can you access and in what manner?

− Based on your access controls, privileges, access settings, and deny access settings, what level of access do you have for each class?

− If you attempt to use a rule that requires a specific privilege, do you hold that privilege?

Note: Refer to the Administration and Security book for a detailed description of the security model and its components.


Implementing Security for Production Systems In Step 3, you worked with your system administrator to set up the RuleSets for your application, as well as the access groups and operator IDs for the project team and test users. To simplify development and testing, your system administrator probably set up the access groups with one common access role that granted broad access to every capability in the application.

While using only a single access role may be sufficient during development, a more sophisticated design is usually required for production use of the application. Work closely with a system administrator to plan, design, and implement application security. First, design the security rules for your application as described in this chapter. A system administrator then creates the rules that implement your requirements.

A system administrator can also create additional access groups and users that let you test and refine the security set up. When the application is ready to deploy, a system administrator references the access roles in the appropriate access groups on your production system.

Security Implementation Checklist 11-5

Security Implementation Checklist The following checklist provides an overview of the tasks described in this chapter for designing and implementing security for your application.

Granting Application Access 1. Define and create the organization, organization divisions, organization units,

and operator IDs for authenticated users.

2. Create one or a few application rules that list the RuleSets and Versions that define the application.

3. Define and create access groups that grant access to the application.

4. Add the RuleSet(s) for your application to the appropriate organization, organization divisions, or access groups.

Granting Access to Work Objects and Other Instances 5. Define and create access roles for granting access to work objects and instances

of data classes.

■ Rules of type Rule-Access-Role-Name define the name of an access role.

■ Rules of type Rule-Access-Role-Obj define the level of access to be granted to instances a particular object class. For each role name, create one access role object rule for every class to which users with that role need access.

■ Rules of type Rule-Access-When define Boolean tests for granting conditional access to a class.

6. Reference the new access roles in appropriate access groups (data instances of type Data-Admin-Operator-AccessGroup).

7. Optionally as needed, define and create privileges (rules of type Rule-Access-Privilege) to grant the authority to run specific restricted rules.

8. Reference the new privileges in the appropriate access roles.


Granting Access to Change Individual Rules 9. To fine-tune access, reference privileges and When condition rules (rules of type

Rule-Obj-When) in selected rules of six types (activities, correspondence, flows, flow actions, harness rules, and sections).

10. Create When condition rules and activities to check whether users have the required access roles, privileges, and access settings at the appropriate points in processing.

Example — PegaRP Security Requirements To illustrate the Step 11 tasks, this chapter uses the PegaRP sample application, which has the following access requirements:

■ Every user can create new work objects of four work types: inquiries, problem reports, enhancement requests, and support requests.

■ Every user can perform assignments appearing on their own worklists and resolve the work objects on their own worklists.

■ In addition, members of the Information Technology (IT) staff can:

− Create new work objects for five additional work types: administrative tasks, code changes, data records, documentation, rule changes, and database schema changes.

− Create and update supporting data records for products and RuleSets.

− Create, update, and delete rules on any system except a production system.

■ IT managers can do what the IT staff can do. In addition, the IT managers can:

− Create research projects (a work type).

− Reopen any resolved work object of any work type.

− Send assignments to the worklist of the chief technology officer (CTO).

To convert this statement of requirements into rules for PegaRP, developers must perform each task in the security checklist above.

Granting Application Access 11-7

Granting Application Access Users can run the rules of an application if their organization, division, or access group references an application rule that lists the RuleSet versions that make up the application. You determine where (meaning, in which of these data objects) to grant access based on how broadly you expect the application to be used within your company.

■ Referencing the application rule in an organization data instance makes the application available to all users who belong to the organization.

■ Referencing the application rule in a division data instance makes the application available to all users who belong to the division.

■ Referencing the application rule in selected access groups makes the application available only to users who are associated with one of those access groups.

■ To make an application available to unauthenticated guest users, reference it in the Data-Admin-Requestor instance for the requestor type. However, most applications require authentication before users perform meaningful work.

Reviewing Your Access Group Needs The Initial Setup wizard creates an initial set of five access groups for your organization. The wizard sets up an access group for each job function (business user, business manager, process architect, system architect, and system administrator). These access groups grant access to the basic Process Commander environment, which is needed for every application. Use these access groups as a starting point for creating your own.

At this time, review your user access requirements and determine whether you need additional access groups for your application. (Refer to Step 2, when you defined access group requirements.) After deployment, administrators associate an appropriate access group to each user, typically based on job function.


Understanding the RuleSet List When a user logs in, Process Commander assembles a unique profile that includes a list of accessible RuleSets (as shown in Figure 11-1). The user’s organization hierarchy and access group provide some of the information for compiling this list. During rule resolution, Process Commander sequentially searches this list until it finds the appropriate rule to apply to the situation. Consequently, the order of RuleSets in this list is critical to both security and rule resolution.

Figure 11-1. Full Profile

Granting Application Access 11-9

As a best practice, carefully consider the impact of the third (or patch) version level — that is, 05-09-01. For example, use only a prefix of the version number such as 05-09 to automatically grant access to all patch-level versions of the RuleSet without the need for an Administrator to update the organization hierarchy or access groups. See the Administration and Security book for more information about how the RuleSet list is assembled and searched.

What You Completed Designed and completed an application rule listing the RuleSets and

Versions that make up the application. Designed and implemented application-level security, including the

organization, divisions, units, operator IDs, and access groups. Added access groups to the appropriate instances.


Granting Access to Work Objects and Other Instances To control access to specific features of your application, first plan how to grant access to work objects and other objects by class. This dimension of security controls the ability for groups of users to access (meaning to open, update, save, delete, and so on) objects in your application. To implement access control, complete the following tasks:

■ Define access roles and reference them in access groups.

■ For each access role, identify the classes to which you want to grant access.

■ Define the level of access to grant for each class using access controls, privileges, and Access When conditions.

■ Document the needed roles in a table format for your system administrator (as in Figure 11-9).

■ Test access after your administrator has created the security rules.

To simplify the design process, start with classes that are work types — the concrete classes in your application that inherit from the Work- base class. When you are finished, repeat the process for concrete classes that inherit from the Data- base class, and for any other application-specific classes.

Defining Access Roles An access role (Rule-Access-Role-Name rule type) represents a business-oriented position (such as IT Staff or Customer Service Manager) that requires a particular level of authority in the business process. An administrator creates access roles, and assigns one or more access roles to each access group, to grant the associated authority to users associated with that access group. Users can view their list of assigned access roles in the profile (Figure 11-1) at the right of window.

Process Commander includes access roles for the five job functions (business user, business manager, process architect, system architect, and system administrator). The initial access groups (created by the Initial Setup wizard) reference these access roles, which you should not remove. However, you must define and create application-specific access roles and reference them in the appropriate access groups.

Granting Access to Work Objects and Other Instances 11-11

Review your application requirements to develop a list of access roles required to reflect each subset of individuals who will use the application. Work with a system administrator to create access roles (rules of type Rule-Access-Role-Name) for your application RuleSet(s) and then to reference the new access roles in the appropriate access groups.

Choose access role names carefully. Each must be unique within a Process Commander environment. As a best practice to achieve uniqueness, follow the syntax RuleSetName:RoleName.

The PegaRP application requires three access roles, as shown in Figure 11-2.

Access Role Name Purpose

PegaRP:Default Basic role for all PegaRP users

PegaRP:ITStaff Supplemental role for IT staff

PegaRP:ITManager Supplemental role for IT managers

Figure 11-2. PegaRP Access Roles

Structure Access Roles to Provide Layers of Access Most applications support certain job functions that build on others, just as PegaRP does. Defining supplementary access roles — that is, access roles that are additive to other access roles — is the most efficient solution. Having fewer access roles simplifies application security and the related logic for checking authority during processing.

Identify one access role that is to grant access to the basic facilities of your application that most users are authorized to perform. Then define one or more additional access roles that grant access only to operations that require more authority to perform. Plan to assign the first access role to all users and the additional access roles only to users who are to have more authority.


As an example, PegaRP includes two access roles that each supplements others:

■ Tbe PegaRP:ITStaff access role supplements PegaRP:Default.

■ The PegaRP:ITManager access role supplements both PegaRP:Default and PegaRP:ITStaff.

All PegaRP users have the access role (PegaRP:Default), which grants access to basic PegaRP facilities that everyone is authorized to perform. IT staff members have two access roles — the basic PegaRP:Default role plus an access role (PegaRP:ITManager) that grants access to additional IT-restricted operations. IT managers have these two access roles and a third that grants access to management-restricted operations.

You can structure supplemental roles in two ways:

■ Each access role includes the access conveyed by all lower layers.

■ Each access role includes only the unique access not conveyed by lower layers. Through multiple access roles, users acquire all layers appropriate to their position.

The second approach typically is simpler to design and easier to maintain.

Helpful Hints

■ Access is additive for multiple access roles.

■ As you build additional applications for the same organization, consider simplifying class access across all applications by assigning basic class access to a baseline role that is included in the access group for every user.


Defining Instance Access by Access Role Once you have identified and named access roles, the next task is to determine which objects users with that access role need to access. The following process is useful for this analysis:

1. Create a table that contains application classes as rows and access roles as columns.

2. List the access roles from the least access on the left (all users, in the PegaRP example) to the most access on the right.

3. Work down the column for the access role with the least access. In each cell, enter a short comment about the type of access to be permitted. Leave blank if this access role needs no access to objects of the class.

4. Repeat Step 3 for each access role, working your way through access roles that grant increasingly more access to users.

Figure 11-3 shows the access roles and type of access to be permitted for a subset of work-related classes in the PegaRP example.

Class Access Role

Least Access Most Access PegaRP:Default PegaRP:ITStaff PegaRP:ITManager PegaRP- Perform any assignments

Update work objects Run activities

Manage rules Bulk-transfer assignments Reopen work objects Assign work to the CTO

PegaRP-Work-Object- Create and modify work objects

PegaRP-Work-Project- Create and modify work objects

PegaRP-Work-Project-Research-

Create and modify work objects

Figure 11-3. PegaRP Work Classes and Access Roles


Helpful Hints

■ By default, users have no access to objects of any class. You must explicitly grant access to each class through an access role as needed.

■ Carefully consider each business use. Errors or omissions in this aspect of application security design are a common source of inaccessible work or data and security errors during processing.

■ If you associate an access role with a parent class, the access role applies to all its child classes, unless explicitly overridden by another access role.

For example, the PegaRP:Default access role applies to the PegaRP-Work-Project- class and to the following child classes:

− PegaRP-Work-Project-Enhancement-

− PegaRP-Work-Project-Inquiry-

− PegaRP-Work-Project-Problem-

However, the PegaRP:Default access role does not apply to the PegaRP-Work-Project-Research- child class. Instead, an access role that grants more access (PegaRP:ITManager) applies to this class.

■ Access is additive if you design your roles to supplement each other. When an access role builds on another access role, you only need to grant access to a class or operation for the access role that grants the least amount of access.

■ For simple applications, each work type may have a single access role that grants access to work objects of that type. However, more complex applications may need to grant several levels of access to each work type.


Understanding Access Controls and Access Role Object Rules An access role rule (Rule-Access-Role-Name) only determines the name of an access role. A related rule type, Rule-Access-Role-Obj, relates this name to eight access controls and a class.

Access controls represent the right to access an instance of a class or a rule that applies to the class. On the Access Role Obj form, eight access controls grant the ability to perform common operations (Figure 11-4).

Access Control Access Allowed

For instances of the class

Open Instances Open an instance of the class.

Modify Instances Modify (or save) an instance of the class.

Delete Instances Delete an instance of the class.

Search Instances Read and search through instances of the class.

Execute Activities Execute activities that apply to the class.

For Rules that apply to the class

Open Rules Open a rule that applies to the class.

Modify Rules Modify (or save) a rule that applies to the class.

Delete Rules Delete a rule that applies to the class.

Figure 11-4. Access Controls

The first three access controls grant the ability to open, modify, or delete instances of a class. If you define any of these access controls for a class/role combination and associate the access role with an access group, users with that access group can perform open, modify, or delete operations for instances of that class (or its child classes). Additional access controls govern processing (searching and executing activities) and rule development. The last three access controls typically are meaningful only for application developers and business analysts or managers who create or update rules.


Understanding Privileges You can also use privilege rules to grant the authority to perform specific processing in your application. A privilege rule (Rule-Access-Privilege rule type) defines only the name of a privilege and the class that the privilege applies to. Privilege rules are referenced in access role object rules (Rule-Access-Role-Obj rule type). Users who have an access role acquire the privileges from all the access role objects for that access role.

Process Commander includes dozens of standard privileges, such as those defined for Work- to control flow processing (Figure 11-5). You can define your own privileges to protect access to application-specific capabilities.

Privilege Action Allowed

Work-.AddFlow Start a new flow.

Work-.AllFlowActions Select any standard flow action.

Work-.AllFlows Start all standard flows.

Work-.Perform Perform assignments on worklists other than your own.

Work-.PerformBulk Apply a flow action repeatedly to each assignment on a list.

Work-.Reopen Reopen a previously resolved work object.

Work-.Update Update a work object.

Figure 11-5. Standard Privileges That Control Flow Processing

In addition to defining the privilege, the application must also explicitly check whether users have that privilege at the appropriate points, as described later in this chapter.


Defining Access Controls and Privileges for Classes You grant access controls and privileges to a subtree of the class hierarchy. An access control or privilege for a parent class percolates down to all lower levels, unless you specify a different setting in another access role object rule at a lower level. For example, if you grant the Modify Instances access control at PegaRP-, users can modify objects of any concrete class that inherits from PegaRP-. However, if you override access control at PegaRP-Work-Object-, users can’t modify those objects.

Next, define the access controls and privileges for each class. Compare your table (like Figure 11-3) with the access controls conveyed by standard Rule-Access-Role-Obj rules and privileges. Replace each entry with an access control name or a privilege (Figure 11-6). Use a code to differentiate privileges from access controls, such as (P) for standard privileges and (AP) plus bold italic text for application-specific privileges.

Class Access Role

Least Access Most Access

PegaRP:Default PegaRP:ITStaff PegaRP:ITManager PegaRP- Perform (P)

Update (P) Execute Activities

Open Rules Modify Rules Delete Rules

PerformBulk (P) Reopen (P) ActionAssignToCTO (AP)

PegaRP-Work-Object- Open Instances Modify Instances Search Instances

PegaRP-Work-Project- Open Instances Modify Instances Search Instances


Open Instances Modify Instances Search Instances

Figure 11-6. Defining Access Controls and Privileges for Work Classes


Note: Each standard privilege name begins with a verb that indicates a basic purpose, such as Action for privileges that provide access to flow actions. For clarity and ease of maintenance, adopt similar naming conventions for your application-specific privileges.

Conditioning Access with Production Level and Access When Rules When installing Process Commander, your system administrator sets a production level value based on how the system will be used (Figure 11-7). These values range from 1 (for least secure) to 5 (for most secure).

Production Level System Purpose

5 Production

4 Pre-production

3 Test

2 Development

1 Experimental

Figure 11-7. Production Levels

You use these values when defining access controls. The number you specify works with the production level of your system. It represents the most secure system on which the user can perform the operation. For example:

■ If you specify 5 for a particular class, access role, and operation, users with the access role can perform the operation on instances of the class on any Process Commander system with a production level of 5 (production system) or lower.

■ If you specify 2 for a particular class, access role, and operation, users with the access role can only perform the operation on instances of the class on a system with a production level of 2 (development system) or lower.

■ If you specify either 0 or no value, access is prevented on all systems.


This feature is useful for implementing a single security model that is more restrictive on a production system than in a development environment.

Note: If you have only one system or don’t want to use this feature, set each access control to 5 or 0. This grants or denies access at all production levels.

You can also grant access conditionally to an access control or privilege. Create an Access When condition rule (a rule of type Rule-Access-When) to define a Boolean test. On a cell in the Access Role Obj form, reference the Access When condition rule (rather than a number between 0 and 5) to grant access based on the result (true or false) of evaluating that expression. Because Process Commander evaluates the Access When condition in terms of the specific instance being accessed, this approach takes into consideration the property values in the work object, characteristics of the user, the time of day, or other factors.


Defining Values for Access Controls For each cell in the table, you can define valid values between 0 and 5. The table now contains access controls and privileges for each class/role combination. Next to each entry, add either a numeric value or the name of an Access When condition to evaluate (as shown in Figure 11-8). Enter 0 to indicate no access.

Class Access Role Least Access Most Access

PegaRP:Default PegaRP:ITStaff PegaRP:ITManager

PegaRP- Perform (P) 5 Update (P) 5 Execute Activities 5

Open Rules 4 Modify Rules 4 Delete Rules 4

PerformBulk (P) 5 Reopen (P) 5 ActionAssignToCTO (P) 5

PegaRP-Work-Object- 0 Open Instances 5 Modify Instances 5 Search Instances 5

0

PegaRP-Work-Project- Open Instances 5 Modify Instances 5 Search Instances 5

0 0


Open Instances 5 Modify Instances 5 Search Instances 5

Figure 11-8. Defining Values for Access Controls and Privileges

What You Completed Designed class-level security, including access roles, access controls,

privileges, and Access When conditions for granting access to classes.


Documenting Access Requirements Process Commander includes a wizard (the Access Role Editor) that streamlines the creation of the individual rules that implement security. To ensure accurate implementation, provide your system administrator with a table similar to Figure 11-9, which documents the PegaRP security requirements presented on page 11-6.

Activities

Class O M D S OR MR DR EPrivileges Access Settings

Perform 5 Update 5

PegaRP-Work-Object-PegaRP-Work-Project- 5 5 5PegaRP-Work-Project-Research-PegaRP-Data-PegaRP-Data-Product-PegaRP-Data-ProductArea-PegaRP-Data-RuleSet

PegaRP- 4 4 4PegaRP-Work-Object- 5 5 5PegaRP-Work-Project-PegaRP-Work-Project-Research-PegaRP-Data- 5 5 5PegaRP-Data-Product-PegaRP-Data-ProductArea-PegaRP-Data-RuleSet

PerformBulk 5Reopen 5ActionAssignToCTO 5

PegaRP-Work-Object-PegaRP-Work-Project-PegaRP-Work-Project-Research- 5 5 5PegaRP-Data-PegaRP-Data-Product-PegaRP-Data-ProductArea-PegaRP-Data-RuleSet

PegaRP-

Instances Rules

PegaRP-Access Role – PegaRP:Default

Access Role – PegaRP:ITStaff

Access Role – PegaRP:ITManager

5

n
Figure 11-9. PegaRP Security Specificatio


The column headings represent the eight access controls (Figure 11-10).

Abbreviation Description

O Open instances of this class.

M Modify (or save) instances of this class.

D Delete instances of this class.

S Search through instances of this class.

OR Open rules that apply to this class.

MR Modify (or save) rules that apply to this class.

DR Delete rules that apply to this class.

E Execute activities that apply to this class.

Figure 11-10. Access Control Abbreviations

Helpful Hints

■ You may find a spreadsheet helpful for specifying security requirements for a system administrator.

■ For ease of review and maintenance, use one table for all classes in your application

■ Clearly indicate application-specific privilege rules from standard privilege rules. The table in Figure 11-9 uses bold, italic text for the former rules.

.What You Completed Documented the security requirements for Work- and Data- classes.


Testing Access After the administrator completes the security rules that you designed, use each role to log in and verify access.

In keeping with good development practices, always build the appropriate security checks into your application so users can never attempt an action that they are not authorized to perform. Otherwise, users are presented with a security alert when they attempt to perform an operation. The security alert appears on the workstation and is also recorded in the system log.

For example, your application should route assignments to worklists of only those users who have the authority to perform these assignments. Similarly, if a user who does not hold the ability to update mortgage loan work objects attempts to update one, your application can detect this situation and present the work object in display-only mode rather than update mode.

The standard functions HaveRole( ) and HavePrivilege( ), described later in this chapter, are useful for such checking.


Granting Access to Change Application Rules The next task is to define security requirements for the rules in your application. Work with your system administrator to implement this access. Some tasks involve modifying the rules or logic in your application (your responsibility), while others involve creating privilege rules (a system administrator’s responsibility).

Understanding Access to Rule-Based Classes Some rule types (for example, Rule-HTML-Fragment and Rule-CorrType) are classless, meaning that the rule applies to objects of every class. The access controls that govern opening, modifying, and deleting these rules are the same as those that govern work object classes, described above.

However, for many rule types, a class name appears as the Applies To key part in a rule. In such cases, Process Commander evaluates security based on both the class of the rule (such as Rule-Obj-Property) and the value of the Applies To key part. The ability to perform operations on such rules requires access to both classes.

For example, the PegaRP example contains a section rule named PegaRP-Work-Project-Problem.NewHeader. A section rule is formally an instance of the Rule-HTML-Section rule type. PegaRP users can update this section rule only if they have both of the following access controls:

■ Modify Rules for the PegaRP-Work-Project-Problem- class.

■ Modify Instances for the Rule-HTML-Section class.

Granting Access to Change Application Rules 11-25

An important aspect of the SmartBuild approach is to identify application rules that managers or business analysts — not only developers — can maintain. (See Appendix A for more information about this guideline.)

The standard access role for managers (PegaRULES:WorkMgr4) grants appropriate access to the standard rule-based classes. Your access roles must grant appropriate access to the rules defined for your application.

Note: Marking a rule as Final prevents its modification by others, regardless of application security settings. See Step 13: “Deploying and Evolving Your Application” for more information about final rules.


Capabilities to Consider in This Step Step 11 provides an appropriate point to assess whether and how the four optional capabilities summarized in this section can contribute to the security model for your application:

■ Denying access rather than granting access to objects of a class, with Access Deny rules.

■ Associating a numeric, text, or date limit with an access role to create an Access Setting rule.

■ Restricting access to individual rules based on a privilege.

■ Checking for access roles or privileges in various activities within your application.

Denying Access to Objects of a Class As noted above, Process Commander denies all access to a class unless explicitly granted by an access role. Being secure and easy to maintain, the mechanism is the recommended approach for most application security. However, government regulations and industry policies — especially in healthcare — are sometimes written as a combination of “You May” and “You Must Not” mandates that could require an explicit denial of access to restrict certain capabilities. This type of security is often referred to as nondiscretionary.

To address these types of specialized situations, Process Commander also provides a mechanism for access denials. Access deny rules (of type Rule-Access-Deny-Obj) allow you to explicitly deny access to some aspect of operation on a class for users with a particular access role. You typically grant full access to all users with an access role. Then you deny access to one or more aspects to some subset of users via another access role, without affecting the entire group.


You define an access deny rule for the class and access role to which it applies. The same access controls (open, modify, etc.) apply to access deny rules. Specify a production level to deny access explicitly or an Access When condition to deny access conditionally. If a user’s profile grants access to mirrored access object and access deny rules, the access deny rule takes precedence.

Using Access Setting Rules for Value-Based Access In addition to simply granting class access, you can define different levels of access based on the context of the work or data object. This option allows you to specify different capabilities for different access roles by comparing the characteristics of a particular object against a predefined setting. In other words, you can grant access only when a particular object meets certain criteria.

You use access settings (rules of type Rule-Access-Setting) for this purpose. In the access setting rule, you define the setting name and type. Access settings can be text, numeric, or date/time values. Then you assign the access setting to an access role, along with the appropriate value for users with that access role. As with access controls and privileges, you specify access settings in the access object rule (of type Rule-Access-Role-Obj) for each applicable class/role combination. During processing, you use the access setting to evaluate (typically in activities) which capabilities to allow on a particular object for users with the access role.

For example, suppose you want bank managers to approve loans for up to $30,000, loan officers to approve loans for up to $100,000, and bank officers to approve loans for more than $100,000. Follow this process to implement this requirement:

■ Create access roles for each of the process functions (for example, YourCoLoan:BankManager, YourCoLoan:LoanOfficer, and YourCoLoan:BankOfficer).

■ Create a numeric access setting (such as LoanLimit) to represent the maximum loan amount.

■ Assign the access setting with the appropriate loan amount to each relevant class/access role combination.


■ Revise your application logic to evaluate this access setting to ensure that users only approve loans up to the amount specified in the access role.

Review your access role table again and add any required access settings.

Restricting Rule Execution by Privilege For six rule types, your application can restrict who ability to execute individual rules. You can reference privilege rules in individual instances of these rules:

■ Activity (Rule-Obj-Activity)

■ Correspondence (Rule-Obj-Corr)

■ Flow (Rule-Obj-Flow)

■ Flow action (Rule-Obj-FlowAction)

■ Harness (Rule-HTML-Harness)

■ Section (Rule-HTML-Section)

Referencing a privilege in a rule of any of these types restricts the ability to execute the rule to those users who have the privilege.

For example, your application may allow all users to select a flow action that sends out correspondence as first class mail. Another flow action, restricted by an application specific privilege, may allow selected users to send out correspondence using expensive overnight delivery services.

Testing for Access Roles, Privileges, and Access Settings When you use access roles, privileges, and access settings, you must also include checks in your application to evaluate whether a user has the required authority. Process Commander includes standard functions (rules of type Rule-Utility-Function) for this purpose. Refer to the online help for more information.

To test whether a user has an access role, call the HaveRole() function rule. Create a When condition rule with the values shown in Figure 11-11. Then reference the When rule in another rule (such as an activity) to perform the test.


Field Value

Field Name Lib(Pega-RULES:Default).HaveRole(this,“rolename”)

Operation Equal

Value True

Figure 11-11. When Condition Rule to Test an Access Role

To test whether a user has a privilege, use the HavePrivilege function. Create a When condition rule with the values shown in Figure 11-12. Then reference the When rule in another rule to perform the test.

Field Value

Field Name Lib(Pega-RULES:Default).HavePrivilege (this,“privilegename”,“privilegeclass”,null)

Operation Equal

Value True

Figure 11-12. When Condition Rule to Check for a Privilege

Similarly, to test whether a user has a setting value, use the getSetting() and getSettingType() functions in the Pega-RULES:Settings library.

While these functions are provided for use in activities and other rule types, expect to use them sparingly. Most access control in your application should be derived from the automatic, always-in-force capabilities defined by access roles, access role objects, privileges, and access groups. Enforcing access through widespread and possibly frequent checking is inefficient and likely to be incomplete, offering security holes to users.




Rules

Create application rules that list the RuleSet Versions that make up the application

Rule-Application Security

Create access roles to grant access to classes and rules

Rule-Access-Role-Name Rule-Access-Role-Obj

Security

Create privileges to grant the ability to perform specialized processing

Rule-Access-Privilege Security

Create Access When conditions to conditionally specify access controls and privileges for an access role

Rule-Access-When Security

Create value-based access settings to refine class access

Rule-Access-Setting Security

Selectively deny access to classes in specialized situations

Rule-Access-Deny-Obj Security

Refine access to rules Rule-HTML-Harness Rule-HTML-Section Rule-Obj-Corr Rule-Obj-Flow Rule-Obj-FlowAction Rule-Obj-Activity

Process

Technical

Check for access roles or privileges, or grant conditional access to a rule

Rule-Obj-When Decision



Data

Enable authentication Data-Admin-Requestor Data-Admin-Operator-ID

SysAdmin Organization

Grant access to the application Data-Admin-Operator-AccessGroup Data-Admin-Organization Data-Admin-OrgDivision Data-Admin-OrgUnit

Security Organization



Designed and implemented application-level security:

- Organizational hierarchy created.

- Operator IDs created for all authorized users.

- Access groups defined for each set of users who perform similar work in the application.

- One or a few application rules define the application as a list of RuleSet Versions

- Application rule referenced in the appropriate organizations, organization divisions, or access groups.

- Access groups assigned to operator IDs.

Designed and implemented class-level security:

- Access roles, privileges, and Access When conditions created to control object class access.

- Access settings and access denials created to refine class access.

- Access roles and privileges added to the appropriate access groups.

Designed and implemented rule-level security:

- Privileges and when condition rules created to protect individual rules, as needed.

Designed and implemented application tests for user security levels, as needed:

- When condition rules created to test whether users have required access roles or privileges.

- Activities created to test whether users have required access settings.

Step 12: Configuring System Interfaces and the PegaRULES Database

Process Commander supports a wide variety of integration services for building and operating interfaces between applications and external systems. This chapter introduces SmartBuild Step 12, including tools and techniques for these facilities:

Services, which enable other systems to access your application.

Connectors, which allow your application to access other systems or databases.

Configuring inbound e-mail and external authentication mechanisms.

Optional background printing, scanning, and portal interfaces.

Working with the PegaRULES database.

Who Does This: System architects typically perform these tasks, with assistance from system administrators for database-related tasks.

12-2 Step 12: Configuring System Interfaces and the PegaRULES Database

Important Terms and Concepts The following terms and concepts are important as you begin working with external interfaces and the underlying database:

Using a set of integration services based on industry-standard technologies, you can extend your application to work with external systems:

– External systems access application data and processes using services.

– Your application accesses data and processes in relational databases or other external systems using connectors.

– Sample services and connectors with documentation are available for download from the Pegasystems Support Network

(www.pega.com/support).

Servers identify specific external systems or file services that Process Commander accesses, based on the server name and integration service used.

Listeners identify specific external systems or file services that access Process Commander, based on the server name and integration service used.

Your application can accept inbound e-mail to initiate work.

SnapStart provides the ability to interactively create a work object from an external system accessed through a Windows workstation.

Note: Use this chapter as an orientation to integration services and working with the PegaRULES database. Refer to the Integrating with External Systems and Administration and Security books for detailed implementation instructions.


What Are Integration Services? Process Commander applications often complement, rather than replace, other systems and technologies that you may have in place for doing work. You can use applications as standalone solutions, or as components of legacy systems.

Integration services provide the means for application-to-application connectivity, as opposed to user-to-application or application-to-database connectivity. Most often, integration services link applications hosted by servers that are typically physically separated, connected by a LAN, and behind the Internet firewall. Integration services provide a set of rules and techniques that are intended for use by system architects with Java experience.

Configuring Integration Services Process Commander includes rule types that define individual integration services:

■ Service rule types define how your application receives input from and responds to requests from external systems.

■ Connector rule types define how your application requests services from or sends provide output to external systems.

While each type of integration service has technology-specific requirements, you need to create the following components:

■ For all integration services – the appropriate service or connector rule that defines the parameters for the interface.

■ For some integration services – one or more data instances that identify the source or destination system and request queue.

■ For most integration services – an activity that performs the necessary processing, possibly requiring custom Java.


As part of configuring any integration service, you also map properties in your application to the corresponding data fields or properties in the external system. You need to map only the data elements that are used to perform the associated processing, not all data elements in the external system.

Rules for Mapping Data To simplify interface configuration, five rule types define how to convert and map incoming and outgoing data to property values on the clipboard. You can create rules that:

■ Generate and format text data as HTML (Rule-Obj-HTML) or XML (Rule-Obj-XML).

■ Read and process text data formatted as XML (Rule-Parse-XML).

■ Read and process structured data (Rule-Parse-Delimited, Rule-Parse-Structured).

The Import Rules and Export Rules accelerators help you create many of these rules.

Delivering Services to External Systems 12-5

Delivering Services to External Systems Services allow an external system to access data and processing in your application. These services are based on industry-standard technologies; they typically can be used directly with an external application that supports one of the available protocols (for example, SOAP, EJB, and CORBA®).

What Services Are Available? Service rules define how your application interoperates with an external system when that system initiates an inbound request. Process Commander includes rule types that support the services shown in Figure 12-1., allowing your application to have a service-oriented architecture.

To Access Process Commander Using Use This Rule Type Business Process Execution Language (BPEL) Rule-Service-BPEL Microsoft® COM Rule-Service-COM Object Management Group CORBA® Rule-Service-CORBA Microsoft® .NET Framework Rule-Service-dotNet J2EE Enterprise JavaBeans™ (EJB) Rule-Service-EJB Inbound e-mail Rule-Service-Email File services Rule-Service-File External Java application Rule-Service-Java Java Message Service (JMS) Rule-Service-JMS JSR-94 rule engine API services Rule-Service-JSR94 WebSphere® MQ messaging Rule-Service-MQ Portlet services (JSR-168) Rule-Service-Portlet Simple Object Access Protocol (SOAP) Rule-Service-SOAP

Figure 12-1. Service Rule Types

Identifying Services Review the external systems that may benefit from services provided by your application. For example, a Web site may include a query facility to report on work objects for one customer. The Web server can access your application using SOAP.


List each external system that may require such access, the purpose of the access, and, if possible, the protocol or technology likely to be used.

Working with appropriate Information Technology staff, design, develop and deploy each service interface in a test environment. For many service types, the Pegasystems Support Network offers working examples and step-by-step instructions.

What You Completed Identified the number and types of services required.

Creating and Testing a Service In many cases, a system administrator can use an accelerator tool to create an initial version of the rules and data instances for a service. For example, the Service Accelerator tool supports development of these types of services:

■ Enterprise JavaBeans

■ Text file import

■ Java Message Service

■ JSR 94 Rules Engine API

■ WebSphere MQ messaging

See Integrating with External Systems for information on the Service Accelerator tool. For information on service rule forms, consult Application Developer Help. For documented, working examples of various services, consult the Pegasystems Support Network at www.pega.com/support.

If you are implementing a new interface from an external system, first configure the Process Commander end of the service. Then configure the external system application to call the service. However, if you are replacing an existing interface, you either need to modify the application or configure the service to match the existing application program interface (API). Matching an existing API is a more complex task.

What You Completed Services created and tested, including appropriate error handling.


Connecting to External Databases and Systems 12-7

Connecting to External Databases and Systems Connectors let your application request access to data or processing from an external system. Each connector interacts with the external database, system, or service. After processing or data retrieval is complete, the external system returns the results to your application.

When you implement a connector, Process Commander becomes a client application to another system’s service.

What Connectors Are Available? Connector rules define the interface and the parameters that your application exchanges with the external service, system, or database. Process Commander supports the connectors shown in Figure 12-2.

To Connect to an External System Using Use This Rule Type

Business Process Execution Language (BPEL) Rule-Connect-BPEL

Microsoft .NET Framework Rule-Connect-dotNet

Enterprise JavaBeans™ (EJB) Rule-Connect-EJB

External Java classes Rule-Connect-Java

Java Connector Architecture (JCA) Rule-Connect-JCA

Java Message Service (JMS) Rule-Connect-JMS

WebSphere MQ messaging Rule-Connect-MQ

Simple Object Access Protocol (SOAP) Rule-Connect-SOAP

SQL (relational database) Rule-Connect-SQL Figure 12-2. Connector Rule Types


Identifying Connectors Review the external databases and systems to which your application may connect. Identify the purpose of each connector and, if possible, the protocol or technology likely to be used. For example, your application may access a customer database using SQL to obtain account numbers and addresses. Your application may send fees and changes to a central billing application using SOAP.

What You Completed Identified the number and type(s) of connectors required.

Configuring a Connector The Connector Accelerator assists a system administrator in implementing connectors. For example, every SOAP service has a Web Services Description Language (WSDL) file that defines its interface. The Connector Rules accelerator uses the WSDL file to create SOAP connectors.

However, the wizard cannot create connectors based on JMS or WebSphere MQ messaging technology because these technologies lack the equivalent of a WSDL file (exposed metadata). Developers create these connectors by completing rule forms and related data forms.

See Integrating with External Systems for information on the Connector Accelerator tool. For information on connector rule forms, consult Application Developer Help. For documented, working examples of various connectors, consult the Pegasystems Support Network at www.pega.com/support.


Connecting to External Databases and Systems 12-9

Incorporating Connectors into Flow Rules Many connectors are called synchronously, as part of a business process. Use the Integrator shape to call a connector from within a flow Figure 12-3.

Figure 12-3. Integrator Shape in Flow Stencil

Alternatively, an agent rule (Rule-Agent-Queue rule type) can call a connector in the background according to a schedule. For example, an agent can retrieve currency exchange rates every hour rather than on a per-transaction basis.

What You Completed With IT staff, designed and tested needed connectors and incorporated them

into the flows as appropriate


Capabilities to Consider in This Step Your application can take advantage of several optional features that provide additional interfaces.

■ Delivering services with e-mail

■ Leveraging an LDAP-compliant directory

■ Implementing single sign-on

■ Desktop integration, known as SnapStart

■ Background printing of correspondence

■ Using scanned document images to create work objects and attachments

■ JSR 168 access from a portal

Delivering Services with E-mail Your application can accept and respond to inbound e-mail as a service. These messages can initiate processing in your application. Use the rule types and data instances shown in Figure 12-4 to configure inbound e-mail services.

Rule Type or Data Instance Purpose

Data-Admin-Connect-EmailServer

Identify an e-mail server from which to gather inbound e-mail for processing via a service.

Data-Admin-Connect-EmailListener

Define a background agent to retrieve inbound e-mail from the server for processing via integration services.

Rule-Service-Email Rule-Service-SOAP

Configure a service to process inbound text, XML, or SOAP client e-mails. Also requires: ♦ A service activity that initiates processing on the inbound request. ♦ Parse rules for incoming XML or SOAP e-mails.

Rule-Obj-Activity Service activity that initiates processing on the inbound request.

Figure 12-4. Configuring an Inbound E-mail Service


As an alternative to e-mail service rules, the Pega-ProCom agent can process unstructured e-mail. To implement this approach, create a Data-EmailAccount instance that defines the address, ID, password, host, and protocol for both incoming and outgoing e-mail. Creating multiple accounts allows the agent to route e-mail by type (complaint or request), division (business loans or home loans), and so on.

Inbound messages that are handled using this mechanism can create new work objects and start a flow. However, these messages can’t take advantage of the powerful message parsing, processing, and responses provided for structured e-mail messages by the Rule-Service-Email and Rule-Service-SOAP interfaces.

Leveraging an LDAP Directory Your organization may already be using an LDAP (Lightweight Directory Access Protocol) directory for authentication, for example, the Microsoft Active Directory or the Lotus Domino Directory. Using minimal configuration, an administrator can leverage an existing LDAP directory into Process Commander.

Consult the Pegasystems Support Network article Authentication and Integration for instructions and examples, at www.pega.com/support

Implementing Single Sign-On Process Commander supports single sign-on, which permits users to log in to the network once and be authenticated for multiple systems. Several configuration options are available, ranging from more to less secure, depending on your application needs.

For design alternatives and step-by-step instructions, review the article titled “Single Sign-On” available from the Pegasystems Support Network at www.pega.com/support.



Setting Up SnapStart to Enter Work Objects SnapStart is a lightweight data import facility that conveys data from a desktop application into Process Commander. Users start the SnapStart feature to automatically create work objects from data in another system, accessed at the desktop.

SnapStart uses the popular Common Gateway Interface (CGI) format for the link from the other desktop application. Follow this process to set up SnapStart:

1. Create an HTML form that passes the necessary details as a URL. Include a button to create a work object of the appropriate type in your Process Commander application. Figure 12-5 shows part of the required HTML.

<input type="hidden" name="PartyRole" value="Customer"> <input type="hidden" name="PartyClass" value="Data-Party-Cus"> <input type="hidden" name="PartyModel" value="newCustomer"> <input type="hidden" name="PrimaryPageName" value="pyWorkPage"> <input name=WorkClass type="hidden" value="YourCo-SwMgmt-Project-Problem-"> <input type="hidden" name="FirstName" value="John"> <input type="hidden" name="LastName" value="Smith">

Figure 12-5. Sample HTML for SnapStart

Note: The PegaSample-IntSvcs RuleSet includes a sample form, IwesSnapStartDemoForm.html (available at www.pega.com/support).

2. In a form in your existing system, add a Process Commander button that pops up this HTML form.

3. Save a copy of the standard SnapStart activity (Work-.SnapStart) in your RuleSet and map the incoming fields to the work object on the Parameters tab.


Background Printing of Correspondence As described in Step 10, your application can support correspondence (e-mail and letters). Users who have Microsoft Word installed on their workstations can preview and/or edit the correspondence before sending it, and may print it on a LAN-attached printer. However, for system-managed background printing, you also need to install PegaDISTRIBUTION Manager. This option may be especially helpful when your Process Commander server is hosted by a UNIX- or Linux-based operating system.

PegaDISTRIBUTION Manager requires installation of Windows 2000/2003 server and Microsoft Word. For more information, see the Administration and Security book.

Creating and Working with Scanned Images Process Commander includes a Scan Station tool that converts paper documents into electronic form. For example, your application can use Scan Station to scan postal mail and then attach the image file to appropriate work objects. Users access Scan Station from the Scan Station link on the Process Work workspace.

Scan Station requires Windows 2000. It can be used with any scanner that is equipped with Automatic Document Feeder (ADF) hardware.

Using JSR 168 for Access from a Portal Your application can provide services to an external portal with interfaces that comply with Java Specification Request 168 (JSR 168) for portlets. In Step 4, you may have decided to provide user access through a portal other than the Process Commander portal. The portlet services, defined through the Rule-Service-Portlet rule type, support this industry standard.

Note: See the document “Building Portlet Services” on the Pegasystems Support Network at www.pega.com/support.


Working with the PegaRULES Database At installation, Process Commander automatically sets up a PegaRULES database that is ready for use. However, this database may require minor adjustments for your application. These tasks, described below, typically require assistance from a database administrator and/or a system administrator. Application developers need to understand how these features impact your application in order to work effectively with your systems staff.

Refer to the Administration and Security book for more information on working with the PegaRULES database.

Preloading Data Tables Many tables in the PegaRULES database, such as the one that stores information about specific work parties, are automatically populated as users enter work objects in the application. Other tables, such as ones that store instances of application-specific Data- classes, may need to be populated before you deploy the application. For example, a purchase request application might require a table preloaded with items that users can order.

Work with your database administrator to preload any such tables before deploying your application. If this information is stored in an existing system, a database administrator can export the information from the existing database and load the information into the PegaRULES database.

Note: Whenever possible, your application should avoid duplication of data and the risk of stale information by accessing external data directly from its system of record, using a connector. However, for some information, storage in the PegaRULES database may be more effective for performance, security, or design reasons.

Working with the PegaRULES Database 12-15

Reporting on Application-Specific Properties If your application requires reports that select instances (rows of a table) based on an application-specific property, work with your database administrator to expose the property as a column. The Administrator workspace includes a tool for this purpose. You can then use third-party tools or the Report wizard to generate reports with the information you need.

Implementing Declare Index Rules In a relational database, internal database indexes make it possible to efficiently search and report on stored data. A database administrator typically defines both the criteria for creating these indexes and a periodic update interval. However, some properties are not indexed, which prevents searching or reporting on them.

To support reporting and searching, some applications require the ability to index an embedded or unexposed property. Declare Index rules (Rule-Declare-Index rule type) provide this capability. Each Declare Index rule creates and deletes instances of a concrete class derived from the Index- base class.

For example, the standard declarative index rule named Work-.PartyURI maintains and synchronizes the work party indexes. In part, the rule supports reporting on work objects based on work party.

Declarative indexes are most beneficial if you want to search or select objects based on a property that is inside a repeating group structure. For more information, see the Administration and Security book.


Creating Additional Tables for Work Objects and History By default, Process Commander uses the following tables in the PegaRULES database:

■ Work objects are stored in a database table named pc_work, accessed by an instance of Data-Admin-DB-Table defined for the Work- class.

■ Work object history details are stored in a database table named pc_history_work, accessed by an instance of Data-Admin-DB-Table defined for the History-Work- class.

In a production environment, these two tables can grow to contain thousands or millions of rows, and become a valuable and sensitive corporate resource. For performance and data management reasons, a database administrator may want to create two new database tables (and their corresponding Data-Admin-DB-Table instances) to store the work objects and history for a single application. To ensure that standard reports operate correctly and that work object searching is fast, the new tables must follow the schemas for pc_work and pc_history_work, providing at least the same exposed columns.

What You Completed Preloaded tables in the PegaRULES database as needed. Created Declare Index rules to index for selected classes and properties if

needed.

Exposed properties needed for reporting.




Rules

Configure services to define how external systems access Process Commander

Rule-Service-* Integration Services

Configure connectors to define how Process Commander accesses external systems

Rule-Connect-* Integration Services

Process text data formatted as HTML Rule-Obj-HTML Portal-and-HTML

Rule-Obj-XML Technical Process text data formatted as XML

Rule-Parse-XML Integration Services

Process structured text files Rule-Parse-Delimited Rule-Parse-Structured

Integration Services

Create custom Java functions for use in activities, often needed for interface-related data manipulation

Rule-Message Rule-Utility-Function Rule-Utility-Library

Technical

Create declarative indexes for automatic table reindexing

Rule-Declare-Index SysAdmin

Data

Configure a service package to bundle the components for a service

Data-Admin-ServicePackage Integration Services

Identify source systems, queues, and files for services, where needed

Data-Admin-Connect-* Integration Services

Identify destination systems for connectors, where needed

Data-Admin-Connect-* Data-Admin-DB-Name

Integration Services SysAdmin



For external systems that will access your application:

– A list of systems, including a brief description and the required types of services.

– Services created and tested, including appropriate error handling.

For external systems that your application will access:

– A list of systems, including a brief description and the required types of connectors.

– Connectors created and tested, including appropriate error handling.

Other optional interfaces implemented, including SnapStart, printing or scanning facilities, and portal integration.

Application-specific database tables preloaded with supporting data, if needed.

Columns for application-specific properties exposed in the PegaRULES database for reporting, if needed.

Declarative indexes created and configured, if needed.

Dedicated work and history tables created for your application, if needed.

Note: Refer to the Integrating with External Systems and Administration and Security books for instructions on completing these tasks.

Step 13: Deploying and Evolving Your Application

When you complete Step 12, your application is functional. This next-to-last SmartBuild step involves deploying and evolving the application to meet your changing business needs. This chapter describes important aspects of managing an application:

■ Deploying and making the application available to users

■ Managing rule and design changes after deployment

■ Additional preparation tasks needed for distributing products

■ Guidelines for evolving your application

Who Does This: Process architects, system architects, and system administrators each perform different parts of these tasks.

13-2 Step 13: Deploying and Evolving Your Application

Important Terms and Concepts The following terms and concepts are important as you begin deploying your application:

■ The first two digits in the version number indicate a major version. For example, if the first major release is 01-01-01, the second major release becomes 02-01-01.

■ To isolate ongoing development and customization from the lower versions, create minor versions of a RuleSet for interim releases. The second two digits in the version number identify the minor version. For example, if the first release is 01-01-01, the first interim release becomes 01-02-01.

■ Create patch-level versions of a RuleSet for ongoing bug fixes and minor rule changes. The last two digits in the version number identify the patch level. For example, if the first release is 01-01-01, the first patch level becomes 01-01-02.

■ Skimming a RuleSet collects the highest-numbered revision of each rule from all existing versions and creates a new major version.

■ Marking a rule as Final prevents changes to a rule in any other RuleSet. This capability is used selectively when building products.

■ Locking a RuleSet version prevents subsequent changes to any rule associated with that RuleSet version.

■ To deploy an application, an administrator uses the Move Rules tool to copy one or more RuleSet versions into a production environment.

Preparing the Application for Deployment 13-3

Preparing the Application for Deployment System architects and system administrators typically work together to prepare an application for deployment. Use the following summary now as an introduction to the deployment process and later as a checklist for reference:

■ Work with a system administrator to set up the organization hierarchy, operator IDs, calendars, and access groups for the business areas that plan to use the production application.

■ Identify the RuleSets and RuleSet versions of your application. For each RuleSet, create a higher-numbered major or minor version for subsequent development work.

■ Check that the Availability setting is appropriate for all rules.

■ Lock each RuleSet version to be deployed, to prevent changes to the rules it contains.

Note: If you are building a product or an application to be implemented at many locations, refer to the end of this chapter for additional guidelines.


Creating a Major RuleSet Version For an initial or later major release of an application, you create a new major version of each RuleSet. You need to collect and promote the highest-numbered version of each rule into the next major version. The Skim function of the Move Rules tool supports this renumbering process (Figure 13-1).

Figure 13-1. Move Rules Section

Creating a Minor RuleSet Version To accommodate ongoing development and interim releases of an application, create a higher-numbered minor version of each RuleSet. For example, if your current application rules belong to the RuleSet version named ALPHA:04-15-17, the next highest minor version is ALPHA:04-16-01.

What You Completed Created major and minor RuleSet versions for deployment.

Understanding Rule Availability Whenever you create or save a new version of a rule, you can specify an availability field that controls how rule resolution operates. This feature provides another option for managing rules in both development and production. The availability field for each rule is visible as an icon in the upper-right corner of the rule form. As part of preparation for deployment, review and verify these settings:

■ Yes indicates that a rule is available to be executed. This setting is the default. Rules with a Yes setting are visible to rule resolution processing and executed normally.

Preparing the Application for Deployment 13-5

■ No/Draft indicates that a rule is not available. Rules with a No/Draft setting are invisible to rule resolution for all users. Setting rule availability to No/Draft is useful when troubleshooting or experimenting with alternate versions of a rule. This setting affects only one version of a rule.

■ Blocked indicates that rule resolution processing should end (with no rule found) when this rule is encountered. Setting rule availability to Blocked is useful for troubleshooting flows. This setting affects all lower-numbered versions of a rule.

■ Final indicates that a rule is available to rule resolution, but cannot be overridden in any RuleSet except the current RuleSet. Rules marked Final can be superseded in a higher-numbered version of the same RuleSet, but not in any version of another RuleSet. Setting rule availability to Final is useful when you want to maintain control over selected rules.


Locking a RuleSet Version You can lock any RuleSet version to prevent changes to the rules associated with that RuleSet and version (Figure 13-2).

Figure 13-2. RuleSet Version Rule Form

Optionally, review or update the Effective Date before you lock a RuleSet version. This setting is useful if you need to replicate past processing based on the rules in a lower-numbered RuleSet version. For example, suppose a customer reports a suspected error in calculating a loan payment six weeks ago. You can reproduce the process that originally occurred with the loan was written, based on business rules in effect at the time.

What You Completed

Verified rule availability settings for all rules in your application.

Locked each RuleSet version to be deployed to prevent unauthorized changes.

Deploying the Application 13-7

Deploying the Application Deploying the application involves extracting RuleSet versions from the development environment, installing them on the production environment, and adjusting user access:

■ Use the Move Rules tool to copy the application RuleSets and any associated date instances into the production environment.

■ In the production environment, create one or more minor versions of the RuleSet for ongoing development and divisional customization.

■ Make the application available to users.

■ In the production environment, create one or more minor versions of the RuleSet for ongoing development and divisional customization.

■ Delegate responsibility for selected rules to users.

Copying the Application RuleSets into Production Copying a RuleSet from development to production involves extracting information from the PegaRULES database of a source environment and loading the extract into the PegaRULES database of a destination environment. The Move Rules tool supports these tasks (Figure 13-1).

If your application includes workbaskets, listeners, calendars, or other data objects to be copied, create a product rule (Rule-Admin-Product rule type) or product patch rule (Rule-Admin-Product-Patch rule type) to identify and incorporate these objects into the ZIP file that contains the rules. On the destination production system, loading a product ZIP file is similar to loading a Move Rules ZIP file.

What You Completed Moved your application into the production environment.


Making the Application Available to Users The last deployment task is to provide production users with intended access. Working with a system administrator, assign access groups to all users, considering which users need which access roles.

Most users know how to use the Internet Explorer browser. Navigation, printing, saving, and other common operations use the browser interface, reducing technology training requirements. You need to provide users with information about how you run your business in the application context. Include project team resources to develop this type of organizational training.

Managing Rules and RuleSets in Production SmartBuild enables you to Build for ChangeTM. Business users can share the responsibility for maintaining selected rules (see Appendix A). Once an application is deployed into production, further changes can impact the daily operation of your business. Follow these guidelines for ongoing change management and migration:

■ Use the Check Out / Check In feature to manage rule changes in production RuleSets. A checked-out rule displays a lock icon ( ) in the upper-right corner.

■ Delegate responsibility for maintaining selected rules to appropriate users (as described in the next section).

■ Make major changes first on a development system where you can test them without affecting production. Then perform integration testing in an isolated test environment before moving the changes into production.

■ RuleSet versions allow you to make minor changes directly in your production environment. Validate any changes with a small group of identified users before making them available to all users.

■ Use access groups, the organization hierarchy, and operator IDs to grant access to a modified RuleSet in a phased approach. Use version levels (specifying a major version only, or also the minor or patch level) to control what RuleSet versions are visible to a user.

Deploying the Application 13-9

■ To automatically grant access to the latest patch version, omit the patch level portion of the version number (for example, 02-03 rather than 02-03-15).

Delegating Responsibility for Rules After you deploy an application, users typically perform work based on rules in locked RuleSet versions, while your development effort continues in higher-numbered versions of the RuleSets.

Delegating a rule enables users who do not routinely develop or maintain rules to have responsibility for and easy access to selected rules. You can also use rule delegation to provide business analysts or managers with direct access to specific rules for ongoing updates. For example, you can allow departmental managers to adjust loan approval service levels as needed. You might want to provide process architects with quick access to commonly modified flows or user interface forms. Delegated rules appear in the My Rules section of the Dashboard (Figure 13-3).

Figure 13-3. Dashboard with Delegated Rules in My Rules Section

Delegation causes responsibilities for ongoing maintenance of the application to be shared among those close to the business operations and IT professionals. Managers, depending on their privileges, may be able to see and update only a simplified version of the rule form, such as the left-most tab and the History tab.

As summarized in Appendix A, delegation is a crucial step to achieve the benefits of building for change.

What You Completed Made the application available to users

Delegated responsibility for selected rules to individual users or groups.


Evolving the Application Using your Process Commander application to manage your business process inevitably offers new possibilities to your organization. You may identify better ways of doing your existing work or discover additional business areas that can benefit from using the application. With your application in production, your organization may identify application enhancements that benefit the business.

Evolving a Process Commander application consists of two types of changes:

■ Business rule changes, which do not require design work. Process architects typically perform these types of changes as needed, without assistance.

■ Application logic and architectural changes, which are more complex and require design work. A process architect/system architect team is typically responsible for these types of changes.

Typical Business Rule Changes

■ Adjustments to service levels, work party roles, and correspondence rules.

■ Minor changes to existing flows, such as work routing and assignments, to accommodate ongoing process improvements.

■ Adding and changing decision rules to reflect changes in the business process.

■ Modifying declarative rules to changes calculations.

■ Cosmetic changes to forms to reinforce branding or support changing data collection requirements.

■ Adding online help to provide context-sensitive business assistance, such as frequently asked questions or case-based reasoning.

Evolving the Application 13-11

Typical Application Logic and Architecture Changes

■ Supporting additional work types or work party types.

■ Building new flows or spin-off flows, for example, to support work performed by external suppliers or partners.

■ Creating new declarative rules to handle new data relationships or decision logic.

■ Creating new activities to support added processing or new paths in flows.

■ Making complex changes to existing classes or properties.

■ Adding interfaces to or from other systems so they can share data and/or processes with your application.


Capabilities to Consider in This Step This section describes additional capabilities that support deployment of your application as a product into multiple Process Commander environments (or less commonly, multiple instances within a single Process Commander environment).

Preparing a Product for Distribution For applications designed as products to be deployed more than once, preparation tasks are required.

■ Identify classes or rules that should not be changed by a customer. Mark them as Final to protect against changes in other RuleSets.

■ When you created the product class structure, you created abstract classes so you could retain design control over the baseline product. You also created a class as the placeholder for a class group for customer deployment. Now create a RuleSet for deployment with a class structure that mirrors the product class structure:

– For each class in the product RuleSet, use Save As to create a similar class in the RuleSet for deployment. If the class is to be concrete when deployed at the customer, don’t include the dash in the name.

– Correct the class settings in the RuleSet for deployment, including whether the class is or belongs to a class group, whether it is concrete or abstract, and its inheritance.

– Create a class to start the class group at the appropriate level in the hierarchy.

– Create concrete versions of each remaining abstract class.

■ Create a product definition to identify the components of your product for packaging. See the next section for more information.

■ Set up an organization hierarchy and access groups that represent a typical customer. Then test the RuleSet configuration and deployment process in a customer setting.


Using the Directed Inheritance Wizard Process Commander includes a wizard that lets an administrator apply directed inheritance to all the classes in a class group. You can clone all or part of an existing class hierarchy in a few steps. This process eliminates the need to copy and save each class with a different name in a new RuleSet.

Using the Directed Inheritance wizard, you can:

■ Exclude classes or subclasses not needed in the copy.

■ Rename the class hierarchy to reflect a new organization, which lets you operate multiple instances of one application on one Process Commander system.

For example, assume your company has several divisions that want to implement the PegaRP example, each of which is in a different business segment and operates independently. However, they all share a central data center. Using the Directed Inheritance wizard, you can create separate RuleSets with unique top-level classes for each division. The divisions can each use their own business rules to drive their application development process, but share one Process Commander environment.

Figure 13-4 illustrates a typical before-and-after scenario of using directed inheritance to map and rename the PegaRP classes in your RuleSet. You must create the destination RuleSet and top-level classes prior to starting the wizard. For complete instructions on using the Directed Inheritance Wizard, see the Administration and Security book.

Source Class Target Class

PegaRP-Work-Object- YourCo-SwMgmt-Work-Object

PegaRP-Work-Project- YourCo-SwMgmt-Work-Project

Figure 13-4. Mapping and Renaming Classes with Directed Inheritance




Rules

Create a master locked RuleSet Rule-RuleSet-Version SysAdmin

For products, create a product definition to control packaging

Rule-Admin-Product

Rule-Admin-Product-Patch

SysAdmin

For products, create a sample RuleSet and a top-level class to represent customers deploying the product

Rule-RuleSet-Name Rule-RuleSet-Version Rule-Obj-Class

SysAdmin

Data

Set up the organization hierarchy and grant access to RuleSets

Data-Admin-Organization Data-Admin-OrgDivision Data-Admin-OrgUnit

Organization

Create access groups and set your default RuleSet for changes

Data-Admin-Operator-AccessGroup Security

Create operator IDs and assign access groups




RuleSet versions that contain the latest rules for your application, with:

– Availability settings verified.

– RuleSet versions locked.

Additional minor RuleSet versions for ongoing development and divisional customization.

Your application moved into the production environment.

Any application-specific data instances moved into the production environment.

Selected business rules delegated to one or more users or access groups.

Step 14: Leveraging Reports and Quality Features

After you complete SmartBuild Step 13, your application is available to production users. This chapter describes facilities that can improve the business results of the processes supported by your application.

To assess any business process, managers must monitor how the process is currently functioning. They must also be able to measure process quality using quantifiable data. This chapter describes features that help process architects and line managers improve business processes, including:

■ Using reports to monitor and improve your business process.

■ Driving work timeliness with service levels and urgency.

■ Segmenting service levels or other rules based on customer characteristics.

■ Measuring process cost.

■ Using statistical sampling for quality control.

Who Does This: Process architects support management in these tasks.

14-2 Step 14: Leveraging Reports and Quality Features

Important Terms and Concepts Te following terms and concepts are important to the tasks in Step 14:

■ Process Commander includes an extensive set of standard reports in both tabular and chart format that provide common metrics for business process management (BPM) applications. You can also use the Report wizard or third-party reporting tools to create custom reports.

■ Service level rules define completion timeframes for assignments or for a complete flow execution. In a service level rule, you can specify what happens when these thresholds are not met. Standard reports compare actual results with timelines and goals.

■ Urgency is a numerical value that represents the relative priority of a work object or an assignment. Your application automatically calculates an urgency value based on points for a work type, work party, and service level. Worklists present assignments based on urgency.

■ Your application can use circumstance-qualified rules to refine application behavior based on customer-specific characteristics. Rule resolution applies different rules for a work object based on circumstance.

■ You can assign a cost to each flow action in a flow. Process Commander automatically calculates the total cost of all flow actions selected for a work object. These cost data can enable you to analyze and refine your business process.

■ Using statistical sampling capabilities, your application can randomly select work objects in a flow for additional review and processing. For example, you can trigger a customer satisfaction survey for a subset of resolved work objects.

Business Activity Monitoring Capabilities 14-3

Business Activity Monitoring Capabilities Process Commander includes an extensive set of integrated business activity monitoring (BAM) capabilities. These provide managers and business analysis with the real-time information needed to analyze processes, assignments, work in progress, and other work-related data.

The following capabilities are a fundamental part of the integrated BAM facilities:

■ Process monitoring — provides real-time process and performance indicators to improve operational execution and decision making. Process Commander includes a set of standard reports in both tabular and chart formats, a wizard for creating custom reports, and online analytical processing (OLAP) support.

■ Automated process management — enables your application to automatically and proactively take corrective actions, handling potential problems through reassignment, escalation, and dynamic process selection.


What Standard Reports Are Available? Standard reports are available directly from the Monitor Activity workspace. The icon ( ) identifies reports available in both tabular and chart formats. Figure 14-1 describes the categories of standard reports, including whether they include open and/or resolved work. (If a resolved work object still has an assignment outstanding, such as a post-resolution quality review, the affected assignment appears on reports for open assignments.)

Report Category

Information Provided

Open Work Objects

Resolved Work Objects

Monitor Process Assignments

Work timeliness. Measured by individual performance of assignments against service levels.

X

Monitor Processes Work timeliness and throughput for organizations, including customers. Measured by organizational performance of processes against service levels and progress towards completion.

X

Analyze Process Quality

Work distribution and timeliness for organizations. Measured by organizational initiation, duration, and resolution of work.

X X

Analyze Process Performance

Work efficiency and duration for processes. Measured by task frequency, completion time, and timeliness for assignments associated with a process.

X X

Figure 14-1. Categories of Standard Reports

For each category, you can enter parameters to include, exclude, and sort data. You can generate reports on demand for quick review and export them to Microsoft Excel for further analysis.


Using Standard Reports to Improve Your Business Process Organizations that adopt a Six Sigma philosophy or similar quality programs recognize the role of data in any improvement effort. Based on statistics, you identify opportunities for improvement, determine actions, and measure the results.

Standard reports support this principle by facilitating data-driven improvement of your business process. Whether you have a formal quality council or less formal management review, you can use these reports to identify opportunities. Figure 14-2 provides suggestions for the improvement process.

Process Opportunity Use Reports in This Category

How efficiently is the staff performing the current work? How are they performing against service level goals?

♦ Monitor Process Assignments

How efficiently is the organization performing the current work? How are work groups performing against service levels goals? Is the work progressing satisfactorily towards completion?

♦ Monitor Processes

How timely and efficient is the business process overall, for both current and resolved work? Which stages of work represent the most effort? How does service level compliance compare across types of work?

♦ Analyze Process Quality

How much work is performed on behalf of key customers? Are your customers satisfied after their work is resolved? After each interaction?

♦ Analyze Process Quality (Effort by Customer)

♦ Custom reports based on pyCustomer and pyStatusCustomerSat properties

Where does the staff spend the most effort overall, for both current and resolved work? Which tasks consume the most time, and what is service level compliance for them? What is the root cause of the work?

♦ Analyze Process Performance ♦ Custom reports based on pyRootCause

Figure 14-2. Identifying Opportunities for Improvement


Using Online Analytical Processing (OLAP) PegaRULES Process Analyzer is an optional product in the SmartBPM Suite. It extends your application by enhancing your ability to analyze and understand the business process in depth. Process Analyzer provides integrated online analytical processing (OLAP) capabilities for historical work analysis. Process Analyzer combines work categories (such as organization, operator, and work object status), quantitative values (such as timeliness, throughput, and actual/estimated effort), and hierarchies (such as geography by country, state, region, division, and unit) to create a multi-dimensional data model referred to as an OLAP cube.

Business analysts familiar with Microsoft Excel can easily execute complex data queries with OLAP cubes, such as viewing workload and throughput over time by division, work group, and operator. Process Analyzer includes four OLAP cubes:

■ Workload — volume of arriving work objects, throughput of resolved work objects, backlogs

■ Queue load — volume of new assignments, throughput of completed assignments

■ Performance — detailed statistics on how users spend time completing assignments

■ Cycle time — elapsed time to resolution

Using Business Process Simulation PegaRULES Process Simulator, a related companion to Process Commander, allows a business analyst to understand and model a business process (represented by one or more flow rules) in an event-driven software simulator. Simulator inputs include a synthesized workload of arriving work objects, staffing levels for each workbasket, service levels, and shift work schedules. Simulator outputs include charts and statistics regarding throughput, backlogs, and service levels achieved. Consult the Process Simulator User Guide for a further description of this optional product.

What You Completed Reviewed standard reports, Process Analyzer and Process Simulator

capabilities.


Creating Custom Reports Standard reports may meet many of your needs, especially for a new application. However, Process Commander also gives you the flexibility to create additional reports as needed or as your needs change.

Using the Report Wizard The Report wizard guides you as you create a custom report (Figure 14-3). This wizard is designed for business users, offering step-by-step instructions. For quick access, you can also add custom report links to the Monitor Activity home view.

Figure 14-3. Report Wizard


The Report wizard creates two types rules of rules. List view reports (Rule-Obj-ListView rule type) present one row for each selected instance. Summary view reports (Rule-Obj-SummaryView rule type) may include charts, subtotals, and drill-down sections. Once either rule is created with the Report wizard, a system architect can refine the presentation, sort order, selection or columns as desired.

Using Third-Party Database Reporting Tools The PegaRULES open database schema allows you to create reports with software tools that you already have for relational database reporting. Choose from third-party reporting tools, including Actuate (e.Reporting Suite), Oracle reporting tools, Microsoft SQL Server reporting tools, and Business Objects Crystal Reports.

What You Completed Created custom reports if needed.


Supporting Customer-Oriented Reports Customer-oriented reports are only meaningful if your application captures information in each work object about the work party who is a customer. Because not all applications require customer involvement, standard harness rules do not include .pyCustomer as a data entry field.

To facilitate customer reporting, modify your application to update the Work-.pyCustomer property and related properties (such as .pyCustomerOrg and .pyCustomerEnterprise) at an appropriate place in each flow. Typically, this requires that you save and modify a copy of the standard activity named WorkPartyRetrieve, so that your application updates properties appropriately.


Improving Quality through Rules Process Commander embraces the Six Sigma concept of continuous improvement, which promotes measuring an existing process in order to decide whether and how to improve it. If you can’t measure and report on something, you can’t effectively manage or improve it. First decide how you want to measure quality in your business process. In this context, quality has four dimensions (Figure 14-4).

Quality Dimension Example Sources of Metrics

Are you performing the work efficiently and correctly?

Established service levels and performance reports for work escalation and completion.

Are you performing the most important work first?

Priority scheme to control the order in which assignments are presented to business users.

Are customers satisfied with their interactions with you?

Customer satisfaction surveys.

Are potential problems associated with the work you perform?

Trend reports based on root cause analysis of the work.

Figure 14-4. Typical Quality Metrics

To streamline the process of gathering metrics, Process Commander provides four features for measuring and monitoring quality:

■ Adjusting service levels to automatically escalate work when it approaches or passes deadlines, based on your business rules.

■ Improving timeliness by calculating appropriate urgency values

■ Serving Customer segments based on using circumstance-qualified rules

■ Sampling for quality by randomly selecting a subset of interactions for follow-up action (such as a customer satisfaction survey).

You can incorporate these features into your application by changing a few rules, as described in the following sections.

Improving Quality through Rules 14-11

Adjusting Service Levels for Timeliness Defined service levels are essential for managing your business process and ensuring that work is completed in a timely manner. They automate the process of monitoring work completion and notifying management when additional scrutiny or action is warranted. Service level rules help managers monitor work as it approaches preset goals (the desired completion timeframe) and deadlines (the required completion timeframe):

■ A service level rule (Rule-Obj-ServiceLevel rule type) specifies three timeframes for completing work — goal, deadline, and late — and optional escalation actions to perform when those timeframes are reached (Figure 14-5). You can designate recurring escalation to continue escalating a work object after the deadline is passed.

Figure 14-5. Service Level Rule Form

■ The standard property Work-.pySLAName identifies the service level rule that applies to an entire flow execution. If you don’t create your own service level for a work type, the standard model Work-.pyDefault sets this property to Default (a standard service level rule).

■ When a work object is created, a standard flow (Work-.OverallSLA) sets its goal and deadline times according to the service level specified in Work-.pySLAName.


■ The Pega-ProCom agent periodically runs a standard activity (Work-.CheckSLA) that monitors work and calls various activities whenever a service level interval is not met.

■ Standard reports help managers analyze completed work based on timeliness against service levels.

Note: Assignments that have an associated service level appear in flow diagrams with a clock image next to the assignment shape.

Standard Service Level Rules Process Commander includes several standard service level rules that represent common business process situations. Figure 14-6 summarizes a few of them.

Service Level Action When Goal or Deadline Not Met Goal Deadline

Work-.Default None. 2 days 5 days

Work-.External None. 5 days 10 days

Work-.NotifyAndTransfer ToManager

Sends an e-mail to the manager. 1 day 3 days

Work-.NotifyAssignee Send an e-mail reminder to the assignee. 1 day 2 days

Work-.NotifyAssignee TransferToManager

Transfers the assignment to the manager. 1 day 2 days

Work-.NotifyManager Sends an e-mail to the manager. n/a 2 days

Work-.TransferTo Workbasket

Transfer the assignment to a workbasket. n/a 2 days

Figure 14-6. Standard Service Levels

Service level rules are of type Rule-Obj-ServiceLevel, which are in the Process category in the Explorer tools. You can use any of these service level roles, or save a copy in your RuleSet to modify for your business needs. For example, you may want to change the timeframes, or specify another activity to call when a goal or deadline is reached.


Note: To monitor service level performance, the Pega-ProCom agent process needs the ability to access and execute service level rules (and the activities they reference) in your application RuleSets. Work with a system administrator to update an access group for this agent. The access group to be modified is referenced in a Data-Agent-Queue instance named Pega-ProCom.

What You Completed Incorporated services levels into flows.

Driving Work Timeliness Completing work in a timely manner depends on presenting assignments to users in the most effective order. Process Commander includes two features that organize assignments in worklists, as shown in Figure 14-7.

Feature How It Works Standard Work- Property

Urgency Assignments with a higher urgency value have a higher priority, and thus sort closer to the top of a worklist. Your application computes urgency based on a combination of automatic and manual methods.

pxUrgencyWork

Service level Automatic notifications (such as e-mail or pager messages), transfers, or recurring escalations when assignments pass service level goal or deadline timeframes. Assignments can receive a higher urgency value as they approach these targets and thus sort closer to the top of a worklist.

pySLAAction pySLADeadline pySLAGoal pySLAName

Figure 14-7. Techniques for Organizing Work


Service Level Icons on Worklists On the worklists display, a red or yellow colored clock highlights assignments that are approaching service level goals or deadlines. For each named service level, you set the default goal, deadline, and late timeframes. Users can also reset the timeframe using standard flow actions if you make these flow actions available to them.

If service level rules specify that a missed goal, deadline, or late timeframe impacts an urgency calculation, work objects that are closer to or have passed their service levels automatically sort to the top of a worklist.

Setting Urgency to Prioritize Work Urgency is a rating scale that works with service levels to determine the priority of a work object or assignment, and thus its sort order in a worklist. As shown in Figure 14-8, this value is a decimal number between 0 and 100, similar to the Centigrade temperature scale.

Total Points Meaning

0 Freezing, or not urgent

20 Room temperature, or normal

40 Hot, or becoming important

100 Boiling, or urgent

Figure 14-8. Urgency Scale

Several properties contribute to the urgency calculation. Your application can influence this computation in several ways:

■ Automatically, based on work type (based on the standard property Work-.pxUrgencyWorkClass). In the PegaRP example, work objects for serious issues have a higher urgency than other work object types. To specify urgency points for a work type, include .pxUrgencyWorkClass in the model.

■ Automatically, based on the work party (based on the standard property Data-Party.pyUrgencyWorkParty). To specify urgency points for a type of work party, set .pyUrgencyWorkParty in an activity.


■ Automatically, based on service levels not met (using the standard property Work-.pxUrgencySLA), such as missed milestones. For example, your application can increase the urgency of work objects not resolved within a service level timeframe. To increase urgency based on a service level timeframe, enter the additional urgency points on the service level rule form.

■ Directly, for an individual work object (based on the standard property Work-.pyUrgencyWorkAdjust). For example, a supervisor can force a specific assignment to the top of a worklist because of repeated calls about the assignment. In addition, a user if authorized can enter urgency points on the work object form.

Your application calculates the total urgency value of a work object, and then uses the value as the sort order for worklists and workbaskets. The total urgency is the sum of all urgency points assigned.

Adjusting Service Levels and Urgency for Best Results For best results, instruct application users to complete assignments at the top of their worklist first. Then, review the values for service levels and urgency together to ensure that the most important work receives the highest priority:

■ If only a few work objects or assignments miss their service levels, management may consider reducing the overall goal and deadline timeframes to speed work completion. Adjust the timeframes in small increments and monitor the results.

■ If work objects or assignments of one type frequently fail to meet service levels, consider providing additional training for that type of work objects or increasing the goal and deadline timeframes.

■ Consider increasing the urgency value for work types that frequently fail to meet their service levels. This change causes those work objects to sort to the top of worklists earlier allowing users more time to resolve them.

The mix of arriving work is constantly changing. As a result, work distribution and performance statistics are rarely constant. Use the standard reports to monitor your


business process on an ongoing basis. Watch for other conditions that might warrant adjusting the service level and/or urgency.

What You Completed Defined relative priorities for work objects. Specified additional urgency points for work types, service levels, and work

parties, if needed.

Serving Customers by Segment Service-oriented organizations often choose to provide a higher level of service to preferred customers, such as premium credit cardholders. In your application, you may want work objects for customers known to require extra processing time to be routed to a work-out team or specialist.

To support such distinctions, first define one or more additional service level rules, one for each customer segment. Then use circumstance qualification (a rule resolution feature) to apply the service level best suited to each customer, based on the value of a property such as Work-.pyCusLevel.

For example, your application can use the GoldCustomer service level rule for customers identified as Gold in the pyCusLevel property, the SilverCustomer service level rule for customers marked as Silver, and so on.

Rules of most types support an optional feature know as circumstance processing. You can use circumstances to drive different behavior for almost any customer-specific characteristic. For example, you can apply different rules for repeat customers, for customers located in one geographic area, or based on a customer’s language preference. In the PegaRP example, enhancements that are suggested by members of the project team are processed differently than those suggested by anyone else.

What You Completed Implemented any customer-specific circumstances for rules if needed.


Tracking Processing Costs Your application can collect and present cost figures representing labor and other per-work-object costs:

■ In each flow action rule, you can record a cost value in units of your choice.

■ As a work object advances through a flow, users select flow action to record information and decisions.

■ Process Commander automatically computes for each work object the cumulate cost of the selected flow actions. A Declare Expression rule computes the property Work-.pyFlowActionsCost.

■ Your application can use this computed value in reports, analysis, or billing.

Sampling for Quality Control Process Commander includes features for building quality control directly into your business process. Through statistical sampling, your application can randomly select a subset of work objects for special processing. For example, you can survey five percent of customers who applied for new jumbo mortgages about their experience.

Note: Consider statistical sampling as an enhancement after your application has been deployed at least briefly in production. This approach gives you time to stabilize your business process and application after initial deployment, which results in a better decision on how to best take advantage of this feature.

How to Implement Statistical Sampling Statistical sampling is a general-purpose feature that you can use to randomly select work objects for special treatment. For example, your application can route a few easy-to-resolve work objects to a group of trainees. Alternatively, your application can survey a randomly selected subset of recent customers in a geographic area.

The following example suggests how to implement a customer survey. Start by analyzing how you want to survey your customers. First, define the steps in the process, when you want to conduct the survey, and who you want to perform the


work. For example, you can conduct a survey after a work object is resolved. Select a survey format (such as e-mail, letter, or phone call) and create the survey.

Follow this process to add statistical sampling into a flow:

1. Update the flow rule to select work objects at the appropriate point in the process. To do this, add a utility task that calls the standard activity named Work-.RandomSelection. For the SelectPercent parameter, enter the percentage you want to select.

2. Add a Spin-off shape for the randomly selected work objects.

3. Connectors utility to the spin-off flow (Figure 14-9).

Figure 14-9. Sample Flow with Statistical Sampling

4. Create the spin-off flow rule to handle the follow-up processing.

What You Completed Incorporated statistical sampling into one or more flows if needed.




Rules

Assign urgency points for a class Rule-Obj-Class SysAdmin

Create service levels with urgency points for one or more classes

Rule-Obj-ServiceLevel Process

Define circumstances for one or more rules Rule-Obj-Class SysAdmin

Set a cost for one or more flow actions Rule-Obj-FlowAction Process

Add statistical sampling to flows to build in quality management

Rule-Obj-Flow Process

Modify the statistical sampling algorithm Rule-Obj-Activity Technical

Application-specific reports at the detail level Rule-Obj-ListView Portal-and-HTML

Application-specific reports at a summary level Rule-Obj-SummaryView Portal-and-HTML


Step 14 Completion Checklist After finishing this SmartBuild step, check that you have the following components.

Standard reports reviewed.

Custom reports created, if needed.

A list of service levels for your application.

Service levels created for one or more work types and incorporated into flows.

Relative priorities defined for work objects.

Additional urgency points specified for one or more classes or work parties, if needed.

Customer-specific circumstances identified and implemented for selected rules, if needed.

Cost values assigned to one or more flow actions, if needed.

Statistical sampling incorporated into one or more flows, if needed (later implementation recommended).

Appendix A Quick Reference to Essential Design Principles

This book describes the SmartBuild process for designing and building Process Commander applications. It presents important design guidelines and recommended best practices for success.

Use this appendix as a quick reference to the fundamental principles that capture the essence of SmartBuild, referred to as “guardrails for success.” Following these principles leads to rules-based applications that are well designed, straightforward to maintain, and architected to Build for Change™. They are your key to success with Process Commander.

A-2 Quick Reference to Essential Design Principles

Ten Guardrails for Success These guidelines summarize important SmartBuild practices.

Follow this guardrail To achieve these benefits …

#1 — Adopt an Iterative Project Approach

Define an initial project scope that can be delivered and provide business benefit within 60 to90 days from design to implementation, as described in Step 1.

An iterative approach enables your team to place a solution into production in a short period so you can gather meaningful feedback from the business to drive subsequent releases. Key points to remember:

Document five concrete use case scenarios upfront and evaluate them at the end to calibrate benefits.

Use your scenarios as storyboards and ensure that each delivers a measurable business benefit.

#2 — Establish a Robust Foundation

The class structure must anticipate the layering of rules and comply with Step 4: “Designing the Class Structure.”

As the foundation of your application, a well architected class structure is critical for optimal processing and performance. It must be understandable, easy to extend, and build upon standard work and data classes appropriately. Key points to remember:

Use your organization entities as a starting pattern, and then proceed with class groups.

Lead with work objects. Create the class structure and “completed work” objects early.

Position rules correctly by Applies To class and/or RuleSet.

Actively use inheritance to prevent creation of redundant rules.

Ten Guardrails for Success A-3


#3 — Don’t Do Things The Hard Way

Use the standard out-of-the-box rules and functions in the initial application. Do not duplicate standard capabilities.

Do things the easy way. Using the tested components built into Process Commander decreases time tomarket and allows your application to benefit from enhancements in future Process Commander releases. Key points to remember for the initial version of your application:

Evolve your application harness and section rules by copying and overriding standard rules, using the same purpose names. Do not create work object forms from scratch. Use only the standard buttons.

Always check the Auto-generated HTML feature for section rules and flow action rules (Step 7).

Always build upon the standard rules, work objects, and properties. Reporting, urgency, work status, and other built-in behaviors rely on standard properties.

Never add a property to control typical work or manage the status or timing of work.

#4 — Limit Hand-coded Java

Avoid Java steps in activities when equivalent standard rule types, library functions, or activity methods are available.

Although using Java directly in activities (as mentioned in Step 9) can be a powerful tool, investigate all of the rule types and existing standard rules before resorting to the addition of a JAVA step in an activity or a Java directive in an HTML rule. Key points to remember:

Reserve your valuable time and Java skills for implementing capabilities that do not already exist.

Using more but simpler rules promotes modularity and reuse, and improves maintainability.



#5 — Build for Change™

Identify and define 10 to 100 individual rules that business users own and will maintain.

Openly discuss rules with business users throughout the SmartBuild process. Agree on the rule instances for which they are to be responsible; design and build accordingly. After the application is deployed, delegate them to individuals or groups, as described in Step 13. Key point to remember:

Do not delegate activities. Use other rule types for business-user-maintained logic.

#6 — Design Intent-Driven Processes

Your application control structure must consist of flow rules and declarative rules, calling activities only as needed.

Intent-driven processes have the rule-driven intelligence to guide users to do the right thing in a given situation. Key points to remember:

Use flow actions to prompt a user for input, as described in Step 9.

Present no more than five connector flow actions for any individual assignment. If a design appears to require more than five, confirm that each action is part of the assignment’s intent-driven process.

To maximize reuse, create activities that implement a single function..

Remember that even simple data updates or changes may be good candidates for small process flows.

#7 — Create Easy-to-Read Flows

Your flows must fit on one page and must not contain more than 15 shapes (not counting Router shapes, Notify shapes, and connectors) per page.

Flows must be easy to read, move from top to bottom and left to right, and minimize crossover between steps. Key points to consider if a flow has more than 15 shapes:

Create a subflow and call, branch, or spin-off to it. Use parallel flows and Split/Join or Split-for-Each shapes.

Ten Guardrails for Success A-5

#8 — Monitor Performance Regularly

Evaluate and tune application performance at least weekly using Performance tools to check efficiency.

Always allocate time during development for system performance testing to ensure that your application operates cleanly and efficiently. Key point to remember:

Use the Performance tool to capture detailed statistics on memory, processor, and input/output demand.

Use the System Console servlet to monitor background processing.

#9 — Calculate and Edit Declaratively, Not Procedurally

Use declarative rules to calculate or validate property values whenever possible, as described in Step 6, “Adding Properties and Sample Data.”

Declarative rules are change-aware and eliminate the need for more expensive activities to check for and implement property value changes. For example:

Create a Declare Expressions rule instead of using a Property-Set method in an activity.

Use a Declare Constraints rule instead of a validation rule.

#10 — Keep Security Object-Oriented, Too

Your security design must be rule-based and role-driven based on who should have access to each type of work (as described in Step 11, “Setting Up Access and Security.”

Standard rule types (Access Roles, Access Whens, Privileges, and Settings) provide the ability to control who can access all or part of a work object. Use these rules to implement a scalable security model for your solution that is class-based and leverages inheritance. Key points to remember:

Don’t use activities and functions as a normal way to check or enforce security restrictions. Use the rule types presented in Step 11, which are automatically enforced at all times.

Use the standard access roles only as a starting point. Use RuleSets and RuleSet Versions for managing rule

changes to the business, not as a security measure (as defined in Steps 3 and 13).


Monitoring Compliance with Guardrails Version 4.2 SP2 of Process Commander (released in 2Q 2005) includes a feature that can assess compliance of an application with several of the guardrails. Using a built-in guardrails compliance checker, an administrator or system architect can assess the extent to which important design and implementation guidance has been followed.

To report on an application:

1. Confirm that your RuleSet list includes the ProCom:04-02-45 version (or higher).

2. Select the application name of the application to be analyzed from the selection list in the navigation panel, such as Time Off in Figure A-1.

Figure A-1. Application Name

3. Click the Manage Rules bar to enter the Manage Rules workspace.

4. Locate the Application Overview area. Click the Preflight button (Figure A-2 ).

Figure A-2. Application Overview

Monitoring Compliance with Guardrails A-7

5. To assess compliance, Process Commander assembles a list of activities, sections, flow actions, and flow rules from the RuleSets and Versions that define the selected application. It reviews activities to identify Java steps and the number of lines of Java code in each Java step. It reviews the flow actions and sections to identify HTML code produced with manual editing (open authoring) rather than auto-generation. Finally, it reviews flows, checking assignments that include more than five connector flow actions and flows that contain more than 15 shapes. A bar chart summarizes compliant (in green) and noncompliant (in red) rules of each time (Figure A-3).

Figure A-3. SmartBuild Compliance Validation Summary

6. Click the yellow arrow ( ) to expand a row of the display. The detailed display identifies each rule and the extent of its compliance (Figure A-4).

Figure A-4. SmarBuild Compliance Validation Details


7. For each noncompliant rule, consider your rationale and justification. To improve the degree of compliance, update rules to eliminate noncompliant elements.

8. Click any row to open the corresponding rule.

Appendix B Contacting Pegasystems

This appendix describes how to contact Pegasystems for the following:

■ Customer support

■ Office locations

■ Education services

■ Documentation feedback

For more information about our company and products, visit our Web site at www.pega.com.

B-2 Designing Your Application with SmartBuild — Contacting Pegasystems

Customer Support Pegasystems Global Services has a dedicated team of support engineers and product specialists ready to respond with support and consulting services. Pegasystems offers a choice of customer support programs to meet your business requirements. Global Services is committed to working in partnership with our customers to deliver world-class support and service.

To contact Pegasystems, go to www.pega.com.

Education Services Pegasystems Education department offers a wide range of courses for our customers. For course descriptions and contact information, go to www.pega.com. Courses are presented at these locations:

■ Headquarters in Cambridge, Massachusetts

■ San Francisco, California

■ Reading, United Kingdom

■ Sydney, Australia

Documentation Feedback Pegasystems strives to produce high-quality documentation. If you have comments or suggestions, please send us a fax or e-mail with the following information:

■ Document name, version number, and order number (located on the copyright page)

■ Page number

■ Brief description of the problem — for example, what instructions are inaccurate, or what information requires clarification

Contacting Pegasystems — Office Locations B-3

Send faxes to: 617-374-9620, attention Technical Communications.

Send e-mail to: [email protected].

Note: This e-mail address is only for documentation feedback. If you have a product or a technical question, contact Pegasystems Global Services department.

Office Locations Pegasystems maintains offices in these locations:

■ Cambridge, Massachusetts (Headquarters)

■ Alpharetta, Georgia

■ Chicago, Illinois

■ Concord, New Hampshire

■ New York, New York

■ Irving, Texas

■ Toronto, Ontario, Canada

■ Melbourne, Australia

■ Sydney, Australia

■ Paris, France

■ Reading, United Kingdom

For more information, contact your Pegasystems Sales Representative or go to www.pega.com.

Designing Your Application with SmartBuild — Index I-1

Index

A accelerators

Application Accelerator, 3-6 Connector Accelerator, 12-8 Export Rules, 12-4 Import Rules, 12-4 Service Accelerator, 12-6 when used, 3-2

accelerators and wizards, 3-2 access controls

defining for classes, 11-17 how they work, 11-15 list of, 11-15 setting conditionally, 11-19 setting explicitly, 11-19 when to use, 11-15

access denials, 11-26 access groups

defining, 3-22, 11-7 list of standard, 11-7 purpose, 2-10 when to use, 11-7

Access Role Editor, 11-21 access roles

defining and creating, 11-10 defining class access for, 11-13 defining supplemental, 11-11 purpose, 2-10 testing for, 11-28

access settings purpose, 11-27 testing for, 11-28

Access When conditions, 11-10 access, granting

to applications (RuleSets), 11-7 to rules, 11-15, 11-28 to work and data classes, 11-10

activities creating, 9-19 Java steps, A-3 overuse of, A-3 routing, 9-24 types, 9-19 when to use, 9-18

alias, property, 6-32 Application Accelerator

and work object IDs, 4-21 and work parties, 4-25 and work types, 5-3 class groups, 4-18 pausing and resuming, 3-8 purpose, 3-6 using, 3-7 what it creates, 3-7 when to use, 3-8

Application Explorer, 3-25 application rules, 11-2, 11-5 application service providers, 2-20 applications

components of, 1-11 deploying, 13-3 evolving, 13-10 making available to users, 13-8 user interface options, 7-4 vs. products, 2-20

Assignment shape, 8-23 assignments

and Perform harness rule, 7-12 concepts, 4-7 routing to worklists, 9-24

attachments categories, 7-34 types, 7-33 when to use, 4-28

authentication in Process Commander, 11-3 using a LDAP directory, 12-11

I–2 Designing Your Application with SmartBuild — Index

authorization, 11-3 auto-generated HTML, 7-27, A-3 available rules, 13-4

B background printing

and PegaDISTRIBUTION Manager, 12-13 of correspondence, 10-2

backward chaining, purpose, 6-20 blocked rules, 13-5 business activity monitoring, 7-7, 14-3 Business Process Execution Language, 8-22, 12-5,

12-7 Business Processing Model Initiative, 8-22

C category, 3-25 chaining, forward and backward, 6-20 charts, 14-4 circumstances, when to use, 3-14, 14-2 Class Explorer, 6-5 class groups

designing, 4-18 granting access to, 5-8

class structure cloning to a new RuleSet, 13-13 creating, 5-8 designing, 4-13 examples, 5-7 guardrail for, A-2 guidelines, 4-15 sequence for creating, 5-5 where to define, 4-11

classes cloning, 13-13 defining access controls for, 11-17 defining access roles for, 11-13 defining privileges for, 11-17 granting access to work and data, 11-10 guidelines for Data-, 6-27 guidelines for Embed-, 6-27 how access controls work with, 11-15 inheritance model, 4-3

naming conventions for, 4-14 security for, 11-5 where to define, 4-11

clipboard, 6-13 cloning a class structure, 13-13 Common Gateway Interface format, 12-12 communications capabilities, 10-1 conditional access

access controls, 11-19 privileges, 11-19

Connector Accelerator, 12-8 connector flow actions, 8-20 connectors

configuring, 12-8 list of types, 12-7 purpose, 12-7 when to use, 2-13

container, 7-22 container classes, 5-5 CORBA, 12-5 correspondence

background printing of, 10-2 building, 10-12 fragments, 10-11 how it works, 10-2 list of standard activities, 10-8 list of standard flow actions, 10-9 naming conventions, 10-12 printing, 12-13 user-invoked, 10-5 using e-mail. See e-mail verification, 10-6 viewing, 10-3

cost centers, 9-24 cost, calculating for a process, 14-17 cover

alternative to pyEventI), 4-9 behavior, 4-10 purpose, 4-7 when to use, 4-10

custom reports, 14-7


customers as work party, 2-12, 5-11 reporting on, 14-4, 14-9 segments, 14-16

cycle time cube, 14-6

D Dashboard, 3-4 Data- classes

purpose, 4-2 vs. Work- classes, 4-6 when to use, 6-27

Data-Admin-Connect-EmailListener class, 12-10 Data-Admin-Connect-EmailServer class, 12-10 Data-Admin-DB-ClassGroup class, 5-5 Data-Admin-Organization class, 3-22 Data-Admin-OrgDivision class, 3-22 Data-Admin-OrgUnit class, 3-22 Data-Admin-Requestor class, 3-16 Data-Admin-Workbasket class, 9-23 Data-Admin-WorkGroup class, 3-22 database

accessing external, 12-7 creating declarative indexes, 12-15 exposing columns for reporting, 12-15 work table (pc_work), 12-16

Data-Email-Account class, 10-13 Data-Party- classes, 4-24, 5-10 Data-WorkAttach-File class, 7-34 date formats, 7-30 debugging

declarative rules, 6-21 security problems, 11-23

decision rules decision table, 9-13 decision tree, 9-13 map value, 9-13 when to use, 9-13

Decision shape, 8-24 declarative rules

debugging, 6-21 Declare Index, 6-23, 12-15 guardrail for, A-5

how they work, 6-20 purpose, 6-17 types, 6-23 when reevaluated, 6-22 when to use, 6-2, 6-18

delegating rules, 13-9 guardrail for, A-4

deny access, 11-26 dependency network, 6-20 deployment

moving RuleSets into production, 13-7 of an application, 13-3 user considerations, 13-8

Describe this Rule feature, 9-20 design

approach, 1-4 project methodology options, 1-8 SmartBuild roadmap, 1-6 Ten Guardrails for Success, A-1

directed inheritance purpose, 4-3 wizard, 13-13

Directed Web Access, 10-14 directives, 7-3 divisions, 3-22 dot notation, 6-12 draft mode for flows, 9-10

E e-mail

configuring inbound, 12-10 inbound, for correspondence, 10-14 outbound, for correspondence, 10-13 services, 12-10

Embed- class, 6-27 Enterprise JavaBeans, 12-5, 12-7 examples used in this book, 1-22 explicit access

access controls, 11-19 privileges, 11-19

Explorer categories, 3-25 Export Rules accelerator, 12-4 exposing database columns for reporting, 12-15


external access Directed Web Access, 10-14 using inbound e-mail, 10-14, 12-10 using outbound e-mail, 10-13

external databases, 12-7

F fields

converting input format, 7-33 formatting options, 7-30

final rules, 13-5 flow actions

assigning a cost to, 14-17 creating, 9-16 guardrail for, A-4 identifying, 8-20 local, 8-21 naming conventions for, 9-16 when to use, 9-16

Flow Explorer, 8-8, 9-11 flow shells

avoiding common mistakes, 8-16 creating, 8-11 design shapes for, 8-10, 8-22 designing, 8-4 Microsoft Visio stencil for, 8-3 opening flows, 8-7 primary and secondary flows, 8-8 refining, 8-27

flows calculating cumulative cost of, 14-17 connecting to harnesses, 9-9 creating, 9-8 design shapes for, 8-10, 8-22, 9-4 designing flow shells, 8-12 Draft mode, 9-3, 9-10 Flow Explorer, 9-11 guardrail for, A-4 Screen Flows, 8-30 Short Description, 9-11 starting a flow, 9-28 translating from flow shells, 9-3

folder alternative to pyEventID, 4-9 behavior, 4-10 purpose, 4-7 when to use, 4-10

Fork shape, 8-24 forward chaining, 6-20

G GenerateID utility, 6-16 guardrails

compliance, A-6 definition, A-2

H harness rules

advantages of, 7-6 list of standard, 7-12 naming conventions for, 7-12 purpose, 7-2 referenced in flow rules, 9-9 SmartFrames layout, 7-10 structural diagram, 7-14

harvesting rules, 9-4 help system, 7-35 HTML

auto-generated, 7-27, A-3 processing HTML data, 12-4 streams and fragments, 7-28 using JSP tags with, 7-3

HTML property rules list of standard, 7-30 when to use, 7-30

I images, 7-28

logo, 7-35 Import Rules accelerator, 12-4 inbound e-mail

configuring, 12-10 for correspondence, 10-14

Index- base class, 12-15 indexes. See declarative rules


inheritance, pattern vs. directed, 4-3 Initial Setup wizard, 3-5 integration services

configuring, 12-3 how they work, 12-3 options, 2-13 passing and processing data, 12-4 simulating, 6-29

Integrator shape, 8-25, 12-9 intent-driven process

definition, 8-21 guardrail for, A-4

interfaces from other systems using services, 12-5 to other systems using connectors, 12-7

Italian, 6-34 iteration within SmartBuild, 1-21

J Java Connector Architecture, 12-7 Java language, A-3 Java Message Service, 12-5, 12-7 Java patterns, 7-6 Java Specification Request 168, 12-13 JavaScript, 7-27 JavaServer Page tags, 7-3, 7-19, 10-3 JSR-168 portal standard, 7-4, 12-5

L LDAP directory integration, 12-11 links, when to use, 4-28 list view rules, 14-8 listeners, 12-2 lists, formatting, 6-33, 7-32 local flow actions, 8-21 localization

defining requirements for, 2-16 of harness rules, 7-29 of selection lists, 6-34

lock icon, 13-8

locking data objects, 5-9 RuleSet Versions, 13-6 work objects, 5-2

logging in, welcome page, 3-3 logo image, 7-35 Lotus Domino Directory, 12-11

M map value rules, 9-13 methods, 9-18 metrics

service levels, 14-10 statistical sampling, 14-10

Microsoft .NET Framework, 12-7 Microsoft Active Directory, 12-11 Microsoft Excel, 14-6 Microsoft Visio stencil, 8-3, 8-10, 8-22, 9-4 models

and Application Accelerator, 6-15 pyDefault, 6-14 rule form, 6-15

models, purpose of, 6-12 model-view-controller pattern, 7-6 Monitor Activity workspace, 7-35, 14-4 monitoring performance, 9-21 Move Rules tool, 13-4, 13-7 multi-application environments, 4-5 multi-lingual support. See language support

N naming conventions

classes, 4-14 correspondence rules, 10-12 flow actions, 9-16 harness rules, 7-12 privileges, 11-18 properties, 6-4, 6-6 RuleSets, 3-11 top-level classes, 3-18 work status, 9-26 workbaskets, 9-23


navigation panel, 3-4, 7-35 Notify shape, 9-4, 9-25

O Object Management Group, 12-5 OLAP cubes, 14-6 online analytical processing, 14-6 open authoring, 3-2 operator

ID, 2-6, 3-21 profile, 3-20

organization hierarchy, 2-7, 3-22 outbound e-mail for correspondence, 10-13

P pattern inheritance, 4-3, 4-5 pc_work table, 5-5, 12-16 Pega Developer Network, 3 PegaDISTRIBUTION Manager, 12-13 Pega-ProCom agent, 12-11, 14-13 PegaRP

class creation sequence, 5-7 description, 1-22 work types, 2-4

PegaRULES database, 12-14 PegaRULES Process Analyzer, 14-6 PegaRULES Process Simulator, 14-6 PegaSample class group, 1-22 Pegasystems Support Network, 3 Pegasystems, contacting, B-1 Performance tool

activities, 9-21 basics of, 6-26 declarative rules, 6-25 guardrail, A-5

portal layout by job function, 3-4 customizing, 7-35 for a system architect, 3-4 how to determine, 3-4

portal rules, 7-35 portlets, 12-13 presentation layer, 7-6

primary flows, 8-8 privileges

defining for classes, 11-17 defining for rules, 11-28 list of standard, 11-16 naming conventions for, 11-18 production levels for, 11-18 setting conditionally, 11-19 setting explicitly, 11-19 testing for, 11-28 when to use, 11-10

process architects, job function, 1-16 Process Commander

Quick Win initial project, 1-2 system name, 3-20 when/why to use, 1-2

Process Commander Portal and portal rules, 7-35 for a system architect, 3-4 how to determine layout, 3-4 layouts by job function, 3-4

process costs, 14-17 Process Simulator, 14-6 production level, 11-18 products

class structure example, 5-7 deployment, 13-12 vs. applications, 2-20

project team members, 1-18 project methodology options, 1-8 project phases, 1-20 required skills, 1-17 standard job functions, 1-16

properties aliases, 6-32 designing, 6-6 list formats, 6-33, 7-32 naming conventions for, 6-4, 6-6 qualifiers, 6-31 reporting on custom, 12-15 standard categories, 6-3 working with, 6-12

pxCoveredCount property, 6-3


pxCreateDateTime property, 6-3 pxUrgencySLA property, 14-15 pxUrgencyWorkClass property, 14-14 pyCusLevel property, 14-16 pyCustomer property, 14-5 pyEventID property, 4-9 pyFlowActionCosts property, 14-17 pyFlowName property, 9-5, 9-28 pyID property, 5-2 pyRootCause property, 14-5 pySLAName property, 14-11 pyStatusCustomerSat property, 14-5 pyStatusWork property, 9-26 pyUrgencyWorkAdjust property, 14-15 pyUrgencyWorkParty property, 14-14 pyWorkPartyURI property, 4-23 pzInsKey property, 6-4

Q qualifiers

adding to a property, 6-32 creating, 6-32 for currency, 6-31 when to use, 6-31

quality features calculating cost of a process, 14-17 service levels, 14-10 statistical sampling, 14-17

quality, how to measure, 14-10 Quick Win, how to identify, 1-2

R repeating groups, 6-9 repeating page group, 4-23 Report wizard, 14-7 reports

creating custom, 14-7 customer-oriented, 14-9 guidelines for using, 14-5

requestor, 11-2 requirements analysis, 2-2 root causes, 14-5 Router shape, 9-4, 9-22

routing activities, list of standard, 9-24 rule harvesting, 9-4 rule resolution, 3-10 Rule-Access-Deny-Obj rule type, 11-26 Rule-Access-Privilege rule type, 11-5, 11-16 Rule-Access-Role-Name rule type, 11-5, 11-10, 11-15 Rule-Access-Role-Obj rule type, 11-5 Rule-Access-Setting rule type, 11-27 Rule-Access-When rule type, 11-19 Rule-Admin-Product rule type, 13-7 Rule-Admin-Product-Patch rule type, 13-7 Rule-Agent-Queue rule type, 9-2, 12-9 Rule-Connect- rule types, 12-7 Rule-Corr-Fragment rule type, 10-11 Rule-CorrType rule type, 10-11 Rule-Declare-DecisionTable rule type, 9-13 Rule-Declare-DecisionTree rule type, 9-13 Rule-Edit-Input rule type, 7-33 Rule-File-Binary rule type, 7-28 Rule-File-Text rule type, 7-28 Rule-HTML-Fragment rule type, 7-28 Rule-HTML-Harness rule type, 7-2 Rule-HTML-Property rule type, 7-30 Rule-HTML-Section rule type, 7-2 Rule-Obj-Activity rule type, 9-2 Rule-Obj-Class rule type, 3-19 Rule-Obj-Corr rule type, 10-7 Rule-Obj-FieldValue rule type, 7-32 Rule-Obj-Flow rule type, 9-2 Rule-Obj-FlowAction rule type, 8-21 Rule-Obj-HTML rule type, 7-28 Rule-Obj-ListView rule type, 14-8 Rule-Obj-MapValue rule type, 9-13 Rule-Obj-Model rule type, 6-12 Rule-Obj-Property rule type, 6-2 Rule-Obj-Property-Qualifier rule type, 6-31 Rule-Obj-ServiceLevel rule type, 14-11 Rule-Obj-SummaryView rule type, 14-8 Rule-Obj-WorkParties rule type, 5-11 Rule-Obj-XML rule type, 12-4 Rule-Parse-Delimited rule type, 12-4 Rule-Parse-Structured rule type, 12-4 Rule-Parse-XML rule type, 12-4 Rule-Portal rule type, 7-35


Rule-RuleSet-Name rule type, 3-15 Rule-RuleSet-Version rule type, 3-15 rules

availability of, 13-4 blocked, 13-5 common types of changes, 13-10 delegating, 13-9 Describe this Rule feature, 9-20 enterprise architecture for, 3-13 final, 13-5 granting access to, 11-15, 11-28 how access controls work with, 11-15 managing in production, 13-8 rule resolution. See rule resolution security for, 11-5, 11-28

Rules Inspector tool, 7-11 Rule-Service-Email rule type, 10-14 RuleSet list, 3-16, 11-8 RuleSet Versions

creating, 13-4 locking, 13-6

RuleSets deciding how many, 3-12 granting access to, 11-7 managing in production, 13-8 moving into production, 13-7 name and version, 3-10 naming conventions for, 3-11 purpose, 3-10 version numbering, 13-2

S Sample Work application, 1-22 Scan Station tool, 12-13 Screen Flow flow rules, 8-30 secondary flows, 8-8 security

access to applications (RuleSets), 11-7 access to rules, 11-5, 11-28 access to work/data objects (classes), 11-10 authentication, 11-3 authorization, 11-3 debugging, 11-23

for test vs. production systems, 11-19 guardrail for, A-5 how it works, 11-3 implementation checklist, 11-5 locking a RuleSet Version, 13-6 system administrator responsibilities, 11-4 testing for in activities, 11-28

Service Accelerator tool, 12-6 service levels

adjusting, 14-15 list of standard, 14-12 purpose, 14-12 using with urgency values, 14-13 when to use, 14-10 worklist indicators, 14-14

service-oriented architecture, 12-5 services

list of types, 12-5 purpose, 12-5 service-oriented architecture, 12-5 when to use, 2-13

Simple Object Access Protocol, 12-5, 12-7 simulation

of business processes, 14-6 of connectors, 6-29

single sign-on, 12-11 SmartBuild

advantages, 1-9 design approach, 1-4 iteration within, 1-21 project structure mapping, 1-20 Ten Guardrails for Success, A-1 what it is, 1-4 what it isn’t, 1-8

SmartFrames feature, 7-10 SmartShapes, 9-4 SnapStart

setting up, 12-12 when to use, 2-13

Spinoff shape, 8-25 Split-ForEach shape, 8-26 Split-Join shape, 8-26 SQL, 12-7


standard data objects access groups, 11-7

standard rules access roles, 11-10 harnesses, 7-12 HTML property rules, 7-30 privileges, 11-16 properties, 6-3 service levels, 14-12 urgency scale, 14-14

standard rules and data correspondence. See correspondence database table for work, 12-16 work parties, 4-24

statistical sampling configuring, 14-18 when to use, 14-10, 14-17

status, work object, 9-26 structured data, processing, 12-4 subflows, 8-8 summary view rules, 14-8 supplemental access roles, 11-11 system administrators

job function, 1-16 security responsibilities, 11-4

system architects job function, 1-16 standard portal layout, 3-4

system performance, 9-21

T Ten Guardrails for Success, A-1 testing for security in activities, 11-28 throughput of staff, 14-6 tickets, when to use, 9-15 time formats, 7-30 timeliness, 14-13 top-level classes, naming conventions for, 3-18

U Unified Modeling Language (UML), 1-4 urgency values

adjusting, 14-15 controlling calculation of, 14-14 standard scale, 14-14 using with service levels, 14-13

use cases, 1-4, A-2 user interface

options for, 7-4 separating the presentation layer, 7-6

users deploying applications to, 13-8 of the application, 2-6

Utility activities, 9-25 Utility shape, 8-27

V verification of correspondence, 10-6 version management, of RuleSets, 13-2 Visio stencil. See Microsoft Visio stencil

W Web Services Description Language, 12-8 WebSphere MQ messaging, 12-7 wizards, 3-2

directed inheritance, 13-13 Initial Setup, 3-5 Report, 14-7

Work- classes purpose, 4-2 vs. Data- classes, 4-6

work groups assignment routing, 9-24 definition, 3-22


work object behavior, 4-10 calculating the cost of resolving, 14-17 creating from another system, 12-12 creating from e-mail, 10-14 definition, 4-9 entering, 5-13 identifying types needed, 2-3 purpose, 4-7 reopening, 11-16 reviewing, 5-15 when to use, 4-10 working with status of, 9-27

work object ID choosing, 4-20 purpose, 4-3 setting prefix and suffix, 6-16

work parties list of standard, 4-24 purpose, 4-23 when to use, 2-12

work pools, defining, 4-18 work status

naming conventions, 9-26 standard values, 9-26

workbaskets creating, 9-23 naming conventions for, 9-23 vs. worklists, 9-22

worklists service level indicators, 14-14 vs. workbaskets, 9-22

X XML

clipboard, 6-2 parsing, 12-4 processing XML data, 12-4 rules, 12-4

Y YourCo

class structure, 4-5 description, 1-22

bootcamp

Documents

dashboard

designated

process commander

pegarules

physical database

process commander

additional

unified modeling