Beruflich Dokumente
Kultur Dokumente
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
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
The benefits to your business are agility for growth, productivity, and compliance.
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.
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-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.
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, dont 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-7
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)
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.
1-11
HTML-based forms, tailored for your work One or more flows, created using Microsoft Visio Activities and decision rules
Flow actions
Description Communication channels (such as e-mail) to and from your application to inform other people or systems automatically about work status. Requests from external systems for information and processing performed by your application Requests from your application sent to external systems (or external databases) for information or processing.
1-13
Description Business structure of your organization, including application developers and users. People in your organization who build, use, or evolve any Process Commander application. Groups of people who perform similar job functions in applications. Access groups control portal layout and application access. Designated process responsibility within a specific application. Access roles refine application access by operation and class. Identifies the workweek and business holidays for a year,
1-15
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.
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 Process architect Preferred Experience System administrator Business process flowcharting User interface design Business logic definition Some familiarity with scripting or application macro tools (HTML and JavaScript preferred) Data modeling and relational databases Object-oriented and modular design Moderate level of programming expertise (Java preferred) System connectivity and interfaces Hardware and operating system administration for your platform User and network management tools Database management tools for your database platform
System architect
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.
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.
Test Business users Business managers Process architect Process architect System administrator Business analyst Process architect
Select several business users to use the functions of all workflows (Step 13). Move the completed application to your production environment and make it available to users (Step 13). 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).
1-21
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.
1-23
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
With these guidelines in mind, you can begin analyzing the requirements for your solution.
2-3
Your objective is to establish the basic purpose and structure of your applications work classes, not a detailed design. Plan to spend no more than several hours on this task, even for complex applications. At this stage, dont 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.
2-4
PegaRP Example
Figure 2-1 describes the work that the PegaRP example application supports. What You Need to Define Purpose of the work Completed units of work that can be represented as work objects As Defined for PegaRP Record, track, and manage the effort associated with developing and supporting a Process Commander application or product. Software tasks to perform (such as a support request). Projects that group related tasks.
Helpful Hints
If youre 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, dont 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.
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 dont 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.
2-6
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 dont 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.
2-7
2-8
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 doesnt 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 isnt 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
2-9
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.
2-10
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 Business user Business manager Description Anyone who enters new work in PegaRP Managers who assign work and monitor progress in PegaRP As Performed in PegaRP (Function and People) Application users Design and development staff Design manager Development manager Documentation manager QE manager Need Custom Access Role? No
2-11
Description Business analysts who perform work (business rule changes) in PegaRP Application developers who perform work (system rule changes) in PegaRP System administrators who perform work (system administration tasks) in PegaRP
As Performed in PegaRP (Function and People) Design and development staff with an assigned worklist Development staff with an assigned worklist Operations staff with an assigned worklist
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.
2-12
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 Person Operator As Defined for PegaRP An external customer for whom someone originates a work object in PegaRP. An employee who is interested in the work object resolution, but is not responsible for performing the work.
2-13
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 dont 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 doesnt require access to or from other systems. All supporting data are recorded directly in the application.
2-14
2-15
2-16
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 Geography Considerations Currency Where are you primarily building and maintaining the solution? Where is the work performed? If users interact with external customers, where are they located? In what language(s) do the participants primarily perform work? If users interact with external customers, what languages do they prefer to speak? 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)?
Language
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 doesnt 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).
2-17
2-18
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.
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.
2-20
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.
2-21
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
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 Systems SVG Viewer, a free plug-in available from www.adobe.com.
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).
3-4
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.
3-5
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.
3-6
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.
Note: Dont 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.
3-8
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 dont 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.
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.
3-10
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.
Planning RuleSets
3-11
Figure 3-5 describes the name and version format for a RuleSet.
3-12
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).
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.
3-14
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.
3-15
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.
3-16
3-17
3-18
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
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.
3-20
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.
3-21
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.
3-22
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).
3-23
Commander job function) to get you started. They are instances of the DataAdmin-Operator-AccessGroup class, which defines the portal layout and application access for a group of people that perform the same job function.
3-24
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.
Make sure that you have assigned each standard Process Commander job function to someone on your team.
3-25
3-26
You work with the following rule types and data instances in SmartBuild Step 3.
Explorer Category
SysAdmin
Create a top-level class Data Modify the system name (optional) Set up the organization hierarchy and grant access to RuleSets
SysAdmin
SysAdmin Organization
Create access groups and set your default RuleSet for changes Create operator IDs and assign access groups
Security
Data-Admin-Operator-ID
Organization
3-27
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.
Dont rush through this step. Its 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.
4-2
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.
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-DEFABC-DEF ABCABC 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-.
4-4
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.
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.
4-5
Figure 4-2 illustrates a typical class structure for this scenario. The product vendor uses YourCoProduct- for cross-product features and YourCoProduct-ProductXand -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-) ASPCustomer3ASPCustomer3-ProductX (pattern and YourCoProduct-ProductX-) ASPCustomer3-ProductY (pattern and YourCoProduct-ProductY-)
4-6
Consider the questions in Figure 4-3 as you design your class structure. Object Type Work Typical Indicators 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? 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?
Data
4-7
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.
4-8
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.
4-9
The standard property Work-.pyEventID can link associated related work objects if you dont 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 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. 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.
Consider Alternatives for Coordinating processing of two or more work objects (use covers). Simultaneously reviewing or analyzing work objects as a group (use folders). 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).
Cover
4-10
Data Structure Features and Behaviors 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
Consider Alternatives for 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).
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.
4-11
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: # of Covered Objects # of Instances Per Day
Work Type
Description
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.
4-12
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 (MyCoMyDiv-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-MyDivMyApp-Type2. The concrete class MyCo-MyDiv-MyApp corresponds to a class group holding all four work types in a single work pool.
4-13
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.
4-14
2.
List the primary groups of coordinated work in your application, if any. These items are your cover and folder classes. Identify the inheritance for each class, including the appropriate Process Commander data structure. Document your design as you go.
3.
4.
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 youve 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).
4-15
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 YourCoFinanceDiv-LoanRequest-Mortgage- and YourCo-FinanceDiv-LoanRequestAuto-.
4-16
and business scenarios to differentiate between classes. Consider how classes relate to each other what they have in common and how they differ. If youre 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.
4-17
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.
4-18
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.
Helpful Hints
Consider using bold type to make class groups easily visible in your class structure outline or diagram. If youre 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.
4-20
Note: If the standard approach doesnt 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. Wellselected 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.
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).
4-22
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 Work objects Covers Folders Employee Orders EMPPO-# EMPCV-# EMPGP-# Customer Orders CUSPO-# CUSCV-# 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.
4-23
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.
4-24
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.
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.
4-25
Figure 4-10 suggests a format for defining work parties. Role Lender DeptManager ExtCustomer Type Company Staff Person Process Commander Class Data-Party-Com Data-Party-Operator Data-Party-Person Data Source Banking application Process Commander 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).
4-26
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-PartyCom 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.
4-27
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.
4-28
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 Description Repeating Group Embed data as a repeating group in the work object. Sometimes may require a Work-, Data-, or Embedclass. Yes always, even if not requested. No additional database reads, but can slow displays. Attachment Attach data to the work object. Yes inherits from Data-WorkAttachclass. No on request only. Link Create a standalone class for the data, with a directional pointer (or link) that references it. Yes inherits from LinkAttachment class. No on request only.
4-29
Attachment No automatically created based on the work object key. Yes permanently attached to a single work object. Must duplicate to associate with more than one work object. Viewed occasionally. Relatively small. Associated with only a few objects.
Link Yes explicitly create the key in your application. Simplifies information sharing between objects. No multiple work objects can point to or from the data without duplication.
Yes associated only with the work object where embedded. Must duplicate to associate with more than one work object. Viewed frequently. Relatively small (<2,000 bytes). A manageable number of records (dozens or fewer).
Viewed occasionally. Divided into many subgroups. Relatively large. Associated with many other objects.
4-30
4-31
Understand alternatives for presenting repeating groups Define a class that inherits from the standard data class (instances stored in database) Define a class that inherits from the standard embedded object class (instances not stored in database)
4-32
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 Dataclasses, 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
5-3
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.
5-4
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.
5-5
4.
5. 6.
7.
5-6
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 youre 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.)
5-7
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 PegaRPWork- 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.
5-8
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.
5-9
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 cant 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.
5-10
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.
5-12
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.
5-13
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.
5-14
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.
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. 4. Click Create. You have created the first work object in your application. Dont 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. Repeat for other work types.
5.
5-16
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.
5-17
Task Rules Create classes that inherit from the standard Work- base class Create a set of work parties Create one or more basic flows based on NewWork Data Review or update a class group (created automatically) that establishes a work pool Map a class group to a database table if necessary Grant access to a work pool
Rule-Obj-Class
SysAdmin
Rule-Obj-WorkParties Rule-Obj-Flow
Process Process
Data-Admin-DB-ClassGroup
SysAdmin
SysAdmin Security
Create classes that inherit from the standard Data- base class Create classes that inherit from the standard Data-Partywork party class
SysAdmin
Rule-Obj-Class
SysAdmin
5-18
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.
6-2
6-3
6-4
Description Identify who is performing the work, including name and business affiliation (such as pyOrigUserID and pyOrigUserDivision). Capture the list and identity of associated parties for an object (such as pyCustomer and pyWorkParty). Measure how well work is being performed, including service levels (such as pxUrgencyWork and pyElapsedPastDeadline).
py pz
Figure 6-2. Standard Property Prefixes By definition, you cant 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,
6-5
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.
6-6
6-7
You cant 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. Decide how to document property requirements. The following table or spreadsheet format may be helpful:
2.
Used in Class Parent class 1 Child class 2 Child class 1 Child class 3 Child class 4 Use a Standard Property?
Property Description
Property Name
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. For each property, mark the column for each class that uses the property.
5.
6-8
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. Dont 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.
6-9
2.
Property Name
Embedded Properties
Applies To Class
3.
Enter the repeating groups you need to add as row titles, including both the description and name.
4.
Mode (whether it is a list or a group). List of repeating properties. Class derived from Data- or Embed- that defines the repeating group.
6-10
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.
6-11
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)
6-12
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.
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
6-14
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.
6-15
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.
6-16
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 applications sequence of work object ID values may contain gaps. This may be confusing, but is not an obstacle to processing. A users 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.
6-17
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.
6-18
FeeLoanOrigination
MaxLoanAmount
6-19
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 doesnt 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.
6-20
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).
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.
6-21
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.
6-22
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.
6-23
6-24
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.
6-25
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.
6-26
6-27
If your application needs any custom classes that inherit from the Data- base, create them and their properties now.
6-28
For more information about integration services, see Step 12: Configuring System Interfaces and the PegaRULES Database.
6-29
2.
3. 4.
5.
6.
6-30
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.
6-31
6-32
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.
6-33
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.
6-34
6-35
Task Rules Create a property Create a property qualifier Control property appearance in forms (referenced in Rule-Obj-Property) Create and maintain a list of valid values for a scalar string property (referenced in Rule-Obj-Property) Convert user input into required internal format (referenced in Rule-Obj-Property) Create a model for work or data Create declarative rules to automatically reevaluate a property value
Rule Type
Rule-Obj-Property Rule-Obj-Property-Qualifier Rule-HTML-Property Rule-Obj-FieldValue Rule-Edit-Input Rule-Obj-Model Rule-Declare-Constraints Rule-Declare-Expressions Rule-Declare-OnChange Rule-Declare-Trigger
Data Create a class that inherits from the Data- base class Create a class that inherits from the Embed- base class Rule-Obj-Class Rule-Obj-Class SysAdmin SysAdmin
6-36
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
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.
7-3
Your work types, derived from Work-Object-, Work-Cover-, or Work-Folderinherit 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.)
7-4
SnapStart
JSR 168
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.
7-6
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.
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.
If you prefer, your application can present section rules as tabs ( than horizontal areas ( ).
7-8
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.
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.
7-10
Harness rules that use the SmartFrames capability (introduced with Version 4.2 SP2) provide a high-fidelity preview directly on the Layout tab. A wireframe preview mode identifies the names of rules referenced in this rule (Figure 7-2).
7-11
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.
7-12
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.
7-13
WorkObjectInfo
Flows
7-14
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.
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
7-15
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.)
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.
7-16
7-17
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.
7-18
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.
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>
7-20
7-21
If you dont 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.
7-22
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.
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 within a cell of a table. Drag and drop the or the 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. control for a layout (a grid of rows and columns) control to place a section rule on the Layout tab, or
values from a Page List repeating group). Every section contains one or more
7-23
), 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.
7-24
7-25
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-CustServiceLoan inherits from Work- so it inherits the Work- harness rules, not WorkCover- or Work-Folder- harness rules. 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. 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)
3.
4.
7-26
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. 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.
6.
7-27
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.
7-28
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.
These rule types are in the Technical category in the Explorer tools. Both are class-independent and can be shared across applications.
7-29
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., YourCoLoanRequest-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.
7-30
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.
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.
7-31
7-32
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.
7-33
You cant update an existing field value rule. Instead, delete the rule with the value you dont want and create a new rule. The pyStatusWork property references field value rules, allowing you to create additional status values.
7-34
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.
7-35
content of an individual attachment. Attachment categories are defined through Field Value rules.
7-36
Task Rules Create or tailor harnesses or sections Create or tailor a class-specific HTML stream Create or tailor an HTML fragment that can be shared across classes Hold an image to include in a harness or section Hold a static text file, such as an HTML style sheet Use, create, or tailor property formats Define input formatting for a property Define portal layout and contents Create or tailor text value lists for a property Create a class for custom attachments that inherits from the standard Data-WorkAttach class, if needed
Rule Type
7-37
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.
8-2
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 users 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.
8-3
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.
2.
3.
8-4
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. Complete the tasks in this chapter to create flow shells for these three work types. Complete the tasks in the next chapter (Step 9) to create the flow rules in Process Commander. Repeat Steps 2 and 3 for the remaining work types.
2.
3.
4.
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.
8-5
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.
8-6
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 channelindependent. 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.)
8-7
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 companys 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.
8-8
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.
8-9
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.
8-10
Assignment
11 12 1 2 10 9 3 8 4 7 6 5
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. 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. 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. End of a flow.
Connector
Flow
FlowEnd
End
8-11
Shape Processing
Description 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.
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. 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. Drag a single FlowEnd shape to the bottom of the page. This reinforces a natural tendency to read a flow from top to bottom.
2.
3.
8-12
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.
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.
8-13
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-FinanceAccount-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.
8-14
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.
8-15
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.
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:
8-16
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 dont miss important processes.
8-17
8-18
8-19
8-20
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.
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, youll 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.
8-22
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.
8-23
Shape Assignment
11 12 1 2 10 9 3 8 4 7 6 5
Description 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 its 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.
8-24
Shape Decision
Description 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.
8-25
Description 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 flows 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. 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.
Integrator
8-26
Shape Split-ForEach
Description 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.
8-27
Shape Utility
Description 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.
8-28
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 dont 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. 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.
5.
8-29
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.
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.
8-30
8-31
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
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.
9-4
Notify
Note: See Step 8 for a complete list and description of other 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.
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.
9-6
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.
9-7
2.
3.
4.
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.
9-8
9-9
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.)
9-10
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.
9-11
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.
9-12
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
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.
9-14
9-15
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 tickets 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 Work-Cover.AllCoveredResolved Work-.Withdraw Work-.StatusRevolved Figure 9-8. Standard Tickets Description Set automatically as soon as all work objects within the cover have been resolved. Cancel the work object. Set in the Withdraw flow action. Set when the work object status changes to Resolved.
9-16
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 Attach Change Engage Notify Transfer Purpose Add an attachment to the work object Change work object and/or assignment property values Initiate a new flow to involve another party Generate correspondence Change responsibility for assignment Example Work-.AttachAFile Work-.ChangeOwnerOrg Work-.EngageManager Work-.NotifyExternal Work-. TransferToManager
Note: For clarity and ease of maintenance, adopt a similar naming convention
when naming your custom flow action rules.
9-17
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.
9-18
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.
9-19
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 Builtfor-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.
9-20
Purpose Perform processing that is executed by a Declare Trigger rule. Perform automated processing that requires no user input. Reference in the Utility shape. Validate user input.
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.
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).
9-21
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.
9-22
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.
9-23
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 WorkToWorkbasket. 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, ProductWorkbasket@YourCompany.com can identify the workbasket to which product-related issues are routed.
9-24
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.
9-25
9-26
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.
9-27
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.
9-28
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.
9-29
Task Rules Create activities to automate processing in a flow Create flow rules Create flow actions to add user control options to a flow Create decision rules that return values based on supplied parameters Create tickets to add event-driven processing to a flow Define basic field validation for HTML forms Create when conditions to define the appropriate path for a work object in a flow Data Understand how Process Commander uses workbaskets for assigning work Understand how Process Commander uses worklists for assigning work Create and use workbaskets for routing work
9-30
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
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
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.
10-4
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.
10-5
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.
10-6
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.
10-7
10-8
Work-CorrSend
10-9
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.
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).
10-10
10-11
10-12
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.
10-13
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.
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.
10-14
10-15
Process
Tailor or create flows that create correspondence Tailor or create activities that support correspondence Tailor or create flow actions that support correspondence Use an agent to process inbound e-mail Configure Directed Web Access for external users Data Review Data-Corr- classes for correspondence examples Configure inbound and outbound e-mail
Data-Corr-* Data-Email-Account
N/A SysAdmin
10-16
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
11-3
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?
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.
11-4
11-5
2.
6.
Reference the new access roles in appropriate access groups (data instances of type Data-Admin-Operator-AccessGroup). Optionally as needed, define and create privileges (rules of type Rule-AccessPrivilege) to grant the authority to run specific restricted rules. Reference the new privileges in the appropriate access roles.
7. 8.
11-6
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.
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.
11-7
11-8
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.
11-10
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.
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 PegaRP:Default PegaRP:ITStaff PegaRP:ITManager Figure 11-2. PegaRP Access Roles Purpose Basic role for all PegaRP users Supplemental role for IT staff Supplemental role for IT managers
11-12
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 managementrestricted 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.
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.
11-13
4.
Class
PegaRP-Work-ObjectPegaRP-Work-ProjectPegaRP-Work-ProjectResearchFigure 11-3. PegaRP Work Classes and Access Roles Create and modify work objects
11-14
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-WorkProject- class and to the following child classes:
PegaRP-Work-Project-EnhancementPegaRP-Work-Project-InquiryPegaRP-Work-Project-Problem-
However, the PegaRP:Default access role does not apply to the PegaRP-WorkProject-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.
11-15
For instances of the class Open Instances Modify Instances Delete Instances Search Instances Execute Activities Open an instance of the class. Modify (or save) an instance of the class. Delete an instance of the class. Read and search through instances of the class. Execute activities that apply to the class.
For Rules that apply to the class Open Rules Modify Rules Delete Rules Open a rule that applies to the class. Modify (or save) a rule that applies to the class. 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.
11-16
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 Work-.AddFlow Work-.AllFlowActions Work-.AllFlows Work-.Perform Work-.PerformBulk Work-.Reopen Work-.Update Action Allowed Start a new flow. Select any standard flow action. Start all standard flows. Perform assignments on worklists other than your own. Apply a flow action repeatedly to each assignment on a list. Reopen a previously resolved work object. 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.
11-17
Class
PegaRP-Work-Object-
PegaRP-Work-Project-
PegaRP-Work-ProjectResearchFigure 11-6. Defining Access Controls and Privileges for Work Classes
11-18
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.
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.
11-19
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 dont 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.
11-20
PegaRP-Work-Object-
PegaRP-Work-Project-
11-21
PegaRP-Work-ObjectPegaRP-Work-ProjectPegaRP-Work-Project-ResearchPegaRP-DataPegaRP-Data-ProductPegaRP-Data-ProductAreaPegaRP-Data-RuleSet
11-22
The column headings represent the eight access controls (Figure 11-10). Abbreviation O M D S OR MR DR E Description Open instances of this class. Modify (or save) instances of this class. Delete instances of this class. Search through instances of this class. Open rules that apply to this class. Modify (or save) rules that apply to this class. Delete rules that apply to this class. Execute activities that apply to this class.
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.
11-23
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 displayonly mode rather than update mode. The standard functions HaveRole( ) and HavePrivilege( ), described later in this chapter, are useful for such checking.
11-24
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.
11-26
11-27
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 users profile grants access to mirrored access object and access deny rules, the access deny rule takes precedence.
11-28
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.
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.
11-29
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 Field Name Operation Value Value Lib(Pega-RULES:Default).HavePrivilege (this,privilegename,privilegeclass,null) Equal 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.
11-30
Technical Decision
11-31
Explorer Category
11-32
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
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.
12-3
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.
12-4
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.
The Import Rules and Export Rules accelerators help you create many of these rules.
12-5
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.
12-6
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.
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.
12-7
12-8
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.
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.
12-9
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.
12-10
Rule-Obj-Activity
12-11
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 cant 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.
12-12
12-13
12-14
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.
12-15
12-16
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.
12-17
Process structured text files Create custom Java functions for use in activities, often needed for interfacerelated data manipulation Create declarative indexes for automatic table reindexing Data Configure a service package to bundle the components for a service Identify source systems, queues, and files for services, where needed Identify destination systems for connectors, where needed
SysAdmin
12-18
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
13-2
13-3
13-4
13-5
No/Draft
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.
13-6
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.
13-7
13-8
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).
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.
13-10
13-11
13-12
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, dont 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.
13-13
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.
13-14
Create access groups and set your default RuleSet for changes Create operator IDs and assign access groups
Security Organization
13-15
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.
14-2
14-3
14-4
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.
14-5
Analyze Process Quality (Effort by Customer) Custom reports based on pyCustomer and pyStatusCustomerSat properties Analyze Process Performance Custom reports based on pyRootCause
14-6
14-7
14-8
The Report wizard creates two types rules of rules. List view reports (Rule-ObjListView rule type) present one row for each selected instance. Summary view reports (Rule-Obj-SummaryView rule type) may include charts, subtotals, and drilldown sections. Once either rule is created with the Report wizard, a system architect can refine the presentation, sort order, selection or columns as desired.
14-9
14-10
You can incorporate these features into your application by changing a few rules, as described in the following sections.
14-11
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 dont 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.
14-12
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.
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.
14-13
Service level
14-14
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.
14-15
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.
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
14-16
business process on an ongoing basis. Watch for other conditions that might warrant adjusting the service level and/or urgency.
14-17
14-18
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. Add a Spin-off shape for the randomly selected work objects. Connectors utility to the spin-off flow (Figure 14-9).
2. 3.
Figure 14-9. Sample Flow with Statistical Sampling 4. Create the spin-off flow rule to handle the follow-up processing.
14-19
14-20
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).
A-2
#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.
A-3
Follow this guardrail #3 Dont 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.
A-4
Follow this guardrail #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 assignments 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.
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: Dont 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).
A-6
2.
Figure A-1. Application Name 3. 4. Click the Manage Rules bar to enter the Manage Rules workspace. Locate the Application Overview area. Click the Preflight button (Figure A-2 ).
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).
A-8
7.
For each noncompliant rule, consider your rationale and justification. To improve the degree of compliance, update rules to eliminate noncompliant elements. Click any row to open the corresponding rule.
8.
For more information about our company and products, visit our Web site at www.pega.com.
B-2
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 worldclass 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
B-3
Send faxes to: 617-374-9620, attention Technical Communications. Send e-mail to: docteam@pega.com.
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
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
I2
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
I-3
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
I4
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
I-5
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
I6
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
I-7
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
I8
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 isnt, 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
I-9
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
I10
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