Declare Pages:

Use a declare pages rules to define the contents of a clipboard page that is to be available in read-only mode to
multiple requestors in your application. For example, a page may contain daily prices for a set of commodities,
bonds, or currencies, an organization chart, or quantity-on-hand inventory data extracted hourly (rather than in real
time on-demand) from an external system. These pages can be "global", available to all requestors on a node.

Pages created by declare pages rules are called declarative pages.

Declarative pages are created only when requested — the first time a requestor attempts to access a property value
on the page. Each page created and maintained by a declare pages rule has a name that starts with the prefix
Declare_. Rules of any type that can reference properties on pages other than the current or primary page —
including activities, decision rules, parse rules — can reference properties on these pages in a read-only or "right-
hand" context. Typically, the rule form identifies the name and class of a declarative page on the Pages & Classes
tab.

Page Scope
Select to determine the scope of requestors that can access the declarative pages created by this rule:

 Node — Any requestor executing on the current node can access the pages.

 Thread — The page is created in a single requestor Thread, and can be accessed as often as
needed by processing in that Thread. Accesses by separate requestors cause the rule to create
distinct pages, which may have different contents.

Page is
Fresh When Optional. Identify the When Name key part of a when condition rule to be evaluated when a requestor
accesses a page with a Page Scope of Thread.

If the when condition rule evaluates to false, the page is recomputed.

To find this rule at runtime, rule resolution uses the class in the Page Class field as the Applies To class,
and the RuleSet list of the requestor. This field appears only when the Page Scope is set to Thread.

Access
Group Select an access group that provides temporary access to the RuleSets and versions needed to access
the load activity. This field appears only when the Page Scope is set to Node.

The requestor that executes this activity uses this access group only during execution of the activity.
RuleSets made available by this access group may not be available to the requestor at other times.

Agents:

An agent is an internal background process operating on the server that runs activities on a periodic basis. Agents
route work according to the rules in your application; they also perform system tasks such as sending email
notifications about assignments and outgoing correspondence, generating updated indexes for the full-text search
feature, synchronizing caches across nodes in a multiple node system, and so on.

Agents are autonomous and asynchronous: the activities they call run individually on their own schedules, and a
second activity execution can start before one started earlier completes.
Agents are defined by Agents rules (Rule-Agent-Queue rule type). Agents are enabled and scheduled through Agent
Queue data instances (Data-Agent-Queue class). In a multinode cluster, an agent can run on multiple nodes — even
each node, to achieve high throughput, if potential deadlock and similar locking issues are correctly handled by the
activities.

The name of an agents rule is the name of a RuleSet and there can be only one agents rule defined for each
RuleSet and version in a Process Commander system. When the Agent Manager master agent notices a newly added
Agents rule (Rule-Agent-Queue), it generates agent schedules (Data-Agent-Queue instances) for each node in your
Process Commander system. If you need to modify the configuration settings for an agent from a locked RuleSet
(any of the standard Process Commander agents rules, for example), you do so by updating the generated agent
schedules. (See Pega Developer Network article PRKB-25049 How to modify an agent.)

Although agent entries are listed and have numbers, the order in which you list agents in an agents rule does not
create a sequence. Each agent activity runs individually on its own interval schedule, as a separate requestor thread.
Do not design application logic that depends on agent activities running in a specific order.

Pattern
Select one of the following to specify the schedule type for the agent activity:

 Periodic — The agent runs the activity and then "sleeps" for the number of seconds
entered in the Interval column.

 Recurring — The agent runs the activity based on a specified calendar schedule (for
example, every Monday at 5:00 P.M.).

The value you enter in this section can be overridden in the generated agent schedule instances. For
information about configuring the interval or schedule for this agents rule, see Pega Developer
Network article PRKB-25048 How to set agent schedule intervals.

Queue Mode
Indicates whether the agent uses the agent queue capability ( introduced in V5.4) to process items
from the agent queue. This feature allows the agent to temporarily skip over items that fail — for
example, because a needed resource is locked — and try again later to process the item later.

 Legacy — Specifies that this is an agent that was created in a version prior to V5.4 and has
not yet been updated. This option is not available for agents created in V5.4 or later.

 Standard — Specifies that this agent processes items from an agent queue and that it relies
on the system to provide object locking and other transactional support.

 Advanced — Specifies that this agent uses custom queuing. See Pega Developer Network
article PRKB-25045 Understanding agent queues.

As a preferred approach in new development, choose Standard. To take advantage of agent queue
capabilities, you can upgrade a Legacy agent activity to Standard. Depending on the complexity of
the activity and transaction-related design features, this may be easy to accomplish.

Auto Queue
For agents of the Standard queue mode, indicates whether the agent uses the agent queue
Management
functionality. When this option is selected, the system locks items that are retrieved from the queue
by the agent until the agent is finished with the item (commit or rollback). If a transient condition
means the item can't be processed (perhaps the work object is locked), the system requeues the item
 and the agent can try again the next time it wakes up.

When this option cleared, the queue items for this agent do not persist. That is, when an agent
attempts to process an item, that item is removed from the queue and the agent gets one chance to
process it. If it fails, the item is not put back in the queue for another attempt.

Use the Security tab to specify the access group to be used for the following kinds of agents:

 Agents whose queue mode is Legacy

 Agents whose queue mode is Advanced but they do not use the agent queue functionality

Agents with the Standard queue mode do not need access groups. For standard agents, each queue
item is processed in the authorization context of the user whose actions or processing (work object, assignment, and
so on) generated the queued task.

Starting and stopping agents

Normally, all agents start each time you start your Process Commander system. Agents running on a specific node
start as that node starts. For testing, or when otherwise necessary, you can use the System Management application
to monitor or control agents:

1. Start the System Management application.

2. Select a node.

3. Select the Agent Management menu item.

4. Click a single radio button to identify the Thread of an agent. (Each agent activity executes in a separate
thread.)

5. Use the buttons at the top of the page to start the agent, stop the agent, or pause agent processing. You
can affect only the selected activity (one row of the form) or all activities

Tracing an Agent:

http://pdn.pega.com/DevNet/PRPCv5/KB/21752.asp#TrcAgnt

Two built-in master agents are background processes operating on each Process Commander node. They are not
defined by agents rules. (Technically, these are daemons, rather than full agents.)

The Master-for-Requestors master agent monitors idle requestor sessions to enforce automatic timeouts. By
default, this occurs every 60 seconds. Your site can establish another value in the prconfig.xml file setting:
<env name="agents/requestortimeoutwakeup" value="NNN" />
The Master-for-Agents master agent starts and monitors agents defined through agents rules and agent schedule
data instances. By default, the Master-for-Agents master agent awakes every ten minutes. Your site can establish
another value in the prconfig.xml file setting:
<env name="agents/newqueuewakeup" value="NNN" />
where NNN is in seconds.
Pega-ProCom Agent:

The agents in the Pega-ProCom RuleSet process email, process service level rules and assignments, and so on. The
agents in this rule provide the following types of processing:

 Processing service level events and escalation (ServiceLevelEvents)

 Applying a flow action to assignments in bulk (AgentBulkProcessing)

 Sending out email correspondence (SendCorr)

 Retrieving PDF files from the PegaDISTRIBUTION Manager (GetConvertedPDFsFromPDM)

 Checks whether starting flows references have been updated (GenerateStartingFlows)

 Checking incoming email (deprecated in V5.3) (Email_CheckIncoming)

Use care to ensure that the Pega-ProCom agents rule has access to all the RuleSet Versions it needs. Symptoms
of incorrect configuration can include:

 Escalation events do not occur as expected

 Email correspondence is generated but not sent

Listener:

A listener is a Process Commander background process that waits on a TCP/IP port or a similar messaging facility
for arriving messages. Listeners can execute on one node or on multiple nodes in a multinode system.

Listeners are defined by data objects created with the following forms:

 Email Listener form (Data-Admin-Connect-EmailListener class)

 File Listener form (Data-Admin-Connect-FileListener class)

 JMS Listener form (Data-Admin-Connect-JMSListener class)

 JMS MDB Listener form (Data-Admin-Connect-JMSMDBListener class)

 MQ Listener form (Data-Admin-Connect-MQListener class)

Through initServices elements in the prconfig.xml file, you can control whether listeners of each class
automatically start when the Process Commander system starts. You can start and stop listeners using the Listener
Management menu of the System Management application.

To debug listener processing, you can use the Tracer to connect to the listener requestor, remote logging, or the
System Management application.

Email Listener:

Email listeners provide Process Commander with the information it needs to route email messages from an email
server to an email service rule (Rule-Service-Email rule type). They identify the email server, the name of the mail
folder to monitor, the message format of the incoming messages, which email service rule to route messages to,
and so on.

When an email listener routes a message that has files attached to it, the listener creates a page named
pyAttachmentPage (of class Data-ServiceMessage) and puts the file(s) on that page, using the properties
pyAttachNames and pyAttachValues. When you use the Email Accelerator to configure inbound email, the generated
service activity is configured to extract files from the pyAttachmentPage and attach them to the work object as work
object attachments.

When and where listeners start

Three settings affect how email listener requestors run. If a listener is not behaving as expected, examine the
following:
 Startup Option – The Properties tab contains the property that controls how the listener starts. If the Node
Based Startup option is selected, ensure that the desired node is added to the list. If Host Based
startup is selected, ensure that the desired host is added to the list.

 initServices/initEmail – At start-up, Process Commander starts execution of an email listener at

startup only if the prconfig.xml file parameter initServices/initEmail is set to true. If you notice
that your email listeners do not route messages, examine the prconfig.xml file to determine if the value
is “false.”

 Blocked – If the Blocked option on the Properties tab of the listener is selected, the listener is disabled.
Listeners with this setting do not start when the Process Commander nodes start and you cannot start them
from the System Management application (Listener Management page).

Edit Validate:

Use the Edit Validate form to define a Java routine that tests the validity of an input value in an activity that
processes user input. The activity calls the Property-Validate method, which applies the test defined in an Edit
Validate rule.

Typically, the input value arrives from a user who completes an HTML form, but it may also arrive through an
interface with an external system.

Normally, if user input fails such processing, the input is rejected and a red X mark appears next to the input field in
error. Messages may convey more about the error and the suggested remedy. The user can change the input and
resubmit the form.

Edit Input:

An edit input rule provides a conversion facility. Use edit input rules to convert data entered by a user (or received
from an external system) from a format that your application doesn't use into another format.

Edit input rules perform conversions, not validations. This rule type does not cause any response to a user
about the validity of the input. Use validate rules and edit validate rules for validations.
 Edit input rules referenced by a property rule execute automatically only during HTTP requests, not for properties
set through data mapping, Property-Set methods, or other computations.

Edit input rules use Java code for the conversion.

Flows:

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

Flows are the fundamental rules that represent business processes. They determine who works on a work object in
what sequence, what decisions and processing occur automatically, and other aspects of the business process.

After you complete and save the flow form, click the Run toolbar button ( ) to create a new work object with the
flow. (The Run toolbar button is visible only for starter flows — flows with Creates a new work object? selected on the
Process tab.)

Shapes:

Visio editing basics Screen flow rules

Flow properties Notification tasks

Start task Router tasks

Assignment tasks Service levels

Assignment-Service tasks Spin-off tasks

Comment tasks Split-Join tasks

Connectors and flow actions Split-ForEach tasks

Decision tasks Swimlane

Call or branch to subflow task Ticket tasks

FlowEnd tasks Utility tasks

Fork tasks Using freeform shapes and other stencils

Building a flow rule from an external flow

Integrator tasks
diagram

Temporary
Select to indicate that this flow creates a temporary work object. A temporary work object is created
object?
and resolved by a single operator or through straight-through processing and is never saved as a
database object.
Security

Field Description
Security
Security restrictions on flow rules can limit when, and by whom, the flow may be started. Order is not
significant in these two arrays.

Privilege Class
Optional. To restrict use of this flow rule to only those users who hold a specific privilege, enter
a class that the system can use during rule resolution to locate the Applies To key part of a privilege
rule.

When this array is not blank, a user must hold at least one of the privileges listed to start an execution
of this flow rule.

Privilege Name
Optional. Enter the second key part — Privilege — of a privilege rule to limit which users can start
this flow rule.

The system uses the Privilege Class and Privilege Name values with class inheritance to look for the
privilege rule.

When Name
Optional. Enter the second key part — When Name — of a when condition rule that specifies
conditions under which this flow rule can be started. The system uses the Applies To key part of this
rule as the Applies To key part of the when condition rule.

For example, you can restrict starting of this rule to mornings only, or to only those users in a specific
department.

When this array is not blank, the flow execution can start only if all the whens evaluate to true.

Define Flow
Identify the objects the flow rule is to update. Select:
on
 On Current Work Item to continue processing on the current (unresolved) work object in
the next flow.

 Choose On Another Work Item to start processing on a different work object.

 Choose On Embedded Page when this flow is part of a Split-forEach operation.

Screen Flow:

A flow rule that presents a user with a sequence of forms to complete is known as a screen flow. This specialized
type of flow rules provides an effective way to simplify input processing and present questions or input fields in a
series of related forms. Users can change an answer to an earlier question by backing up in the flow; and, in some
situations, can complete steps in any order.

Allowed Shapes:
To support this style of interaction, a screen flow's Visio flow diagram can contain only these shapes:

Assignment Fork

Flow SplitForEach

Connector Start

Decision Utility

FlowEnd

Because many business processes require additional shapes, you may need to create a subflow for the screen flow
iterations, and call the subflow from an unrestricted starter flow.

Call or Branch to subflow:

A screen flow rule can call or branch to another flow rule, but only if the other flow rule is also a screen flow rule and
uses the same harness rule

Split for each shape:

When using a Split-ForEach shape in a screen flow, the only flow processing mode is Iterate, which spawns flows for
elements of a Page Group or Page List property. No when conditions are available. Page Group properties are
processed unordered and all pages are shown.

Buttons for Back, Next, Submit and Cancel:

At runtime, each assignment task in a screen flow rule presents a button labeled Next>> . When users click this
button, processing validates user input and advances to the next assignment. (For tabbed screen flows and tree
screen flows, the label on the Next>> button changes automatically to Submit when this assignment is the last
one in a flow.)
A <<Back button appears automatically when a user has completed any task that is an entry point.
Optionally, screens can also include a Cancel button. To include a Cancel button:
1. Update the Parameters tab of the screen flow rule to add a flow parameter named AddCancel. Select
Boolean as the Data Type.

2. Open each calling flow rule in Visio. Locate the Flow shape that calls the screen flow subflow. On the
SubFlow Properties panel:

 Select the AddCancel parameter checkbox to cause a Cancel button to appear.

 Clear the AddCancel parameter checkbox to remove the Cancel button.
3. Add a ticket named Withdraw at an appropriate place in the calling flow rule. When a user clicks the
Cancel button during execution of the screen flow, a ticket named Withdraw is activated. Processing
typically continues at that ticket task in the calling flow execution.

Four standard rules support execution of screen flows:

 Harness: Work-.PerformScreenFlow

 Activity: Work-.CancelScreenFlow, Work-.GenerateScreenFlowFrame

 Section: Work-.ActionScreenFlow
  Text file rule for JavaScripts: Webwb.Screenflowutils.JS

Notify:

Connect a Notify shape to an assignment to cause your flow rule to send correspondence to a work party (identified
in the work object) reflecting the creation of the assignment instance. The system creates this correspondence as
the assignment is created, not later when the assignment is performed.

For example, a Notify task can send an email message to the originator work party, informing that party that an
important processing step for the work object has started, and who has received the assignment

Router:

Optional. A router activity determines which workbasket, worklist, or agent is to receive an assignment. See Atlas —
Standard activities for use in flows (interactive).

Associate a router activity with each assignment, unless the assignment is always to appear on the worklist of the
current user (the one who is currently executing the flow rule).

Allowing users to reset service levels

Optionally, your application can allow all users or selected users to change or remove the service level rule
associated with a specific assignment, through a local flow action included with the assignment shape. Copy and
adapt the standard flow action Work-.ChangeWorkSLA as needed. Include the action as a choice in the flow, and
then ensure that the appropriate users have an associated privilege to see and choose it

Spin-Off:

When a work object advancing through a flow reaches the Spin-off shape, Process Commander starts execution of a
different flow, using the current or a different work object. Processing in the current flow rule continues in parallel,
without waiting for the other flow to complete.

A flow rule that is reached and started by another is sometimes informally called a subflow; the original is called
the parent flow. However, no field on the rule form marks a flow rule as a subflow; the term describes how a flow
rule is referenced rather than its characteristics. Some Business Process Management materials use the term
subprocess for a branch flow.

Use the Flow shape rather than a Spin-off shape to start a synchronous flow execution, in which the current flow
execution pauses while the subflow executes

On Another Work Item

If you choose On Another Work Item, complete the following fields. Complete either the Work Property field, Page
Name field, or both.

 When a Work Property value is supplied but the Page Name field is blank, the other work object is opened
base on the supplied key into a new page named pyNextObjZZZZ, where ZZZZ makes the page name
unique.
  When both Work Property and Page Name are supplied, if they specific a common page, that page is locked.
If they specific different pages, the page named in the Page Name field is unlocked and the other work
object is opened into that page (overwriting the previous contents)

 If the Work Property field is blank and a Page Name is supplied, that page is assumed to contain the other
work object, and a lock is acquired.

Split-Join:

Use the Split-Join shape to require that multiple subflows of your flow be completed before the current flow
continues execution. This allows subflows to execute asynchronously, in parallel. For an example, see the standard
flow Work-.ParallelWork.

For example, a mortgage application workflow may require that facts about the home buyers be validated, and that
a title search be completed. These two tasks are unrelated and can be performed in subflows that proceed
independently and in parallel. Other processing later in the primary flow can require that both these two subflows
complete.

Join When..
Choose Any or All. Choose:
Flows are
Finished  All if the current flow is to resume only when all the split subflows return.

 Any, if processing in the current flow is to resume after any one of the split subflows
completes. At that time, processing of the other split subflows that have not completed is
stopped. Open assignments for these subflows are cancelled.

Split-ForEach:

The Split-ForEach task provides a form of searching or enumeration over the pages in a property. Use a Split-
ForEach shape to iterate over the pages of a Page List or Page Group property. For each page, you can
conditionally start a flow execution for the work object.

Processing in the original flow pauses while the subflows execute. Processing in the original flow can resume after all
the subflows complete, or after the any one of them completes. For an example, see the standard flow
Work-.StandardApprovalsAll or similar "approvals" flows.

You can't use the Split-ForEach shape to create work objects. At runtime, this shape process the work object's
embedded Page List or Page Group properties; the embedded pages must exist before the Split-ForEach shape
is reached.

Join
Select Any, All or Iterate. Choose:

 Any to cause processing in this flow execution to resume after any one of the split subflows completes.
At that time, processing of the other split subflows — which have not completed — stops. Open
assignments for these subflows are cancelled. (If you choose Any and at runtime one flow execution
ends before some others are started, the others are not started.)

 All if the current flow is to resume only when all the split flows complete and return.

 Iterate to spawn flows for elements of the Page Group or Page List property one-by-one, testing
conditions you list below to determine whether to continue.
 If you choose Iterate, execution of the subflows must not alter the index values in the Page Property value,
to prevent unreliable results. For example, if an activity in the subflow started for the fifth element of a Page
List deletes the first element of the Page List, the original sixth element (now fifth) may be unintentionally
skipped.

When used in a screen flow, there is no Join option in a Split-ForEach task. The only processing mode is
Iterate. The conditions When and Abort Iterations are not available. A Page Group property used in a
screen flow Split-ForEach task is processed in an indeterminate order and all pages are shown. Therefore, Page
Group-specific iteration settings are not available; that is, you cannot determine a different order as you can in
a regular flow.

Ticket:

Use the Ticket shape ( ) to mark the starting point for exceptions that may arise at any point in the flow, such
as a cancellation. The ticket is a label for a point in a flow, much like a programming "GOTO" destination.

An activity executing anywhere in your entire Process Commander application can set or raise this ticket by
executing the Obj-Set-Tickets method with this ticket name as a parameter.

A raised ticket causes the system to search for any executing flow (on the same or a different work object) that
contains this ticket. If found, processing stops on that flow promptly, and resumes at the ticket point

*If a task shape has more than one ticket shape connected into it, then processing continues with that task only
after all tickets are set.

Utility:

A utility task is an activity that can update a work object without human input. It may perform computations,
searches, retrieve data from another system, make a decision affecting the course of the flow, and so on.

Some utility tasks appear in the flow immediately before an assignment task, to complete preprocessing. Others may
appear immediately after an assignment task, for post-processing of user decisions and input.

You can add a Utility shape by dragging an activity rule of the following types from the Application Explorer onto
the Visio diagram:

 Locate

 LoadDeclarativePage

 OnChange

 Trigger

 Validate

 Utility
Business processes that can usually or often be performed completely automatically, with no human intervention,
are said to support straight-through processing (STP).

A flow rule that contains no assignment tasks by definition implements straight through processing. A flow rule that
contains assignments that apply only for unusual, rare situations also can be considered straight.

Requests completed with straight-through processing are sometimes called "one-and-done" requests, though this
term is also used of requests that require only one user decision or input, or one customer interaction.

Case Type:

Case type rules enable you to nest cover objects within other cover objects in a parent-child hierarchy. This
capability helps centralize flow processing and monitoring among multiple work types in large applications. To use
the rule, add it to a cover class and define the work classes you want to cover. You can nest any number of parent
and child covers.
You can also add a case type rule in any work class to specify flows that can be started in an open work object
created by a previous flow execution. These flows appear in the pull-down list when a user clicks the Start New
Process list.

Agent

The Pega-ProcessEngine agent supports calculations defined in case type rules. If your application includes these
rules, enable the Agent Schedule instance for this agent

Correspondence:

Build correspondence from multiple paragraph rules and fragments, allowing re-use of smaller pieces
such as headers, footers, or body text across many correspondence rules.

Our standard types of correspondence are available:

 Email
 Fax
 Mail (letter)
 Phone Text

Where referenced

Rules of three other rule types can reference correspondence rules:

  Flow rules, using Notify tasks
 Flow action rules, indirectly through activities identified on the Action tab
 Activities

Process Commander’s correspondence feature is supported by the following:

 Work parties. A work party is a person or organization associated with a work object. Correspondence can
be sent only to people who are identified as work parties.
 Correspondence rules. These rules provide the content and logic that flow processing uses to generate
customized correspondence for the recipient.
 Correspondence flow actions. When the (human) operator working on an assignment needs to specify
information about what to send and who to send to, use correspondence flow actions. (Ex: Notify and
SendCorrespondence)
 Correspondence activities. If the same piece of correspondence is to be sent to the same work party for
every work object created by a flow, there’s no reason to make operators do any work. In this case, use flow
shapes and standard activities to configure correspondence to be added programmatically.
 Background correspondence processing. Process Commander’s flow processing and agent activities take
care of correspondence generation and processing in the background

Flow Shapes and Correspondence Activities

When the same piece of correspondence should go to the same work party for every work object created by a flow,
you configure the flow to provide the correspondence programmatically. Which flow shape to use depends on if it is
a notify message for an assignment.

 To send automatic notification messages about assignments, use the notify shape with one of the standard
notify activities (Work-.Notify, for example).
 To send any other kind of correspondence programmatically, use the utility shape with the Work-.CorrNew
activity.

Work Object Attachments and Correspondence

 Several standard flow actions prompt operators to attach files of some kind to the work objects they are
assigned. For example, the AddAttachments flow action enables users to upload a single file and select a
category for it while AddMultipleAttachments enables user to select multiple files and choose a category for
each.
 Correspondence processing can use work object attachments as email attachments. For example,
theCorrNew activity has an input parameter for attachment category. At runtime, if the category parameter
has a value and a file has been attached and identified by that category, correspondence processing
attaches the file to the email message.
 Additionally, when an operator interacts with the SendCorrespondence flow action, if there are any work
object attachments, the form displays them and the operator can select which ones should be email
attachments. Here's an example of one of the BuildCorr screen flow forms when a work object has an
attachment

Background Correspondence Processing

The standard activities and flow actions that you use to add correspondence generation to your flows are used by
the flow and correspondence processing that generates email messages or Word documents or PDF forms in the
background. All you have to do is reference the CorrNew activity or correspondence flow actions in the appropriate
places in your flows and Process Commander takes it from there.

Correspondence processing queues up the messages or documents to be emailed, printed, or faxed in theAssign-
Worklist queue. The Pega-ProCom agent activity named SendCorr runs every 30 seconds and processes all the
correspondence in the Assign-Worklist queue.
Summary of Steps

The following list summarizes the general steps for configuring correspondence generation in your flows.

1. Create the work parties rules that associate work party roles with your work classes.
2. Configure an email account object (Data-EmailAccount) that holds information about the email server and
user account flow processing should use to send outbound email.
3. Create correspondence, correspondence fragment, and HTML stream rules.

Configure your flows to call the standard correspondence activities and flow actions at the appropriate places.

Also get info from http://pdn.pega.com/DevNet/PRPCv5/KB/24210_3.asp

What are the ways available to send a correspondence in PRPC?

Our standard types of correspondence are available:

Email

Fax

Mail (letter)

Standard flow actions

These standard flow actions support correspondence:

 Work-.Notify, Work-NotifyQuick, and Work-.NotifyExternal support interactive correspondence.

 @baseclass-.SendCorrespondence starts a screen flow to gather and validate correspondence details, before
sending the correspondence.

 Work-.AttachandHold and Work-.EditCategorizedAttachments support Word correspondence of a user-

selected attachment category.

Standard activities

In flow rules, you can use the two standard Notify activities named Work.-NotifyAll and Work-NotifyAssignee for
correspondence related to an assignment.

Use the standard utility activity named Work-.CorrNew to generate correspondence without any user interaction.
When you use this activity to generate email correspondence, you can set parameters so that all work object
attachments, or all attachments of one or more specified categories, become attachments to the email message.
Optionally, you can send the email to multiple TO: work parties, one or more CC: work parties, and one or more
BCC: parties. You can associate a priority level of High or Low with a message, as expected by Microsoft Outlook.

Three standard low-level activities support outgoing email. Typically, these are called only by other standard
activities:

 Data-Corr-Email.Send — Can send in plain text or HTML format

 @baseclass.SendEmailNotification

 @baseclass.SendEmailNotificationwithAttachments
 In most situations, use only the Work-.CorrNew activity, a notify activity, or a flow action such as
@baseclass.SendCorrespondence rather than calling any of these three low-level activities directly. This approach
assures that

 all needed parameters are gathered and validated

 the outgoing email is associated with a work object and that the email appears in a work object History and
Attachment display, supporting common legal or compliance requirements.

Service Level:

Service level rules define three time intervals, known as goal, deadline, and late intervals. The goal time is the
smallest time interval, the deadline time is a longer interval, and the late interval defines post-deadline times. Each
time interval is in days, hours, minutes, and seconds.

Service level rules can be associated with a work object or an assignment. When the time interval defined by the
service level is reached without the assignment being performed (or the work object becoming resolved), escalation
occurs.

Escalation can change the urgency value of the assignment or work object, send it to someone else, send an alert or
email message, cancel the work, or initiate other processing.

The Pega-ProCom agents rule — a background requestor — detects goals and deadlines not met and performs
escalation processing. To make your application's custom service level rules visible to this agent, update the access
group for the Pega-ProCom agent schedule data instance to include your application RuleSet versions.

Assignment Ready
Indicate how the system determines the starting time for assignments (or work objects)
associated with this service level rule. In most cases, choose Immediately:

 Immediately — Assignments associated with service levels are immediately sent to a

worklist, a workbasket, or to a Directed Web Access email. This setting indicates that the
assignee can work on the assignment as it is created — as soon as it arrives on the
worklist or workbasket.

 Define from a Property — Instructs Process Commander to use a DateTime

property value you specify to determine when the assignee can optimally begin work on
the assignment.

 Interval from assignment creation — Sets a delay period (defined in other

fields) before the assignee can start work on this assignment. For example, you can
compute a start time for the assignment seven days after it is created. If you choose this
option, complete Days, Hours, Minutes, and Seconds fields for the calculation.

In some situations it is beneficial for the application to create an assignment but not realistic to
expect a user to start work on the assignment for a while. This computed field identifies a
recommended but not binding "not-before" date and time for an assignment associated with a
service level. It determines the value of the Assign-.pyActionTime property.

For example, if completing the assignment depends on a user accessing end-of-trading-day

security prices, the start time of the assignment can be set to 4:30 p.m. New York time, when
many United States security markets close.

The system derives the computed start date and time value independently from the goal and
 deadline date and time values.

(no label)
Select whether you want goal and deadline times to be fixed, constant intervals recorded on this
form, or the value of a DateTime property:

 Interval from when assignment is ready — Enter fixed numeric values in the Days and
HH:MM:SS fields to define goal and deadline intervals.

 Set to the value of a property — Goals and deadlines are defined as the value of a
property rather than fixed intervals.

For example, a mortgage or bond may have a known, fixed maturity date that doesn't depend on
when processing starts on it. A property in the work object, not a fixed time interval, may
become the goal or deadline date.

Allowing users to reset service levels

Optionally, your application can empower all or selected users to change or remove the service level rule associated
with a specific assignment or work object, through a local flow action included with an assignment. (These can be
helpful when testing service levels, even if they are removed or restricted later.)

 Include the ChangeAssignmentSLA flow action to allow a user to review, or modify, the service level
associated with an assignment.

 Include the ChangeWorkSLA flow action to allow a user to review, or modify, the service level rule associated
with a work object.

Include the flow action as a choice in the flow, and then ensure that the appropriate users have an associated
privilege to see and choose it.

Business day calculations

If the Business Days checkbox on the General tab is selected, the system calculates the goal or deadline interval
using a calendar data instance (Data-Admin-Calendar class). The calendar instance may identify normal weekly
closing dates and holidays that are skipped over in business day calculations. The calculation occurs as the
assignment is created. The calculated dates and times are not revised if the service level rule or the calendar
changes later.

Different work objects may employ different calendars. For example, in some areas, Saturday may be a work day,
while other areas are closed. Some offices may observe holidays that others do not.

To locate the calendar for an assignment, Process Commander looks in three places in sequence:

 A calendar referenced in the work object to which the assignment belongs (in the property named
Work-.pyCalendar or an override property of that name.

 A calendar associated with the current operator (who may not be the assignee for the assignment). The
calendar for an operator can be recorded in the Operator ID data instance or in the Organization instance
referenced in the Operator ID data instance.

 The calendar named Default.

A Calendar data instance has two key parts — a name and a start date. References to calendars identify only the
name key part. The system uses the calendar instance with a name that matches the supplied name key part and a
start date closest to — but not later than — today's date

Skill:

Use skill rules to name and set proficiency rating ranges for a user skill that is important to your application. For
example, some assignments may require users who have one or more of the following skills:

 Reading proficiency in Spanish

 Speaking proficiency in Cantonese

 A Series 7 license from the National Association of Securities Dealers (NASD)

 Completed company training in customer service skills or new products

Validate:

Use validate rules to help users enter valid property values into an HTML form or to validate data received from
another system or source. A validate rule can test input values against conditions defined as part of the rule. When
a value does not pass the tests, the system adds one or more messages to the clipboard page containing these
values, marking the page as invalid.

Creating a validate rule is simpler than creating a custom activity that validates user input.

Don't confuse validate rules with edit validate rules; the latter require Java programming skills to develop.
Validate rules can call edit validate rules.

Work Parties:

A work party is a person, organization, or other actor identified in a work object, who can be the recipient of email
or other forms of correspondence.

A work object may identify no work parties, one, or many work parties. The work party role associated with each
work party identifies why a party is present, and may determine which properties are defined for that party.

Five standard data classes derived from Data-Party are available for capturing information about work parties:

 Data-Party-Com — For business organizations

 Data-Party-Gov — For government organizations

 Data-Party-Operator — For Process Commander users (who each have a Data-Admin-Operator ID instance)

 Data-Party-Org — For nonprofit organizations

 Data-Party-Person — For people who may not be Process Commander users with Operator IDs

Your application can include other classes derived from Data-Party or from one of the above concrete classes.

Declare Onchange:
Create Declare OnChange rules to run an activity automatically at activity step boundaries when the value of a
specified property changes. This capability provides a form of automatic forward chaining.

For example, a Declare OnChange rule can update a year-to-date counter property (an integer) to track how many
times a work object status changed in value. Another Declare OnChange rule can compute the average dollar
amount of work objects entered by a work group, in real time.

Declare OnChange rules can force all processing on a work object to be suspended pending an independent review
of the situation. The independent review is supported by one or more flow rules. This feature can support
compliance, fraud detection, and quality control staffs.

Where referenced

No other rules explicitly reference Declare OnChange rules. After you save a Declare OnChange rule, Process
Commander immediately thereafter runs it when and as needed.

Declare Trigger:

Create Declare Trigger rules to cause an activity to run when instances of a specific class are created, updated, or
deleted in the database. This implements a form of forward chaining.

For each Declare Trigger rule, Process Commander monitors database operations for objects of the Applies To class
(and concrete classes derived from that class). During database commit processing, forward chaining processing
may trigger — start execution of — the activity identified in this rule.

For example, a Declare Trigger rule can execute an activity each time an instance of Data-Party-Person class is
saved with a modified ZIP code (property Data-Party.pyPostalCode). The activity might send an email message to
the sales representative whose territory includes the new address. Similarly, a Declare Trigger rule can implement a
form of logging or audit history for a class, recording the date, time, and other facts.

Where referenced

No other rules explicitly reference Declare Trigger rules. After you save a Declare Trigger rule, Process Commander
immediately begins to run it when and as needed.

Harness:

Use harness rules to define the appearance and processing of work object forms used in your application to create
work objects and process assignments.

Process Commander includes more than a dozen standard harness forms for entering, reviewing, updating, and
processing work objects and assignments. Your application can override the standard rules to extend and tailor them
to specific needs.

Most standard harness forms incorporate one of these words in the Purpose key part:

 New — Support initial entry (creation) of the object.

 Perform — Support users completion of assignments.

 Review — Display the work objects in display-only mode, with no fields changeable.
  Confirm — Accept a text note explaining a user's reasoning about a recently completed assignment.

 Reopen — Support reopening a previously resolved work object.

 PrintReview — Support printing of all the fields.

Activities and clipboard page names

Use the standard activity @baseclass.Show-Harness to display harness forms. This activity and the standard harness
rules expect to find (by convention) objects on the following page names:

 pyWorkPage — Conventional name for the page that contains a work object. This page usually has a class
derived from the Work-Object- class.
 pyWorkCover — Conventional name for the page that contains a covering work object, if one exists. This
page has a class derived from the Work-Cover- class.
 NewAssignPage — Conventional name for the page that contains an assignment object. This page has a
class derived from the Assign- base class.

These page name conventions need not apply to applications that do not depend on harness rules; the work
object page may have any name established in the flow.

Presenting Flow Actions:

Harness rules that allow users to select from multiple flow actions (often called Perform harness rules) contain an
action section. The action section can present user options in a number of ways, and the developer can choose the
method that best suits the workflow and expectations of those who will be processing work objects. The action
section can display options in a dropdown menu, as a series of buttons, or as a series of links.

To configure the display:

1. Select the harness and, in the Layout tab, change to wireframe mode.

2. Select the section using Work-.pyActionArea and click the magnifying glass to display its properties panel.

3. Click the magnifying glass beside the Include Section field to display the section's parameters panel

4. Select the display option for actions that you prefer: buttons, dropdown menu, or links.

If you choose the Drop Down option, a checkbox appears. Check this
option to have the most likely action (determined by the percentages
established for each action in the flow chart) appear as the action
section title. The other possible actions appear, in descending order of likelihood, in the dropdown menu. Users can
then just hit the Submit or Continue button at the bottom of the screen; if they want to choose a different action,
they can pick it from the dropdown menu.

If you do not select this option, the dropdown menu has the label "Take Action", and the most likely action appears
as the first selectable option.

Flow Action Types:

 A local flow action may update the assignment and the work object, but retains the flow at the same
assignment task, allowing the current user (or another user in some cases) to choose another flow action.
  A connector flow action, corresponding to a connector arrow in the flow rule, updates the work object,
completes the assignment and advances the work object in the flow.

Privileges

For example, you can restrict a Cancel flow action to only users who hold certain privileges. You can restrict use of a
DeferToTomorrow flow action to be visible only after 4:00 P.M.

Order is not significant in these arrays. Access to the flow action requires that users hold at least one of the
privileges listed and that at least one of the when condition rules evaluates to true.

Field Description
Privilege Class
Optional. Enter the Applies To class — first key part — of a class the system is to use to find a
privilege rule. Leave blank to refer to a privilege with an Applies To key part that matches the first
key part of this flow rule.

Privilege Name
Optional. Enter the — name second key part — of a privilege to restrict access to this flow action to
those users who hold the privilege.

The system uses the Privilege Class and Privilege Name values with class inheritance to look for the
privilege rule.

A user that holds any one of the privileges in this array can see and select the flow action. You
hold a privilege if at least one access role in your access role list that grants access to the privilege.
The association of access role names and privileges is defined by Access of Role to Object rules.

When Name
Optional. Identify one or more when condition rules to control whether, when, or which users at
runtime can select and complete this flow action. This feature can further conditionalize the
availability of this flow action, based on data associated with the work object, the user, or other
facts.

For example, you can restrict a flow action on assignments involving more than $2,000 to appear
only to managers. Alternatively, you can restrict a flow action to appear only before a 4:00 P.M.
daily cutoff time.

***
For both section rules and harness rules, the system generates HTML from information provided in the rule form as
it saves the rule form. Note these important differences:

 A harness rule creates a complete, well-formed HTML document, starting with the <HTML> tag and ending
with the </HTML> tag. A section rule corresponds to a well formed segment of HTML text, but not an
entire HTML document.

 For a harness rule, you can review but not directly edit the system-generated HTML, accessed from the
HTML tab. For a section rule, if the Auto-generate HTML? checkbox is cleared, you can edit the generated
HTML text.

Access Role Name:

An access role rule defines a name for a role, and represents a set of capabilities. To deliver the capabilities to
users, you reference the access role name in other rule types to assign the access role to users and to provide, or
restrict, access to certain classes.

Create access role names using the format application name:role name, where application name is the name of
your application and role name is the name of a role that uses the application.

An access role identifies a job position or responsibility defined for an application. For example, an access role can
define the capabilities of LoanOfficer or CallCenterSupervisor. The system grants users specified capabilities, such as
the capability to modify instances of a certain class, based on the access roles they acquire at sign on.

The Access Role form defines only the existence of a new access role. It contains no other information and
conveys no capabilities. Through other rule types, access roles provide users various types of access to classes.
They provide a finely tuned differentiation of categories or groupings of users of your application

Access Role Editor:

Use the Access Role Editor to define or update up to four interrelated rules through a single facility:

 Access roles (Rule-Access-Role-Name rule type)

 Access of Role to Object rules (Rule-Access-Role-Obj rule type)

 Privileges (Rule-Access-Privilege rule type)

 Settings (Rule-Access-Setting rule type)

The editor provides a unified approach to creating and updating the rule forms directly. The results are the same.

Access Deny:

Use an Access Deny rule to restrict users who have a specified access role from accessing instances of specific
classes under certain conditions. Denial of access to the class can depend on the production level value (1 to 5) of
your system or whether certain Access When rules evaluate to true.

By default, Process Commander denies all access to a class except when explicitly granted by an Access of Role to
Object rule. However, government, or company regulations and policies sometimes require explicit denial of access
to specific capabilities. In these cases, use Access Deny rules to explicitly deny access to an access role and class
combination

Database Table:

Create database table data instances to map classes or class groups to database tables or views. You can use the
Database Table form to revise existing class-to-table relationships.

A database table instance associates an existing class (and other classes derived by pattern inheritance from that
class) with an existing relational database table or view, in the PegaRULES database or an external database.

Typically, a developer working in coordination with a database administrator maintains database table data
instances.

Declare Index:

Indexing can improve database performance and facilitate reporting. Create a Declare Index rule to define criteria
under which Process Commander automatically maintains index instances for faster access. 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.

Index instances are sometimes called alternate keys or secondary keys. The system saves indexes as instances of
concrete classes derived from the Index- base class.

Class Group:

A class group data instance unifies a set of classes in the PegaRULES database that share a common name structure
and common key structure. A class group causes all instances of these classes to be stored in one database table,
As a result, processing can later convert an instance of any member class from its current class to another class
within the class group, without affecting the key structure or changing the database table that holds the instance.

Class groups are primarily used to group a set of related subclasses of the Work- base class; such class groups are
also known as work pools.

PAL:

Use the Performance tool to understand the system resources consumed by processing of a single requestor
session, or the SQL statements sent to the PegaRULES database by the requestor session.

Process Commander always accumulates cumulative resource statistics for the Performance tool. Use the tool to
display these statistics, and to identify incremental resources (in the delta rows) consumed by your processing.
Because this feature displays existing data, its use does not degrade processing.

The Performance tool is sometimes known as PAL.

Using this data, you can assess possible sources of improved performance (faster response time or higher
throughput) through software changes, hardware changes, or rule changes.
As Process Commander operates, it collects statistics about the demands made on processing resources, and the
server system's response. The Performance tool summarizes and formats these statistics and presents them as
HTML pages.

Performance data shows the processing demand statistics of your work since you connected, and may help you
assess the performance impact of various approaches or configuration choices.

The DB Trace facility logs all SQL interactions between your Process Commander session and the PegaRULES
database.

Performance statistics can help you distinguish between performance issues that arise in the Process Commander
server, the PegaRULES database, or external systems called by the workflow. In all cases, the statistics can help you
determine how to improve performance.

DB Trace:

You can monitor the interactions between Process Commander's server engine and the PegaRULES database or
other relational databases, and the operation of the rule cache. Familiarity with SQL is required to interpret the
output. To use this facility:

1. Open the Full details window.

2. Click the DB Trace Options link to set up which database events are monitored. See Setting DB Trace
options.

3. Click the Start DB Trace link to turn on the facility and record SQL statements that Process Commander
sends to the database software.

4. Click Stop DB Trace to end data collection and access the trace results as a text file or with Microsoft Excel.
See Interpreting DB Trace Results.

Unlike the resource statistics feature, the DB Trace feature is normally off. Use the DB Trace feature only for
a brief interval. When enabled, DB Trace processing can produce voluminous output and may adversely affect
session performance.

The DB Trace tool link is not displayed in a production system — a system with the Production Level on the
System form set to 5. In addition, the DB Trace is available only to users who have the PegaRULES:SysAdm4 access
role. These access roles provide access to the standard privilege named Code-Pega-.PerformanceTools.

You can start and stop this tool from an activity, by calling the standard activity Code-Pega-
Requestor.SetRequestorLevelDBTrace to turn the DB Trace tool on and off. This activity sets the
pxRequestor.pyDBTraceEnabled property; the tool closes the output text file when tracing is turned off.

System Management Application:

Use the System Management application (SMA) to monitor and control caches, agents, requestors, listeners, and
other processing in your Process Commander system. Consult the System Management Application Reference Guide
5.1 for more information on this utility.

Capabilities
Using the System Management application, you can:

 Review the memory used by the Java Virtual Machine on the server.

 Review the most recent ServletRequest and HTTPRequest details.

 Display the prconfig.xml file.

 Access any requestor and view the clipboard, start the Tracer, examine performance statistics, and
terminate requestor processing.

 View executing threads and their characteristics.

 View, stop, cycle, or restart agents and listeners.

 View open JDBC database connections.

 View rule cache statistics, and empty the cache.

 Force extraction and recompilation of the functions in a library.

 Extract and compile one activity rule or model rule.

 Start or stop remote logging.

 Observe the utilization of requestor pools supporting stateless services.

 Review the status of the Java class loader.

PegaRULES Log Analyzer (PLA):

The PegaRULES Log Analyzer (PLA) is a Java program that can parse, consolidate and summarize Process
Commander logs of all three types — Pega log (also known as the system log or console log), Alert log, and JVM.
You can use PLA results to identify, diagnose, and help remediate issues that may affect performance, stability, or
scalability.

Work object prefix:

How to start spin off from activity:

In your primary flow, add a utility shape where you want the spin-off to occur . You can use the standard
activity Work-.SpinoffNewWork (in v4), or create your own. This activity needs to runs the following steps:

1. Creates a new page — call it SpunoffWork — of the class passed by the parameter classname, applying the
model passed by the parameter modelname.
2. Creates a new ID for the spun off work object.
3. Calls the Work-.SaveNew activity which initiates the flow for the spun off work.

In most cases, you will want to supply a custom activity in your RuleSet and work class. You may want to save the
spun off work's pyID to a property on the primary page

Clipboard:

Every connected Process Commander requestor (including browser-based user, even if unauthenticated guest users)
has an associated temporary memory area on the server known as the clipboard. The clipboard has a hierarchical
structure, consisting of nodes known as pages, most of which have a name and an associated class.

Pages act as buffers or temporary copies of object instances (of that class) that are copied from, or may later be
stored into, the PegaRULES database or another database.

Top Level Pages

The clipboard contains three broad categories of top-level pages:

 User pages

 Declared pages, produced by Declare Page rules.

 System-managed pages, including the requestor page, process page, application page, thread page,
Operator ID, Organization, OrgDivision, and OrgUnit.

Use the Clipboard tool when developing and debugging to:

 Examine property values and messages associated with them

 Find the information necessary to reference a property — the page names and the property name

 Quickly create, update, delete, and modify pages using the Action menu

 Quickly start activities and flows using the Action menu

What properties don't appear?

 The Clipboard display includes only a few of the many properties with names that start with pz. Such
standard properties support internal operations.
 To see pz properties and other clipboard entries that aren't truly properties, right-click in the left panel and
select Show XML. To see the contents of unnamed pages, use the Tracer.
 The primary pages of some activities are not named and don't appear on the Clipboard display. The
parameter page of an activity is not part of the clipboard. Use the Tracer to view these pages.
 Properties of mode Java Object, Java Object Group, and Java Object List do not appear on the
Clipboard tool display.
  The Application page contains much, but not all, of the properties that make up the requestor's
application rule

Logging Levels:

Use this tool to support debugging by temporarily overriding the severity settings in the prlogging.xml file for the
current node.

For example, you can change the logging level for activities in the Work- class from FATAL to DEBUG. Thereafter,
Olog() calls in Java steps that have a severity setting of DEBUG or lower appear in the Pega log.

The changes you make take effect immediately and remain in force until the server on the node is stopped, or until
you or another developer use this tool again to reset them.

The prlogging.xml file is not altered. Logging on nodes other than your current node is unaffected.

Select a level to be applied. Each level causes messages of that level and all lower levels except OFF to be
included:

 ALL — Same as DEBUG

 DEBUG — Least severe

 INFO

 WARN

 ALERT

 ERROR

 FATAL — Most severe

 OFF — No messages logged

Through the Log-Message method or Java oLog() calls, your code determines the severity of each message.

RAP:

Complete the Product form to define a rule that identifies the RuleSets and versions, rules and data objects, and
other parts of an entire application. This rule supports the migration and delivery of an application to other Process
Commander systems.

After you complete and save a product rule, you can generate a ZIP file containing:

 Rules in RuleSets and versions comprising a specific application.

 Rules in selected RuleSets and versions.

 Instances within any class. These can be filtered using a list view rule, or can be individually selected from a
list.

 A post-installation Read Me display.

Backward Chaining:

Through a powerful technique known as backward chaining, Process Commander allows a computation to
advance even when the value of an input or parameter property is not available.

Declare Expression rules (Rule-Declare-Expressions rule type) and the Property-Seek-Value method work together to
provide this capability. The system uses the internal dependency network of property relationships to develop
inferences about how to obtain the missing property value.

Such computations are sometimes called goal-seeking, as the system reaches a final goal (finding a value for
property X) by completing other goals (finding a value for properties that allow X to be computed).

Forward Chaining:

Forward chaining is an internal mechanism that provides the automatic propagation of changes in one property
value to changes in other property values or to indexes.

In a Declare Expression rule, constraints rule, or Declare Index rule, you can establish required relationships among
properties. When an activity step changes the value of a property that is defined in such rules, the system
automatically consults an internal dependency network to see if other values are affected, and performs property
value computations, indexing, and other processing as determined by the network. This is known as forward
chaining.

Similarly, Declare OnChange and Declare Trigger rules implement automatic processing when certain database or
property value conditions are met.

Forward chaining operates only when the source properties are not marked as invalid. If a property has an
associated message, forward chaining halts.

Cache:

 Rule cache — Per node. Reduces PegaRULES database traffic, contains copies of rules recently accessed
or recently updated by developers. Occupies virtual memory. The PegaRULES agent, during the periodic
system pulse, invalidates rules in the rule cache that were recently updated on another node.

 Rules Assembly cache — Per node. Tracks rules for which Java generation and compilation is complete.
Formerly known as the FUA cache. Located in virtual memory; links to loaded Java classes.

 Rule Resolution cache — Per node. Supports faster rule lookup; in virtual memory.

 Lookup List cache — Per node. Consists of XML files saved on disk containing the results of list view
reports, such as used by the Application Explorer and Class Explorer

 Static Content cache — Per node. Compressed text and image files on disk corresponding to extracted
binary file rules and text file rules. Contains a subdirectory for each RuleSet list. Supports ordinary HTTP
serving.

 Personal rules cache — Per node. Similar to the Rules Assembly cache, for rules checked out into private
RuleSets by developers.
  PegaRULES database cache — System-wide. Provided by Oracle, Microsoft SQL Server or other database
software, not by Process Commander software. This can be an important factor in performance, but
managed independently of Process Commander server caches.

 Conclusion cache — Similar to rule cache, for field value rules and a certain property rules; also called the
dictionary cache.

 Browser cache — On each user's workstation; for Internet Explorer, also known as Temporary Internet
Files.

 String pool cache — Reduces memory requirements

 Declarative pages cache — Holds the contents and status of those declarative pages that have a node-
wide scope.

 Declarative Networks cache — Supports declarative processing.

For more information about these caches, search the Pega Developer Network for Rule Caches (May 2006), a
PDF document.

Use the System Management Application to learn the current count and size in bytes of the rule cache, rule
assembly cache, declarative pages cache, and conclusion cache.

Work Object ID:

A work object ID is the permanent, external identifier of a work object, the value of propertyWork-.pyID.

Prefix and Suffixes:

By default, the system assigns a permanent work object ID automatically as a work object is created. The standard
utility activity named Work-.GenerateID uses the standard propertiespyWorkIDPrefix and pyWorkIDSuffix in its
computation.

For every work object, the work object ID is required to contain either a prefix or suffix. For example, the prefix of
work object Q-1432 is Q. The prefix of the work object MORT-763-K4 is MORT. The suffix of work object 15378-DR
is DR.

If you don't specify a prefix (on the Details tab of the application rule), the Work-.GenerateIDactivity uses W- as the
prefix and no suffix. The Work-Cover-.GenerateID activity uses C- as the default prefix. Conventionally, the F- prefix
is used to identify folder work objects.
The internal class Data-UniqueID supports work object numbering, and ensures that work object IDs are unique
system-wide, not just within an application or organization. (Accordingly, when two applications that both use W- as a
prefix on one system are accessed by separate users, users of each application may notice gaps in numbering.
Similar gaps are be visible if one application is used by two organizations with separate staff members. This is
expected.)

Typically, the prefix and suffix are determined by a model rule — conventionally namedpyDefault — for the work type
or the class corresponding to the class group. The model is referenced on the Process tab of the flow rule that
creates the work object.
For applications created with the Application Accelerator, the work object ID has a prefix of one to five alphanumeric
characters, and no suffix. The worklist display and many standard reports assume that a work object ID is no more
than 18 characters long, counting the prefix, the number, the suffix, and one or two dash characters. Your application
can use longer object IDs but this requires you to customize all the reports and displays you use in the application.

For the work object IDs of your application, you can use prefixes only or both prefixes and suffixes. The standard
function compareWorkIDs (in the Pega-RULES:Sort library) expects work object IDs in the form ZZZ-NNNN-ZZZ.
That is, the IDs start with a prefix that ends in a dash character and (if there are also suffixes) end with a suffix that
begins with a dash character.

Cannot use work object IDs to count work objects :

Although every work object has a unique ID, your application may include "gaps" in work ID sequencing, arising from
many causes. For example, if a Commit method fails and a Rollback occurs after work object W-6666 is assigned,
the work object is not created and the number is never reused. This results in a gap between W-6665 and W-6667.

Accordingly, you cannot rely on work object numbers as an exact count of new work objects created during an
interval.

Uniqueness of work object IDs

When one system hosts two or more independent organizations using a common application, it is important
that each organization have its own dedicated work pools and work types.

When required, you can relax this constraint by overriding the standard GenerateID activity, being careful to
ensure uniqueness of work object IDs in the appropriate realm. For example, the Application Accelerator uses an
activity PegaAccel-.GenerateID that allows users from multiple organizations to use this accelerator without
collisions on work object IDs. However, consider carefully the long-term design implications of such an override.

In releases before Version 4.2SP5, work object numbering was unique only within organization; two separate
organizations on one system could each have a work object numbered W-1234. This approach is not recommended
for new applications.

pc_data_uniqueid table

Instances of the concrete class Data-UniqueID (stored in the PegaRULES database tablepc_data_uniqueid)
store the most recently assigned work object ID for a specific prefix.

The property Data-UniqueID.pyPrefix holds the prefix and is the key to instances of this class. The integer
property Data-UniqueID.pyLastReservedID holds the highest assigned number. The property Data-
UniqueID.pyOrganization, a key part, is not filled in by standard rules as was done in earlier Process Commander
versions. This property value is left blank so that work object IDs are unique system-wide.

See the Pega Developer Network article PRKB-25851 How to include a check digit in work object IDs.
Activity Types:

For integration which type u use in flow shape?

Integrator tasks

An Integrator task identifies an activity that connects your Process Commander system to an external system to
send or receive data.

For example, an integrator task can connect to a customer master database to retrieve account balances or verify
account numbers and status. Integrator tasks use activities (with Connect as the Activity Type) that call connector
rules (Rule-Connect- rule types).

You can add an Integrator shape by dragging an activity rule instance of type Connect from the Application
Explorer onto the Visio diagram.

Delegated Rules:

A delegated rule is one that appears for a specific group of users so that they may manage these rules outside the
development environment. Delegated rules appear on the My Rules gadget for a single user or for all the users who
are associated with a specific access group.

An application user who has the PegaRULES:WorkMgr4 access role can update the leftmost tab of existing rules that
may change frequently.

Opening a delegated rule

To open a rule delegated to you:

 From the Manager portal, open the Dashboard workspace, locate the Delegated Rules area, and click the link
that labels the delegated rule.

 From the Designer Studio, select My Favorites > Edit My Favorites from your profile menu.

Delegating a rule

To mark a rule as delegated, click the Favorites toolbar button ( ) and complete the Delegated Rules options

Although rules of any type can be delegated, managers are most likely to learn and understand the following types:

 Case match

 Constraints
  Decision table

 Decision tree

 Declare Expression

 Flow

 Flow action

 Service level

 Map value

 When condition

A cover is a work object (in a concrete class derived from the Work-Cover- abstract class) that is also a parent to
one or more related work objects (usually in a class derived from Work- class). Typically one work party — such as
the customer party — is present in the cover work object and also present in all of the covered work objects. These
objects are the children in a parent-child relationship.

Some Business Process Management materials refer to cases and case management, rather than the Process
Commander term cover.

Benefits

A cover work object provides a means to coordinate processing of related work objects. In most applications, the
system resolves a cover work object when all of its "member" covered work

The cover facility has many practical benefits. For example, if a single customer request causes a user to create
three separate work objects, these work objects may follow separate flows, be handled by separate departments,
and not otherwise affect each other. The cover object provides a way to consolidate, view, and manage the
outstanding service requests of this customer. After all three covered work objects become resolved, the cover work
object can be resolved.

Using the cover facility is optional. You can use the PegaSample sample application to learn about covers and
determine whether this feature is useful in your application:

1. Open a WorkManager portal. Select the Process Work workspace.

2. Select Sample Work as the current work pool.

3. Enter a Customer Request object. These work objects are covers that can cover multiple General Task work
objects.

4. To enter the first covered work object, select General Task as the Issue.

5. Select Add Work... and select General Task to enter a second and additional members of the cover.

Covering other cover classes

Case type rules enable you to nest cover objects within other cover objects in a parent-child hierarchy. This
capability helps centralize flow processing and monitoring among multiple work types in large applications. You can
nest any number of parent and child covers. You access attachments to covered work in a parent cover object. In a
case management application, the rule lets you expand the scope of a top-level case (parent cover) by covering one
or more subcases (child covers) and their children work types.
Covers as seen by application users

Work object forms support working with covers and its covered objects:

 Click the View Contents button ( ) at the top right of the cover work object form to access the member
work objects.

 From the ALL tab, select any single cover member work object using the drop-down list or click a row.

 Click the yellow cover ID link to return to the cover-only display.

In the above example, the use of a case type rule enables C-13 to cover another cover, C-14. By convention, the
work object IDs of covers have the format C-999999; basic work objects have the format W-99999. Your application
need not follow these conventions.

Developer facilities for covers

Internally, a cover is a work object that is an instance of a concrete class derived from the Work-Cover- abstract
class. Your system includes harness rules, flow action rules, and activities that support working with covers. The
covered work objects can be of differing work types. However, the work type of the cover and the work type of the
covered objects must all belong to the same work pool.

 Locking — By default, locking a covered work object also locks the cover work object. This is desirable
because the cover work object may contain totals, balances, counts, or other derived values that require
single-threaded access.

 Page Names — By convention, a cover work object occupies a clipboard page named pyCoverPage; the
covered work object is on a page named pyWorkPage. Many standard activities depend on these naming
conventions.

 Ticket — The standard ticket rule Work-Cover-.AllCoveredResolved alerts a cover flow that all the member
work objects are resolved. If your application is to incorporate this constraint, include this ticket in the flow
rule or rules for the cover work object.

 User access — The View Contents button ( ) on a cover work object starts execution of a list view rule
named AppliesToclass.WorkInACover.ALL, which is embedded using the <pega:listView> JSP tag.
The standard list view rule Work-.WorkInACover.ALL displays the urgency (pyUrgencyWork property), work
object ID (pyID), subject (pyLabel), and status (pyStatusWork) fields as columns, without sorting. You can
copy and override this list view rule for your work types, choosing different columns, add sorting as
required, and enabling paging if required. However, note that list view rules with paging enabled cannot
sort rows by work object ID, as the Work-.pyID property has a custom sort function.

 Flow actions — The standard local flow actions Work-.AddToCover, Work-.AddCovered, and
Work-.RemoveFromCover allow user management of cover contents.

 Harness rules — The Work-.NewCovered harness rule supports entry of a new cover and cover members.
  Process Engine API — Activities Work-.AddCoveredWork, Work-.AddCovered, and others support operations
with covers.

Related PDN articles

See the Pega Developer Network article PRKB-25838 Use one ticket to end a flow for both a cover object and its
covered objects.

Folder:

This term has two uses:

 A shortcut folder is an organizing element for grouping shortcuts saved by a developer. On the
My Shortcuts display from the Designer Studio Application menu, the image identifies a
shortcut folder.

 A work object folder is a work object in a concrete class that inherits from the Work-Folder-
class. A folder object holds a collection of one or more other work objects (which themselves
may be basic work objects, other folders, or covers) providing access for analysis and reporting.
By convention, the work object ID of folders has the format F-99999.

Covers and folders are two built-in facilities that allow your application to support collections of work
objects. In contrast to covers:

 One work object may be associated with multiple folders, but only with one cover.

 Members of a folder can belong to different work types, which need not belong all in a single
work pool.

 The relationships between folder work objects and their contents may be many-to-many.

Example

To review or work with a flow rule that creates a folder work object, examine or test the standard flow
rule PegaSample-Folder.NewWork.

As a business example, consider a purchasing application where a basic work object is a line item on a
single purchase order:

 The purchase order corresponds to a cover object. Every line item belongs to one purchase
order.

 Folders organize open purchase order line items by our part number and also by the vendor's
part number. A folder work object (in Work-Folder-OurPartNum work type) may be associated
with several line items, and one line item can simultaneously belong to a Work-Folder-
OurPartNum work object and a Work-Folder-TheirPartNum work object.
Standard rules

These standard rules support folders:

 Work-.AddToFolder flow action — Add a work object to a folder

 Work-.RemoveFromFolder flow actions — Remove a work object from a folder

 Work-Folder-.Review harness — Show folder work object, includes the View Folder Contents
button ( ) to access contents

 Work-Folder-.Perform harness — Update folder work object and contents

 Work-Folder-.ReviewforExplore harness — Split-screen presentation

 Work-Folder-.FolderContents section — Show folder contents

 Work-Folder-.NewWork flow — Create a folder

Notes

A folder work can be a member of other folder work objects.

Instances of the Link-Folder class associate of work objects with folders.

Pending Question:

Property expose
diff agent/listener
model chaining- system defined properties
activitis used for flow shapes
performance tools