Automating Business Policies

Automating Business Policies

DATA TRANSFORMS

The Data Transform rule is a powerful tool in Pega 7 which makes data manipulation on properties and pages easy and efficient. Data Transforms map data from a source to a target, performing any required conversions or transformations on that data.In PRPC, Data Transforms are part of the Data Model category and are instances of the “Rule-Obj-Model” rule type.

There are multiple situations in which the use of the Data Transform is more appropriate than any other rule type. Whenever we need to set properties values on a given page, whether they are the initial values or updated values, a Data Transform is the best option. Also, when updating property values on a page using properties from another existing page there is no better option than using a Data Transform rule.We can also use it when there is a need to append a new or existing page to a page list or to append and map properties from one page to another page. Multiple features in PRPC accept a reference to a Data Transform rule.

In general, there are only a few situations in which a different approach might be more appropriate than a data transform:

• A property value should be set declaratively, rather than procedurally. To set a property value declaratively, use a declare expression rule instead.
• When defining source data for a data page. Depending on the source of the data use of a report definition, database lookup, or activity may be more appropriate.
• Updating data in a database. Data transforms do not provide any means to write data to a database.

Data transforms can be chained with other data transforms defined in their parent classes. To do this, we need to enable the “Call superclass data transform?” checkbox, and the data transforms must share the same name.

PRPC checks for the same name in all the parents of this class following both pattern and directed inheritance. Then it applies all the data transforms starting with the deepest ancestor continuing for each child upward.

Structure of Data Transform Definition

There are four columns on this tab.

• Action – This is where we identify what the step is for. This is required for each step. We will look at the different actions that are possible shortly.
• Target – Most actions require a target. In cases where an action is not required, we cannot select one. The smart prompt box acts both as a select and a text box.
• Relation – This is an optional column. The typical relationship between source and target is "equal to." There are a few actions that use other relationships.
• Source - This becomes selectable only if the action requires a source. We can specify literal value, properties or expressions. We can, for example, set the target property “Employment Type” as the value “Full Time,” target property the “Full Name” as concatenation of two other properties “First Name” and “Last Name,” and target property “Rate” as an expression, namely, the sum of source properties “BaseRate,” “LoanRateAdjustment,” and “RiskRateAdjustment.”

As a best practice, and to improve readability, do not create more than 25 steps. If we need to define more than 25 steps, we can group some of the actions and define them in another data transform rule. 

Let’s look at some of the key actions available to us:

Set is used to set the target from a source. 

Remove is used to delete the target and any associated values from the clipboard.

We can also use Update Page to set the properties defined on an embedded page.

Whenever we need to invoke a “Data Transform” from another data transform rule, we use “Apply Data Transform.”

Conditional Actions:

• When — To conditionally perform actions.
• Otherwise When and Otherwise — To provide actions for the alternative to the When actions.

We can also iterate over a pagelist using For Each Page In action.

“Append to” action to copy a page from the source to the target. 

“Append and Map to” is used to map individual properties in the page list.

If we don’t want to loop through all the pages in the pagelist, we can use the “Exit For Each” condition to exit the loop, or we can exit from processing all the remaining steps with the “Exit Data Transform” condition. Typically, we have these steps after a when condition.

Here is the list of symbolic indexes that we can use when we loop through the iteration:

<CURRENT> - Identifies the index of the current iteration
<APPEND> - Inserts the element at a new position at the end
<LAST> - Retrieves the highest index
<PREPEND> - Inserts the element at the top
<INSERT> - Inserts the element at a specific position that is indicated by the number

Param.pyForEachCount – Same as <CURRENT>. Identifies the index of the current iteration.

This can be used for the Page index and in the expression as well, while <CURRENT> can be used only for the Page index.

For Data Transform rules, we cannot use the <APPEND> keyword in the For Each Page In action. Instead, we need to follow the For Each Page action with an Append to action or Append and Map to action. We can use <APPEND> for “Update Page” action  in the Data Transform and also for looping through in the steps of an Activity rule.

Top – Refers the top most page of the embedded page.
Parent – Refers to the parent page of the embedded page. If the embedded page has only one parent, and no grandparents in the hierarchy, Top and Parent refer to the same parent page.

Data Transforms in the Business Processes

In the starting processes of a case, the data transform rule is defined on the Processes tab, which is invoked to set initial properties for the case instances. The starting process has the “Creates a new work object” setting selected as shown below.

Any time, when we create a new case either through any explorer or create new cases with a new application through Application creation wizard, PRPC creates pyDefault.

In the case hierarchy, we use the data propagation configuration to propagate the data from the parent case to the subcases when the subcases are instantiated.

 If we are simply taking the data without making any changes, we can use the data propagation option and we do not need to select “Also apply Data Transform.” If we are using the data conditionally or looping through a pagelist or if we need to reuse propagating data from parent to subcase in other rules, we can use the “Also apply Data Transform,” option and use a Data Transform rule.

For each step, there is an appropriate flow rule associated with it. A step of step type “Case” uses the “Create Case(s)” smart shape in the flow rule for that step. Referencing a data transform on step configuration is the same as setting the properties on the smart shape in the flow rule. We can modify it in either place and it is reflected in the other place.

To avoid accidentally overwriting data when a subcase is instantiated, it is important to understand the order in which an application evaluates these Data Transforms:

1. First, the application applies the Data Transform on the starting flow of the subcase 
2. Next, the application applies the data propagation and Data Transform configured on parent case type rule (defined on Case Designer – Details tab)
3. Finally, the application applies the Data Transform defined on the case instantiation step in the Case Designer of the parent case, or the Data Transform defined in the “Create Case(s)” smart shape in the “create case” flow rule of the Parent case.

In flows, on any connector between any two shapes, we can set properties or reference data transform rules. If it is a simple setting of one or two properties, we can use “Set Properties.” But, If we are using data conditionally or looping through a page list or if we need to reuse the data transform in other places, we can use the “Also apply Data Transform,” option and use a Data Transform rule.

In Flow actions, we can specify a data transform on the flow action's Action tab. To populate the properties from another page, we can invoke a data transform in the “before this action” area. If we want to copy the values submitted in the user session to another page, then we can invoke “after the action” is submitted.

We can reference a data transform in a section rule, for a change event of any cells directly, and also we are able to reference a data transform if we select "Refresh This Section" for the client change event. This is handy, when we change a value from a drop down or select a radio button.

ACTIVITIES

PEGAPULSE

So, we see when the PegaPulse postings are published in Private mode, they are visible to everyone who accesses the case, but only in the case management interface.

When the PegaPulse postings are published in Private mode, they are visible to everyone who accesses the case, through the case management interface.

When the PegaPulse postings are published in public mode, they are visible to everyone in the work group in the portal. They are also visible to everyone who accesses the case through the case management interface.

Каждый может удалять только свои сообщения и комментарии. При удалении сообщения, появляется сообщение предупреждающее об удалении связанных комментариев.

That can be filtered Posts by Me, Automated Posts, Posts with Files and Posts with Links

Click on the link and select “Create a Task.”?

User Profile - Открыть профиль другого пользователя и добавить сообщение только для него.

“Post to Pulse” Smart Shape

To Current operator or to other operator

Configuration	Result
Message pertains to the current case is disabled	Post is public and appears in the Pega Pulse feed in the Case Manager
Message pertains to the current case is enabled, Make secure post is disabled	Post is public and appears in the Pega Pulse feed in the Case Manager. Post references the case ID
Both Message pertains to the current case and Make secure post are enabled	Post is private and only appears in the Pega Pulse feed when the case is opened

CASE ATTACHMENTS

By default, case instance attachments are stored in the “pc_data_workattach” table as instances of concrete classes derived from the “Data-WorkAttach-“ class.

• Note attachments from the “Data-WorkAttach-Note” class;
• File attachments from the “Data-WorkAttach-File” class;
• URL attachments from the “Data-WorkAttach-URL” class;
• Screenshot attachments from the “Data-WorkAttach-ScreenShot” class;
• Scanned document/image attachments from the “Data-WorkAttach-ScanDocument” class; When we click the “Scan and Attach a Document” link in the advanced menu, we see the Attach Scan Document dialog.  We first need to scan a document before we can attach it. So from the Select Source button, select a scanner. Next, select the Scan button and we will see the scanned document in the viewer.
• Enterprise Content Management attachments from the “Data-WorkAttach-ECM” class.We can configure our application to store attachments of type file in an external enterprise content management system (or ECM) using the CMIS protocol such as Microsoft SharePoint or IBM FileNet. 

В карточке Case есть возможность видеть attach, и добавлять все их виды.(Стандартный портал)

 All attachments types can be added as a local action.

• AddAttachments allows us to add a file attachment and assign it to an attachment category.
• AddMultipleAttachments though provides the ability to add multiple file attachments, with a category for each, in a single action. For every attachment types, there is one flow action.
• AttachAFile as its name implies is used to attach a file to the work item, including an explanatory note but no attachment category.
• AttachANote flow action prompts users to type in a text note that becomes an attachment to the case instance.
• AttachAScreenShot is used to select one window from a list of windows on the Windows desktop, and then capture and attach a screen shot JPG image to the case instance with an explanatory note.
• AttachAUrl is the flow action you might use to attach a URL reference to the work object with an explanatory note.
• AttachFromScanner allows us to start the Image Viewer tool to scan, view or update a TIFF file from a scanner and attach it to the case instance.
• AttachmentForECM allows us to attach a document from content repository to the case instance.

“Attach Content” smart shape

When attaching a file, we can choose either to attach a binary file from a folder or to reference an attachment from the case type.

“Attach a URL” and “Attach a note” options require a URL and description and a note and description respectively.

As part of attaching a file automatically, we can generate a PDF file and attach it to the case. To accomplish this, we can use the smart shape “Create PDF.”

The attachment category is a business classification to indicate the content or significance of the attachment. It is different from attachment type. At the same time, it is used to control operations on attachments including create, edit, review or delete.

In PRPC, Attachment categories are part of the Security category and are instances of the “Rule-Obj-AttachmentCategory” rule type. 

On the first tab, Security, we can control access to the attachments through Privileges and/or When rules.

•  Create — to grant users the ability to add attachments of this category if they have the privilege in the Privilege Name field.
• Edit — to grant users the ability to edit attachments of this category if they have the privilege. The permission to Edit implies permission to view.
• View to grant users the ability to view attachments of this category if they have the privilege.
• Delete Own — to grant users the ability to delete attachments of this category that they added earlier if they have privilege.
• Delete Any — to grant users the ability to delete any attachments of this category if they have the privilege. The permission to delete any implies permission to delete own.

The “Enable Attachment Level Security” option allows the operator at runtime who attaches a work attachment of this category to identify one or more work groups that have access to the attachment.

The next tab, “Availability”, provides a list of the attachment types. We select the checkboxes for the attachment types that are valid for the

If no types are selected, the category is not inaccessible. Instead, a default category rule in Work- class is used for its respective type. The default category has no security restrictions. category and the work type identified by the “Applies to” class of this attachment category rule.

ROUTING

There are two basic types of routing: Push routing and Pull routing.
Push routing routes the assignment to a single user’s worklist.PRPC can use multiple criteria to select the owner, including availability (if an operator is available or on vacation), the operator’s work group, his/her skills, or current workload.Depending on how the routing is configured, it is possible to route to a substitute operator if the chosen operator is not available. Users can work on any assignment from the worklist.Pull routing, on the other hand, routes to a workbasket that is shared across multiple users. Ownership does not occur until an operator takes action on it. Most applications use “GetNextWork” logic to select the most urgent assignment from multiple workbaskets. When this happens, the assignment is removed from the workbasket and is assigned to the operator’s worklist.
In most of the standard portals, we can pull the next assignment to work with “Get Next Work” logic by clicking on “Next Assignment” button at the top of the portal.
The case manager portal, typically for work group managers and other managers, shows a list of operators in their work group, on the right side of the dashboard.
As a work group manager, he/she has the privilege to view individual members’ worklists.
The work group managers and all the other operators can see the list of workbaskets to which they have access, on their portal, on the bottom right hand side of the dashboard.
Selecting a workbasket shows the assignments in a particular workbasket. They are waiting to be pulled by an operator.
An operator can select one of these items directly, which promotes it to his/her worklist, or use the GetNextWork function, which selects an item for him. GetNextWork queries both worklist and workbasket items. GetNextWork is a great way to ensure that the most appropriate item gets the most attention. This way, we can prevent an operator from cherry picking the item that they want to work on from the workbasket, instead of the items in the worklist.

Configure Directed Web Access (DWA)

We might need to get information from external users who don’t have operator credentials to login to PRPC to provide the data that we are looking for.

Sending the assignment to an external user is called ‘Directed Web Access” (DWA), because the external users accesses the assignment on the internet through a web browser. As a prerequisite, we need to configure PRPC to send emails. (See Designer Studio > Integration > Email > Outbound Email.)

We can send the assignment to an external user, by selecting the assignment type as “External” in the assignment tab. When we select this assignment type, we can configure what correspondence we want sent to the vendor.

When the case reaches “request for quote” external type assignment in the flow, PRPC sends an email to the vendor. The vendor gets an email as shown below, with a link.

When the recipient of the vendor organization, clicks on the link, they get the quote request flow action in a web page. When they fill in the requested data and submit the flow action, the assignment and the flow action are complete and the flow moves on to the next shape.

We need to configure the URL that is to be sent in the emails. We can configure this through Designer Studio > System > Settings > URLs > Public Link URL.  Public Link URL is set typically in the form as shown below.

Identify and Use Some Advanced Standard Routers

When we have the assignment type as “WorkList” or “WorkBasket,” we can select a host of standard routers. 

• “ToWorklist” routes to a particular operator by name.
• “ToWorkParty” routes to a work party. The actual operator depends on the work object; for example, if the workparty is “Initiator”, the actual operator is different for every work object. Work Parties are covered in more detail in another lesson.
• “ToWorkGroupManager” and “ToOrgUnitManager” route to the manager of the operator’s workgroup and Organizational Unit.
• “ToWorkgroup” routes to a random operator within a workgroup.
• “ToSkilledGroup” also routes to an operator in a workgroup and takes required skills into account.
• “ToLeveledGroup” is similar “ToSkilledGroup”, but instead of the system choosing an operator randomly, operators are sorted by workload and desired skills.

We should not get confused by the naming of some of these routers. ToWorkgroup, ToSkilledGroup, and ToLeveledGroup do NOT route to a group; they route to an operator, as is the case with all push routing. These routers simply use the workgroup as a criterion for selecting the operator.

A couple of workbasket routers are worth noting. Workbasket routers are used with pull-based routing.

• The “ToWorkbasket” router does exactly that; routes to a particular workbasket.
• “ToSkilledWorkbasket” also routes to a particular workbasket. We will look at the details of this router later in this lesson

Determine Work Balanced and Skill Based Routing

The skill rule stores very little information; the description, as well as a range from Low to High, the high score representing the highest level of proficiency with the skill.

Operators are associated with any number of these skills, and the appropriate rating is supplied. The assignment is then associated with skills as well, depending on the type of router selected.

If the operator has a rating that is equal to or above the level required by the assignment, that operator can be chosen by the router. Note that a skill can be set to be required, or not.

For skill-based push routing, an operator is selected for a specified group and required skill. For the “ToSkilledGroup” router, this selection is random.

For Pull-based routing, the “ToSkilledWorkbasket” router adds an assignment to a workbasket, and also associates a skill with that assignment. Subsequently, GetNextWork will take these skills into account when finding an assignment for an operator to work on.

For the “ToLeveledGroup” router, the selection is prioritized by load and desired skills. A high load, in this case, refers to when an operator has a high number of assignments that are past deadline.

GET NEXT WORK

PRPC allows us to either push tasks directly to workers or allow workers to pull a task from a workbasket when they ready to perform a task.

In the first case, when pushing tasks to a worker’s worklist, the process flow can be configured to use criteria such as worker availability, skills, region or others to assign a task to a specific worker. Typically, this happens when the task is first created. This can be fully automated or manual.

Many business processes though can require that the tasks be stored in a centralized workbasket. Workers can then select a task when they are ready to work on it. To avoid cherry-picking, PRPC applications can select and provide the best, most appropriate tasks to workers. Every task is eventually completed, but the order in which workers process those tasks may be an important factor. PRPC provides an easily tuned set of capabilities that match workers to open tasks using the “Get Next Work” functionality.

Default “Get Next Work” Functionality

PRPC provides different ways to access the “Get Next Work” functionality. On the top left corner of the case manager or case worker portal, the “Next Assignment” link provides a way to access the GetNextWork functionality.

On the other hand the “Get Most Urgent” button may also appear at the bottom of the user forms on the confirmation harness allowing users to access the next available task right after completing one.

When users click the Next Assignment link or the Get Most Urgent button, PRPC starts the standard activity Work-.GetNextWork. This activity calls the final activity Work-.getNextWorkObject.

Thus the default “Get Next Work” functionality can be summarized into these steps:

1. Users click either the “Next Assignment” link or the “Get Most Urgent” button.
2. The Work-.GetNextWork activity starts
3. The Work-.GetNextWorkObject activity starts
4. The pyWorkBasketFirst property is checked “Get from workbaskets first?” Check box on Work tab of the Operator ID rule form
   1. If TRUE then it calls Work-.findAssignmentinWorkbasket activity first then examines the worklist
   2. If FALSE then it calls Work-.findAssignmentinWorklist activity first then examines the workbasket
5. The Work-.findAssignmentinWorkbasket activity starts and uses the list view Assign-Workbasket.GetNextWork.ALL. The list of assignments are sorted in decreasing order by assignment urgency (property Assign.pxUrgencyAssign)
   1. "Merge Workbaskets?” checkbox is NOT checked
      1. workbaskets are searched in order defined on Work tab
   2. “Merge Workbaskets?” checkbox is checked
      1. “use all workbasket assignments in user’s workgroup?” is checked
         1. list of assignments from all workbaskets with the same workgroup as this user
   3. “use all workbasket assignments in user’s workgroup?” is NOT checked
      1. assignments from all listed workbaskets in the Work tab are assembled into a single list
6. Assign-.GetNextWorkCriteria Decision Tree is used to filter the most appropriate task.This decision tree rule first checks to see if the task is ready to be worked on. This means that the pyActionTime property of the task is NOT in the future.
   
   If it is ready to be worked on, the decision tree checks if the current worker has already worked on or updated the task earlier that day.
   
   If the current worker did not work on the task, the Assign-.GetNextWorkCriteria now examines whether the worker has the required skills to work on this task. The worker’s skills are recorded on the work tab of the operator ID rule form.
7. First task that passes all the above requirements is selected
8. New newAssignPage is populated with this task and the case instance is locked
   1. Based on GetNextWork_MoveAssignmentToWorklist system setting rule
9. No assignment is found from the workbaskets
   1. Repeat steps 5 to 8 but with the Work-.findAssignmentinWorklist activity and  the standard list view Assign-Worklist.GetNextWork.All

Note: The order in Step 9 is reversed if pyWorkBasketFirst property is false, as explained in step 4 – the worklist is processed first and then the workbaskets.

CORRESPONDENCE

Correspondence refers to letters, email messages, Fax , and SMS text messages that PRPC applications send to interested parties while a case instance is being processed.

In PRPC, correspondence is part of the Process category and is an instance of the “Rule-Obj-Corr” rule type.

1. The recipients of the emails are represented as PRPC work parties or the email ID itself as that can be typed in certain configurations. If the recipient is internal to the system, the email address is stored in the operator record.
2. The Sender information is stored in an “Email Account” rule. This rule holds account information, and as with life outside PRPC, a single account is used to send multiple emails.
3. The message itself is created from a “Correspondence” rule, which dictates the actual content and layout of the email body. Correspondence rules can also contain smaller, reusable “Correspondence Fragment” rules and/or “Paragraph” rules.
4. On the delivery front, task-driven notification is setup from the PRPC representation of tasks: Assignments. Assignments point to a special subset activities, called “Notification Activities”. Or they can be set up with the “Send Email” smart shape after the assignment shape in the flow rules. Reminders are set at the SLA level. That is, when the goal or deadline of a service level agreement has been reached, a notification email is sent out. This is done using an “Escalation Actions”. Ad-Hoc emails are typically sent using the out-of-the-box “Send Correspondence” flow action, which can be configured as a local or flow wide or stage wide or case wide flow action.

Creation of an Email Account

In order to send emails, we need to set up an email account. The easiest way to create an email account is through the Email wizard, which can be accessed by selecting the DesignerStudio button > Integration > Email > Email wizard. 

In the wizard, change the drop down value to “Configure an email account. “Note that this account is being shared for a workpool. Multiple cases, even multiple assignments for a case type, will share the same email account record, therefore, we only need to do this once, for a workpool. When creating an email account using the wizard, when you select a workpool name PRPC makes the Email Account rule name the same as the workpool name, , and implicitly associates this account rule for the subsequent notifications. 

se the form below to provide the account information. To help us get started, click the “Select Email Provider” button to pre-populate the form with information from a well-known email provider.

We then fill out other critical information, such as the address, host, user ID, and password. It’s possible to use different account information for sending and receiving. For now, we’ll use the same.

Correspondence Creation and Configuration

In PRPC, we can create a correspondence from any explorers, under the Process category.

In the correspondence rule form dialog, we need to specify what type of correspondence, by selecting one of the standard correspondence types, Email, Fax, Mail and PhoneText.   We also need to make sure the Context (App Layer, Apply to class and ruleset name is accurate.

A correspondence rule is a template that contains the standard body of the message that we wish to send. We can insert PRPC properties and include logic as well as text in this content.  The correspondence rule provides a Rich Text editor with a wide variety of formatting tools to change the appearance of our correspondence. The toolbar includes selectors for bold, italics, fonts, font size, color, spell checking, list formatting, alignment and including images and graphic elements.

PRPC properties are marked using angle << >> brackets and these are replaced with the actual values at runtime before the correspondence is sent to the recipient.

We can also include larger fragments of text, including paragraphs, sections, other correspondence rules, and correspondence fragments, by clicking the “Include a Rule” button, when we are editing the message contents of a correspondence rule.

Correspondence Fragment rules are part of the Process category, and Paragraph and Section are part of the User Interface category.

Add correspondence to a flow

Once the correspondence rule is created, we can configure the flows and assignments to utilize the rule, to send the correspondence when the case instance is being processed.

We have covered the details of the “Send Email” smart shape in SAE I course. We can use the smart shape in a flow rule to send the correspondence to any work party. The correspondence rule should be of Email correspondence type in the correspondence template field.

Instead of the smart shape, we can also use a utility shape and call a correspondence activity. PRPC includes several standard correspondence activities. The two main ones are CorrNew, which is typically used when generating correspondence from a utility, and CorrQuickStart, which is a simpler correspondence generation activity, with fewer options than CorrNew.

In a flow rule, instead of using the send email smart shape or utility shape with a call to a correspondence activity, in the notify tab of the assignment we can configure it to send correspondence . Assignment shape correspondence is generally used to send automatic notification messages to the users who have the assignments, alerting them that more work has arrived in their worklist or acknowledging some other party that the specific assignment has happened.

Note that, since notification is now set up in the notification tab, a mail icon appears on the assignment shape, similar to the “Send Email” smart shape. We can enter one of the activity rules “Notify,” “NotifyAll,” “NotifyAllAssignees,” “NotifyAssignee” and “NotifyParty” in the Notify field, and enter the appropriate parameters.

• NotifyAssignee, sends a message to the assignee, or to the first contact in workbasket for workbasket assignments.
• NotifyAllAssignees is similar, but sends to all workbasket contacts.
• NotifyParty sends a message to designated work parties
• NotifyAll sends to all work parties
• “Notify” is a template for creating customized notification activities.

Some of these rules can optionally check for urgency, and only send email when the urgency is equal to or above this value. 

If the service level is not met for an assignment, we can send the correspondence to the appropriate recipients. Previously we learned that service Level rules are referenced in the Assignment tab of the assignment shape in a flow.

In the service level rules, we can do one or more escalation action(s), if the goal or deadline is not met and the deadline is passed.The list of possible actions is shown below:

1. Notify Assignee
2. Notify Manger
3. Notify Party

Notify actions can be used to send correspondence. We can see what activities are called when using the Notify Assignee and Notify Manager activities.

Whenever an email is sent automatically as part the processing the case instance, or manually (ad-hoc), a copy of the email is attached to the case instances, and we can view them from the attachments section in the perform harness.

Ad-hoc Notifications
We’ve looked at use cases for automated emails; smart shape in a flow, on an assignment, and triggered from an SLA. Now, let’s look at ad-hoc messaging. Imagine a situation in which a manager wants to send an initiator a question about the current purchase request. He doesn’t want to approve the message until he gets his answer. He could just email the requestor directly, but prefers doing it in PRPC for better record keeping. The assignment is set with the local flow action “SendCorrespondence”. This could also be set as a flow-wide or stage wide or case wide flow action.

When we click on the link, the correspondence action is initiated and we see the work parties drop down. Owner work party is configured as the operator who initiates the purchase request case.

Now, we select from a list of out-of-the-box correspondence template rules. We can select “SampleLetter”, which allows us to edit the correspondence before sending it.

We can click the Next button to finish and the correspondence is sent back to the requester. Please note that all emails sent from PRPC, are included as attachments in the case instances just as we have seen.

TICKETING

Introduction

During the normal sequence of processing a case instance, an event may be considered a business exception. When that event occurs, a ticket may redirect the processing to another point in the processing of the case.

In PRPC, tickets are part of the Process category and are instances of the “Rule-Obj-Ticket” rule type.

We raise the ticket when the business exception happens, and we reference the ticket at a point where we want the flow of the case to resume again. In this lesson, we will learn how to raise and reference tickets.

With the introduction of alternate stages in Pega 7, the use of tickets is diminished. 

A ticket rule only defines a name and description and not the processing to occur in the case of an exception.

In the flows for a case, we define when an event may be considered a “business exception” by raising a ticket.
PRPC provides us with two distinct ways to raise a ticket. One way is to provide users the option of selecting the Work-.SetTicket or @baseclass.SetTicket flow actions when processing an assignment. If an assignment is presenting a case instance with a condition that meets the business exception criteria, users can select this flow action to trigger the exception processing. As shown below, users have to select a ticket from the dropdown, to set the ticket flow action during the processing of the case. We use an HTML rule, ActionSetTicket to display a list of Tickets. These standard flow actions require users to have the “ActionSetTicket” privilege.
The second way to raise a ticket is by calling the standard activity @baseclass.SetTicket.  This activity takes the ticket name as a parameter and turns it on or off. Instead of using the standard SetTicket flow action, in the flow action where the business exception is occurring we use the standard activity to raise the ticket. In the return to purchase business exception flow action, we raise the “ToPurchasing” ticket that we created earlier, by passing the name of the ticket as the parameter to the activity.
The SetTicket activity takes the ticket name as parameter and turns it on or off.
In the flows for a case, we also need to define the starting point of the processing that needs to occur once a ticket is raised. We do this by referencing the ticket.
Once a ticket is raised, flow processing stops and resumes at the point in the flow where the ticket is referenced.
In the process modeler, specific shapes have the ticket functionality built into the Properties panel.
Use the “Tickets” tab of the Properties panel on the shape we want the processing to resume from when the ticket is raised.
The following shapes provide a “Tickets” tab in their properties panel:

• Assignment
• Decision
• Subprocess
• Utility
• End
• Split For Each
• Split Join
• Integrator
• Assignment Service
• Most of the smart shapes

The shape has a ticket indicator with the description next to it

We can use the Ticket landing page available by selecting the Pega button >Process&Rules > Work Management > Tickets in our current application to verify which ticket rules are in active use, and by which flows or activities.

Identify and Use Standard Tickets

Several standard tickets are available in PRPC. Among those, there are few common ones. The advantage of using these tickets is that we don’t need to raise them. We just need to reference them where the flow has to resume.

• “Work-.StatusResolved” is automatically raised by the system when a work item is resolved. We can then reference it in our flows to indicate the starting point of the processing we would like to occur when our work item is resolved.
• “Work-.Withdraw” is similar but is raised when the work item is withdrawn. If this needs to be handled in a special way in our flow, we can reference it to indicate the starting point of the special processing.
• The “Work-Cover-.AllCoveredResolved” ticket is raised by PRPC when all covered work items are resolved. The ticket alerts the covered work item and any needed special processing referenced by this ticket is triggered. The parent Purchase Request case is waiting in a workbasket and when all the subcases are resolved, the ticket is raised. It is referenced here in the Update Status utility shape to resolve the status of the parent case automatically.
• he “Data-Party.ApprovalDecisionMade” ticket is quite common to use when processing needs to occur as soon as enough parties have reached a decision either approved or rejected.

DECLARATIVE PROCESSING

Explain the Benefits of Declarative Processing

Declarative rules are not invoked from other rules.  This eliminates the dependency on different rules making the creation and deletion of rules independent of each other. 

Keeping the rules independent makes it easy for us to separate business rules from the process. This gives us the option to delegate these rules to business managers. A declare expression can invoke a decision table and the managers can modify decision tables directly in production.

Declarative rules offer speedier development because developers only need to configure the rules and not decide on where to put the rule.

Development time is shorter because the code is less prone to errors since the declarative engine handles the processing of the rules. Maintenance is easier since newer teams do not need to dig through to locate these rules and the rules are easier to configure than activities

 We can use the Declarative Network landing page to access the declaratives defined in that application.(Pega button>Process&Rules>Business Rules>Declarative Network)

Declarative rules support all those features that apply to other rules such as class specialization, ruleset and rule specialization, circumstancing and or effective date.

Another benefit of declarative processing is Performance. Well written declarative rules offer better application performance than using a procedural rule.

Declarative rules allow us to use chaining to any number of levels which creates a declarative network.

Differentiate Between Forward Chaining and Backward Chaining

Since Declarative rules are not referenced explicitly PRPC must determine when to execute them. Most declarative rules use one of two modes - Forward or Backward Chaining. All declarative rules use source and target properties. 

The target property is what is being calculated or computed using these declaratives and

Source properties (in some cases there is more than one property) are the ones which are used as an input.

Forward chaining is executed when the value of any of the source properties change. Most of the declarative rules follow forward chaining.

In the case of Declare expressions, the expression is calculated whenever any of the source properties change.

eclare Expressions are configured in Forward Chaining Mode when we select the option Whenever inputs change.

In the case of Constraints, when the value changes, the constraint is executed to verify that the value conforms to the conditions expressed. Constraints can have any number of rows and the order in which they are listed is not significant. The message text can be entered directly in the rule form or saved as a message rule which can be referenced as shown below.

Declare OnChange can track several properties that have been saved as part of the case. When one or more of these properties change it invokes the activity which has the logic to be performed. The Declarative Engine invokes the activity only once if more than one property gets changed.

The Declare Trigger executes when instance of its classes are created, saved or deleted in the database. On the database event, it triggers an activity which contains the logic to be performed. Triggers can be used in cases when we want to capture the history of how a property got different values over the case lifecycle.

The Declare Index executes when the values of a page list or a page group change which requires the system to update the records saved in the indexed table (corresponding to the indexed class). This is primarily used in reporting when we expose the page list properties to improve performance. Whenever a new page list gets created or deleted or when one or more of the values change the Declare Index automatically create or update the records stored in the index table.

Backward Chaining mode executes when the target property is referenced. Backward chaining is supported only for declare expressions . 

Declare expressions provide three options for Backward chaining.

1. When used, if no value is present
2. When used, if property is missing
3. Whenever used

The target property is considered used when it’s referenced by its name, such as in a UI rule, in a decision tree or in a data transform.

The no value present / if property is missing options make sure the expression is calculated only once in the case lifecycle unless the property is removed from clipboard.

When we use Whenever Used the system throws a performance warning, indicating that the expression will fire as many times as the target property is referenced.

The remaining two options – When applied by a rule collection and When invoked procedurally – allow a declare expressions rule to be used in a procedural manner, by a collection rule. These two options behave similarly, except that chaining in to or out of the expression is not supported by the When invoked procedurally option.

Both options allow the declare expression to refer to itself, such as in the expression .Property = .Property +1. With either forward chaining or backward chaining, this type of expression results in a never-ending recursive calculation.

Collection rules are an advanced topic, and not covered in this course. As a result, the remainder of this lesson focuses only on forward and backward chaining

What are the Performance Impacts of Declarative Processing

Using declarative rules can significantly improve the overall performance of an application, since the declarative engine controls the execution and it is always better than a procedural rule such as an activity or a data transform. There are some key points to consider though when designing declaratives.

The decision to use Forward or Backward chaining of declarative expressions is dependent on the application requirements especially in terms of how the target and source properties are referenced. Choosing them incorrectly severely impacts performance.
Forward chaining becomes more performance intensive if the expression uses lot of factors and they change quite frequently.

Using the Tracer helps us to identify places where we can optimize the declarative calculations as well as making sure the expressions are always displaying the correct values.

Finally, it’s important to remember that declarative evaluation can cause severe application errors that would not otherwise occur with procedural evaluation. When configured incorrectly, a declarative rule may cause the system to access pages that have not been created or properties that have not been set, leading to unpredictable results. With a procedural alternative, we can better control rule evaluation. So, if we need to perform a calculation at a specific point in a process, a procedural approach may prove less error-prone than a declarative approach.

DECLARATIVES RULES

Business calculations involving user defined fields should all be implemented using declaratives. Some calculations use simple mathematical operations like add, subtract, multiply or divide, while there are some advanced operations which might involve creating a java function.


Business calculations may span multiple layers that together form a deep network

Design Declare Expressions

A declare expression can be created by right clicking on the property in the App Explorer and clicking Define Expression.

In the new rule form, we need to identify the Target Property.

Declare expressions have a number of prebuilt calculation types. This list is different for each type of target property

 To set a scalar value we use Value Of and then select the free form expression which allows us to write any expression.

Other calculation types for decimal and integers include: sum of, min/max of, average of, count of and the two index calculations.  Each of these loops over a list and performs their respective calculation.

The result of the decision tree, table and map value allows us to call other business rules and take their return value and set the target property.

The “Value of first matching property in parent pages” option allows declare expressions to “reflect” a value for a property of the same name on a parent page. The class of the target page must equal or be a descendent of the class of the declare expressions rule.

Similarly a date property comes up with different list that applies to date functions. We can also apply a condition in the In Which field, that applies a condition for each item in a page list or a page group.

Identify and Use Utility Functions

Some complex declare expressions require using a Function rule. The definition is easier by opening the expression builder to pick the function from the list of available libraries.

A function is a rule type in Pega that is used in various other rules. Functions allow us to extend PRPC capabilities by using custom java code. Functions belong to Technical Category (Rule-Utility-Function) and are grouped by Library.

The Library rule is primarily used only for grouping related functions. PRPC ships various libraries each of them containing a list of functions for us to use as-is. The expression builder allows us to select the library which in turn provides the list of functions that are available in that category. In most cases we should be able to use these functions as such and we may need to write new ones on rare situations.

In the expression builder, first we need to select the library, if we are not sure which one it might belong to we can selectAll.

When a function is selected, it opens up the parameters panel. Functions require one or more parameters to be passed as inputs. After adding the parameters, we click Insert to add the function. The expression builder provides functionality to validate if the function is valid.

Functions are also used in other rule forms like when, decision trees, etc. We will learn more about these in other lessons.

Use Context-free and Context-sensitive expressions

Declare Expressions can be configured to execute either using forward or backward chaining modes. The lesson on Declarative processing provides more information on this topic.

The other important concept we need to learn in declare expressions is the Context Execution behavior.

There are two general types of context settings, Context Sensitive, which is set by selecting the first choice and context free, which is set by choosing the “regardless of any pages it is contained in” option.

The third option is a hybrid where we can explicitly list the classes for which it will behave like a context free expression. In practice this option has limited appeal as maintaining such a list reduces reusability.

The context sensitive option is the default for expressions. The term context sensitive really means that the path defined by the page context + target property must be complete from the top level page that derives from the Applies to class

Context free expressions allow us to define the expression without taking into account where it is used in the expression. This option is best used for calculations that are ALWAYS necessary and the same, regardless of where the object is embedded.

Explore the Declarative Network Analysis

For many applications the complexity of the calculations can be quite significant, with potentially hundreds of nested calculations. Luckily PRPC provides tools for viewing the expressions directly.

The first tool is the declarative network landing page. We can get to the landing page by going to the Pega button, clicking Process & Rules > Business Rules > Declarative Network.

The landing page shows us the “top most” expressions. The expressions that are used by these top expressions are not shown here.

We can open our  expression to test further by clicking the highlighted icon.

For complex networks we can zoom out (or in) to see different components of the network. PRPC also provides alternative views of the network. Here we can see the basic tree view as well as the org tree view.

Another useful feature for more complex networks is the ability to expand the network one level at a time.

Unit Test a Declare Expression

We can unit test expressions in couple of ways.

In the declarative network on a specific property we can click By clicking the run button to see the test expression screen.

 Each property is editable so we can test directly from here.

To enter a value, we need to click on the property that does not have fx to its left, the ones with fx are calculated by the expression. We then enter the value in the text box and click update.

 The expression testing tool has a number of other features which can be very helpful when reviewing the calculations with other developers or the members of the business team. This form can also be accessed directly from the declare expression rule using the actions menu and clicking Run.

DELEGATING RULES TO THE BUSINESS USER

Enterprise applications require us to design the application so it’s flexible and supports modifying the business logic in real-time.  Pega offers us the ability to delegate the rules to business users who can change the logic directly in a production system without going through the longer development cycle.

One of the key benefits of PRPC applications is that they are very adaptive to change. A well designed PRPC application should involve business users not just to capture requirements in the product but also provide them with the option to change the rules in real-time.

Identify the group of delegated users – These users must be part of a specific access group and the rules should be in a specific production ruleset that these users can access. These users should also be able to access the delegated rules from their portal.

Identify the Rules that can be delegated– Typically any of the Decisioning rules can be delegated. This makes it easier to make changes and PRPC supports additional configuration to Decisioning rules which makes it easier for us to update them.

Improve readability and customization options to make it easier for users to make their updates.

Setup Delegation Users

The first step in delegation is to create a new ruleset for end users to make changes. The ruleset should use the application ruleset as its prerequisites. The ruleset should remain unlocked in production so that the users can make changes.

If the rules are delegated to more than one user, then we should enable the checkout option so the changes are not overwritten.(Use check-out? option)

The ruleset should then be added as a production ruleset in the application rule.

The Accessgroup of users should also be modified to include the production ruleset.

Lastly, the operator IDs should be configured to allow checkout of rules.

Delegated Rules to the Business

Decisioning rules are good candidates for being delegated to business users. These rules frequently change and are easier for business users to make changes. After a rule is identified we need to save a copy of the rule in the delegation ruleset.

After the rule is saved, we delegate the rules by using the actions menu to add it to favorites.

This gives us the choice to whether add it as a favorite for a specific user or an access group. The last two choices appear only after we add the rule to a production ruleset.(Other Access Group, Other User Personal)

Once added, the delegated rules appear as part of the user portal for users to access.

1. For users using designer studio, these rules can be seen in the Favorites Explorer.
2. For users using case manager portal, these rules are accessible in the operator menu.

Improving Readability of Decision Trees

Decision trees usually look complex with multiple if-then-else statements, but we can make these more user friendly in several ways. We recommend you follow these guidelines when delegating rules to business users so it’s easier for them to configure.

1. Display Label – The display label button displays the short descriptions saved in the property instead of using the property name, so meaningful short descriptions make the decision tree more readable. 
2. Function Alias – Using a function alias adds more meaning to the condition rather than using the actual function signature. A function signature We can modify that by using a function alias rule

Function Alias Rules

These rules are part of technical category and they reference a function. So we either need to create a function and then create an alias or we can create an alias for an existing function.

A function alias helps in making the decision trees very readable to simulate reading an If – then – else condition logic.

The key factors involved is to identify how the parameters for the function get values (theycan be assigned to a property value or can provide an option for users to select when the alias is selected(SmartPrompt)).

Customize Options to Reduce Errors

When delegating rules to business users we recommend that you restrict the choices from which users can select.

This can be enabled both in trees and tables, and the choices can be added in one of two ways.

We can add these directly in the Allowed Results table. Or, the results can be stored as part of a property and then we can refer the property in the Allowed Values Property.

We can also set another property when the results are chosen. These property sets are hidden to users, and we can set one or more properties for each result.

Decision Trees

The options field must be carefully selected on rules that are extended to business users. In most cases the ability to change functions, call decision or take actions should be disabled. If there is a case where we need to let users change functions, we should add the list of functions in the Functions Allowed field. Then users can select from that list and not the entire list.

Similarly if users need to take actions, then we use the Allowed Action Functions field to add the properties that we need to add.

Decision Tables

1. Allow to update row layout — When this field is disabled, then business users can only modify the values corresponding to that row.  They can neither add new rows nor delete any existing row.
2. Allow to update column layout: — When this field is disabled, then business users can only change the values corresponding to that column. They cannot add or delete columns in the table. In addition, they cannot change the property that is referenced in the columns.
3. Allowed to build expressions —: This field enables the end user to use expressions as part of the cell in the decision table. If disabled, then users can enter either a constant or a property in the cell.

Map Values

Map Values offer two options for delegated users —they can change the matrix layout or use expressions in the cell.

AUTOMATING DECISIONS

Applications become powerful when we automate its decision making capabilities. Decisioning can be applied on the action paths taken by the case or to assign a specific value based on a set of specific conditions.

Decision rules play a key role in any enterprise application that involves business processes. They represent the decisions and policies that drive business processes and case management.

Decision rules can be invoked using a decision shape in the flow, using a declare expression or using a method in an activity step. The referencing of the decision rule depends on the context in which we need them.

We use flows in case processing to determine which path the case goes down. Using decision rules in our flows automates the case processing.

Declare expressions can use decision trees or decision tables to get a specific value based on a set of conditions.

There are four types of decision rules that we can write to evaluate decisions:

• When
• Decision trees
• Decision tables
• Map Value

When Rules

When rules belong to decision category, however they can return only one of two values – True or False. When rules are used in processes to decide which one of the two paths the case can take.

When rules are also used in other rules like UI, data transforms, other decisioning rules and declare expressions to evaluate a condition. Though most of these rules support adding the condition directly, we recommend that you use a when rule so the condition is entered once in the when rule and is used everywhere.

When rules can use a Boolean expression or a function rule part of the library shipped in the product or a custom function defined as part of the application. When rules can involve any number of conditions and can be combined using AND, OR & NOT.

Decision Trees

Decision Trees are useful when applying the If- Then- Else construct. Decision trees can be constructed to have many branches which evaluate different properties to determine a decision. Decision trees can also use function rules or when rules for building the condition.

One of the main reasons to use Decision trees is that it allows nesting, which means it can invoke another decision tree or other decision rules such as a decision table or a map value.

Decision Tables

Decision Tables are useful in presenting the set of conditions using a tabular structure. This is very user friendly to for managers since it resembles a spreadsheet with rows and columns. Decision Tables are suited to cases where we use a set of properties to arrive at a decision.

Some of the main reasons we use Decision Tables are that they:

1. Give us the option to evaluate all rows to arrive at a decision.
2. Let us increment values on the specified condition which is useful in implementing scoring.
3. Can invoke another decision table

Map Values

Map Value rules let us determine a specific value based on one to two properties- think of this as in a map determining the location based on the latitude and longitude.

Map Values are usually used in special circumstances where we the values of one to two factors decide the outcome. For example, if we want to determine the interest rates for bank accounts and customer types.

If we have five different types of customers and eight different types of accounts, we need forty rows in decision table to present this while we can do this in a 5x8 matrix. Map values can be chained to other map values as well if we need to use more than two properties to determine the outcome.

Configure and use a Decision Tree

The decision tree can use the direct expression such as .pyStatusWork = “Resolved-Completed” or reference a when rule named StatusIsResolved or use a function rule.

Decision trees usually return a value, these values can then be used in the calling rule such as the declare expression or the flow.

The decision tree can also be configured to set a value to properties and this can be done using the Take Action option in the menu. Continue is used to check additional conditions and otherwise is always used as an else condition.

Decision trees can also be configured to check values on a specific property and decide its course of action. Evaluate is used in such scenarios.

A new tab Input appears when the Evaluate option is selected to enter the actual property that is evaluated.

Though the decision tab is where we configure the decision, the developers need to use the entries in the Results tab to control how decision trees can be used

The Options area has two options – basic (by default) and advanced. Selecting Advanced enables all the checkboxes in the options area. Besides the options we can use the Functions Allowed section determines what function rules are allowed for the selection.  Similarly we can configure what options are available for Take Actions in the Allowed Action Functions area.

The decision tree can also have restricted return values, in this case the decision tree can return either true or false. We can also enter a property in the Allowed values property, in that case it uses the values saved as part of local list in property definition. The decision trees must be configured to have all these selections if they are delegated to business users. This helps our users to select the results that are allowed, use the functions that are required and only take the appropriate actions.

Configure and use a Decision Table

Decision tables are easier to delegate to business users and in most cases is the sought out decision rule if the same logic can be written using either a tree or a table. This resembles tools like MS Excel and hence most developers also feel more comfortable using them.. Decision tables are more apt to be used if we are using a smaller number of unique properties to evaluate the decisions. Since we use tables, each property gets a column and it makes sense to have rows added in a way that each of these columns have values.

The table columns can use properties for specifying a set of conditions. The property can be compared against a single value like Customer Type = Retail or against a range like Total price is greater than or equal to 300 and less than or equal to 1000.

Decision trees also offer additional capabilities to add OR conditions. Suppose we want to introduce a new column for Supplier and for two of the three customer types the values in other columns do not change. We could use OR to split a cell instead of adding a new cell. In the example below we have a single cell using OR for suppliers (Named vendor, New Vendor) for the first two rows.

We can return values or enable the property set field to set properties directly, using other icons we could return more than a single property based on the condition.

The results tab provides a similar set of options that we saw in decision trees – we can restrict the results returned using a property or a set of values. The main difference between the tree and table is the first option (Evaluate all rows), if this is selected, the decision table continues evaluating other conditions even if one condition is satisfied. This behavior is not enabled by default and is used only on specific cases. We will review one such case later in this lesson. When this setting is enabled, the decision table cannot return values and hence we cannot execute the decision rule from a declare expression.

Check for Consistency and Unit Test the Rules

Some rules become increasingly complex especially trees and before we release our rules we need to verify that they are correct. To help us, PRPC provides two options – check for consistency and check for completeness.

The Check for Consistency button verifies that there are not any unreachable paths in the rule and that there are no logic conflicts.
The Check for Completeness button populates all values that are part of otherwise, giving us an opportunity to review and maybe add logic for those conditions. Completeness is just a suggestion by PRPC and we need not always use it.

The rules can be tested by using the Run option in Actions menu.

It shows the first column, we enter a value and click the Run again button to see the second column.

VALIDATION

PRPC supports different levels of validation:

• Mode validation: This validation is automatic and always in force.
• Dictionary validation: Part of this level of validation occurs automatically and another part occurs when it is built into the application and at specific times during the process execution.
• Object validation occurs only when explicitly designed into the application.
• Another validation level which is optional and occurs only when built in the application is Constraint validation. Based on declarative constraint rules, it is evaluated automatically by the system each time a property identified in a constraint rule changes

Mode Validation leverages the property mode setting. A property mode is identified on the “General” tab of the property rule form and it is combined with property type, as shown below. The Mode Validation enforces the property mode when a value is being assigned to a property.

The Dictionary validation examines a property value in the context of the corresponding property rule. It includes multiple validation tests. The first validation test is to ensure that the property value is compatible with its type. 

The next validation test is related to the Maximum length assigned to the property.  mode properties of type Password, Text or Identifier.If the length of the input string exceeds this limit, the clipboard keeps the longer value, but the dictionary validation adds an associated error message.

We may also reference an “Edit Validate” rule which defines a Java routine that tests the validity of an input value. Normally, if user input fails such processing, the input is rejected and a red X appears next to the input field in error along with messages that may convey more about the error and the suggested remedy. “Edit Validate” validation is only possible with properties of mode “Single Value”, “Value List”, or “Value Group.” Any architect who has java knowledge can build new edit-validate rules. Or we can use any of the standard rules that are available to us.

The other validation tests performed at this level are the Control and Table validations. Both are configured in the “General” tab of the property rule form.

 The Table type field is used for this purpose.  To use table validation, first make sure to select Single Value, Value List, or Value Group for the Property Mode field as we cannot use table validation for properties of any other modes. Table values can come for any one of those in the list shown

As we just saw, “Dictionary validation” includes multiple different tests. These tests are performed by the system when:

• User input entered on an HTML form is placed on the clipboard.
• The Page-Validate method (in an activity rule) is applied to a page containing the property, or to the property if it has mode Page.
• An Edit Input rule and Property-Validate method (in an activity rule) is applied to the property. [An edit input rule provides a conversion facility. We can use edit input rules to convert data entered by a user (or received from an external system) from a format that our application doesn't use into another format. We can reference an edit input rule in the Edit Input Value field on the advanced tab of Property rule.]

This type of control and display validation can be enabled in a user interface rule as well, under the “Presentation” tab of the cell, where the property is included.  We can configure “required” fields validation in the “General” tab.

he next level of validation is “Object validation”. This validation is optional and occurs when a flow action rule calls a “Validate” rule , or when called by a correspondence rule to validate user responses to prompts, or when the “Obj-Validate” method is called in an activity.

The validation error message invalidates the page, preventing it to be persisted. The display of the validation error message can be configured or customized. 

Process Commander provides one more level of validation: the “Constraints” validation with Declare constraints rules, 

Constraint Validation

Constraints rules provide an automatic form of property validation every time the property's value changes, in addition to the validation provided by the property rule or other means. The technique used is called “forward chaining,” like in many other declarative rule types.

The system automatically adds a message to any property that is present on the clipboard and fails a constraint. No other rules explicitly reference constraints rules. When we save a constraints rule, Process Commander enforces it immediately and thereafter.

First row checks for a When condition. Here we are checking whether the client is a preferred client for any application that involves customer service. The second row is the constraint and here we are checking whether the client name has a value or not. The third line, “Else add message” allows us to add a specific additional message to become associated with that property or another property when the property fails the constraint. Like many other rules, we can use or build our own expressions for the when and constraint conditions. We may add more constraints by using the “Add new Constraint before this one” or “Add new Constraint after this one” icons.

At runtime, when the system detects that a constraint fails, it adds a message to the page of the property identified in the left portion of the “Require That” field, if any.

Because constraint validation is enforced automatically by the system anytime the property’s value changes, it might cause a performance impact. Therefore, it is critical to evaluate the potential impact before choosing this type of validation.