SAE-2

1. Effective Application Development with PRPC

1. Introduction

2. Building blocks of PRPC application

i. Case types define what the application will do

ii. Processes will define how the work defined for case or sub-case is completed

iii. Processes are broken down into:

1. Assignments that users need to complete

2. Business logic that determines what assignment should be given to user

iv. Rules defines and configures applications. Rules are the building blocks of application

v. Rules has different categories:

1. Data Model

2. UI

3. Decision

4. Process

vi. A class is a container for rules which defines the applicability (scope) of the rule. For e.g., SAE-HRServices-Data is a class.

vii. An application is a collection of rules

3. Managing building blocks of PRPC Application

i. Ruleset is a deployment unit for a set or group of rules. It helps to identify, store and manage the rules.

ii. Ruleset versions consists of 3 two-digit numbers. xx-yy-zz where xx = Major version, yy = Minor version and zz = Patch version

iii. Inheritence: Application contains the most specialized version of reusable rules

iv. Rule Resolution: It is the process of determining appropriate rule to use when a process is run. The rule is selected based on the below factors:

1. Purpose: Look for name and type of the rule and return if matches (e.g. Approve (Name) UI (Action))

2. Availability: usability of the rule. If in development, does not return

3. Applicability: Look for scope or if intended for the application

4. Permission: Security permission to use the rule

5. More…… (Refer to PDN) (This means there are more factors while resolving a rule using rule resolution process)

v. PRPC uses a dual-inheritance model while resolving a rule.

1. Pattern inheritance: Optional and involves parsing of class names. Enables to reuse Application classes

2. Directed inheritance:

a. Specified in the rule form which defines related classes

b. Allows to access rules from PRPC standard classes such as Work-, Work-Cover, and @baseclass

c. Is meant to reuse the objects (rules) provided by standard packaged classes.

vi. Application explorer is the resource used to view the structure of the classes and rules

vii. Rulesets and class inheritance enables to build reusable applications

4. Guided Application Development using Guardrails

i. It is about best practices and guidelines about situations that contains risky conditions or that might result in an undesirable outcome

ii. Guardrail warning = Severity level + Warning type

1. Severity levels:

a. Severe: Data integrity related issues. E.g., Unreachable action in Data Transform

b. Moderate: Impacts maintenance. Property used in a report is not optimized for reporting

c. Caution: Least severity level. E.g., Draft mode of process,

2. Warning Type:

a. Data Integrity

b. Maintainability

c. Performance

2. Designing Enterprise Applications Using Case Management

1. Case Management Design

i. Cases:

1. Have a life cycle

2. It is a business transaction to resolve. It is what we do

3. Have at least one process

4. Contains: Actors, Tasks, Data, Status and History, Resolution

5. Provides a more holistic view of a business transaction

ii. Processes:

1. The path a case may take. It defines how we do

2. It is a way of ensuring a business transaction can be adapted to frequently changing business conditions

2. Stage based case designing

i. Case type:

1. Defines tasks and decisions needed to complete a business transaction

2. It is a collection of artifacts including data elements, UI Screens, processes and sub-cases, decisions, integrations

ii. Stage:

1. Is a 1st level grouping for related tasks

2. Represents:

a. Transfer of case from one authority to another

b. From one part of organization to another

c. Significant change in the status of the case

3. Best practice is to limit the count to 7 +/- 2

4. Alternate stages:

a. Special circumstances or exceptions

b. Must be manually called

c. Cannot be sequenced

5. Resolution Stages:

a. Stage where case can be resolved

b. There can be more than one resolution state

c. No automatic status changes

iii. Exercise

iv. Effective Case decomposition

1. Steps:

a. A distinct action taken to help resolve a case

b. Should have a goal that can be expressed as a singular outcome

c. Rule of seven: No of steps in a stage, +/- 2

d. Single step: Single action by single user. Can be only a UI screen. No logic

e. Multi-step:

i. Any combination of actions represented by different shapes depending on action

ii. Involves multiple users

iii. Logic between shapes

f. Case:

i. Automated single steps

ii. Performed by PRPC

iii. Have their own life cycle, but are still related to parent case

iv. Focus on subset of data transferred from main case

v. Usually involves different parties than the main case

vi. Executed outside the context of main case

v. Effective Process decomposition

1. Role of a system architect during process decomposition is:

a. Focus on areas of flows that may be reusable

b. Look for manual steps that can be automated and

c. Keep an eye on efficiency

2. The flow diagram should provide a view into the process that is clearly and easily communicated in 5 minutes or less

3. Use shapes for their intended purpose

4. Consider limiting the number of shapes on any given flow rule to 15 or less

5. Limit the number of connectors emanating from assignments to no more than 5

6. Limit the number of results emanating from a decision shape to five or less

vi. Guardrails for Case Management design

1. Most common guardrail warning encountered during case design is “Caution-Best practice”

3. Creating an Effective Data Model

1. Best Practices for Designing a Data Model

i. Two different types of data in an application:

1. Flow Data:

a. Info needed by application to determine what to perform and who to perform

b. Can be gathered directly from participants but can also be retrieved from external sources including: LDAP, Databases and Web Services.

2. Business Data:

i. Provides context for a given task for a given participant

ii. Data required from 3 different vantage points (User or Position point perspective):

1. Process participant: Task level view of data. Immediate perspective of data

2. Process Analyst: Data needed for reporting, metrics and analysis. Use historical metrics to improve process

3. Process Designer: Implementation perspective of data. Define efficient data structure for development. Plan for future data changes and maintenance

2. Best Practices for Managing Data

i. Data model consists of data objects, attributes and association between the data objects

ii. Data model is defined outside PRPC and is a collective effort of entire organization.

iii. Some reserved words for data classes: Top, Parent, Local

3. Best Practices for Managing Reference Data

i. Data tables are used to manage reference data

ii. Data table is a simple structure which is used to store reference data outside of application

iii. Values of a data table are maintained manually in Designer Studio

iv. It is strongly recommended to use data tables for small sets of data

v. Data table is recommended to use when there is non-volatile data that will only change periodically

vi. Various options to access data external to application

1. Access Database: Advantage is data will be accurate. But performance will be impacted

2. Access Data table: Performance will improve but any data change required, it should be done manually

3. This is where Data page comes into picture!

a. data page loads the data into memory and stores it on the clipboard, it is then accessible to the application.

b. Improves performance, but the possibility of accessing stale data will be high.

c. You can use various refresh strategies to refresh data:

i. Refresh if Older Than: Refreshes only on next access only when the data is not accessed for the period defined

ii. Do not Reload When:

1. Applicable only when the page scope is set to: Thread or Requestor

2. Conditional. IF false: Loads data. If True: No refresh

iii. Refresh once per interaction:

1. Highly accurate data will be available

2. Applicable only when the page scope is set to: Thread or Requestor

d. 3 important aspects to data pages includes:

i. How often data is refreshed

ii. How long does the data remains in memory and

iii. How to get data into data pages

e. 3 scopes for data pages:

i. Node: Shared across all requestors of that page for that node

ii. Thread: Maintained in each thread.

1. If a request has multiple threads, each thread will have its own data page.

iii. Requestor:

1. Data page is shared across all the threads for a given requestor

4. Sharing data across cases and subcases

i. Uses data propagation feature. Configurable at main case details tab level

ii. Different ways to propagate data:

1. Map Property values and

2. Data transform – Useful when conditional processing is required

iii. Data changes at main case level will not be updated in child case

5. Guardrails for data modeling

i. Data modeling goals:

1. Reusable

2. Should be intuitive to architects and business users

3. Define classes and properties for objects and work being represented

ii. Working with data tables:

1. Always consider performance vs accuracy of data

4. Integrating with external data sources

1. Integrating with external database

2. Guardrails for Integrating with external data source

5. Creating engaging user experience

i. Designing UI for reuse and maintainability

1. By creating and using reusable UI components, we can build UIs that are always consistent in structure and layout and an application which is scalable and extensible.

2. Reusability guidelines:

a. Meaningful and relevant naming conventions

b. Short description should indicate what the component does or contains

c. Always use a new ruleset for different versions of same component. Never stamp versions into the short description

d. History tab. This is where people would look when they need more descriptive info as to what a rule does

e. Well documented rules provides developers a clear description of how and why to use a rule

3. Applies To

a. It determines the scope of reusability for a given rule

b. If section contains data elements relevant to more than one case type, then apply section to ORG-APP-Work

c. Flow actions can be applied to Work class

ii. Building assignment focused (Intent-driven) UIs

1. 3 core components that make up UIs in Pega application:

a. Case Manager dashboard: Controls and displays a workspace for business users

b. Designer Studio:

i. Design and modify case management applications.

ii. Used by Business and System architects.

c. Work forms:

i. Used to create, update or resolve cases

ii. 3 core components of work forms:

1. Sections:

a. Contains content for a portion of work item

2. Flow actions:

a. It defines a specific action a user can take and

b. Presents the relevant portion of work form – a section to the end user for each specific action

3. Harness:

a. Sets the context for processing an action. It defines the behavior of a work form

b. 4 types:

i. New: Used when creating a case

ii. Perform: Allows a user to select a flow action to complete an assignment

iii. Review: Presents a work form in read-only mode

iv. Confirm: Presents a pre-defined confirmation screen to the user

c. Tightly integrated with the shapes in a flow diagram and are set by default

iii. Best Practices for designing the UIs

1. User experience should focus on 3 main areas:

a. Who is using the system

b. What are users trying to accomplish through the system

c. What information do users need

2. Usability is a key attribute to make an application useful

3. Key principles of UI Design and usability

a. Consistency:

i. Set standards and define conventions: actions, messages, icons etc... Should be consistent

ii. Use words, phrases and concepts familiar to end users

iii. Use words rather than icons

iv. Make icons meaningful

b. Visibility of system standards

c. Recognition rather than recall

d. Error prevention

iv. Using advanced UI controls

1. A drop down can be sourced in 4 different ways:

a. As defined on property. This has 5 different ways of definition:

b. Data page

c. Clip board page

2. Drop down list could be grouped by a property

3. 3 different load behaviors for drop downs:

a. When screen renders

b. Defer until user hovers

c. Defer load until all the other UI elements are loaded

4. Auto complete:

a. Possible to categorize search results

b. Possibility to define max results

c. Possibility to specify to enter max characters to search

d. Highlight match to highlight the search string

e. Pattern matching (start or end of string)

5. Radio buttons:

a. Possible to configure to display specific number of items in each column or row

6. Modal dialog

a. A form to be filled-in or statement to be acknowledged (e.g., License agreement) that pops up on top of an application UI

b. Not possible to continue until a choice is made

7. Overlay:

a. Can be dismissed by user by clicking on outside overlay area

b. Commonly used to show detailed information

v. Sourcing list controls

1. Several ways to source data for selectable lists:

a. Local list as defined on property?

b. Data pages by maintaining the list in database tables

vi. Building dynamic UIs

1. Dynamic UIs provides:

a. More functionality without overwhelming the end user

b. Respond in real-time to end user

c. Avoid full page refresh

d. Increase performance

e. Compelling and modern user experience

2. Configured using property and user action based events

3. Hide and disabling components:

a. 5 options for visibility:

i. Hide if it is blank or zero or define a condition:

1. IF an expression is defined which can be run on client side:

a. THEN the “Run Visiblity Condition on client” check box is shown

2. Use WHEN condition

3. Server side condition with refresh section strategy

vii. Validating user input

1. 2 types of validations: Server and Client

2. Most common client side validation is Form controls

a. Option to configure not to enter text while using date control

b. Option to limit the length while using Text control (Min and Max)

3. Another type is Data type Validation (e.g., Date, TrueFalse, Decimal etc.)

4. Validate Rule:

a. Test property values against specified criteria

b. E.g., FICO rule

viii. Guardrails for engaging user experience

1. 2 common guardrail warning with UI

a. Not Auto-Generated: Appears when auto-generated HTML checkbox on the HTML tab of a section or control is selected

b. Adding custom inline styles to individual cells in a layout which increases maintenance difficulties

6. Enforcing Business Policies

i. Designing Business rules for Business users

1. Recording business policies in rules provides an application an degree of modularity and transparency that can simplify maintenance

2. The rules which are affected most likely with constantly changing business policies are:

a. Service levels

b. When

c. Decision tables

d. Constraint

3. Other candidates: Flow, Map value, decision tree and declare expressions

ii. Enforcing Business policies through service levels

1. SLAs: Used to ensure that the work is completed within the expected time intervals

2. 3 Milestones:

a. Goal: How long it should take. Measured from the time of assignment was started

b. Deadline: How long it may take. Measured from the time of assignment was started

c. Past deadline:

i. How long after the deadline before taking additional action.

ii. Can be set to repeat it’s countdown cycle a specified number of times

d. Options available to configure when the service level clock should start include:

i. Immediately

ii. Determined by some property

iii. Some defined interval from start of assignment

e. Service level rule defined for a case type is named as “pyCaseTypeDefault”

iii. Notifying users from within a Process

1. Timely, clear communication keeps participants engaged in the resolution of a case and can help keep the process working efficiently and effectively

2. Fundamentals of communications:

a. Who – Work Parties

i. Work parties: Whom to communicate with (Recipients)

1. Originator – The person who submits case

2. Manager – Person who might be responsible for approvals and oversight

3. Customer – Person on whose behalf the case is transacted. Customer might be originator in some cases but might not be always

4. Interested – Who needs to be aware of the progress, but is not personally involved in the case

ii. Work parties are used for:

1. Communicating with users

2. Routing assignments to right users

iii. For each case type, a default work party is created with name: pyCaseManagementDefault

iv. It contains 3 standard entries: Customer, Owner (automatically populated and updated as case progresses) and Interested

b. What – How to communicate

i. 4 correspondence types – email, text message, mail and fax

ii. Correspondence are categorized in Process category

c. When – At what point of time in the process

i. Two options:

1. Automatic: Using various flow shapes

a. Send Email

b. Notifications tab on Assignments – Notify users that a task is assigned or customer that a case has reached a milestone

c. Utility shape – Used to send other correspondence such as text msgs, letters or faxes

2. Manual:

a. Local action: Operator to decide to whom to send and how to send

iv. Enforcing business policies using decision rules

1. Types of decision rules:

a. When – Useful when you know the condition and need to check if it exists or not

b. Decision Table – Same factors with different values

c. Decision Tree – Factors with different values determines other factors to evaluate

2. Delegated rules should be placed in a unlocked RuleSet

3. Non-delegated rules should always belong to a locked RuleSet

v. Enforcing data relationships with Declarative Rules

1. Declarative processing helps simplifying application by describing a computational relationship between property values that is expected to be valid “always” or “often” or “as needed”

2. Example scenarios:

a. “Declare” the value of a given property to be sum or other properties

b. “Declare” that a specified action be triggered when a property value changes

c. Restrict the allowed values of a property based on the value of another property

3. Primary benefit of declarative processing is computation is done automatically.

4. 6 Ways of managing declarative processing:

a. Constraint – Records an expected relationship between property values

b. Declare Expression –

i. allows us to define automatic computations of property values based on computational expressions

ii. The expressions may include: Property references, decision rule results or other declare expressions

c. Data Page – Records what the contents of a clipboard page should be

d. Declare onChange –

i. Records computation (defined by expressions) that must be performed when a value of a “Watched” property changes

ii. Can cause frequent updating

e. Declare Trigger

i. Records specified processing to occur automatically when an instance of a specific class is saved or deleted in database

ii. E.g., Send an email when a customer record is updated

f. Declare Index

i. Used to define criteria under which PRPC automatically maintains index instances for faster access

ii. An index can improve search and reporting access for properties that cannot be exposed as database columns because they are embedded within an aggregate property.

5. Note that no other rule explicitly refers to declarative rules

vi. Guardrails for enforcing business policies

1. Common warnings while enforcing business policies

a. Best Practice - Caution: Occurs if inline styles or scripts are used in correspondence text

b. Logic Conflict: Occurs when a subsequent row is unreachable. Use show conflicts to identify such rows and fix them

7. Process visibility through business reporting

i. Preparing your data for reporting

1. Purpose of reporting is to get insights

2. 2 types of metrics associated with reports data:

a. Business metric: Represents data that users defined using properties

b. Process metric:

i. Tracked by PRPC

3. Case data is stored in a single row of a database table

a. It includes columns: pyID, pyLabel, pxCreationDate, pxCreateOperator, pxUrgencyWork, pyStatusWork, pzPVStream (blob)

b. pzPVStream is a blob field which stores the case data in an encrypted format

i. Advantages of blob field:

1. No size constraints

2. High performance

c. Exposed columns:

i. Properties used for reporting. Extracted from case data blob

ii. Is updated additionally to blob column for every update

iii. If exposed columns are more in numbers, it is possible to create separate table called Declare Index

d. Other process metrics which are already tracked includes: pyID, pyLabel, pxCreationDate, pxCreateOperator, pxUrgencyWork, pyStatusWork

ii. Building Business Reports

1. 2 types of reports:

a. List

i. Spreadsheet style data on each row for an individual case

ii. Can combine both business and process metrics

b. Summary

i. Shows summarized data from multiple cases or work items

ii. Often used to show trends over time

c. 4 categories of reports:

i. Monitor Assignments:

1. Display information about assignments for Open (Unresolved) work items in an application

2. Supports ongoing monitoring of work from the perspective of who the work is assigned to

3. E.g., A report that measures timeliness by task

ii. Analyze Performance:

1. Granular analysis of completed work

2. Display information about resolved work items in an application at the level of individual steps, or flow actions, within business processes

3. Helps determine whether processes are efficiently and effectively performed

4. E.g., a report that measures the average processing time in hours by task and flow action

iii. Analyze Quality:

1. Application analysis of completed work

2. E.g., a report that measures the average elapsed time per status

iv. Monitor Processes

1. Support ongoing monitoring of work from the perspective of the work being performed

2. E.g., a report that measures throughput in past week by work type

d. It is OK to unoptimized property in a report. Just be sure that it impacts performance based on how often the report is used

e. To create charts, one of the fields in the report needs to be aggregated

iii. Guardrails for Business reporting

1. Common guardrail warning:

a. Using unexposed property

i. Not exposing any property doesn’t necessarily affect application performance, but will affect report performance

b. Format on date time property: Any calculations, grouping, sorting etc will happen on unformatted values

2. Process to follow while creating reports include: Think, Plan and Iterate

8. Best practices for preparing an application for testing deployment

i. Using guardrail reports to ensure best performance

1. Some common guardrail warnings:

a. Duplicate property names – Impacts caching of application

b. Optimized properties – Not using optimized properties for reporting

c. Draft mode – Not turning off draft mode in processes will be ignored in production environment

2. General best practices:

a. Do not duplicate logic

b. Use inheritance

c. Do not reinvent the wheel

ii. Guidelines for maintaining requirements and specifications

1. Applications are defined by a set of:

a. Specifications: What the application does

i. It represents a small processing unit performed by one or more actors for a given case type within an application

ii. A single specification can correspond to an:

1. Entire process

2. Single flow action

3. Screen flow

4. Or a new harness of a flow

iii. A specification uses one or more requirements to define success criteria that the specification is complete

b. Requirements: Specifies conditions that must happen

i. Requirement is an inventory of events, conditions or functions that needs to be satisfied and tracked by application