CSSA Study Guide for Pega 7.

1 – February 2016

a. Class
b. Ruleset
c. Circumstance
d. Circumstance Date
e. Date/Time
o Remove all candidates that are withdrawn or have the same class, same RuleSet major and the same qualifiers as the
withdrawn candidates.
1. Set the cache.
2. Find the best instance (and check to make sure there is not a duplicate rule).
3. Check that the Availability is not set to BLOCKED. (could cause error message to be thrown when called at runtime)
4. Security – Verify that the user is authorized to see the rule. (could cause error message when called at runtime)

* Availability settings:
 Yes = “I’m OK to be executed.”
 No = “I’m not OK to be executed, pick someone else.”
 Withdrawn = “I’m not OK to be executed and neither are any of my earlier versions. Pick someone else.”
 Blocked = “I’m not OK to be executed, but do not pick anyone else. Just don’t execute.”
* Ancestor Tree
 The “ancestor tree” refers to a rule’s inheritance.

* Default Candidate
 A default candidate is the first candidate (highest ranked) rule that has no qualifiers.
 Rules with qualifiers that match are selected before the default.

* Enterprise Class Structure (ECS)

 The Enterprise Class Structure is the backbone of reuse in our application
 PRPC generates an Enterprise Class Structure for us when we run the Application Express

* The Organization Layer

 The organization layer exists at the very top of our enterprise class structure.
 This layer is intended to hold all rules that apply corporate wide.
 The kinds of rules most often encountered here are:
o Security (for example, LDAP access, how users are granted rights, etc…)
o Corporate Logos and Skins
o Corporate wide data models (for example, Customer, Insured, etc…)
o Some Integration Points (Note that these should only be placed here if they are used organization wide.)

* The Division Layer

 The division layer exists to hold all the rules for a logical grouping within that business
 Most often, this is based on the line of business, but it is not restricted to that and instead could be regions or departments
 The key is to identify if these rules span across different processes within the business
 The kinds of rules most often encountered here are:
o Division wide data models
o Division wide letterheads, signature lines, office locations, telephone numbers, etc…

* The Framework Layer

 The framework layer is all about the process.
 This is what empowers an organization to achieve the majority of their reuse.
 Processes within an organization are often very similar between the different divisions.
 Frameworks should not be tied to a single line of business, as this limits their reuse, but instead should always look at the
broad picture across the whole organization.
 If a rule is slightly different for one or more divisions, the rule should be built in the framework and another specialized rule
should be built for each division needing specialization of the rule
1
CSSA Study Guide for Pega 7.1 – February 2016

 The kinds of rules most often encountered here are:

o Case types
o Flows
o Flow actions
o Sections

* The Implementation Layer

 This layer is the application that a user leverages to perform their tasks. You can think of it as the ‘glue’ that holds together
the rules from the framework, organization and division layers. The rules that are the most specific would exist here.
 The kinds of rules most often encountered here are:
o Class groups (A grouping of similar or related Work- concrete cases case types, whose instances are stored in the
same relational database table. Analogous to what users think of as an application.)
o SLAs
o Routers
o Work instances instantiation (allowing the class to be the most specific and avoiding possible cross division
contamination of work)

* The ECS Best Practices

 A well designed Enterprise Class Structure should never contain 100% of the rules in any one layer. Instead, the same number
of rules that would have been used in a single application are just spread around throughout the layers.
 Building an ECS should not take any more effort than asking yourself “What does this rule represent?”
 The key to planning is keeping the purpose of the rule in mind when building it. If the rule is related to the process, it goes in
the Framework. . .

* Inheritance
 Inheritance is what allows a class to use rules from its parent as if they were its own.
 Parents cannot access rules from their children, so Class B can only use the rules defined on B.
 Inheritance is an Object Orientated Programing concept. Inheritance is defined as being “a kind of”. In most Object
Orientated Languages, we can only define one thing as being “a kind of” one other thing. Like a desk ‘is a kind of’ furniture, or
a poodle ‘is a kind of’ dog.
 PRPC has the ability to define two kinds of inheritance, Pattern and Directed. By providing two paths of inheritance, we can
achieve multiple reuse patterns.
 Pattern inheritance is checked before directed inheritance.
 In order to see all the parents a class has, we just need to right click on the class and select Inheritance.

* Pattern Inheritance
 Pattern inheritance is defined by the name of the class. For example, let’s look at the class:
o ADV-Purchasing-Work-PurchaseOrder
 Anything before the last ‘-‘ is considered the classes parent. Patten inheritance continues to chain all the way up to the very
first class referenced in the chain. So for our class, the chain of parents is:
o ADV-Purchasing-Work
o ADV-Purchasing
o ADV
 Our class can use any of the rules defined on any of these three parents.

* Directed Inheritance
 Directed inheritance is how we explicitly specify an alternative parent for a class. We specify the directed inheritance on the
class’s rule form.
 For our example, the directed parent is Work-Cover-. Directed parents also chain so if we were to open each of the class
definitions we’ll find that this classes parents are:
oWork-Cover-
o Work-
o@baseclass

2
CSSA Study Guide for Pega 7.1 – February 2016

 So our class is also able to use any of the rules in these classes.

* Circumstancing
 Circumstancing is a way we can create specialized copies of rules to use based on the evaluation of a condition
 This helps us handle the outlier cases that go beyond the basic process
 These are the kinds of outlier situations that exist in businesses today. Complex business rules vary from state to state; by
time, by demographic groups, and any and all possible combinations.
 By using circumstancing, we can keep the processes streamlined, and allow the system to determine when to do things
differently based on the information available at the time the rule executes.

* Four types of circumstancing

 Single Property (needs to be a single value, must be entered/not mapped, and has to be an exact match/case sensitive)
 As of Date Processing (must be date/time single value, the value in the property is past the specified date or time)
 Multivariate (base rule, circumstanced template, circumstanced definition, and circumstanced rule)
 Time-Qualified (temporary - rule if the current time is after the start date, but before the end date)
 Note: If the specialization is not based on property values or related to time/date, it probably is not a good candidate for
circumstancing
* The Base Rules
 One of the important concepts in Circumstancing is the base rule.
 The base rule is the un-circumstanced version of the rule that acts as the default for the basic process.
 Since a circumstance is a variation of this base rule, the circumstanced version can’t even exist unless the base rule exists first.
(all circumstance scenarios will have a least two rules – a base and a circumstanced rule)

* Creating a Circumstance Rules

 Select our base rule, then we select ‘Specialize by circumstance’ to a new rule
 In order for a rule to be circumstanced, that type of rule must have at least one these two options enabled.
o Allow selection of rules based on property values? (circumstance qualified)
We use this option for circumstancing on the data available.
o Allow rules that are only valid for a certain period of time? (date range availability)
We use this option for circumstancing based on the time the rule executes.

* Multivariate Circumstance
 Multivariate requires Circumstance Templates and Circumstance Definitions and may span multiple properties and values.
 There are four rules involved in this type of circumstance:
o The Base rule
o A Circumstanced Template (instance of Rule-Circumstance-Template) – defines which properties take part
o A Circumstance Definition (instance of Rule-Circumstance-Definition) - any number of rows and can contain any value
o The Circumstanced Rule

* Time-Qualified (Date Range)

 These rules aren’t based on values. Instead these rules depend on when they are executed.
 Time qualified rules are used for temporary purposes.
 Only two additional values can be specified. The Start Date and the End Date. Only one of these is required, though both can
be, and often are, specified.
 The system executes this version of the rule if the current time (not CreateDate of object) is after the start date, but before the
end date.
 If either the Start Date or End Date is missing, then this becomes an open ended circumstance, which applies to all after a
specified start date or before a specified end date.

* Describe circumstancing in rule resolution

 During the ranking process, all valid circumstance variants are sorted according to their circumstance values.
 The ranking processes orders by:
1. Override

3
CSSA Study Guide for Pega 7.1 – February 2016

2. Class
3. Ruleset
4. Circumstance Value in alpha order (Multivariate circumstances rank by the order the properties are listed in Template)
5. Circumstance Date in descending order (largest first)
6. Time Qualified by end date, in ascending order (smallest first)
7. Time Qualified by start date, in descending order (largest first)
8. Non-Qualified
9. Version
 Often one or more of these rules supersedes another.

* The Base Rule Flag

 Any version of any rule that can be circumstanced can also be designated as a base rule.
 This is done by checking the Base Rule flag while setting the rule’s availability.
 Checking this flag designates that this version of the rule is now considered this rule’s base and any previous circumstances no
longer apply.

* Understand the Importance of Rule Naming and Documentation in Reuse

 Choose descriptive, Meaningful names
 Complete the Full field on the history tab
 Give rules meaningful names. Only rules with meaningful names will be reused.
 The rule name should indicate what the rule does, like “OpenPurchaseRequests”
 This is our primary way to communicate with someone who may wish to extend the application or support it in the future
 Complete the fields on the History tab, Other “description” fields, such as those in the “Parameters” table, should also be
completed with thoughtful information

* Understand the Importance of Rule Modularity in Reuse

 Size Rules thoughtfully – create rules that execute a single logical function
 Break down rules into smaller parts
 Most rules can be architected with this in mind
 Make sure that rules are just the right size: big enough to be useful, but small enough to be reusable.
 If a rule is packed with so much functionality that it can only be used for a particular use case, then consider breaking it down
into smaller components. Most rules types are designed so that they can be broken up into smaller rules.
 Place rules in the right class to support a robust and intuitive class structure

* Class Specialization
 Small amount of high level variants, and a LARGE portion of rules are specialized for them
 Security - Class specialization is the only technique that offers control over security
 Persistence - Can also be controlled only with class-based specialization
 If two different variants of work objects must be stored in different tables, they must be in different classes.
 Class-based specialization provides the most options, and should be considered first when assessing a particular requirement.

* Ruleset Specialization:
 Management/Deployment: If the rules should be managed or promoted to production differently based on the specialization,
ruleset specialization is needed. RuleSets are really meant to facilitate deployment. They are not meant for specialization
within a given application. They do help specialize, but the specialization is very broad, to differentiate one application from
another. To specialize within an application, use either class or circumstancing.
 Reusable feature set: Functionality used across applications, even organizations. The next question to ask is if the set of
features we are developing, while designed for a particular purpose, are reusable for almost any application. For example,
let’s say we are developing a “customer complaint” component for our insurance application, it is likely reusable.
 If two rules are identical, except for the Ruleset, a user must login to a different application to switch from one to the other.

* Circumstancing Specialization:
 Edge Cases: MANY variants, few rules specialized for each variant. In this case, circumstancing is very well suited.
4
CSSA Study Guide for Pega 7.1 – February 2016

 Customer-specific Data: If the specialization depends on customer-specific data, rather than some predefined organizational
construct. Example: If insurance premiums depend on a combination of a customer’s age and address.
 Dates and/or Temporary: If the specialization depends on dates, or is in some way temporary, use Circumstancing. These are
the key use cases for which circumstancing was designed.

* Understand the Use of Parameterization in Reuse and Specialization

 Parameters (like inputs/outputs) are values passed into a rule to make it more reusable.
 The data type can be a string (which is the default), Boolean, integer, or page name.
 “Required?” indicates if the parameter must be passed in.
 “In/Out” specifies if the parameter is going in or out; the default is “in”.
 “Prompt Default Value” allows us to set a default.
 Only certain rule types can be parameterized They are:
o Sections o Functions
o Flows o Messages
o Data Transforms o Collections
o Activities
* Understand the rules behind the Case Designer, and Process View
 We need to ensure the correct rules are in an unlocked ruleset version, before we make any changes.
 We can open the rule behind the case designer configuration from the Case Explorer itself, by right-clicking on the case and
selecting the Open menu option.
 This opens the Case Type rule, pyDefault (if locked, the design could not be edited for a specific case)
o This rule is also used to configure some items that are not part of Case Designer. We can make the Case Designer
changes in this rule. We recommend that you make the configuration changes in the Designer instead of in the rule.

* Process Tab of Case Rule

 The Processes tab of the Case Type rule stores the configuration information we saw on the detail tab of the case designer.
 This includes the work parties, data propagation, case wide supporting processes, case wide local action and case match which
is for duplicate search.
 In this tab, we also see the list of subcases that are part of this case, under coverable work types and the starting processes.
 The starting process is the first process that runs when users click on “create” from the Create menu in the portal.

* Details Tab of Case Rule

 Details tab to configure the case.
 The top most parent case only has Email Instantiation configuration, any case that has subcases has the Data Propagation
configuration item, which is used to propagate the data declaratively from a case to its subcases.
 All subcases also have Instantiation configuration.

* Understand the rules behind the Case Designer, and Process View
 Open the starting process by clicking on the magnifying glass next to the starting process rule name. The starting flow usually
consists of only one utility shape (“pzInitializeStage”) if the case utilizes stages.
 In the process tab of the Case Type rule, we can have multiple starting processes. For each starting process, there is an entry in
the “Create” menu for the end users.
 We can add flows from the current layer and flow from any class in the whole direct inheritance tree.

* Stages Tab of Case Type Rule

 The Stages tab of this rule stores the stages & processes tab information of the case designer.
 We can see the primary stages, configuration of each stage and configuration of each step.
 This tab also stores the information related to alternate stages, very similar to primary stages.

* Calculation Tab of Case type Rule

 The Calculation tab stores the calculations that are configured in the details tab of the Case Designer.
 We can use the Attachment Categories tab in the Case Type rule to add new categories associated with the case on which we
are working. This tab does not store any information from the Case Designer.

5
CSSA Study Guide for Pega 7.1 – February 2016

* Advanced Tab of Case Type Rule

 We can use the “Advanced” tab to publish as a remote case type, which is required for “Federated Case Management.”
 The locking configuration in the Case Designer and the locking configuration in the advanced tab of the case type rule are
different. Case Designer locking configuration is valid for cases that are instantiated under a case hierarchy. The locking
configuration here is valid for cases that are instantiated as stand-alone case instances.

* Calculation of parent case from subcase properties

 The calculation of a property of the parent case can be based on the properties of subcases
o By configuring it on the case type rule in the parent case
o By configuring it in the case designer – details tab of the parent case

* Case Lifecycle Management

 A case defines the work we want to complete.
 A case is then broken up into a set of stages; stages are logical milestones that work will transition through.
 Stages comprise a set of actions that can either be a single step, multiple steps or launch another case.
* Resolution Stage
 Is this a resolution stage? — By checking the box on stage configuration we identify the stage as a resolution stage.
 Visual indicator of the end of the lifecycle of a case.
 Visually represent the stage(s) in which a case may be closed (resolved).
 A case can have more than one Resolution stage, even in Primary path.
 Both Primary and Alternate stages can be resolution stages.
 Has no functional behavior, and has no automatic status change. Used for clarity and understanding.

* OPTIONAL PROCESSES — We can specify optional processes, which are implemented as flow rules.
 These optional processes appear to end users in the Perform Harness, under the “Other actions” menu. Users can run optional
processes as needed.
 In addition to stage level optional processes we have configured here, we can also have “case wide supporting processes”
which we configure on the Case Designer – Details tab.
 Optional processes can be stage wide or case wide.

* OPTIONAL ACTIONS — We can have optional actions, which are implemented as local flow actions.
 These optional actions appear to end users in the perform harness, under the “Other actions” menu.
 Local action when processed does not make the case instance to move from the assignment shape. Local Actions can be:
Specific to Configured on Available to End Users
Assignment Assignment Shape Only in that specific assignment
Flow wide Flow rule In all the assignments of a specific step
Stage wide Stage Configuration as shown above In all the assignments of a specific stage
Case Wide Case Designer – Details Tab In any assignment throughout the case

* Rules for configuring a case stage

 Service level rule for the stage
 When rule for conditionally skipping the stage
 Validate rule to determine whether the case enters the stage or not, by selecting
o Stage entry validation – a specified validate rule runs against the case.
o Attachment validation – the case must contain an attachment of the specified type.
o If either validation fails, the case returns to the previous stage with the appropriate validation error message.

* Step Type — As a step type, we can choose one of the following:

 Single Step Assignment — creates a flow rule with a single assignment shape and start and end shapes.
 Case — it creates a flow rule with a single “Create Case(s)” smart shape and start and end shapes.
 Approval — creates a flow rule with a single subprocess shape. The subprocess shape calls the standard
 Multi Step Process — creates a flow rule with two assignment shapes.
 Attachment — creates a flow rule with a single subprocess shape.
6
CSSA Study Guide for Pega 7.1 – February 2016

* Start Step — The Start Step section allows us to determine when – if at all – in the stage the user is allowed to perform the step.
When the case enters the stage, it automatically attempts to prompt a user to perform the first step. Subsequent steps can either occur
in parallel or in sequence.
 Upon stage entry – steps are processed concurrently when the case instance enters this specific stage.
 Upon completion or skip of previous step – steps are processed sequentially when the case instance enters this specific stage.

* pzApprovalFlowWrapper flow
 Approval steps can be configured for processing by a single operator, or a cascading series of operators based upon either the
existing reporting structure or an authority matrix configured by a decision table.
 The cascading approval option behaves similarly to the Cascading Approval smart shape & can be configured in the same
manner.

* pzAttachFile flow and pxAttachContent flow action

 Attachment — creates a flow rule with a single subprocess shape.
 The subprocess shape calls the standard pzAttachFile flow, which itself consists of a single assignment that calls the
pxAttachContent flow action.

* pxIsInCurrentStage
 When a specific step of a stage is processed, subsequent step in that stage will be automatically kicked off, if that is marked to
start “upon completion or skip or previous step.” In the previous step, if we change to a previous stage using the “Change
Stage” smart shape, another step in the previous stage also started.
 If this effect of two steps across two stages getting kicked off is not desired, we can have the standard when rule
“pxIsInCurrentStage” in the subsequent step.

* Launch on re-entry?
 Once a stage is processed it can be re-entered from another stage by the change stage process or manually by the end user.
Only the steps that have this option selected are started automatically when the stage is re-entered.

* Summary View
 Using the summary view of any standard portal, end users can quickly get an idea of how many cases are in each stage of the
case lifecycle. The number next to the stage names indicates the number of instances in that stage.
 Clicking the number pulls a standard report.
 In the portal, from the drop down, end users can change to different cases to pull the summary for that case.

* Instantiation of Subcase Instances

 We can configure subcases to be instantiated in different ways. The different instantiation options are:
o Subcase Case Designer (Details Tab)
o automatically when parent case starts or when rule or with dependency condition
o manually by end users when condition is true
o Step Configuration in the Parent Case Designer (Case as step with or without when rule upon creation)
o “Create a top case” option – Any case can be instantiated as stand-alone top level case or another parent case
(may select data transform for instantiation data)
o “Create a subcase” option – May select starting process (if multiple) and data transform for instantiation data
o “Create multiple subcases” option – Uses a page list to create multiples of the same case (may also select staring
process and data transform)
o Create Case Smart Shape in any Flow rule – Used when instantiation is for any case (not just same case type or children of)
o “Create a top case” option – Any case can be instantiated as stand-alone top level case or another parent case.
o “Create a subcase” option – May select starting process (if multiple) and data transform for instantiation data
o “Create multiple subcases” option – Uses a page list to create multiples of the same case (may also select staring
process and data transform)

7
CSSA Study Guide for Pega 7.1 – February 2016

* Instantiation dependency
 We can instantiate the subcases based on dependencies.
 We can configure the subcase to instantiate when “any or all” dependencies are met.
 For a subcase to be instantiated, a dependency can be a parent case and/or any other sibling subcase(s).
 The dependency conditions are:
o “Has Started” (dependency is another sibling subcase for a subcase to be instantiated)
o “Has Work Status” (dependency is the parent case or another sibling subcase for a subcase to be instantiated)
o “Has Completed” (dependency is another sibling subcase for a subcase to be instantiated)
o “Manually by user when” (users manually click in other actions to instantiate “Add Work” when condition is true)
 We can have more than one dependency.

* Inheritance of a subcase
 Direct inheritance does not have to be the same as that of the parent case or the class of the parent case.
 Pattern inheritance does not have to be the same as that of the parent case or the class of the parent case.
* Getting Data from the Parent Case to the Subcase(s)
 Details tab of the Case Designer – for using data conditionally or looping through a page list and may also apply data transform
 Processes tab of the Case Type rule of the parent case – data propagation configuration information is stored
 Step Configuration in the Parent Case Designer – a data transform can be used for data propagation
 If the parent data changes after propagation, the new data is not reflected in the sub case
o If the latest value of a property of the parent case is needed during the processing of a specific step of a subcase use a
data transform in the flow rule that is associated with that step.

* Calculating a Parent Case Property from Subcase Properties

 In the Details tab of the Case Designer of a parent case, we can use the Calculations option to set the values in the subcase(s).
 Calculation configuration information is stored in the Processes tab of the Case Type rule of the parent case.
 Once the calculation is configured, the system creates declare triggers (pyCaseTypeAggregate) for all subcases in calculation.

* Locking of the Parent Case and the Subcases

 Users can select one of two configuration options on a case by case basis— Default locking or Optimistic locking.
 In the Case Designer (details tab) of the parent case, we can use the Locking option to set locking on the top most parent case.
 If the subcases are instantiated as part of the parent case, they have the same locking settings as the parent.

* Default locking
 Locks the case when an operator opens the case.
 If a second operator tries to open the same case, they get a message that the case is locked by the first operator.
 The second operator is able to open the case in review mode only (with a message saying it is locked and can only be opened
in review only mode)
 The Default locking timeout is 30 minutes but can easily be changed to a custom timeout.

* Optimistic locking
 Enables both the operators to open the case.
 No lock is obtained when the case is opened.
 The lock occurs when the user clicks Submit.
 When two operators are working on the same case, the changes to the case are made by whoever submits the case first.
 The second operator receives a message with the first operator’s name and the time of the change.
 Also there is a refresh button that allows the second operator to get the new changes made by the first operator.
 The second operator’s changes are not applied until they click refresh and submit their action after the refresh.

* Locking of Subcases
 If the subcase is instantiated under the parent case hierarchy, then the subcase inherits the parents locking respectively.
 If default locking is used, a custom timeout for the subcase can be different than the parent case.
 In the subcase locking configuration, if the “Do not lock” option is selected, the parent case is not locked when the subcase is
being worked on. The default option & recommended approach is to lock the parent case when the subcase is being worked.

8
CSSA Study Guide for Pega 7.1 – February 2016

o The advantage of using the “Do not lock” option, both the parent and subcases can be processed simultaneously.
o The main disadvantage of using the “Do not lock’” option is that since the parent case is not locked, any properties
related to the subcases, such as count of open subcases is not updated in the parent case.

* Locking Standalone Cases

 Any subcase can be created as a standalone case, but the locking process for a standalone case is a little different.
 If a subcase is instantiated as a standalone case, the locking configuration is done on the Advanced tab of the Case Type rule
for that specific subcase. It does not have to be the same as the parent case.
 Select Default locking and set a custom timeout or select Optimistic locking.

* pxCoveredInskeys
 This property holds the handles or pzInskeys of the subcases that are linked to the parent case.
 This might be useful if there is a need to list or identify all the subcases instances of a specific parent case.

* pxCoveredCount
 This property indicates the number of subcases linked to the parent.
 Anytime, a subcase is added or removed, the system automatically updates the value of this property.
 PRPC uses this property to indicate whether a parent case contains subcase instances and behaves accordingly.

* pxCoveredCountOpen
 A standard property that holds the number of subcase instances within a parent that are not resolved yet.
 As the subcases are being resolved, PRPC keeps this count updated automatically.
 This property value is used to ensure that there are no open subcases within the parent case.

* Creation of Flows
 When a step is added in a stage in the Case Designer, a flow rule is created for that step. Recommended way to create a flow.
 If a flow needs to be created as an internal process for technical reasons, such as parsing a temporary file and do some logic
behind the scenes, we create the flow, not as a step in a case.
 We can create a flow rule from the Case, Data and App explorers.

* Editing Flows
 Flows can also be edited using the embedded process modeler in the flow rule and the process view of the case designer.
 In the process modeler of the process view, if the step type is a Case or a Single Step Assignment, we won’t see the flow
diagram. The only way to add another shape is through the tree view, when the flow is opened in the process view.
 Adding a shape in the tree view is has its advantages because the new shape is automatically added with the connectors
between the shape we right clicked on and the next shape. Similarly removing the shape in the tree view removes the shape
and the appropriate connectors and the existing shapes are reconnected.
 If the step type of the step is “Single Step Assignment” or “Case”, adding more shapes to the associated flow rules changes
those steps to “Multi Step Process” step type.

* Opening a flow from App Explorer or Search

 We can open the flow in the App Explorer or from Search options, when flow rule was not created in the Case Designer.
 To parameterize the flow, set the security, and configure the process, we have to open the flow rule.

* Calling Flow(s) From a Flow

 We can call other flows by using one of these three shapes
o SubProcess shape in the basic shapes
o Split For Each
o Split Join

* Calling Flow(s) From a Flow using a SubProcess

 We can use the subprocess shape to call a subflow on a current page or on an embedded page or another work object.
 Calling a flow on an embedded page lets us call a flow that belongs to another class, such as a data class.

9
CSSA Study Guide for Pega 7.1 – February 2016

 If the spinoff flow check box is not checked, the main flow waits for the subprocess flow to finish and return the result.
 If the spinoff flow check box is checked, the main flow does not wait for the subprocess flow to execute (parallel processing).
 If we select “on specific work item,” we can run the flow on another case, which could be a subcase or a top level case.

* Split-Join
 Using the Split-Join functionality is similar to using a sub-process without the spin-off option selected
 Allows the calling any number of different flows on the current page or embedded page or a specific work item
 We can configure the join condition as well (“All” “Any” or “Some”)
 The calling flow execution is halted until one or all or some of the subflows are completed
 The flow joins back to the main flow when all or any of the subflows are complete. For “some,” the flow joins back based on
the iteration condition. Iteration conditions can be based on a conditional When rule or it can be based on a count.

* Split for Each

 With the “Split For Each shape”, we can call the same flow from another flow for all the objects in a list or group
 We can configure the join condition as well “All” “Any” “Some” or “Iterate”
 The calling flow execution is halted until one or all or some of the subflows are completed
o If we use the “Some” join condition, the exit iteration can be based on a when condition or based on a count
o If we use the “Iterate” join setting, then also the exit iteration can be based on a when condition or based on a count

* Configuration of Wait shape

 There may be times when we want a flow to wait before processing continues.
 The Wait shape can be configured for Timer Wait Type and the waiting period can be a future date/time.
 The other option is “Time Interval”. This can be any combination of minutes, hours, days and so on.
 The Wait shape can be configured for “Case Dependency” Wait Type for Mid Process Dependency

* Mid Process Dependency

 The Wait shape can be configured for “Case Dependency” Wait Type
 The current case is made to wait in a flow with a Wait shape and for “any or all” wait for conditions
 This waiting for a case dependency is called “Mid Process Dependency”

* Cascading Approval Smart Shape

 Used when we want to get multiple approvals based on the requirements
 The Cascading Approval smart shape simplifies the development required to get multiple levels of approvals
 Approvals can be based on an Authority Matrix (with Decision Table) or a Reporting Structure

* Authority Matrix
 First, we need to create a decision table to capture the requirement
 This table evaluates multiple rows based on conditions and returns one or more values
 This table differs from the default decision table configuration, which only returns the result for the first condition satisfied
 The value(s) returned by the decision table needs to be stored in a property in a page list
 When the case instance reaches this step in the stage, multiple assignments are created one by one to get the approval from
each one of the approvers

* Reporting Structure
 The reporting structure can be based on ReportsTo Manager or WorkGroup Manager
 In the Reporting Structure option, approvals are based on the reporting manager structure or workgroup manager structure
 If the first when condition is true, based on the levels of approval, assignments are sent and approvals are made
 We can add more when conditions by clicking “Add Item”
 When the case instance reaches this step in the stage, the approval assignment is sent to one operator
 The systems evaluates all the when conditions and stops at the last when condition. The approval assignments are then sent to
the number of levels configured using the when condition

10
CSSA Study Guide for Pega 7.1 – February 2016

 Both the “Reports to” and “Work group” are set for an operator in the operator data instance – work tab

* Search for Duplicate Cases with Duplicate Search Smart Shape

 When case instances with similar characteristics are created, one of them gets resolved with the status resolved-duplicate
 We can be proactive and prompt the end-users of potential duplicates using the duplicate search functionality
 To configure you need:
o A Case Match rule to compare
o Flow rule with a duplicate search smart shape
 “Must Match” are used to filter the potential duplicate cases from the list of existing case and the conditions must match
between the current case instances that we are creating with past instances
 Weighted Match Conditions are used next, if the conditions are matching, then weights are assigned
 Current case properties have to be referenced with the keyword “Primary” as mentioned in the configuration dialog box itself
 Potential duplicates are identified based on the sum of the weighted conditions.

* Persist a Case with Persist Case Smart Shape

 We can create temporary case instances and then make it permanent after we know that the case instance is needed.
 Once the user identifies that the object is indeed not a duplicate, the temporary case can be made a permanent case.
 This involves two steps.
o In the starting flow of the case, we can select the “Temporary object” under the process tab. The case is not actually
created in the database if this option is selected.
o In an appropriate step, we can have the flow with the “Persist Case” smart shape, which makes the temporary case a
permanent case in the system (stored in the database)

* Screen Flows
 Used to break up a step performed by a single user into screens in which related data are entered.
 Screen flows tend to be short in length and easy to complete in one sitting.
 A screen flow is run by a single operator, and drives a single, serial process.
 Create a flow rule first using the Screen Flow template, then add it as a step in the Case Designer.
 The whole screen flow is an assignment and is assigned to one user.
 Routing, harness rule setting, persistence and error handling are set on the start shape of a screen flow for the whole flow.

* TreeNavigation7
 The current step of the screen flow highlighted in blue and shows all the steps in the navigation tree
 Users can navigate using the back and next buttons or by clicking on the menu item in the tree navigation
 When clicking on the tree navigation, users can jump multiple steps backwards or forwards

* TabbedScreenFlow 7
 This user interface shows the current step of the screen flow highlighted in blue and shows all the steps in the tab navigation
 The user can navigate using the back and next buttons or by clicking on a tab in the tab navigation
 Users can jump multiple steps forward or backward by clicking on a tab in the tab navigation

* PerformScreenFlow
 This user interface shows the current step of the screen flow and the previous steps in the horizontal bread crumb display
 This harness option of the UI display does not show the future steps
 Users can navigate using the back and next buttons to go back and forth
 Users can only go back, not forward until they have already clicked that forward step (used to enforce a strict sequence)
 So, clicking on a bread crumb in the navigation, users can only jump multiple steps backwards

* Configuration of Sequencing and Post-Processing Options for Screen Flows

 One of the simplest ways to enforce a strict sequence is to use the “PerformScreenFlow” harness
 When ”Enable link if using breadcrumb trail” is not selected, the step does not show up in the navigation flow listing. The only
way is to use the back and next buttons.

11
CSSA Study Guide for Pega 7.1 – February 2016

 When ”Enable link if using breadcrumb trail” is selected, the step as an entry point. By default, this option is enabled for each
assignment; this option must be enabled for at least one assignment in the screen flow.
 When the “Only going back” checkbox is checked, the step is disabled, when the user is on a previous step. Users must
progress naturally to the step using the “Next” button.
 If we enable both ”Enable link if using breadcrumb trail” and “Only going back,” the step shows up in the navigation flow
listing, but is initially greyed out from a previous step.

* Persisting Data in Screen Flows

 In screen flows, the flow action is on each assignment shape and when navigating through different steps of the screen flow,
the actions are not posted by default.
 We can force posting to the server from any step, by selecting the check box “Perform post-processing when navigating back”
 Enabling post-processing actions run the post actions such as validation rules, apply cost, data transform rules and activity
rules. The post-processing data transform can compute additional property values and post-processing activity can perform
other processing.
 These run only if “Perform post-processing when navigating back” is selected for the assignment shape of the screen flow.
* Configuration of Persistence and Routing Options for Screen Flows
 The start shape has a “Save on Last Step” property option. When selected, the screen flow is not saved until, the last step.
 This is often used in tandem with the “Allow Errors” option, which when selected does not prevent processing even though
errors are raised until the screen flow is complete.
 This is handy for an application in which the operator is entering data provided by a customer on the phone.
 As a best practice, select the “Save On last step” box in most cases, to reduce the number of case instance Commit operations
and history instances.
 By default, if “save on last step” option is not selected, each form in the screen flow is committed to the database.

* Screen Flow Limitations:

 The assignment shape does not have a ticket, an SLA or notify configurations (no need for any of them).
 The screen flow does not have integrator shapes, and no assignment service shapes.

* Work Status
 The standard property for the case instance status is Work-.pyStatusWork.
 Its values are restricted and controlled.
 Every case instance must have a status, which changes as the case instance progresses through the steps.
 PRPC provides several standard work status values. We can also create our own statuses.
 There are four broad categories of work status values:
o New (Identified with a green Flag) - just been created and has not been reviewed or qualified for processing
o Open (Identified with a blue Flag) - being processed by the organization which is supposed to process it
o Pending (Identified with a red Flag) - currently with an external organization
o Resolved (Identified with a checkered Flag) - final status for a case instance as it indicates the completion of the work

* Looking at statuses:
 A few standard values are defined in each category. Click Designer Studio > Process & Rules > Processes > Status Values.
New Pending-Fulfillment Resolved-Duplicate
Open Pending-Investigation Resolved-Rejected
Pending Pending-PolicyOverride Resolved-Revoked
Pending-Approval Pending-Qualification Resolved-Withdrawn
Pending-External Resolved-Completed

* Adding more Statuses:

 We can also define more status values through Field Value rules for the Field name (.pyStatusWork).
 When doing so, we need to make sure that we start each value with one of the words New, Open, Pending and Resolved.

* Use PRPC Standards to Update Work Status

12
CSSA Study Guide for Pega 7.1 – February 2016

 Most flow shapes, including Start, Assignment, End, Utility shapes, and Smart shapes, provide a means to set or update work
status in the properties panel.
 Work item’s status is updated when the shape is reached.
 As a best practice, the status for an assignment shape should never be set to “Resolved” if the status is resolved, the user is
unable to perform any additional work on it.
 The flow “End” shape provides two fields: “Flow Result” and “Work Status.” Make sure to use “Work Status” for this purpose.
 When we set the work status of a case, PRPC uses the standard activity Work-.UpdateStatus to update the value of the
property Work-.pyStatusWork.

* Work-.UpdateStatus activity
 Activity that changes the .pyStatusWork property directly and calls some standard activities such as Work-.Resolve if the status
value is one that started with the word “Resolved”.
 Can be called from a flow utility shape.
 Activities such as Work.WorkBasket and Work-.Worklist which place an assignment in a workbasket or worklist respectively,
also call Work-UpdateStatus.

* “Status-Resolved” and “AllCoveredResolved” tickets

 When a case instance/work item status is first updated to a “Resolved” status, PRPC calls the Resolve activity automatically.
This activity activates the “Status-Resolved” ticket.
 Another standard ticket is “AllCoveredResolved.” If a subcase status becomes Resolved, the immediate parent case is checked.

* Work Properties:
 PRPC also automatically maintains three standard properties in Work-class. They are:
o pyElapsedStatusNew
o pyElapsedStatusOpen
o pyElapsedStatusPending
 These properties contain cumulative time in seconds that a case instance has had a New, Open, or Pending status value

* Work Party:
 A work party represents an entity (internal or external) that needs to be notified about the progress or status of work.
 Work parties are saved as a page group property in the case instance.
 When a case is created as part of a new application through the Application Express wizard or added to an existing application
through the case addition menu in the case explorer, the system creates a default Work Parties rule for newly created case.
 This rule can easily be configured from the Details tab of the Case Designer.
 Clicking on the edit link displays the “Parties” form for us to edit or delete existing roles or add a new role.
 By default, PRPC adds three roles, Customer, Owner, and Interested.

* Work Party Configuration:

 A role (does not impact the visibility of the work party) can be standard roles such as Owner, Customer a custom one.
 The Description is the unique name for each of the roles we see displayed in the user interface.
 The Party Type field references the data class that contains the properties we’ll use to store the work party information.
 The Model field is optional and is a data transform rule that defines the initial properties of our work party when adding the
work party to a case instance. It causes the system to set initial values for some properties of the work party.
 The “Display on Creation” checkbox can be selected to if we want the work party to appear at runtime when the case
instance/work item entry form first appears.
 The “Required” field indicates that this party must be present in every new case instance/work item.
 The “Allow Multiple” check box, when selected, allows for the addition of multiple instances of a single work party role.

* Work Party Data Structure

 Process Commander organizes the Data-Party data into meaningful categories.
o Data-Party-Com for business organizations, and the Party/Company Party Type roles are instances of this class.
o Data-Party-Gov for Government organizations, and the Party/Government Party Type roles are instances of this class.

13
CSSA Study Guide for Pega 7.1 – February 2016

o Data-Party-Operator for PRPC application users with an Operator ID record, and the Party/Operator Party Type roles are
instances of this class.
o Data-Party-Org is reserved for the non-profit organizations, & Party/Non-profit Party Type roles are instances of this class.
o Data-Party-Person is designed for any person who is not however a PRPC application user, and the Party/Person Party
Type roles are instances of this class.
 We create our own sub-classes (direct or pattern from Data-Party) to expand more categories of work parties for application.

* Work Party Properties

 A substantial set of Work party properties are delivered with PRPC. A few properties are required, such as:
o pxPartyRole, which identifies the role of the party.
o pyWorkPartyUri, which uniquely identifies the party.
o pyEmail1, which Pega 7 uses to send notifications to the party. If we don’t provide a value for pyWorkPartyUri, Pega 7
uses pyEmail1 to determine a value when validating the work party using the standard activity Data-Party-.Validate.

* Add a Work Party to a Case Instance

 A work party role can be added to any case instance by configuring the parties configuration in Case Designer, or by using the
perform harness, new harness, or by including pyWorkPartiesWrapper section rule or by using the “AddParty” flow action.
* A good data model
 Should define entities that can represent business objects in a way that can be reused by other applications
 Should be understood by both architects and business users

* Classes
 Classes are the fundamental building blocks of almost everything in PRPC
 Classes define the logical entities or objects that an application will work with

* Pages
 Pages are instances of classes that are stored in memory on the Clipboard
 Pages can be top-level pages or embedded pages

* Properties
 The property rules that define the attributes of the class and are critical to data modeling
 Properties can be as simple as a single value, for example, FirstName
 Properties can also be complex and represent a list or another class all together
 Properties are both the glue that connects the blocks (classes) as well as the details that make them complete

* Clipboard
 The clipboard is a memory based container for pages assigned to each user session.

* Class Type
 A page is always defined as being of a specific class type
 The class type defines the properties that CAN be defined on the page

* Top-Level and Embedded Pages

 A page property allows you to embed a group of properties inside of another page. A property of type page is sometimes
referred to as an embedded page. Proper use of pages is critical to building reusable assets.
 An embedded page can be created by referencing the embedded property.
 Pages can be top-level pages or embedded pages or both. The term top level page refers to pages that have a name and are
not embedded in any other pages. The most common example of a top level page is pyWorkPage.
 Embedded pages are embedded into other pages as properties themselves.
 When trying to understand the relationship of a class and a page it is important to remember that the class is the definition
and does not contain values for its properties whereas the page is the actual instance.

* Value List/Group and Page List/Group

14
CSSA Study Guide for Pega 7.1 – February 2016

 A value list is an ordered list of single value properties. The value list is subscripted using numeric values starting at 1.
 The Value Group is an unordered list of single value properties. The value group is subscripted using strings.
 The page-list and group are similar to the value list and group except they represent a list of pages. Since most applications
require complex structures, page lists and page groups are much more common than value lists and groups.
 Lists are particularly good when we always want to display or process all of the items in a list. Consider if you will be working
on a specific item in the collection (group), versus all items in the collection, in which case a list may be more appropriate.

* ‘Define Properties wizard’

 Use the ‘Define Properties wizard’ to bulk create properties. After clicking Finish, PRPC will create the properties.

* Inheritance
 Inheritances and the class model, whether on work or data classes, represent a form of specialization.
 They allow subclasses to inherit the properties or rules the parent class has defined. Inheritance represents an “is a type of”
relationship.
 On the other hand when looking at the data model and the embedded page or page list properties we are seeing a “has a”
relationship.

* Data Modeling Best Practices

 Understand runtime data structure can differ from design time structure since pages can be instantiated as sub classes.
 Focus initially on the relationships of the classes, which classes will use inheritance and which will become embedded pages,
page lists or groups.
 Review inherited properties and out of the box data classes to ensure that any already defined properties are used.
 Group properties into data classes rather than as direct work properties - limiting properties defined directly on work object
 Define the data structures at the right layer of the layer cake.
 Use page lists and groups over value lists and groups.

* Property Mode (Page)

 Instead of defining a type (like single value), the class determines what this page will represent.
 Like the Page mode, the PageList mode requires a Page Definition. This property now represents a list of Line Items rather than
a single line item. The list can be referenced using the dot notations with a numeric subscript (ex: .LineItems(1).ProductID).
 The PageGroup mode is similar to the PageList except that the subscript is a text string and the list’s order is not guaranteed.
PageGroups can be referenced using a string subscript, for example .Vendors (VendorA).VendorID. PageGroups are useful
when a specific item in the list needs to be retrieved based on a key.

* Data Access for Single Value

 For a single value type property there are two data access options; Manual and Automatic reference to class instances.
o Select Manual if the user adds data to this property through the UI or if data transforms or other rules may be required to
manipulate the value.
o Select Automatic reference to class instances (linked) to establish a direct relationship to a single instance of a different
concrete class also known as the target.

* Data Access for Page

 For the page type property there are three data access options: Manual, Refer to a data page, and Copy data from a data page.
o Select Manual if the user adds data to this page property through the UI or if data transforms or other rules may be
required to manipulate the value.
o Use Refer to a data page to point to a data page. The data is not persisted with the case, but instead is always fetched
when needed. We use this setting if we want the most up to date information, such as a customer‘s address.
o Use Copy data from a data page to copy data from a data page to the property. The data is not be reloaded unless one of
the data page parameters changes. The data is persisted with the case. We use this setting if we want a snapshot of the
data, such as the details of an insurance policy.

* Linked Property vs Data Page

 The best practice is to use data pages over linked properties whenever possible. Data pages are more flexible with both
reference and copy options. In addition, the data source can easily be changed for example, from database to SOAP.
15
CSSA Study Guide for Pega 7.1 – February 2016

 Linked properties should only be used if we can guarantee that we’ll only ever need read-only access and that the objects will
always live in a database.

* Configure Display and Validation for properties

 The Display and Validation options are available when single value property is selected.
 The UI Control field is populated with a default control for the specific property type.
 The Table Type field provides validation against a list of valid values. The list is determined by the table type. This validation
occurs both at runtime and design time when saving business rules.
 Local List allows us to define a simple list of strings that define the valid values.
 Prompt List uses two values, a standard value, the value stored on the clipboard and database and a prompt value, the value
shown to users.
 Class Key Value allows us to specify a class whose instances become the “allowed values”. The class key value requires us to
enter a validation class, which is the class whose instances are used for validation.
 The Subset Name field is used when the class has a multipart key and we wish to use only a subset of values.
 The Display Only (Not For Validation), option allows us not to validate against these values; commonly used with localization.
 The last table type we will review is the Field Value. Allows us to utilize field value rules which can be fully localizable.
* Configure Advanced Settings for properties
 There are also many advanced features that can be set on a property definition. These options are dependent on the property
mode and type set on the general tab.
o Max Length allows us to set the maximum length, in characters, of the field. Longer values result in a validation error.
o Expected Length is used by some UI controls to set the width of a text field. No warning or validation error occurs if
more text is entered.
o Override Sort Function allows us to specify a custom sort function to be used when sorting a list.
o Access When setting is used for encrypted text to determine when the clear text value can be accessed.
o Edit Input allows us to set the Rule-Edit-Input rule that applies to this property. Edit Inputs is used to format a value
when it is entered on a user screen. This formatting occurs on the server side.
o Use Validate specifies a Rule-Edit-Validate rule that is applied when user input from a screen is sent to the server.
This rule is applied after the edit-input and can add validation messages to the property.
o Column Inclusion provides guidance to database administrators (DBAs) as to whether a column should be exposed for
direct reporting. This field does not have direct impact on the runtime behavior of the system.
o If we want the value of this property to be omitted when a page containing the property is committed to the database
we can select Do not save property data. Marking appropriate properties improves performance by reducing the size
of the Storage Stream property value.

* Configure Security Settings

 Select Cannot be Declarative Target to prevent a property from being used as a declarative target. For developers use.
 Select Cannot be included as Input Field to prevent users from directly entering a value for this property in an HTML form.
This can be useful as an additional security measure for critical properties.
 Select Allow use as Reference Property in Activities to make this property a reference property that can link to a source
property.
 Select Cannot be localized in UI controls to prevent this property from being localized.

* Data Object
 A data object determines the structure of its data pages since each data object references a data class for its definition.
 When you expand the data object in the data explorer, it lists each data page and the number of times it’s used.
 We can also use the data explorer to add new data objects by selecting Add/Remove Data Objects from the dropdown menu.

* Data page
 Data page names must start with D_ or Declare_ to support legacy Declare pages.
 Data pages store a single instance of a class or multiples (Page or List).
 Data pages can be configured as read-only (default) or editable.
 While data pages can be editable they do not automatically persist back to the source. That must be done explicitly.
 The Load Management tab controls the settings for the refresh strategy.

16
CSSA Study Guide for Pega 7.1 – February 2016

* Scopes for Data Pages

 Thread scope creates a separate instance of the Data Page page per Thread. Since a single requestor session may have
multiple open cases, Thread level scope is useful when the data page should be context sensitive to a particular case.
 Requestor scope allows us to share data pages for a given user session and is often used when the data page contains data
associated with the logged in operator.
 The node option makes a single data page instance accessible by all users of the application and other applications running on
a given node. Node level pages reduce the memory footprint by storing only a single copy of the data available to all users and
are an excellent option for storing common, typically more static, reference data.

* Source for a Data Page

 Data Pages (list) load data using sources: Connector, Data Transform, Report Definition, or Load Activity
 Data Pages (page) load data using sources: Connector, Data Transform, Lookup Data, or Load Activity
 It’s also possible to conditionally use a variety of sources based on a when rule.
 When the page is a page list property, we see the “Load this page in this page list individually” option box. (used for multiple of
the same thing – like line items)
* Connector Source for a Data Page
 There are many different connector protocols available including a newly added REST architecture.
 Each of these connector types requires a Request Data Transform rule which sets the properties or parameter values that are
used in the connect rules.
 If the connector class is the same or inherits from the class of the data page, a Response Data Transform is optional.
 Otherwise, a response data transform is required to map the different properties from one class instance to another.
 Other data sources include a data transform as well such as Lookup, which retrieves an instance of a class by its key values.

* Simulation Option for a Data Page

 All of these data sources have a simulation option so that we can test our application in the event the source data does not yet
exist or has no data.
 Selecting this option allows us to select an alternative data source while persisting our intended one.
 This way when the real data source becomes available we can disable the simulation and the data page automatically switches
to the non-simulated data source.

* Load Processing Activity for a Data Page

 At the bottom of the page definition is an option to use a post load processing activity.
 This is useful if we want to supplement our data page with additional data or check for errors during the load process.
 Even in read only, it is an opportunity to make data changes before the page is available to the application.

* Load Management Tab for a Data Page

 For Requester or Thread Pages
o We have the option of reloading the data for each interaction or upon a when rule evaluating to false.
o It could also become stale based on an elapsed time interval calculated from the last load time.
o We may combine the “Do not reload when” and “Reload if older than” options in which case the data page refreshes
as soon as either condition is met.
 For Node Level Pages
o Reload Per Interaction and Do Not Reload When options disappear.
o Load Authorization section is added prompting us for an Access Group to be used when executing the supporting data
page’s rules.
o If no refresh strategy is selected, we may choose to clear pages after non-use. This causes the system to remove
Node level pages that are unused for a period of 24 hours.

* Parameters for a Data Page

 Parameters offer an additional option under the load management tab, the option limit to a single data page
 This setting is only available if a page has parameters and it overwrites the existing data page on the clipboard as soon as the
data page is requested again with a different parameter.

* Optional Data Mapping option

17
CSSA Study Guide for Pega 7.1 – February 2016

 When the data page access method is set to “copy”, an additional configuration option is available and it’s the Optional Data
Mapping option.
 The reason it is optional is that the data page itself already has a response Data transform which is used to map the data.
 It’s helpful if we think in terms of reuse. We might have three different case types that can each use the same data page
provided they each customize the data mapping just slightly.

* Save parameters with this property for access on reopen

 The other is the “Save parameters with this property for access on reopen” check box which only appears on the Refer To
option.
 It gives us the choice to persist the parameter value with the case so that if it is later reopened, it automatically reloads the
data page using the persisted parameter value.
 If not checked, then the data page is not referenced until the parameter is set to some value as a result of further processing
of the case.

* Referencing data pages with syntax

 D_ProductDetail – data page reference with no parameters
 D_ProductDetail.Cost – data page property reference with no parameters
 D_ProductDetail[“A=101”] – data page reference with 1 parameter hard coded
 D_ProductDetail[param.ProductID] – data page reference with 1 parameter using param value
 D_ProductDetail[.ProductID] – data page reference with 1 parameter using param value
 D_ProductDetail[@Pega-RULES:String).trim(.ProductID)] – data page reference with 1 parameter using function result
 D_ProductDetail[ItemID:“A=101”,IncImage:param.Image] – data page reference with 2 parameters hard coded
 D_ProductDetail[ItemID:param.ProductID, IncImage:true] – data page reference with 2 parameters using param values
 D_ProductDetail[ItemID:.ProductID, IncImage:ShowImage] – data page reference with 2 parameters using param values
 D_ProductDetail[ItemID:@Pega-RULES:String).trim(.ProductID) , IncImage:true] – data page reference with 2 parameters using
function results

* Asynchronous loading of data pages

 In some situations, we may want to proactively load the data before it is actually needed.
 To accomplish this from a technical perspective, an explicit call is made to the necessary data page using one of two activity
methods which cause the data to pre-load.
o Load-DataPage method which lets us specify the name of the desired data page to load. If the data page has
parameters, we are able to supply a value for each.
o Call-AsyncActivity method which does not directly load a data page but instead calls another activity which would
want to make a reference to a data page in order to load it.
 If at any point, we require the data to finish loading before proceeding, we can use the connect-wait method to force the
system to wait for a desired period of time before proceeding or return a fail status if it does not complete in a timely manner.

* Principles of Good User Experience

 Automating business processes (example: calculating totals for the user as the inputs change)
 Using intent driven processes (providing users the information they need, when they need it)
 Ergonomics (making the system easier to use, less clicks, smart placement of items on screen-tabs-breaking up screen-no
horizontal scrolling-minimal vertical scrolling)

* User Interface (a component of the user’s experience)

 Portal - user workspace and can also indicate the role the user has- pyCaseManager portal is a good starting point for design
 Harness - an HTML Page/top level component within the Pega UI/ Perform and Review Harnesses are the most popular types
 Section - building blocks of the application UI
 Layout (component but not a rule) - way we want our form data to be presented, Every section contains at least one layout
 Controls - most granular of the UI components, allow us to present data, take user input, make decisions & interact with users

* Access and Leverage the UI Gallery

 Launch the UI Gallery by selecting DesignerStudio-> User Interface-> UI Gallery.

18
CSSA Study Guide for Pega 7.1 – February 2016

 The UI Gallery is configured in two parts.

o Showcase, which contains some samples of complete User Interfaces
o Available Components, which contains samples of individual controls
 Components
 Layouts & Containers
 Tables & Grids and Samples
 Combinations
 “View design-time configuration” link opens the section rule so that we can examine how examples have been configured.

* Use the UI Kit - pyEndUser71 skin

 The UI Kit ruleset provides the latest Pega standard end-user UI, with features designed to ensure responsive interfaces on
mobile devices, and includes the most current, enhanced styles used by the pyEndUser71 skin.
 The UI Kit is delivered as a locked ruleset. To customize the rules provided by the UI Kit, copy them to an application ruleset.

* Parts of a Portal
 The top pane is setup as a header that provides access to search for or create new work.
 The left-hand pane is referred to as the navigation pane. This allows the user to switch between screens of the application.
 The main area is known as the Work Pane (mandatory). This is where a user interacts with each individual piece of work.

* Working with Harnesses

 Aside from controlling user portals, the main function of a harness is to support the display of a work (Work Pane of the portal)
 Think of a harness as the form for the work object; it groups the individual sections together and presents them to the user

* Portal Role (Skins Tab)

 User
 Developer – system includes additional scripts, such as check-in and check-out.
 These additional scripts cause the system to leverage more memory, so it is a best practice to specify any new portal as user
and to only use the existing developer portals for development.

* Portal Type (Skins Tab) can be one of four possible values:

 Fixed—provided to support backwards compatibility with applications created - prior to version 5.5
 Custom—this type of portal determines the user interface from an activity
 Mobile—this type of portal supports displays on smartphones and tablets
 Composite—this portal uses harnesses to define its layout and is the recommended portal type to use for all new
development.

* Portal Skin rule (Skins Tab) can be one of four possible values:
 In most cases, we want to default to the Application Skin option. This will allow the system to inherit all the same settings for
the entire application.
 Alternatively, we can specify another skin to use, but this does not provide for reuse and should only be used when it’s
unavoidable.

* Portal (Spaces Tab)

 When using Composite portals, the other tab we need to configure is the Spaces tab.
 In most cases, we only need to specify a single space called Work and provide the associated harness.
 The Work space must always be present even if we specify any additional spaces.
 The harness we specify is a special kind of harness that uses a screen layout.

* Screen Layouts
 Screen layouts allow us to specify which sections to display to the user.
 Screen layouts consist of a main section and its adjacent regions. Out of the box, there are eight possible configurations for the
main and adjacent sections.
 More combinations can be defined in the skin rule, but the majority of portals leverage the Header Left configuration.

19
CSSA Study Guide for Pega 7.1 – February 2016

 Each region in a screen layout can only contain a single section, though that section can then in turn contain multiple
embedded sections.
 The main region is typically a section that provides a single Dynamic Container (necessary to display work objects)

* Categories of Harnesses
 New—this encompasses any harness that is displayed when the work object is being created
 Perform— this encompasses any harness where the user is performing their assignments
 Review—this encompasses any harness where the user is viewing read-only data and not interacting with a flow action
 Confirm—this encompasses any harness where the user has submitted the work and does not own the next assignment

* Flow Actions
 Flow Actions are how a user interacts with a work object in a Perform harness.
 Specified in the flow as connectors off an assignment.
 Data Transforms and Activities can be configured to execute before and after a flow action on the Action tab
* Local Actions
 Local actions are a special kind of flow action that is not associated with an assignment in a flow but configured the same way.
 They perform the actions specified on the Action tab but leave the work object on the same assignment
 Used for optional tasks, such as transferring work between operators, updating information, and sending correspondence
 Local actions should only be used if the requirement is an optional task

* Layout Types
 Dynamic Layout – This is the most common layout used and use HTML5 tags and support responsive behavior
 Column Layout – As the name suggests, this creates a layout with columns
 Smart and Free form layouts – they exist in the product for backward compatibility
 Repeating layouts – Used to display repeating groups such as a pagelists

* Dynamic Layout Format

 The format controls the presentation
 The format is defined in the skin rule. PRPC ships with a set of standard layout formats that we can use in the application skin.

* Repeating Layouts
 Dynamic and Column layouts can also be extended using the repeating mode.
 To add a repeating layout, we select Repeating in the Set Layout Type dialog and then select the type we want.
Grid (commonly used choice)
Tree Grid
Dynamic
Column
Tabbed
 Unlike other layouts, the repeating layouts (like grids) require us to identify a source.
page list
a data page (with list structure)
report definition
 Dynamic repeating layouts can be sourced using either a page list or a data page.
 The repeating layout displays a single cell where we include a section. The section gets repeated for each item of the page list.
 The Section can be designed to use any dynamic layouts similar to how we set it up for a single level property.
 Column repeating layouts are similar to grids except the items are repeated across columns instead of rows. Column
repeating layouts can be sourced by a page list or a report definition.

* Configuring layouts
 Layouts play a critical role in separating content and presentation.
o The presentation is configured in the skin rule
o The content is configured directly in the section where the layout is added
o Data elements are added into the layout using Control rules

20
CSSA Study Guide for Pega 7.1 – February 2016

* Containers and Headers

 Layouts can be configured to use headers and use containers
 They are useful in grouping cells to present them in logical groupings
 The properties panel of the layout has options to select the header and container format
 The header and container formats are styled in the skin rule.

* Tabs and Accordions

 We can also use a tab or an accordion as the header format.
 When we add a Tab Layout a tab shows in the Layout.
 We can add another layout or a section inside this tabbed layout as a new tab. To do this, we select Layout or Section in the
Layout group and then drop it next to the existing tab.
 To delete a single tab we need to click the tab and then use the delete icon that is in the canvas. Clicking the delete a row icon
will remove the entire tabbed layout (including all tabs).

21
CSSA Study Guide for Pega 7.1 – February 2016
* Nesting of Layouts
 Dynamic and column layouts allow nesting of layouts.
 Nesting is a very powerful feature which helps in the creation of layouts where fields are arranged in multiple ways.

* Floats in Dynamic Layouts

 Another powerful feature of a dynamic layout is that it can be floated to the left or the right.
o Set layout width to auto — This flag allows layouts to use only the width that it requires.
o Self-Clear — This field is enabled by default and is used to account for the height of floated layouts. Do not disable
this field unless you want more than one float stacked horizontally.
o Clear floated layouts — This field clears other floated layouts so that they don’t appear in same line.
 Floats are useful when rendering multiple layouts in the same line.

* Configuration of Grid Layouts

 Grid layouts allow us to configure pagination formats, as well as conditions to control the visibility of the grid, row, header and
footer. We can also configure the refresh when condition so that it can refresh only a single row.
 Pagination is useful not just for the cosmetic appearance, but also aids in improving the performance at runtime. The results
are split across pages and at runtime the system displays only the first 20 and then users have to click to the next page to see
another 20. In addition, if we select Progressive in pagination, it actually gets only 20 rows in clipboard.
 Grids allow various types of edit modes.
o Inline allows rows to be edited directly in the grid
o Masterdetail allows them to edit the grid in a modal dialog or by expanding the row or in a separate panel outside the
grid. Master-detail is useful if the grid displays the high level information and clicking a row then provides additional
details. The content that is being displayed to present additional details comes from a flow action rule.

* Grid Operations in Grid Layouts

 All three modes (None, Inline and Master-Detail) support grid operations. Grid operations allow us to configure sorting,
filtering of the records in addition to other settings. When enabled, sorting offers column specific operations, so we can disable
or enable only the columns where we require sorting.
 Filtering in grids can be configured to either use a value or range. The options vary based on the data type of the column, if it’s
numeric it allows the range to use min and max values and if it’s string it uses a set of string characters it can search on.

* Standards Mode
 Modern browsers comply with stricter standards mode, which follows the W3C and IETF standards.
 In this mode, web applications rendered through a browser use a combination of HTML and CSS.
 Modern browsers also provide a “Quirks” mode for backward compatibility, to support the browser-specific code found on
older web sites and in older web applications.

* Standards Mode in PRPC

 PRPC applications must use Standards mode to use the newer layouts such as dynamic layouts, column layouts, screen layouts
and repeating dynamic layouts.
 The newer layout types use the <DIV> tag instead of the <TABLE> tag which makes it much more flexible to resize the
information based on screen resolution.
 In PRPC Standard Mode can be enabled in few a places:
o Application rule: In the application rule there is a flag (Include HTML5 document type) listed under the user interface
section. When checked Standards Mode is enabled.
o Harness rule: In the harness rule on the Advanced tab we select Inherit from application rule for the document type
and the application renders in standards mode.
 If our application was built prior to Pega 7, we can upgrade to Standards mode by using the HTML5 readiness gadget.
 When using IE as the browser, we need to disable compatibility view for the standards mode to work.

* Designing Layouts for Achieving Responsiveness

 When using layouts, we either use a standard Format (such as Stacked or Inline grid double) or define a custom format.
 The standard formats shipped in the product use % for width, so they use the width depending on the screen resolution.
 Designing UI for multiple form factors we should avoid horizontal scrolling. Setting the width in % helps us to achieve this goal.
* Set Responsive Breakpoints

22
CSSA Complete Study Guide for Pega 7 – January 2016

 Dynamic layouts separate the presentation from the content. The content that displays in the screen is configured in the
section rule while the presentation or the style is configured in the skin rule.
 Responsiveness is configured by enabling the response breakpoint.
 When the screen resolution reaches the max-width it pushes the sidebar below the main area.
 The size can be configured in pixels or in em’s (the current font size). In addition to max-width we can also specify the min-
width at which the dynamic layout will display in this format. That is typically used when we have multiple response points.
 Response breakpoints can be set on various layouts (dynamic layouts, column layouts, grids and in screen layouts).

* Set Responsive Breakpoints for Grid Layouts

 Unlike other layouts, there is some configuration to be done in the grid repeat layout for responsiveness.
 In the presentation tab there is a flag to enable responsiveness.
 We also need to configure the columns importance as Other, Primary, or Secondary.
 Responsive options are: Drop Columns with importance “Other”, Transform to List, and Hide Grid

* Layout Group
 Layouts can be made responsive using Layout groups.
 Layout group is a way to group different layouts such as dynamic, column, repeating dynamic and present them together.
 Layout group can also include another layout group.
 PRPC support four formats by default:
o Tab
o Accordion
o Stacked
o Menu
 Layout groups require that the applications be rendered via the HTML5 Document Type (Standards mode)

* Skin Rule
 The skin rule is now a one stop shop for configuring the presentation of our application.
 The tools in the skin provides us the ability to achieve branding and styling consistency throughout our application.
 The skin generates the entire CSS for our application.
 A skin rule is broken down into three parts. Mixins, Components and CSS.
 Skin rules are only referenced in a couple of places throughout the application.
o application rule (main skin for the entire application)
o portal rule (can override the default skin for cases where we may want to display a different look and feel, such as for
external vs internal users)
 Operators can also setup a preference for a particular skin. This preference is used for developers to override the skin of the
designer studio when previewing or testing an application. Ideally, we refer to the same skin as our application.

* Mixins
 A mixin defines values for a group of style attributes.
 Mixins allow for efficient and clean style repetitions as well as an easy way to update our styling with ease.
 A collection of mixins form the palette for the skin, such that a mixin or mixins can be used to style components in the skin.
 There are three different kinds of mixins that can be defined.
o Typography, which covers anything related to text.
o Backgrounds, which covers, well, backgrounds.
o Borders, which relates to borders and shading effects.
o There’s a 4th category called Combinations, which is any mixin that affects more than one of the other categories.

* Format Categories
 General
 Layouts
 Controls
 Reports

* Formats

23
CSSA Complete Study Guide for Pega 7 – January 2016

 The Components tab is where we define styles for all the different components.
 Every component in the system can have one or more formats defined (Many have additional formats already defined)
 We can think of a format as a ‘Type of’, so that we can have a format of button called Primary, and another called Secondary.
 A format is what determines the styling of the component once associated to a User Interface element in a section.
 Once these formats are defined in the skin, we can then associate formats on User Interface elements we drop in a section.
 This association provides the User Interface element its look and/or style.
 All components have a default called either “Standard” or “Default” that is supplied out-of-the-box.
 Formats are where we use mixins. We also have the option of overriding part of the mixin.
 By using mixins, we’re defining the same style to all components formats where that mixin is used.

* Using Formats
 In any UI screen, select the component to edit, open the properties panel and on the presentation tab, select a format.
 Once we click on OK our button now reflects the style defined by the new format.

* CSS
 The CSS portion of the skin can largely be ignored. This tab is leveraged to support backwards compatibility with applications
that already use custom CSS. For any new applications, it’s better to leverage the format and mixin features.
 If style sheets are used, a warning message is added to remind us that it should be avoided.

* Controls
 Controls are used in two places
o when a property is defined (in the property rule form)
o where the property is referenced in the user form such as sections.
 Controls are also useful in formatting the columns of the report definition.
 PRPC automatically assigns a default control when a new property is created and the same control is applied when the
property is referenced in the section or report definition.
 As developers we have the option to change the control in either the property rule form or in the rule where it’s referenced.
 Selecting a control in the UI cell overrides control defined in the property rule form. By default, it uses the setting Control
inherited from property. We can use the change link to change it to another control.
 Controls are auto-generated giving us flexibility to use in various browsers, easier configuration options (eliminating the need
to write JSP, JavaScript, CSS or HTML tags).

* Auto-generated controls that are shipped in the product

Action Controls User Input Controls Formatting stored Values

pxButton pxCheckBox pxCurrency

pxIcon pxDateTime pxDisplayText (Display value in read-only format)
pxLink pxDropdown pxHidden ( The value is hidden from display)
pxRadioButtons pxInteger
pxAutoComplete pxNumber
pxTextInput pxPassword
pxTextArea pxPercentage
pxRichTextEditor

* Non-autogenerated controls
 Auto-generated controls can be configured to serve most requirements, however some of the non-autogenerated controls
that we still use are Chart, SmartInfo, and the Menu Bar.

* Configuring Controls
 Controls are a rule type that is defined as part of the UI Category.

24
CSSA Complete Study Guide for Pega 7 – January 2016

* Controls have four separate sections that we can configure:

1. Basics – here we select the type of the control. The choices in the UI Element field vary with the control mode.
2. Options/List Source – the choices here vary with the type of UI element we previously selected.
3. Format: The Format section is useful when configuring the presentation. Format appears in the presentation tab at runtime
for us to configure or override the default selections made in the control rule. We need to remember that the presentation in
terms of font, color choice, size, width and other such configurations must be applied in the skin rule.
4. Behavior: This allows configuring how a change in value on this control will affect other data elements. Event/Action

* Control Options:
 Most of our applications use standard auto-generated controls, so we can configure the options and formats in the sections
where the control is added. Behaviors are also configured in the section where we add it.
o The General tab consists of the property that the control is associated with, the label, visibility settings and so on. List
Source is also configured in the General tab.
o The Presentation tab allows us to configure the items in the Options and format sections.
o The Actions tab is used for setting the behavior, which we will learn about

* Set Event-based actions on controls

 Controls can also be used to apply actions based on certain events. The behavior is configured in the Actions tab using an
Action set. An Action set has two components –
o Event (when we want the action to occur) Mouse, Keyboard, Other
o Action (what we want to perform) Post Value, Refesh, Run data transform
 The same event can trigger more than one action.
 Actions are performed in the order defined, so Actions attached to an event are sequenced
 An additional events can be in the same action set. When adding an event the actions are performed when either of these
events occurs.
 If we need different events to perform different actions then we need to create it as a new action set.

* Auto-complete to select from a list

 The auto-complete looks like a text box with a special icon at the end to indicate that it is an auto-complete control. When
users enter one or more characters in the auto-complete field, it filters the list to show only the options that match the
entered string option.
1. Listing Source – Similar to other list based controls such as drop down, we can select the source for the list. We can select
Data Page, a clipboard page or a report definition.
2. Search Results Configuration- Once the source is selected the system provides us with the option to select the fields that
can be used as search criteria. This section allows us to select which fields appear in the auto-complete (using the Show
flag), if the value in the field is being stored in another property (using the SetValue flag) and if the field is used in the
search (Use for Search).
3. Search Method – Auto-complete can be configured to search “StartsWith” or “Contains”
4. Search Results – search results can be categorized using a specific field or can be configured to display the best bets. Best
bets display the most popular amongst the list of options at the top.
5. Number of Options – we can also configure the minimum number of characters that a user needs to enter before seeing
the list of choices and also the maximum number of results that it can display for performance reasons.

* Cascading relationships using controls

 In some cases, when a form is presented to users, the fields are related to one another.
 Controls that can be populated using a cascading relationship include: Auto-complete, Drop down, and Radio buttons
 The product which is dependent on this field is configured in the general tab of the property as a parameter.
 In the parameter field we need to configure an action set. The Post value action triggers saving the change.
 PRPC supports cascading relationships to multiple fields.

* Dynamic User Interface

 Dynamic UI is a term that refers to the concept that UI content should change dynamically based on user interaction.
 In PRPC, dynamic UI’s require an event- action model.
 When the event occurs the action associated with it presents the change immediately to the user. This helps in creating a user
interface that provides a great user experience.
25
CSSA Complete Study Guide for Pega 7 – January 2016

* Dynamic User Interface Benefits

 We do not need to clutter the user interface with unnecessary information.
 User forms are no longer lengthy, they only display information that is relevant to the user.
 We can refresh only a part of the screen, even a single cell so the changes appear seamlessly.
 This concept is very powerful in PRPC – there is a wide variety of supported events and a wide variety of supported actions.

* Events
 Events are used to trigger an action that makes the user forms dynamic.

* Event Association
 Controls – In most of the cases, we associate events on controls. The main purpose of a control is to decide the presentation of
the data element in the user interface screen. Events are not defined in the actual control rule. They are defined in the cell
where the control is added.
 Grids - The Events are configured by opening the properties panel of the Grid layout.
 Expression Calculation – The event occurs when a declare expression computes the value of a property. This configuration is
enabled by default on all newer PRPC versions. This configuration is on the flow action rule form.

* Actions
 Actions are triggered by the event.

* Actions Association
 Actions are usually configured along with the events using an action set.
 An Action set can be defined both on controls and on grids.
 Some specific actions can also be associated outside the context of an action set. They are directly configured on the part of
the screen where we want the action to take in effect. These actions can be to:
o Apply a visible when condition on a cell or a section or a layout to hide or show its elements based on a condition.
o Apply a refresh when condition to refresh a cell or a section or a layout.
o Apply a Disable when condition to disable the cell.
o Apply a Read only condition to make the cell read-only.
 Actions can also be associated directly in a Navigation rule.

* Actions Sets on Grids

 After a grid is added, an action set can be configured via the properties panel.
 The action set is initialized based on edit operations.
 Actions can be customized on grids, however the list of common actions is a little different from that of controls. Again the All
actions link opens up the complete list of actions. Examples include:
o Add Item
o Delete Item
o Edit Item
o Open Selected Item
o Set Focus

* Visible When
 Visible when is the main mechanism that's used in PRPC to toggle whether or not some part of the page is visible.
 Visible when can be applied on sections included in another section, on layouts, and on cells.
 Visible when uses a condition.
 Three Visible when options exist for dynamic layouts and sections.
o Always
o Conditional (expression)
o Conditional (when rule)
 Additional Visible when options for Cell Properties (In addition to Always and Conditional options)
o If not blank
o If not zero
 Visibility conditions can also be added on grid layouts. We can configure to show/ hide the entire grid or a specific row.

26
CSSA Complete Study Guide for Pega 7 – January 2016

* Refresh When
 Refresh When allows us to have a portion of a page return to the server to refresh its content when a specified condition is
true.
 Refresh When can be configured to refresh either an included section or a specific layout.
 Similar to Visible When, we can use the condition builder to add conditions.
 We can configure the properties to respond to a condition and there is the option to use AND, OR to add more than one
condition. In addition to these, there are two keywords.
1. Changes – This indicates when the property’s value is changed, in this example, it refreshes when the discount is changed.
2. AddDelete – This applies only on repeating groups, so a line item can be added to or deleted.
 We can also configure refresh of a specific row within grids. By default, the row never refreshes; we can configure it to refresh
on a specific condition
 Unlike Visible When, a Refresh When conditions can also be configured using an action set. The action set allows refreshing the
current section or another section by its reference.

* Disable When
 Disable whens can be applied only on a control using an expression or when rule
 Always permanently disables it, while Never is the default choice for all controls.

* Read-Only When
 Read Only whens can also be applied only on a control and the choices are not very different.
 Auto means editable in most cases while read only can be applied as an expression or a when rule.

* Navigation rule and its usage

 Navigation is a type of UI rule which is very useful in rendering a menu.
 This rule essentially has one tab (Editor) to configure.
 We add nodes using the icons in the header and form a tree.
 Typically a parent-child relationship and then Tools has some child nodes.
 Other than setting the hierarchy, the next important part is to define the action.
o Actions can be added by double clicking the row to open up the properties panel.
o We can also modify the type field.
o Item is most commonly used. An Item list can reference a page list which is useful when presenting a dynamic list of
options stored as part of a pagelist.
o Reference is useful to refer another navigation rule.

* Run Conditions on Client

 Events are processed on the server, unless specifically configured to process on the client.
 Events can be processed on the client if:
o The condition does not reference a When rule. When rules can only be processed on the server.
o The condition contains no more than four (4) properties and constants, combined by Boolean operators.
 When the condition is configured to run on the client, the server sends all of the possible layouts to the client, and the client
determines which layouts to display and keep hidden.
 The choice of client-side or server-side processing can have a significant impact on how the UI behaves for end users, as
outlined in the following table:
Client-Side Event Server-Side Event
Fired client-side and changes seen without requiring a refresh action Fired server-side and requires a refresh action to see changes
Refresh is not required since the html source already has the content Content requested from server which changes the html source
downloaded in client side and is usually hidden using a markup
Can be applied only when using a direct expression for determining Can be used on all possible conditions
the visibility
Usually done in cases where the content is to be hidden, there is not It can be made to look not obvious by refreshing only that part of the section that
a lot and it is more effective and quicker to save an extra trip to is changed
server
Example: Check if the user has AAA membership, enabling it opens Example: Display 5 recent transactions and then click next 5 to see the next 5
up a textbox to enter member # transactions

27
CSSA Complete Study Guide for Pega 7 – January 2016

* How does the navigation rule get referenced?

 There are multiple options:
1. We can reference it in an action set either using a control (such as a Button, link) or on the grid.
2. In the menu bar control.
3. Using the reference keyword in a navigation rule.
 To access a Navigation rule, we need to define an action set that can have an event (click, doubleclick, rightclick, etc.) that
invokes a specific action (Display Menu) [Action_Nav_rule.png]

* Use Data Transforms

 Multiple features in PRPC accept a reference to a Data Transform rule.
o To set default values for the properties defined on a clipboard page
o To copy one clipboard page to another clipboard page
o To map properties defined on one page to another page
o To append properties from one page list property to another page list property
o To iterate over pages in a page list property to map data on each page
o We can reference Data Transform rules in a host of other rules, wherever we need to set and manipulate data

* Do Not Use Data Transforms

 In general, there are only a few situations in which a different approach might be more appropriate than a data transform:
o A property value should be set declaratively, rather than procedurally
o When defining source data for a data page
o Updating data in a database. Data transforms do not provide any means to write data to a database.

* Structure of Data Transforms Definition The columns include:

 Action – This is where we identify what the step is for. This is required for each step.
 Target – Most actions require a target. In cases where a target is not required, we cannot select one.
 Relation – Optional column. The typical relationship between source and target is “equal to.”
 Source – This becomes selectable only if the action requires a source. We can specify literal values, properties or expressions.
 As a best practice, and to improve readability, do not create more than 25 steps.

* Configuring Data Transforms

 The “Definition” tab is where we define the actions to be taken. We use the Definition tab to manipulate the data.
 The Data Transform rule definition is a sequence of rows in a tree grid. The system invokes each row in sequence starting with
the first row except for the conditional and transitional types of actions.
o 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.
 The “Parameters” tab is where we can either list the variables that input data to, or return data from, the Data Transform

* Use of Symbolic Indexes

 When we are iterating through the pages or updating a page, we don’t know the index of the page on which we are working.
 We iterate through the pages in both Data Transform and Activity rules.
 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 (for “Update Page” action in the Data Transform and also for
looping through in the steps of an Activity rule)
<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

* 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.

28
CSSA Complete Study Guide for Pega 7 – January 2016

* Data Transforms in Business Processes

 In the starting processes of a case, pyDefault is the data transform is invoked to set initial properties for the case instances.
 In the case hierarchy, for data propagation we can use the “Also apply Data Transform,” option
 We can also use a Data Transform rule in a step where a subcase is instantiated from the case designer of the parent case.
 Referencing a data transform on step configuration is the same as setting the properties on the smart shape in the flow rule.
 In flows, on any connector between any two shapes, we can set properties or reference data transform rules.
 In Flow actions, we can specify a data transform on the flow action's Action tab.
 We can reference a data transform in a section rule, for a change event of any cells directly
 We are able to reference a data transform if we select “Refresh This Section” for the client change event
 We can reference a data transform from another data transform rule

* Data Transforms Evaluation Order

 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. Data Transform on the starting flow of the subcase
2. Data Transform configured on parent case type rule (defined on Case Designer – Details tab data propagation)
3. Data Transform defined on the case instantiation step in the Case Designer of the parent case

* Purpose of an Activity Rule

 Activities are structured as a series of steps which are executed in sequence. Each step references a method, or another
activity, or can contain plain java code.
 Activities are harder to maintain and not as easy to construct as other rules in PRPC. A best practice is:
o Use declarative processing rather than activities when feasible
o For data manipulations, we can use a Data Transform instead of an activity
o To query from an external DB, we can use Report Definition rules instead of activities
o We may need to automate the processing of cases with a sequence of steps to be executed
 Before writing our own activities, let’s look at the standard activities (API activities) that come with PRPC.

* Purpose of an Activity Rule

 Some standard activities we can use are CorrNew to create and send emails, AddWork to create a new case instance, and
UpdateStatus to set the status of the case instance.
 Here are some scenarios where we cannot avoid writing an activity. For example:
o To perform Case related functions such as creating a case instance, routing the case, or updating the work status, as part
of certain operations such as parsing an input file.
o To send requests to external systems or to receive requests from external systems.
o To perform functions such as writing to a log file or to the history database.

* Configuration of Tabs of an Activity Rule

 Parameters tab is used to identify any variables serving as input or output parameters to the activity rule.
o The Local variables section identifies scalar variables, and they are stored as fields in the java class that PRPC generates to
implement the activity. They are often used to pass information from step to step. We can reference the properties listed
here as Local keyword (Local.PropertyName) in the Steps tab for any processing.
 The Pages and Classes tab lists pages and classes - the three common page types we will interact with are:
o Primary pages (clipboard page which has the same class as the “Applies To” class of the activity)
o Step pages (When a Branch or Call instruction executes as defined in a step in the Steps tab, this becomes the primary
page for the duration of this step's execution)
o Parameter pages (parameter page contains parameter names and values, as listed in the parameters tab)
 The Security tab has a few settings that allow us to set who can access the activity and how.
o “Allow direct invocation from the client or a service” check box indicates whether user input processing can start the
activity or it must only be called from another activity.
o The authenticate checkbox, when selected, only allows authenticated users to run the activity.
o The Privilege Class and name identify a privilege a user must have in order to be allowed to execute the activity.
o The Usage type determines whether and how the activity can be referenced in other rules. Select one usage type
depending on the intent of the activity.

29
CSSA Complete Study Guide for Pega 7 – January 2016

* Label, Loop, and Other Options for an Activity Step

 We use the Steps tab to do sequential programming steps.
 Each step of an activity contains multiple parts:
 The Label provides an identifier for the step that can be referenced from other steps. We can also put two slash characters as a
step label to indicate to Process Commander not to execute the step. Such steps can also be used as comments.
 The Loop allows us to setup the iteration through the elements of a Value List, Page List, Value Group or Page Group and
performs the provided activity method on each value or each embedded page.
 To add a child step to an iteration, right-click the iteration step and select “Add Child”.
 The When allows us to define a precondition that controls whether the step is executed or skipped.

* Loop Options For Activity Steps

 “For Each Page” option to sequence through all pages of a specified class or classes and perform a method or instruction for
each page. Leave the Step Page field blank. Each time the step repeats, the step's page changes internally automatically.
 Use the “For Each Embedded Page” option to apply a method or instruction to each embedded page in a Page List or Page
Group property. Identify the property containing the embedded pages in the Step Page field.
 For the optional Valid Classes (“Only loop for certain classes” as shown below) parameter for these two “Repeat” conditions,
we can enter a class or classes. We can click the “Add Row” icon to add more than one class. When valid classes are
populated, iteration processing only processes pages of the valid class list and the ones derived from them and skips over the
pages of classes that are not in the list.
 We can select the “For Each Element in a Value List” option to repeat the step for each element in a Value List property. When
we select this iteration form, a Property Name field appears. Identify the Value List property in the Property Name field.
 We can select the “For Each Element in a Value Group” option to repeat the step for each element in a Value Group property.
When we select this iteration form, a Property Name field appears. Put the Value Group property in the Property Name field.
 We select the “For Loop” option to repeat the step a number of times determined by the values of integer constants or integer
properties. Enter integer constant values or integer property references for the Start, Stop, and Increment fields.

* When Rules for Activity Steps

 We need to check the “Enable conditions before this action” to display the row where we can enter a condition or reference a
When rule. When the rule returns true or false, we can select one of the conditions.
Continue Whens To continue to evaluate other when conditions if any
Skip Whens To skip processing rest of the when conditions if any
Jump to Later Step To move to a later step with the label of the step noted in the param field
Skip Step To skip the step and to move to the next step
Exit Iteration To skip the iteration and to move to the next iteration in the same step
Exit Activity To skip processing rest of the steps in the activity

* Method, Step Page, Description and Jump for an Activity Step

 The Method indicates which Process Commander method the step will execute.
 The Step Page, as mentioned earlier, identifies a Page to be used as the context for referenced properties within the step
 The Description is text that explains to other developers the action that the step is performing.
 The Jump condition or post condition is similar to the When precondition. After the step is executed, a condition is evaluated.
Based on the result, the activity may perform different actions such as jump to another step, or exit the activity. Also, there is
another option of what needs to be done in case of an exception in the step processing.

* Some Common Methods

 Process Commander provides an extensive library of methods that we can use in our activities. Some common methods are:
o Property-Set — used to set the value of one or more properties.
o Call — used to find and execute another activity. After the called activity completes, the calling activity resumes
processing.
o Page-New – creates a blank clipboard page of a class specified.
o Page-Remove — used to delete one or more named pages from the clipboard. If no page is specified, the page
referenced by the step page will be removed.
o Apply-Data-Transform – used to invoke a Data Transform rule directly from a step.

30
CSSA Complete Study Guide for Pega 7 – January 2016

* Pega Pulse
 PegaPulse is a rich social platform that adds social activity streaming capabilities to the user interface.
 Most of the standard harnesses, such as Perform, Confirm and the Review harnesses use the contextual activity stream
 All the posts show by default. That can be filtered Posts by Me, Automated Posts, Posts with Files and Posts with Links
 PegaPulse is limited to attaching conversations, URLs and files, compared to Case Attachments which are more open.
 In PegaPulse, we can take actions such as creating a task, which we cannot do with Case Attachments.

* Public vs. Private Mode in Pega Pulse

 In private mode, only those who have access to the case can view the content. This can be made only in the context of cases.
 In public mode, anyone who has access to the case and also users in the workgroup can view the content. Workgroup users
can view the content in the standard portal interface.
 When a posting is made from the portal, it is visible to the work group users only.

* Pega Pulse Social User Profile

 The profile includes operator information such as photo, position, contact information, and skills.
 When we click on the link of any user’s profile, we see that information and send a PegaPulse posting to that user.

 We can reply to a posting from here.

 We can post to the workgroup from here – and it’s the same as posting from the portal.

* Configuring an Application to Automatically Post to Pega Pulse (Post to Pulse smart shape)
 To automate the posting of an update to the contextual activity stream, we can use the Post to Pulse smart shape.
 The properties panel for this shape contains four configuration options that govern how updates can be viewed.
o The User posting drop-down list lets us select the user under whom the system adds the update to the contextual
activity stream. By default, posts are attributed to the assigned operator (Current Operator). We can also select
Other, then select the operator ID we want to use.
o The Message field contains the content of the automated post.
o The Message pertains to the current case and Make secure post checkboxes allow us to configure the availability of
the post. The Make secure post option is available only when Message pertains to the current case has been selected.

* Adding Attachments Add and Advanced

 On the right hand side, we can use the “Case Attachments” section to add attachments.
 We can use the “Add” or “Advanced” link to add attachments.
 We can attach a File or a URL using the “Add” link.
 When we click the “Advanced” link, an attachment listing window pops up and it has an “Add” dropdown button. Using the
button, we can attach a Note, File, URL, Screenshot and a Scanned Document.

* Configuration for ECM

 We can store attachments in an external ECM using the CMIS protocol such as Microsoft SharePoint or IBM FileNet.
 We enable this option by:
o Selecting a checkbox on the application rule “Integration” tab to enable CM system integration for the application.
o Use the “Connector Name” to specify the Connect CMIS rule used to connect to the external CMS system.

* Viewing Attachments
 Anyone who has access to this case can view the list of the attachments and can also view the contents of the attachments.
 In the Advanced attachments window, attachments are grouped by type. Here we get to see the timing/description/author.

* Adding Attachments with Local Acction

 If the perform or review standard harnesses are customized, or some other standard or custom harness is used, the case
attachment section may not be available to end users to add attachments. In that scenario, the system architects can provide a
local action to the end users; end users can select the local action menu option from the other actions menu.
 All attachments types can be added as a local action. For every attachment types, there is one flow action.

31
CSSA Complete Study Guide for Pega 7 – January 2016

 AddAttachments allows us to add a file attachment and assign it to an attachment category and AddMultipleAttachments
provides the ability to add multiple file attachments, with a category for each, in a single action.
* Tables for Attachments
 By default, case instance attachments are stored in the “pc_data_workattach” table
 They are stored as instances of concrete classes derived from the “Data-WorkAttach-“ class
 They are not stored directly with the case instances in the same table.

* Adding Attachments Automatically

 To add a note or link or file, we can use the “Attach Content” smart shape in the flow rules. In the flow rule, when the smart
shape is processed, an attachment is attached to the case instance automatically. End users can view the attachment in the
same way as before, in the perform and review harnesses.
 When attaching a file, we can either attach a binary file from a folder or 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.”

* Security through Attachment Category

 Process Commander provides a powerful tool to restrict operations that can be performed on case attachments. We restrict
access using the attachment category. 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.
 We can reuse the standard categories or create entirely new attachment category rule instances.
 Two main tabs are available on the rule form. On the first tab, Security, we can control access to the attachments through
Privileges or/and When rules.

* Attachment Category Security Tab

 In the “Access control List by Privilege” section, we can select a privilege rule in the “Privilege Name” field. The system uses the
“Applies to” class of the attachment category to validate the privilege name.
o Create — to grant users the ability to add attachments of this category.
o Edit — to grant users the ability to edit attachments of this category if they have the privilege.
o View to grant users the ability to view attachments of this category if they have the privilege.
o Delete Own — to grant users the ability to delete attachments of this category that they added.
o Delete Any — to grant users the ability to delete any attachments of this category if they have the privilege.
 We can add multiple privileges, but users must hold at least one privilege to gain access.
 In the “Access Control List by When” section, we define a list of When rules to control access to the attachments.
 The “Enable Attachment Level Security” option allows the operator at runtime to identify one or more work groups that have
access to the attachment. This restriction operates in addition to and independently of any other restrictions for the category

* Attachment Category Security Tab

 The next tab, “Availability”, provides a list of the attachment types. We select the checkboxes for the attachment types that
are valid for the category and the work type identified by the “Applies to” class of this attachment category rule.
 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.
 When adding an attachment to the work item, users have the ability to choose the “category” to which the attachment
belongs.

* Push and Pull Routing

 Push routing routes the assignment to a single user’s worklist:
o Immediate ownership as soon as the assignment is created
o PRPC can use criteria to select the owner, including availability, the operator’s work group, his/her skills, or workload.
o It is also possible to route to a substitute operator if the chosen operator is not available.
 Pull routing routes to a workbasket that is shared across multiple users.
o Ownership does not occur until an operator takes action on it.
o Most applications use “GetNextWork” logic to select the most urgent assignment from multiple workbaskets.

32
CSSA Complete Study Guide for Pega 7 – January 2016

o 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.

* Viewing Work
 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.

* Directed Web Access (DWA)

 We might need to get information from external users who don’t have operator credentials to login to PRPC
 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.
 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.
 We need to configure URL that is to be sent in the emails. We can configure this through Designer Studio
-> System -> Settings -> URLs -> Public Link URL.

* More Standard Routers

 When we have the assignment type as “WorkList” or “WorkBasket,” we can select a host of standard routers.
 Most of these routers are for push-based routing, which routes to the worklist of a particular operator. Most of the routers are
parameterized and we can enter the appropriate parameters when we select a router.
 “ToWorklist” routes to a particular operator by name.
 “ToWorkParty” routes to a work party.
 “ToWorkGroupManager” and “ToOrgUnitManager” route to the manager of the operator’s workgroup & 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”, operators are sorted by workload and desired skills.
 Note: ToWorkgroup, ToSkilledGroup, and ToLeveledGroup do NOT route to a group; they route to an operator
 Workbasket routers are used with pull-based routing.
o The “ToWorkbasket” router does exactly that; routes to a particular workbasket.
o “ToSkilledWorkbasket” also routes to a particular workbasket.

* Work Balanced and Skill Based Routing

 To assist both push and pull routing, we can associate skills to operators and assignments. The skill rule stores 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, that operator can be chosen by the router.
 Note that a skill can be set to be required, or not. If skill is not required, the skills are used in ranking the choice.

* Default “Get Next Work” Functionality

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?” Calls find activity for worklist or workbasket
5. The Work-.findAssignmentinWorkbasket activity starts and uses the list view Assign-Workbasket.GetNextWork.ALL.
 “Merge Workbaskets?” checkbox and “use all workbasket assignments in user’s workgroup?” checkbox are evaluated and
list is compiled accordingly
6. Assign-.GetNextWorkCriteria Decision Tree is used to filter the most appropriate task
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 (Based on
GetNextWork_MoveAssignmentToWorklist system setting rule
9. No assignment is found from the workbaskets
33
CSSA Complete Study Guide for Pega 7 – January 2016

Repeat steps 5 to 8 but with the Work-.findAssignmentinWorklist activity and the standard list view Assign-Worklist.GetNextWork.All
* Decision Tree for “Get Next Work” Functionality
 If the task is ready to be worked on. This means that the pyActionTime property of the task is NOT in the future.
 If the current worker has already worked on or updated the task earlier that day.
 If the worker has the required skills to work on this task.

* Email Four Step Process

1. The recipients of the emails are 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 a single account 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 point to a special subset activities, called “Notification Activities”.
 “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 is through the Email wizard.
 In the wizard, change the drop down value to “Configure an email account“ (this account is being shared for a workpool)
 PRPC makes the Email Account rule name the same as the workpool name, and implicitly associates this account rule.
 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 (you may use different account
information for sending and receiving)

* Correspondence Creation and Configuration

 In the correspondence rule (process category) form dialog, specify the type of correspondence (Email, Fax, Mail & PhoneText)
 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.
 PRPC properties are marked using angle << >> brackets and these are replaced with the actual values at runtime.
 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 UI category.

* Add Correspondence to a Flow

 Assignments can utilize the rule, to send the correspondence when the case is being worked (typically automatic notifications)
 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:
o CorrNew, which is typically used when generating correspondence from a utility (used for the “Send Email” smart shape)
o CorrQuickStart, which is a simpler correspondence generation activity, with fewer options than CorrNew.

* Assignment shape notifications

 Note that, since notification is now set up in the notification tab, a mail icon appears on the assignment shape We can enter
one of the activity rules and enter the appropriate parameters. Activity rules:
o NotifyAssignee, sends a message to the assignee, or to the first contact in workbasket for workbasket assignments.
o NotifyAllAssignees is similar, but sends to all workbasket contacts.
o NotifyParty sends a message to designated work parties
o NotifyAll sends to all work parties
o “Notify” is a template for creating customized notification activities.

34
CSSA Complete Study Guide for Pega 7 – January 2016

 Some of these rules can optionally check for urgency, and only send email when the urgency is equal to or above this value.
* Ad-hoc Notifications
 The assignment or flow or stage or case can have the local flow action “SendCorrespondence”
 At runtime, from other actions menu, we can click the “Send Correspondence” and lets us send ad-hoc notifications.
 When we click on the link, we see the work parties drop down.
 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.

* Tickets
 In the flows for a case, we define when an event may be considered a “business exception” by raising a ticket
 A ticket rule only defines a name and description and not the processing to occur in the case of an exception
 We can use the Ticket landing page available by selecting the Pega button >Process and Rules > Work Management >, Tickets
in our current application to verify which ticket rules are in active use, and by which flows or activities.
 PRPC provides us with two distinct ways to raise a ticket.
o Provide users the option of selecting the Work-.SetTicket or @baseclass.SetTicket flow actions when processing
o By calling the standard activity @baseclass.SetTicket. This activity takes the ticket name as a param and turns it on/off

* Referencing a Ticket
 We do this by referencing the ticket defines the starting point of the processing that needs to occur once a ticket is raised
 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.
 Most shapes (except Start) provide a “Tickets” tab in properties panel (The shape has a ticket indicator with description)

* Key Standard Tickets

 Several standard tickets are available in PRPC. 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.
o “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.
o “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.
o 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.
o The “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.

* Benefits of Declarative Processing

 Declarative rules are not invoked from other rules. PRPC determines when to run them, making errors less likely.
 Keeping the rules independent makes it easy for us to separate business rules from the process which makes maintenance and
delegation easier.
 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 and applications are easier to change.
 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.

* Calling Declare Expressions

 Declare Expressions are configured in Forward Chaining Mode when we select the option Whenever inputs change.
 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.

35
CSSA Complete Study Guide for Pega 7 – January 2016

* Forward chaining
 Forward chaining is executed when the value of any of the source properties change.
 Most of the declarative rules follow forward chaining.
 Declare Expressions are configured in Forward Chaining Mode when we select the option Whenever inputs change.
 Constraints- when the value changes, the constraint is executed to verify that the value conforms to the conditions expressed.
 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 instances 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
page list properties to improve performance.

* Backward chaining
 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 if 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.

* 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.
 If the target property is of page list or page group then we need to identify the Page Context.
 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.

* Identify and Use Utility Functions

 Some complex declare expressions require using a Function rule.
 A function is a rule type in Pega that allows us to extend PRPC capabilities by using custom java code.
 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. We should be able to use these functions as such and we may need to write new ones on rare situations.
 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.

* Context-free and Context Sensitive Expressions

 Context Sensitive is set by selecting the first choice where the path defined by the page context + target property must be
complete from the top level page that derives from the Applies to class. Default option.
 Context free, which is set by choosing the “regardless of any pages it is contained in” option. 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.
 A hybrid is where we can explicitly list the classes for which it will behave like a context free expression. (reduces reusability)

36
CSSA Complete Study Guide for Pega 7 – January 2016

* Delegation of Rules
1. 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.
2. 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.
3. Improve readability and customization options to make it easier for users to make their updates.

* Setup of 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.
 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.
 The operator IDs should be configured to allow checkout/checkin of rules. This ensures user changes are not lost.

* Delegated Rules to the Business

 Decisioning rules (Decision Trees, Mapped Values and Decision Tables) 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.
 Once added, the delegated rules appear as part of the user portal for users to access.
o For users using designer studio, these rules can be seen in the Favorites Explorer.
o For users using case manager portal, these rules are accessible in the operator menu.

* Improving Readability
 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
2. Function Alias – Using a function alias vs function name and pick functions that accepts a fewer number of parameters
3. Customize Options to Reduce Errors – When delegating rules to business users restrict the choices users can select.
o The ability to change functions, call decision or take actions should be disabled.
o If there is a need to let users change functions, we should add the list of functions in the Functions Allowed field.
o If there is a need to let users change actions, use the Allowed Action Functions field to add the properties needed.
o Map Values offer two options for delegated users —change the matrix layout or use expressions in the cell.
o In the Decision table rule form the options are listed as Delegation Options. Only the highlighted flags impact how
users can make the changes on delegated rules.
 Allow to update row layout — When disabled, users cannot add new rows or delete any existing row.
 Allow to update column layout — When disabled, users cannot add or delete columns in the table
 Allowed to build expressions — This field enables the end user to use expressions as part of the cell in

* Decision Rules
 Decision rules represent the decisions and policies that drive business processes and case management.
 Decision rules can be invoked using a
o decision shape in the flow
o declare expression
o method in an activity step
 There are four types of decision rules that we can write to evaluate decisions:
o When – Boolean
o Decision trees – Nested If- Then- Else construct
o Decision tables – set of conditions using a tabular structure
o Map Value – determine a specific value based on one to two properties

37
CSSA Complete Study Guide for Pega 7 – January 2016

* When Rules
 When rules are used in:
o processes to decide which one of the two paths the case can take.
o other rules like UI
o data transforms
o other decisioning rules
o 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:
o Boolean expression or
o a function rule part of the library shipped in the product or
o a custom function defined as part of the application.
o 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
o can be constructed to have many branches which evaluate different properties to determine a decision
o use function rules or when rules for building the condition
o allow nesting – to invoke another decision tree or other decision rules such as a decision table or a map value
o usually return a value, the values can then be used in the calling rule such as the declare expression or the flow
o can also be configured to set a value to properties and this can be done using the Take Action option in the menu.
o can also be configured to check values on a specific property and decide its course of action (Evaluate is used)
o can also have restricted return values, in this case the decision tree can return either true or false.
o can also enter a property in the Allowed values property, uses the values as part of local list in property definition

* Decision Tables
 Decision Tables are useful in presenting the set of conditions using a tabular structure
 Decision Tables are suited to cases where we use a set of properties to arrive at a decision
 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 for each column to have values
 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
 Decision Table
o provide the option to evaluate all rows (not enabled by default and cannot use from a declare expression when on)
o can have a given cell can be “split” to represent add OR conditions
o can return values or enable the property set field to set properties directly
o using other icons we could return more than a single property based on the condition
o can restrict the results returned using a property or a set of values

* Map Values
 Map Value rules let us determine a specific value based on one to two properties
 Map Values are usually used in special circumstances where we the values of one to two factors decide the outcome
 Map Values allow you to have restricted return values

* Check for Consistency and Unit Test the Rules

 The Check for Consistency button verifies that there are not any unreachable paths and that there are no logic conflicts
(Decision Trees, Decision Tables AND Map Values) all have this.
 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.
38
CSSA Complete Study Guide for Pega 7 – January 2016

* 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.
 Constraint validation: declarative constraint rules - evaluated automatically each time a property identified in a rule changes

* Mode validation
 The Mode Validation enforces the property mode when a value is being assigned to a property

* Dictionary validation examines a property value in the context of the corresponding property rule
1. Type: value is compatible with its type
2. Maximum length: for 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.
3. Edit Validate: for properties of mode Single Value, Value List, or Value Group. Defines a Java routine that tests the validity of
an input value.
4. Control validation: Numbers must be entered for a number field, Date for date field, etc.
5. Table validations: for properties of mode Single Value, Value List, or Value Group. Table values can come for any one of those
in the list shown in Local List, Field Value, Class Key Value, Remote List, or Prompt list (selected in the table type dropdown).

* Dictionary tests are performed by the system when:

 User input entered on an HTML form is placed on the clipboard
 The Page-Validate method (in 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 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.

* Object Validation (optional validation)

 Object validation executes a validation rule to test a set of property values when explicitly designed into the application
 It 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 (can be configured or customized) invalidates the page, preventing it to be persisted.

* Constraint Validation
 Constraints rules use forward chaining to provide an automatic form of property validation when the property's value changes
 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 and is enforced as soon as it is saved
 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.

* Case level Validation

 In the Details tab of the Case Designer, we can configure the validation rules to run when a case is instantiated and/or
whenever the case is saved in the database: “Upon Instantiation of a Case” and “Upon Save of Case”
 The advantage of having the validation at case level is, whenever we need to validate certain data for every saving of the case
instances, we can configure it in the case designer once instead of needing to call the validate rule in multiple flow actions.
 Case level Valuation can be specialized by putting the rules in the work class of the work pool or a specific case.

* Best Practices
 Use validate rules over edit validate rules, because:
o Validate rules are easier for non-programmers to design and understand. Edit validate rules require Java skills
o Validate rules are more connected with the process and the UI, because flow actions and case designer can call them
o Validate rules simplify application design, because one validate rule can verify multiple input values at once
 Constraints validation automatically happens when a property changes its value. If we want the automatic validation at the
property level, then we use constraints validation. But this might have a performance impact, so we need to use it properly.
* Client Side and Server Side Validation:
39
CSSA Complete Study Guide for Pega 7 – January 2016

 Constraints, Edit Validate, and Validate rules are server-side validation –validation occurs on the server and the result is sent
back to the client.
 All other validations rules are client-side validations. The “Enable client side validation” flag should be checked in the
“Advanced” tab of the harness or in the “HTML” tab of the flow action rules, for client-side validations to work. The harness
rule enables the option for the whole flow. If the harness is not enabled, the flow action rule can be used to override for a
specific action.

* Report Browser
 The Ad-hoc Reports are accessible in a Report Browser
 The report browser is part of the default Case Manager portal
 While designing end user portals, it is a best practice to customize how the reports are presented
 PRPC ships with a wide variety of standard reports, so it’s essential to decide which of these reports are necessary for users

* Report Categories
 There are two types of categories – Private and Public
 Private Categories are specific to an operator, so the reports in that category can be accessed only by that operator
 Public Categories include all standard and shared reports.

* Public Reports (Standard and Shared)

 Standard reports—PRPC reports that are shipped with the product and categories created by developers. When a developer
creates a category, it’s accessible for all users who can view the report browser.
 Shared reports – Non-Developer (manager) creates a new category, PRPC saves it as a shared category and only users
belonging to the same access group can access the reports in it.

* Category Rule
 The Category is saved as a rule but when we open the rule we can see that it only has a short description.
 The Category rule does not indicate the category type—Public (Shared or Standard) or Private (Personal).

* Shortcuts—a shortcut is a link that displays the report title in the report browser
 When we click on a category, we see all the shortcuts that are defined in that category.
 Shortcuts serve two purposes—
1. Providing the ability to run a report in the report browser
2. Creating links to a report definition rule in a different category
 The shortcut rule has three parts:
o Category it belongs to
o Category type (private or public)
o Operator
 The shortcut is displayed as a link and when we click, it, we see the report results in the Report Viewer

* Report Viewer
 The Report Viewer also allows us to manipulate the results
 There is a toolbar on the top with options to export the results to a pdf or excel or to a printer
 The Filter criteria can be edited by clicking on the link and modifying the condition
 In addition to this, the report viewer supports a wider choice of command menus which can be accessed by right-clicking on a
column header.

* Report Definition Rule

 We can control what users can do in the report viewer by configuring them in the actual report definition rule. This allows us
to configure these actions to be specific for each report instead of using the same for all reports the managers are using.
 We can also restrict the report from appearing in the report browser if the report is not to be used as an ad-hoc report.
 The report definition rule form is accessible only to developers
 Query and Chart can be configured either with the report definition, report editor or the report viewer
* Report Editor (drag and drop user friendly tool)
 Enables us to build using a visual interface rather than using the report definition rule form

40
CSSA Complete Study Guide for Pega 7 – January 2016

 The Report Editor provides more options than the Report Viewer—we can add new columns for filtering, add new columns to
the report, delete the columns that are currently in the report, and so on
 The Report Editor is also available for developers in addition to them being able to work on the report definition rule form
 In most cases, we can build the report with all the features without ever opening the report definition rule form
 After making changes, use the save link (at the top of the Report Editor) to save the rule

* Creating New Reports

 If a manager wishes to restrict reports to their own group of users, then the manager should create a new category
 The categories must be created manually before we begin creating reports
 After creating the category, we can create a report and select which category it belongs to
 When creating a new report, we need to select the following:
1. Type of report (list or summary) and
2. The data that we want to run the report against – it can be one of the case types or, if we need to run it against all the
case types, then we select the work pool. We can also report on assignments to track the case processing.

* Saving New Reports

 Clicking OK opens up the report in Report Editor for the manager to complete it. The system actually creates a report before
the manager makes any changes. To do this, it uses a template rule named pyDefaultReport. We can modify the template rule
to include additional columns or new filter criteria.
 When a manager creates a report, it must be saved in the private category
 The system also creates a shortcut rule which provides access to the report definition rule
 After defining the report, the manager can keep it private until he finishes completing it. To share it with other users, they
should use the “Take action on report” icon to access this menu.
 The manager then has to select the category where they want the report to be saved. After saved, the manager can delete his
private copy and shortcut.

* Report Scheduling and Subscription

 PRPC’ has a report subscription feature that prints report results as a PDF and sends them via email automatically
 To configure this, use the Take action on report menu to schedule a report
 Once we click Schedule, it provides options for us to configure to schedule the report
 We can select if it has to be scheduled once or if it can be a recurring task that occurs after a specific time period
 We can also configure the format of the report results and the email message which is sent automatically to a set of users

* Production RuleSets
 When applications require business users to make modifications, we need to make sure that the report definition rule allows
modifications even in a production environment
 To implement this functionality, we need to define a RuleSet and then add it as a production RuleSet in the application
 Production RuleSets remain unlocked in production so that the rules belonging to that RuleSet can be modified by users
 We need to ensure that we are allowing this for a specific group of people and not to everyone
 Often, developers create reports in a private ruleset – such as a branch or a personal ruleset – so that they can test their
reports before making them available to all users. By branching the production ruleset, we can also allow business users to
create and configure reports in a private environment without disrupting the production environment.

* Report Viewer Tab of Report Definition Rule form

 In the Report Viewer tab we decide which options we want to make available to the business users in the report viewer.
 One way to limit the number of results that the user can see at a time is to use Pagination. Pagination can be added by just
enabling a flag (Enable paging) in the User Actions area.
 The Paging options allow us to customize the pagination features such as the Page size (number of rows per page) and Page
mode (the pagination format). When paging is configured, the system retrieves only the rows that are required in the current
page and it retrieves the results for the next page only when that page is accessed. Paging in addition to filtering helps to limit
the number of records that we query from the database.
* Data Access Tab of Report Definition Rule form
 PRPC allows setting threshold values on cases when paging cannot be enabled
 In such cases, these threshold values help to limit the number of rows accessed by the system
 We can limit the maximum number of rows that it can retrieved, by default its set to 500
41
CSSA Complete Study Guide for Pega 7 – January 2016

 We can also set the maximum elapsed time in seconds, by default its set to 30 seconds
 The system stops at the time limit and displays a message indicating that the report is taking a long time to run
 If the application is configured to export the results, we can set thresholds for the reports

* Setting Up Smart Info and Other Sections

 Reports can use section rules to present additional content
 A custom section can be set up for filtering. When we define filters for a report, PRPC automatically opens the section in a new
dialog. However we can override that by using a custom section. We typically use a custom filter section when we want to give
business user some help in selecting a filter value or customizing the filters.
 A custom section can be set up for smart Info. Reports display data in a grid structure – rows and columns, each record
displays as a row and the columns provide values of other fields specific to that row.
 The feature that we use to configure this behavior is called Smart Info. First we select the Enable Smart Info flag in the Report
Viewer tab and then click the options next to Enable Smart Info.
 To display the information that is specific to our application, we can create a section rule named SmartInfo in our application.
 In addition, we can also change the appearance of the report header by configuring the corresponding section

* Creating and Configuring Sub Reports

 A report can be added as a sub report to another report
 The sub report results are available in main report where it is linked
 We typically use sub reports when we want to filter a list based on data stored in another class
 In short, sub reports are PRPC’s way of handling the “IN”, HAVING” and “WITH” clauses
 Another popular way of using sub reports is to display aggregate calculations

* Creating Sub Reports

 We create sub reports the same way we create any other report - we create a report, add the columns that we are interested
in, add any filter conditions and save it
 When sub reports are used to filter the results in the main report, we do not need to make any changes in the dialog, but we
may need to use the alias mentioned in the sub report dialog in the filter condition.
 However when fields in sub reports are presented in the main report such as in the aggregation example, we need to enable
the Columns to Include field and then configure the join condition, filter criteria and what rows to include

* Using an Alternate Reporting Database

 Running reports on live data may cause performance issues, impacting both the users working with cases, and running reports
 To avoid potential performance issues of this nature, reports can be run against a copy of the database, referred to as a mirror.

* SQL Functions
 SQL functions are helpful in addressing this data manipulation. SQL functions are applied at the database level, so the function
is passed directly in the query that is executed against the table.
 PRPC comes with a lot of standard SQL functions that we can use without making any changes.
 They can be implemented in reports created either in the Designer Studio, or the Manager Portals
 ALL SQL functions MUST have an applies-to class of Embed-UserFunction and are instances of the “Function Alias” rule type.

* Using SQL Functions

 A Function Alias if created properly can provide the proper instructions so that managers can add them in reports.
 To write a new function, access the list of all SQL functions using the landing page. The landing page has a new button to
create a new SQL function. The Function Alias rule form has three main parts:
o Input Parameters — Identifies the field that has to be converted
o Presentation section – Identifies the type of function (text), and also the data it returns.
o The Source –code for implementing the logic. Circumstancing to create function alias rules for different databases.
* Data Storage in PRPC
 Though classes are mainly used for applicability of rules and play a key role in inheritance, they are also useful in deciding
where the data is persisted.
 If the PRPC classes can have instances, then they are mapped to a database table. When the class is mapped to a table, the
instances of that class are saved as individual rows in the mapped database table.

42
CSSA Complete Study Guide for Pega 7 – January 2016

 When a class is used as a work pool (class group), any instances of that class or any class defined as belonging to the class
group are saved in the same database table.

* DB Name and Table (PRPC records for managing the database mapping)
 DB Name record defines the database configuration details and can be configured to use either JNDI or JDBC url for the
database connection details.
 DB Table record- which defines the class name, the database table name and the DB Table record.

* Case Based Reports

 When a case is created, it uses a variety of properties - a list of all standard properties to save the date of creation, the name of
the user who created the case, the status of the case, the list of all interested parties for that case and so on.
 In general, PRPC uses a specialized table structure which uses a BLOB column to save all of these properties.
 Using a BLOB column provides us with the flexibility to design the data model without any restrictions.
 So in addition to being stored as part of the BLOB these properties are also saved as columns in the database table.

* Properties for how much time (seconds) was spent at each status
 pyElapsedStatusNew
 pyElapsedStatusOpen
 pyElapsedStatusPending

* Properties for Sub Cases

 pzInsKey – this is the internal identifier used by PRPC for each case.
 pxCoverInsKey (this is the property used to identify the parent case)
 The Covered SubCase Count, (pxCoveredCount)
 The Covered Open SubCase Count,(pxCoveredCountOpen)
 The Covered Subcase Actual Effort Total, and (pySubTasksEffortActual)
 The Covered Subcase Estimated Effort Total.(pySubTasksEffortEstimate)

*Performance Reports
 If pyPerformTaskTime is significantly lower than pxTaskElapsedTime then the assignment has been idle for a long time.
 Using these properties in a report we could find out how each operator is performing.

* Defining Relationships between Tables

 We can configure the Join directly in the report definition rule form in the data access tab or
 We can create an association rule which defines the Join, and then reference the association rule wherever it’s required

* Class Join
 Class Join is configured in the report definition rule form
 To configure a class join we define a prefix to join two classes
 PRPC allows both Inner and Outer Joins - Inner Joins return records that are in both tables while Outer Joins return all the
matched records from one table and all the records(including unmatched) from another table
 Select only include matching rows is an option to configure the Inner Join
 After defining the prefix, we need to define the condition
 To display any property belonging to the class we need to use the prefix that we defined earlier while the properties belonging
to that class can be referenced without any prefix

* Association:
 We can also use associations to join multiple classes.
 PRPC comes with standard associations to connect commonly used classes like Assignment- Case and Case – History tables.
 In the report definition rule, we can access the association by entering some part of the text of the association such as
Assignment which gives us access to the properties in the class. The association gets automatically referenced in the data
access tab once we add a column. If we need to associate other tables, define the association rule and then reference it

43
CSSA Complete Study Guide for Pega 7 – January 2016

* Optimization of Properties
 PRPC allows optimization of properties for all the standard properties such as work status, creation date and time, and
creation operator, which are exposed by the product.
 We can add unoptimized properties to appear as columns in a report definition or in filter criteria (system displays a warning)
 PRPC by default restricts adding the unoptimized properties in the Report Editor because it impacts the application
performance. But, we can enable a flag in the report definition so that the unoptimized properties can also be added to the
Report Editor.
 If a page list needs to be in a report, it must be optimized
 To improve the performance of a report, properties should be optimized as much as possible

* Optimization Wizard for non-list

 When optimizing a single level or a page property the Optimization wizard does the following:
1. Tags the Required property flag in the property rule form to indicate it’s optimized.
2. Creates a new column in the same table.
3. Runs a query that takes all the values from existing cases and populates this column.

* Optimization Wizard for list

 When we use a page list, we cannot create a column since we are not sure how many rows we are going to need. To do this
PRPC creates an indexed table. When optimizing a page list, the property wizard creates the following:
1. A declarative index class
2. A set of all indexed properties in the declarative index class
3. A declarative index rule that maps the properties in the declarative index class to the corresponding properties in the
main class
4. A database table that corresponds to the declarative index class
5. Database columns for all of the indexed properties in this table
6. A query to populate this table with data taken from existing cases

* Data Visualization
 Only summary-type reports can include charts.
 A summary-type report has at least one column with a numeric aggregate value, such as count, total, or average and at least
one unaggregated group-by column such as status, day/month when the items were created or as in this case work type.

* Work with charts in reports

 By default the Report Editor shows simulated data to speed up rendering time to allow us to concentrate on the look of the
report and its chart. Click Actual Data to switch off simulation and view actual report data.
 Click Edit Chart to open the Chart Editor for the report. The Chart Editor allows us to create and edit charts for summary-type
reports. We can choose from 12 chart types, most with several sub types.
 Charts can be drilled into another report that displays a chart or a map report

* Types of charts in reports

 Combo charts let us combine a column chart and a line chart in a single display.
 Area displays data values as lines with the area between them and the X-axis shown as colored regions.
 Funnel to displays values for an ordered set of steps or stages in a process. First step representing the largest part of funnel
 Pyramid is like a funnel chart, but with the step or stage with the largest value shown at the bottom.
 Bubble shows three sets of numeric column (X & Y axes represent two values and diameter of bubbles represents the third)
 Spark columns and spark lines are micro charts, typically displaying trend information that we can embed within a layout cell
 Gauges can be very effective in displaying burn rate, throughput and other measurements of the current state
* Conditional colors for charts
 Conditional Colors allow us to define colors that are conditionally applied to chart elements
 The condition can be based on either numeric values or Group By column values displayed on the chart.
 We can use Threshold Colors to define colored lines or regions to display on the chart grid

* Configure a map
 Pega 7 includes hundreds of maps that we can use to illustrate the data in a Report Definition
 Map charts can’t be defined in the Report Editor. They must be defined using the Charts tab on the Report Definition
44
CSSA Complete Study Guide for Pega 7 – January 2016

 By default the name of the country is used for the property value. If a country code is used instead it can be mapped
 Configure the drill down map on the Report Viewer tab

* Services and Connectors

 If our application needs to respond to requests from external applications the integration is known as a service.
 If our application needs to initiate the request by making a connection to an external service, the integration is known
as a connector.
 A range of industry-standard protocols are supported.

* Integration Wizards
 The development of most integration is supported by wizards, which guides us through creating connectors and
services and dramatically accelerates development
 The connector wizards use metadata, such as a WSDL file, EJB class, or a data table definition to create the connector
and mapping rules
 Classes and properties used for mapping the request and response data are typically created as well
 The service wizard creates service and deployment records as well as listeners if they are required for the service

* Invoke a Connector
 A connector is invoked either from a data page or an activity. If you call a connector from a flow you can use the
Integrator shape to reference the activity.
 Data page – to fetch data from the service
 Activity – to push data to the service

* Connect Rule Processing Model

1) Data Page / Activity
2) Data Transform (from application to integration clipboard structure)
3) Connect rule
4) Mapping rule (from integration clipboard structure to format specified by the target service)
5) Mapping rule (from format received by the service to integration clipboard structure)
6) Data Transform (from integration to application clipboard structure)

* Diagram the Service Processing Model

1) Service Package
2) Service Rule
3) Mapping rule (from format received by the service to Clipboard structure)
4) Service Activity
5) Mapping rule (from Clipboard structure to format specified by service type)

* Configure Resource Settings

 When we migrate an application, references to the external systems, such as endpoint URLs and JNDI servers might change
 To avoid having to unlock and update rules, the Global Resource Settings feature is often implemented

* Service Package
 The service package is data, not a rule
 It specifies the access group for locating the service rule, plus provides “service requestor” authentication, pooling and
deployment options
* Service Rule
 The service rule is the first step toward exposing our service activity as a service
 It specifies the service activity, defines the external API of our service (the ‘signature’ that external applications use to
communicate with this service), and specifies the data mapping for the request and response

* Service Activity
 The service activity is the primary activity that is executed by the service
 It contains the ‘business logic’ with the request as input and creates the Clipboard structure that represents the
response
45
CSSA Complete Study Guide for Pega 7 – January 2016

* Service Listener
 The job of the service listener is to sense when a request has arrived
 In many Integration Types, this functionality is provided by the underlying Web or Application Server
 In those Types where this is not provided, PRPC provides Listener data classes that allow us to specify the details about
listener initialization
 The data instances should be associated with our application’s ruleset since it is our application that provides the service.
There are no special considerations with regards to the enterprise class structure when creating a service.
 Note that it is a best practice to use authentication.

* Types of Error Handling in Connectors

 There are two basic types of errors that can occur when integrating through a connector:
1. Transient - typically don’t last very long and correct themselves over time. (remote host is temporarily unavailable)
2. Permanent - typically due to a configuration error or an error in the remote application logic

* Detecting Errors in Connectors

 Depending on how the connector is invoked there are different mechanisms for determining if there has been an error.
Each of these mechanisms is described below.
1. If the connector is invoked from a data page we can use the Post Load Processing Activity to check for and handle
errors.
2. If an error occurs while loading the data page a message is added. Check for messages in the Post Loading
Processing Activity and handle the error.
3. If the connector is invoked from an activity, use the Transition Step Status to check if the connector failed and if
so handle the error.

* ConnectionProblem Flow
 After the connector is invoked it is also possible to use the Error Handling Flow feature available for most connectors.
 The standard connector error handler flow can help recover from transient errors
 If the exception is a resource unavailable exception, the case is automatically assigned to a workbasket named
IncompleteConnections.
 The RetryConnection Service Level Agreement (SLA) goes into effect. It tries the connector again from the original flow
for a maximum of five times: one at goal event, one at the deadline event and then three times at passed deadline.

* Simulate a Connector
 Connector simulations are very useful in situations where the data source is not available or when one wants to dictate
the response returned. Connector simulators are NOT appropriate if the interface has not yet been defined.
 Connector simulations can be temporarily enabled and disabled from the landing page using the Enable/Disable
Simulations button.
 It is also possible to permanently disable all active simulators in one easy step using the Clear Simulations button.
 Note that SQL connectors cannot be simulated and that there are no connector simulations available out-of-the-box.
 Simulation activities can be defined on a global (all users) or user session level. (user session simulation overrides the
global simulation if there is more than one simulation for the connector)
 If we’re using our connector with a data page we have the option to simulate the data source instead of the connector

* Running a simulation
 It is worth considering placing the connector simulation activities in a separate RuleSet, (not moved to the production)
 The step page in the connector simulation activity is the service page of the connector it simulates so it is easy to set
response properties. Note that the properties are set directly on the service page and the stream and parse rules that
some connector types have defined on the service page are not used in simulation mode.
 We can use pre-conditions to return different responses based on things such as values in the request.

* Error Handling in Services

 It is a best practice to configure clipboard property values to communicate service errors to the calling application.
 Many service types have an exceptions or faults tab. Service SOAP, for example, provides a Faults tab.
 Other service types allow a service error condition to be defined on the Response tab.
46
CSSA Complete Study Guide for Pega 7 – January 2016

 When the service encounters a processing error and a condition evaluates to true an error message as defined is returned
to the calling application. The following options are available for defining an error response message.
o When – Specified When rule returns true.
o Queue When – If the specified When rule returns true the request is queued and a PRPC specific SOAP fault that
includes the queue ID of the request is returned.
o Mapping Error – Error occurs while mapping incoming data from the request message to the clipboard.
o Security Error – Authentication fails.
o Service Error – Valid instance of the service activity cannot be found.
 If the mapping, security, and service errors are not defined the system returns standard exceptions.

* Tracer Debug Connectors and Services

 We can use the Tracer to capture session information about the connector’s actions from the moment the session
starts. The Tracer can monitor any active requestor session.
 When using it for a connector, we start it for our requestor session before running the connector activity.
 A Service runs in a new requestor session and the processing is usually so quick that it can be hard to catch the event to
trace it. Therefore, the Trace option available in the Run menu is more convenient to trace service rules
 In the Tracer, we can use the following options when tracing services.
o The services option adds steps when the service invocation begins and ends. Nested within those steps are entries
that show when the inbound and outbound data mapping begins and ends.
o The parse rules option adds steps when the parse rules begin and end their processing.
o The stream rules option indicates when HTML and XML stream rules begin and end their processing.

* Clipboard Debug Connectors and Services

 We can use the Clipboard tool to examine property values and messages associated with them.
 For connectors, you can create or select a work item, move it through the flow and examine the Clipboard before the
connector is invoked and after it obtains a response.
 The session data of a service requestor is also accessible on the Clipboard. To see the Clipboard of a service rule, we
must invoke the service using the Run option.

* Log File
 A message is written to the Alert Log file for services and connectors when some processing events exceed their threshold.
 During a service execution, the following operations can contribute to a long transaction time:
o Inbound data mapping
o Outbound data mapping
o Data parsing
o Service activity execution

* More on Logging
 If one of those time thresholds is exceeded, a PEGA0011 alert message is reported in the alert log.
 PEGA0020 alert message is reported when a connector call to an external system has exceeded an elapsed time
threshold.
 Beside the Alert Log, we have the Pega Log in which system errors, exceptions, debug statements are gathered. While testing
our integration interactions, we can increase log level settings, add more loggers and then examine the results in the log file.
* SOAP Class and Ruleset for Reuse
 The setting we use for the reuse layer determines the base class and ruleset in which the connector rules created.
Reuse Layer Baseclass RuleSet Option Connector RuleSet RuleSet
Prerequisite
Implementation Org-App-IntSupplier New SupplierIntegration AppInt
Reuse Layer AppInt OrgInt
Organization Org-Int-Supplier New SupplierIntegration OrgInt
Reuse Layer OrgInt Base Pega RuleSet
Global Int-Supplier N/A SupplierIntegration OrgInt has
SupplierIntegration as a
prerequisite

47
CSSA Complete Study Guide for Pega 7 – January 2016

* Handle WSDL Changes

 If we need to make changes to the WSDL once it has been created, we can re-run the wizard.
 The wizard then creates a new RuleSet version of the integration RuleSet and creates new and updated rules in that
RuleSet version.

* Records Generated from SOAP WSDL

 The SOAP connector wizard creates the following rules.
o Classes and properties representing the request and response data
o Connect SOAP rule
o XML Stream and Parse XML rules for request and response mapping
o In addition to the above rules, an Authentication Profile record is created if we configured it in the wizard.

* Creating a SOAP rule

 A service always requires an activity, which provides the logic for the service. The service purpose defines the activity. There
are three options:
o Create and manage work
o Invoke existing activity rule
o Process input and output data

* Connect SOAP rule (Service Tab)

 The Service Endpoint URL (shown in the Connection section). The Global Resource Settings feature allows us to specify
the endpoint URL with a system variable.
 The wizard defaults the response timeout to 120,000 milliseconds. This means that a connection attempt will wait up to
2 minutes before timing out with a failure message. Typically we are going to want to adjust this to a much lower value,
depending on the SLA of the service. In particular, if this service is invoked as part of a user’s interactive session, this
value should be reduced to a few seconds.
 The error handling properties hold status and exception information returned by the connector and the processing options are
advanced settings that allow us to setup the connector to operate asynchronously.

* Connect SOAP rule (Request Tab)

 Entries in the request headers specify any data that needs to be included in the SOAP envelope header.
 Entries in the request parameters specify the data that will be mapped into the body of the SOAP request message.

* Connect SOAP rule (Response Tab)

 We use the target property if we want to store the entire original SOAP response with the case (useful for auditing)
 Response header entries are used to map the incoming SOAP envelope header
 The response parameters allow us to specify how to map the data from the body of the reply message to Clipboard properties

* Connect SOAP rule (Faults Tab)

 A SOAP fault is an error in a SOAP communication resulting from an incorrect message format, headerprocessing
problems, or incompatibility between applications.
 When a SOAP fault occurs, a special message is generated that contains data indicating where the error originated and
what caused it.
 The properties on the faults tab allows us to map the faults details returned and handle the error appropriately.

* Connect SOAP rule (Advanced Tab)

 The client properties allow us to specify settings for the Axis client
 If the connector requires security we can configure it on the Advanced tab
 Compensating actions are intended for use when the connector succeeds, but a subsequent step in the process
determines that the action of the connector should be reversed. Typically the compensating action sends a message to
48
CSSA Complete Study Guide for Pega 7 – January 2016

the external system by executing another connector that un-does the action of the original connector. Compensating
actions are not intended to help recover from system failures.

* XML Stream Rule

 The XML stream rule maps data from the Clipboard to the SOAP request
 In the mapping tab, we map the supplier to the update supplier service request as we can see in the tree structure
 In the XML tab, we define how the properties will be mapped into the XML message structure

* XML Parse Rule

 The XML parse rule maps the response to the Clipboard

* Deploying SOAP Services

 Provide the ‘client application developers’ with authentication credentials to be used when invoking the Service – such as
UserIdentifier and Password
 Ensure that the Access Group listed in the Service Package has access to your service rules
 Ensure that all of the RuleSets involved in the service are locked
 Ensure that all of the rules involved in the Service are checked in

* Test the SOAP Service

 We can use the Run in the Actions menu on the service rule to test our service. Select Run allows us to enter input params.
 (1) Use the Current Requestor Context – testing your Service Activity and Mapping rules
 (2) Use “initialize service requester context” to test authentication
 (3) Invoke the Service from an external application

* Trigger a Service
 Each service that we configure requires a trigger. This trigger invokes the service, to process the inbound request.
 For a basic SOAP service, the server reacts to the incoming request automatically, performing the actions outlined by
the service. In other cases, however, we not only need to configure the service, but also need to configure the
triggering mechanism, known as a listener.

* Listeners
 Listeners allow us to configure services that respond to emails or file uploads
 The listener operates in the background, watching a specific location – such as an email address or folder on the server
 When the listener observes activity– the system triggers the appropriate service to process the inbound request. The
service then writes data to the corresponding case or data record and can return some of the case data to originator.

* A file service typically consists of the following components:

1) Service Activity, which is the primary activity that is executed by the service.
2) Parsing Rule, which parses the file content and creates the service clipboard page which is used in the service activity.
3) Service Package, which specifies the access group as well as authentication and requestor options.
4) Service File, which specifies the parsing rule and service activity.
5) A File Listener which encapsulates details about listener initialization and processing options.
* Parse Delimited
 The service file rules support three types of parse rules:
o Parse XML rules which are used for XML files.
o Parse Delimited rules which are used when a comma, tab, quote, or other character separates fields within each input
record.
o Parse Structured rules which are used to import fixed-format flat files

* There are three options for the processing method:

 File at a time parses the entire file.
 Record at a time parses a record at a time. Use the Record Terminator or Record Length fields to identify the record.
 By record type extracts a record type from the record. Use the Offset and Length fields to identify the record type and
the Record Terminator or Record Length to identify the record.

49
CSSA Complete Study Guide for Pega 7 – January 2016

* Parse Segments
How the information configured in the Parse Segments is used depends on the processing method specified in the Methods tab.
 The Record Type is used to identify which parse segment to apply to a record parsed from the file. This option is only
relevant if the processing method on the method tab is record type.
 Select Once to apply the parse segment only once. This option is useful for files that contain a header record.
 The Map To field defines the action to take in the parse step. The following options are available:
Clipboard – Map this segment to a Clipboard property
XML ParseRule – Parse the segment with a parse XML rule
Delimited ParseRule – Parse the segment with a parse delimited rule
Structured ParseRule – Parse the segment with a parse structured rule
Skip – Skip this segment

* The Frequency field

 The Frequency field allows us to specify a number of records to process before committing database changes
 When this field is not blank, a final commit operation also occurs after all records are processed
 If this field is blank, no automatic commit operations are performed

* Success Criteria
 Use the Success Criteria to specify a when rule to be evaluated after each record is processed. If this rule evaluates to
false a database rollback occurs backing out of the most recent commit operation and the processing of the file is
abandoned.

* File Listener Scope

 The Startup Option allows us to control how listeners start:
o Run on all nodes – The listener is run on all nodes, in other words all servers in a cluster.
o Node based startup – The listener is started only on specified nodes.
o Host based startup – The listener is started on specified number of nodes on specific servers within the cluster.
 The Source Location and Source Name Mask are populated from the wizard. The listener creates three sub-directories within
the source directory:
 Work – Original files are copied to the Work directory for recovery attempts
 Completed – Files for which processing completed successfully are copied here
 Report – Report files are copied here

* Listener Errors
 Some errors are technical and related to the infrastructure and hence might be temporary. It might be worth trying to
attempt to recover from such errors. If we select Attempt recovery? the system leaves the files containing errors in the
Work folder for recovery purposes.
 Max Recovery Attempts defines the maximum number of times the system attempts recovery.
 In the Cleanup section we can define what we want to happen to the file when an error occurs. It can either be deleted
or renamed. If you choose to have it renamed the file extension is renamed to the specified value. The file name itself
remains the same.
* Register an External Database
 Each relational database we need to connect to must be defined as a Database instance
 When the Database instance has been created and a suitable JDBC library has been installed on the server we can
connect to and interact with that database. Database and Database Table instances can be found under the SysAdmin
category in the Record Explorer.
 There are three options we can use to connect:
o Use configuration in preferences
o Use JDBC Connection Pool
o Use JDBC URL

* Understand External Classes

 An external class is a concrete class that corresponds to a table in an external relational database, rather than to a table or
view in the PegaRULES database.

50
CSSA Complete Study Guide for Pega 7 – January 2016

 External classes do not contain the two properties pzInsKey and pxObjClass, which are present in every internal class. In some
cases, no single property in the external class can serve as a unique handler. In that case a substitute string is assembled from
the key columns of the table.

* Use the Obj-Methods

 Use the Obj-methods in an activity to open, save, and remove instances from the database. The Obj-methods can be used on
instances of all classes and are not limited to external classes.
 Use the Obj-Open or Obj-Open-By-Handle to load an instance

* Configure Connect SQL Rules

 The Connect SQL rule can be used to interact with an external database.

* Know when to use Obj-Methods vs Connect SQL

 If our application needs to perform simple SQL statements against a single external database table, it is a best practice to
configure access to the database table as an external class. This can be done using the External Database Class Mapping tool.
 When such external access is configured for an external class the Obj-methods can be used to interact with that table through
the class. It is not necessary to create Connect SQL rules.
 We use Connect SQL rules if our application needs to run complex SQL statements such as joins or stored procedures to
update or extract information from an external database.
 The Obj-methods are included in Pega 7’s transaction handling while SQL statements in Connect SQL rules are committed as
they are executed.
 Connect SQL rules Implement a custom error handling.
 In certain situations it might be worth considering using a combination of Obj-methods and Connect SQL rules. For example,
when a complex search only supported by Connect SQL is needed but the rest of the operations can be covered by the Obj-
methods.

* Agents
 A facility to run internal background process operating on the server and performing some tasks on a periodic basis.
 The order in which the agents are listed does not create a processing sequence.
 Each agent activity runs individually on its own interval schedule, as a separate requestor thread
 Agents can
o execute tasks according to the rules defined in an application
o system tasks such as sending email notifications and outgoing correspondence or synchronizing caches across nodes in a
multi-node system

* Agent types
 Typically, an agent can either be task-driven or schedule-driven.
 Task-driven agents pick their work from a queue. The queue entries are generally created during the work item processing.
 Schedule-driven agents, however, do not use queue entries but rather directly run an activity to perform their tasks.

* Agent modes
 Legacy agent mode:
o only provides backward compatibility for agents being upgraded from versions prior to 5.4.
o No queue is involved in the legacy agents processing. They typically just wake up and run.
 The new agents can take either of the following modes: Standard or Advanced.
 Advanced mode:
o the agent activity is responsible for both transactional and business processing as in the Legacy mode.
o However, the agent may still use the agent queue functionality; it just must do so explicitly.
o So, when an advanced agent “wakes up,” it runs its activity directly, and that activity may either call the agent queue and
performs all the locking and other database operations, or just does processing without a queue.
 Standard mode:
o default mode setting for agents created in PRPC versions 5.4 and higher.
o The transactional processing is handled by PRPC itself and leverages the agent queue functionality.

51
CSSA Complete Study Guide for Pega 7 – January 2016

o Consequently, the agent activity contains only business logic.

* Understand the main characteristics of Standard agents

 There is one “Agent” rule per RuleSet
 The primary page of the activity or method will also be the primary page for the agent processing
 Make sure the object referenced by the primary page is saved and committed to the database with all the property values
 The queue entry holds a reference to the object and a reference also to the primary page

* Auto Queue Management

 The AQM can either be enabled or disabled on each agent
 AQM allows a Standard agent not to worry about transactional processing
 When enabled, any entry retrieved from that agent queue is locked while the entry is being processed until a commit or
rollback occurs at the end of the process.
 If a rollback occurs, AQM puts the queue entry into failure status and stores it into the “Broken-Process” Queue.
 When the AQM is disabled, the agent gets only one chance to process the entry as the entry is removed from the queue rather
than being locked. In the case of process failure, the queue entry is not kept anywhere for another possible attempt.
 As a best practice, always enable AQM for standard agents.
 The AQM is enabled through the agent rule form.

* Patterns for Agents:

 PRPC supports two patterns for the agents: Periodic and Recurring.
 When an agent is defined with the “Periodic” pattern, it runs its activity and “sleeps” for the number of seconds entered in the
“Interval” column which is the next field. By default, this value must be at least 5 seconds.
 The “Recurring” agent runs the activity based on a specific calendar schedule.

* Standard Agents
 As the Standard agent wakes up, we can indicate the maximum number of entries from the agent queue it will process before
it goes back to sleep. This number is specified in the “Max Records” field. The default value is 50 (can be 0 for unlimited).
 For each Agents rule, it generates as many agent schedule instances as there are nodes in our system.
 By default, the Agent Manager checks for new or updated Agents rule once every ten minutes.
 Standard Agents do not need access groups. Each queue entry is processed in the authorization context of the user whose
actions or processing generated the queue item.
 Agents are internal background processes and are authenticated differently than operators. If the agent's processing calls an
activity that has the “Require Authentication” option selected on its “Security” tab, Process Commander throws an error.
o To avoid this error, select this option to allow this agent to run activities that require authentication, even if the agent
is not authenticated.
 Standard agents queue entries are instances of System-Queue-DefaultEntry class and are typically persisted in the
pr_sys_queues database table.
 The System-Queue-DefaultEntry class is automatically used for all task-driven agents with no custom structures.
 When needed, you can create your own class, but it must directly or pattern inherit from the abstract class System-Queue-.
* Understand the processing of a Standard agent
 Agent Manager wakes up the Agent Thread, and creates a brand new requestor which it associates to the agent Thread.
 It then checks the agent’s queue for entries.
o If there are no entries in the queue for this agent, the agent goes back to sleep for the specified interval without
running the agent activity and then checks back.
 If one or more entries are found in the queue though, the system retrieves, locks and opens the first queue entry.
 The Authorization is checked.
 The System calls the “EstablishContext” activity to lock and load the related object referenced in the queue entry.
 The agent activity is called with the object as the primary page object.
 The system runs the agent activity for each item in the queue until it reaches its “max Records” count.
 For each entry, if the agent processing succeeds, then the Agent Manager commits all deferred operations to the database.
 If the agent processing however throws an exception on any operations, then the Agent Manager does a rollback of all entries
associated with that entry.
 Depending on the AQM setting, the entry is kept on the queue or removed from the queue.

52
CSSA Complete Study Guide for Pega 7 – January 2016

 When the agent is done processing the entries, it goes to sleep for its interval period.

* Be able to trace and troubleshoot a Standard agent

 If AQM is enabled and when there is an exception, the failed entry is moved to the Broken Queue.
 You can access the Broken Queue through the Process Commander System Management Application or also known as SMA.
 The “Requeue” button allows us to move the selected entry back into the “Scheduled” queue for it to be re-processed.
 We can also decide to identify the issue by tracing the agent but a special trace has to be set up to catch the activity.

* Access Group
 When Application Express creates an application – either in the framework layer or the implementation layer – it creates two
default roles and access groups: one of each for managers and users. We can create additional roles or access groups.
 An access group defines an application the operator can access – and its rulesets – and describes the capabilities allowed
 A user can switch between access groups by selecting a different application in the Application menu

* Roles
 Each access group also lists a series of roles
 A role lists a set of allowed capabilities
 Unlike the access groups listed on an operator ID, all of the roles listed on an access group are in effect at the same time
 The ability to divide capabilities into multiple roles improves reusability

* ARO
 Rule-Access-Role-Obj rule
 The ARO defines the capabilities that apply to that class and the instances of that class
 Each ARO can also include a set of privileges, which allows an application to permit or deny access to specific rules and tools

* Privileges
 Privileges can be added to many rule types, and can be checked programmatically by utility functions
 Privileges can also be conditionally granted by system level or through the use of Access When rules

* Access Manager
 To review the security model – the permissions provided – or denied – to a group of users, we can use the Access Manager
 The Work and Process tab lists the operations available to the selected access group for each case type, and allows control
over the actions available to a specific role defined for the access group. Each action can be set to either Full Access, No Access
(the worklist for each operator in that role contains only his or her own assignments), or Conditional Access.
 The Process Flows and Flow Actions sections indicate the flows and flow actions that an operator can access – and therefore
perform. By default, the Access Manager only lists the starting flow for the case type, and the flow actions referenced by that
flow, but we can configure permissions for flows and flow actions and any other rule type that allows permissions manually.
 The Tools tab configures access controls for Designer Studio features and capabilities, such as the Clipboard and Tracer.
 The Privileges tab lists all of the privileges configured for a specified role and case type or data type (summary of other 2 tabs)
* Conditional Access (Access When)
 Conditional access – the yellow circle – generally indicates the use of an access when rule to determine the circumstances in
which a role is to be granted access.
 When the yellow circle appears next to the case type, it means that more than one permission level is applied to the actions
listed for that case type.

* Workbasket
 We can control access to a workbasket by adding specific roles to a workbasket record.

* Attachments
 Access control for attachments can be configured on the attachment category rule form.
 The access control model for attachment category rules uses privilege rules and when rules (rather than access when rules) to
determine whether users can create, edit, view, or delete attachments from a case.
 Enable attachment-level security option allows an operator to identify one or more workgroups that can access the
attachment.

53
CSSA Complete Study Guide for Pega 7 – January 2016

* Control Run-Time Access to Individual Rules

 Pega’s access control model can be extended to individual rules as well. This allows an application developer to grant or deny
access to specific rules, such as flows, flow actions, and activities, and affects the actions that an operator may perform during
case processing.
 Access control for a flow, flow action, or activity is configured by adding a privilege to an access role, and applying that
privilege. This process involves three changes:
1. Create a privilege rule.
2. Add the privilege to the ARO.
3. Add the privilege to the controlled rule.

* Authentication Using LDAP

 Authentication is the process of verifying if a user has access to an application and is who they say they are. This is often
accomplished by verifying a user ID and password.
 LDAP is short for Lightweight Directory Access Protocol. (It is a directory service designed to represent large complex
organizations). It is extremely flexible but at its core it’s a list of records, usually representing people and their passwords.
 The process of authentication via LDAP and creating operator IDs is managed by the PRCustom authentication scheme.
 The PRCustom authentication scheme is used for both LDAP authentication and single-signon (SSO) approaches.

* LDAP Directory Structure

 LDAP server URL
 Bind Distinguished Name/Password (account to connect to LDAP with, not the account of the user being authentication)
 Directory Context (location in the directory to search)
 Search Filter (used to find the user)
 Test Account (test account’s attributes are used by the wizard in the data mapping step)
 Attributes
o uid – Email of user
o o – organization
o l – division
o ou – unit
o cn – user name

* LDAP Wizard
 The Authentication wizard creates an authentication service already configured to one of three predefined servlet definitions.
This eliminates the need for us to create a new servlet or modify web.xml.
o Sun (For anything but the WebSphere and Weblogic built in server - safe choice)/WebSphere/Weblogic
 Note that running the wizard doesn’t disable other authentication services or servlets. It is possible to have LDAP and PRBasic
 PRPC prevents users created via external authentication from logging in via PRBasic authentication.
 The data from LDAP takes precedence over the model operator.
* Activity Customizations
 Changing the messages shown to the user when authentication fails. Perhaps even localizing the messages.
 Another common customization is to add additional mapping logic to use decision rules to determine the proper model
operator or access group using a number of different LDAP attributes.
 Or to add logic that uses LDAP attributes to explicitly to deny access to certain users.

* Clipboard to Review Session Data

 Process Commander always associates a temporary memory area on the server to every requestor including browser-based
users and even unauthenticated guest users.
 The Clipboard tool provides a requestor a way to review and act upon the contents of the clipboard.
 The Clipboard is very useful for debugging - allows us to access the entire page structure for the system, one thread at a time.
 Typically, the clipboard tool is used:
o when developing and debugging to examine property values and messages associated with them
o to find the information necessary to reference a property, such as the page names and the property name

* PRThreads

54
CSSA Complete Study Guide for Pega 7 – January 2016

 The first thing to mention here is that clipboard pages are defined in a specific name space context or scope called a PRThread
 PRThreads are a data structure used to allow a single requestor to run multiple copies of a workflow simultaneously
 Properties of mode Java Object, Java Object List and Java Object Group are not shown on the clipboard.

* The clipboard tool arranges the top level pages into four categories.
 User Pages – this contains the top-level pages created by the requestor during normal processing
 Data Pages – this contains all the data pages instantiated in the system
 Linked Property Pages – this contains all the pages created by a linked property
 System Pages – this contains special, reserved pages the system relies on to function. Within this category, three pages are
always present.
o pxThread – this contains the information about the current PRThread
o pxRequestor – this contains the information about the requestor and HTTP protocol parameters
o pxProcess – this contains information about the server’s Java Virtual Machine and the operating system
 Additional pages that contain information on the access group, application rule, operator ID, organization, org division and org
unit may appear as required. Guest users do not have these pages as they’re part of the authentication for a named user.

* Clipboard Options
 Edit - allows us to update values on the page. This is useful to prepopulate data during testing.
 Refresh - gets the latest values from the system.
 Show XML - provides a raw XML view of the entire page. This is useful to see the entire page & properties that start with ‘pz’
 Execute Activity - allows us to run an activity using this page as its step page.

* Clipboard’s toolbar
 This toolbar provides us a search box to locate values on any clipboard page, a tools menu with the options Analyze and Collect
Details. These are advanced tools used to track approximate sizes of pages on the clipboard.

* Use the Tracer to Debug Applications

 The tracer is tool that is useful in identifying how the system behaves during processing. It allows us to:
o view exceptions
o look at SQL queries
o examine the properties of pages at each step

* Tracer Results
 The most recent event is at the top of the tracer.
 Most events in a tracer have both a Begin and an End.
 When tracing Data Transforms and Activities, we will also see a Step Begin and a Step End for each step in the data transform
or activity indicating the method being executed, providing a link to the step page of that step, identifying the status, & more
* Configuring Tracer for Performance
 Tracer by itself can greatly impact the system performance.
o Abbreviate Events – this option reduces the performance impact, but sacrifices keeping the clipboard detail. When this is
selected the step pages are not available and we cannot view the values associated with their properties.
o Expand Java Pages – this is only useful if the system contains any properties of mode Java Page. This option should be
turned off if such properties are not in use.
o Local Variables – this option provides the means to view the local variables which are not available from the parameter
page. This option should only be turned on when we specifically need to debug an issue with a local variable.

* Configuring Tracer
 The event types category provides additional, optional events that we can trace. We have the option to add additional event
types. Since the most common types are already provided, we should not need to use this capability except as directed by
your Lead System Architect.
 The rulesets to trace category allows us to eliminate some rulesets from the tracer output, to improve its performance. The
entire ruleset stack is available to us, but as a general rule we shouldn’t need to trace any of the Pega* rulesets. Our primary
concern with debugging is our rules, so by removing these rulesets we can potentially save thousands of lines of results.

55
CSSA Complete Study Guide for Pega 7 – January 2016

 The tracer only provides the step page and the parameter page by default for each event it traces. We have the option of
tracking additional named pages when necessary. This capability is very powerful, but comes at the cost to performance.
This option is not available if Abbreviate Events is selected.
 The last option is for the number of lines visible in the tracer window. By default the system displays 500 lines visible in the
tracer window. This can be increased (or decreased) as necessary.

* Using the Tracer Viewer

 Tracer viewer is an external standalone installation that can be installed in the local system.
 It is useful in interpreting the tracer’s output.
 Note that processing the file may take some time, depending on the number of events traced.

* UI Inspector
 The UI inspector is used to discover, view and edit the user interface elements in our application.
 The real power to the UI Inspector comes from running it in the user portal.
 To run the UI Inspector in a user portal, we need to launch the user’s portal from the launch button in the developer studio.
 After the user portal opens, there is a floating button that allows us to toggle the UI Inspector on or off.
 While the UI Inspector is active, as our mouse hovers over any user interface element, the selected element is highlighted in
red and an information panel is displayed about that element.
 The information panel displays the type, name and name of the immediate container of this element on the left panel. The
right panel displays the entire UI structure showing all the parent containers for this element.

* Access the system logs

 One important aspect of debugging is to keep an eye on the system logs.
 These logs track when exceptions and other events occur and provide valuable insight into their cause.
 At the end of development there should be no log entries being recorded so it is important to periodically monitor these logs.
 There are several logs available to us, but the important one for debugging is the one called “PEGA”.

* Remote Logging
 Via the System Management Application, we have the ability to perform remote logging.
 Remote logging establishes a connection between the server and a standalone application running on our desktop.
 A feature of the remote logger is that it is updated near real-time, without having to constantly download the log files.
 You can filter the events written to the Remote Logger

* Read Stack Traces

 When we’re dealing with log files, tracer files and other debugging tools we’re going to encounter a stack trace
 Stack traces provide us a look at all the processes we’ve stepped through on the way to the current exception
 The key here is to look for information that paints a picture of what was occurring when this exception occurred
* Performance Analyzer (PAL)
 This tool provides a view to all the performance statistics that PRPC captures
 To launch PAL, we can select the Performance option in toolbar in developer studio, open PAL on a landing page, or through
the System Management Application (SMA) (viewing the results through the SMA is only a current summary and does not
allow us to add incremental readings).

* Taking PAL Readings (Add reading has to be clicked to view the performance statistics for that reading)
 The first step to taking measurements is to click Reset Data. Since the system is constantly monitoring performance, by
clicking this button we’re eliminating any previously recorded entries from our results.
 Next, we need to take some readings. We have two options to add a reading, with or without the clipboard size. There is no
difference between the two readings other than the addition of the clipboard size, which takes a bit of extra time to calculate.
 Each reading added is shown as a delta. This is indicates it’s the change from a previous reading.
 There are many different results available to us for analyzing the performance. There’s no magic number when it comes to
these results. It is up to us to work with the LSA and the business to determine what is an acceptable result for each step of
the process.

* DB Trace
 The DB trace tool is useful in tuning the application if there are any database performance issues
56
CSSA Complete Study Guide for Pega 7 – January 2016

 DB Tracer must be run if PAL readings indicate performance issues in the Database operations
 DB tracer can trace all the SQL operations like queries or commits that are performed in PRPC
 Like the performance analyzer, the DB tracer is available from the performance button the developer studio toolbar, the
system management application and the performance landing pages.

* Configuring the Options

 To configure the DB Trace tool, click on the Trace Options button.
 This opens a window that lists all the possible events to trace. By default, all of them are selected. If an event does not apply
to a situation, it should be removed from the list to streamline the results.
 We also have the option to generate a stack trace. Generating the stack trace is an expensive process and should only be used
when required.

* Running DB Trace
 To run the tracer, we just need to click the green play button. After performing our steps, we can click the red stop button to
complete the trace
 After stopping the tool, the table is updated with the results for all the PRThreads it traced. We’ll want to identify the results
for the thread corresponding to process where we performed our work. When in doubt, look for the largest size. It is most
likely the one we want.
 The results are a tab delimited file so they can be opened using any spreadsheet program, such as Excel to then review the DB
Trace findings.

* Performance Profiler
 The third tool in our Performance landing pages, the Performance Profiler is like a hybrid between the tracer and PAL.
 We run the Performance Profiler by clicking on the green play icon, performing some actions and then clicking the red stop.
 Just like DB Trace, we want the record that matches the one where we did work. Again, this is most likely the largest one. The
difference here is when we open the file, unlike the DB Trace, the data associated with the profiler is stored as a simple CSV.
 The profiler can show us the CPU time and wall time across a series of transactions. It is useful when determining which part
of the process might be having performance issues, or identifying the particular step of a Data Transform that might have a
performance issue. Run in conjunction with PAL to narrow down both the specific step (profiler) and the cause (PAL).

* Pega Log Analyzer

 The Pega Log Analyzer, also known as PLA, is a standalone application that can combine and format the PRPC logs.
 Once PLA is launched, we need to upload the Pega, Alert and GC log files from the system. PLA will format these logs and
provide us a summary table separates out each day. We have the options to export a single day to Excel.
 The copy in Excel provides us with summaries for each of the alert, exception and garbage collections. Using these summaries
we can identify the critical events that cause poor performance and address them.
* Log Usage
 Unlike the PAL tool, which shows data for one requestor only, the Log-Usage reports shows overall system activity.
 Log Usage reports are normally accessed in SMA.
 Based on the number of interactions, the Log Usage shows various Performance Analyzer counts of system usage. This enables
the system administrator to see what activities are going on from a system level perspective.
 For example, if a user complains that the system is slow at 1 p.m., the system administrator can choose Start and Stop
parameters to highlight that time and see whether there was a sudden spike in the number of users, or in activities run by
existing users, or some other occurrence that might cause a system slowdown.

* Autonomic Event Services (AES)

 Autonomic Event Services, also known as AES, is a standalone application that can be used to monitor the performance status
of one or more PRPC instances running in an enterprise deployment.
 AES aggregates the most serious alerts and exceptions into work items for use in a work flow and assigns them for diagnosis
and resolution. Each work item can be transferred to a different operator, has SLA’s defined for the work item and provides
reports for tracking the work items.
 The AES Enterprise Health console provides the current status on key system functions indicating normal, warning, and
critical conditions for the following:
1. Number of active requestors
2. Number of agents running
57
CSSA Complete Study Guide for Pega 7 – January 2016

3. Percentage of JVM Memory being used

 PRPC sends data to AES through a series of SOAP calls. AES picks up this data and can perform various functions with it.
o Consolidates and summarizes all the Pega log files.
o Formats the alerts and errors.
o Produces a scorecard.
o Sends emails.
o Suggests recommended actions.
o Provides reports for performance patterns

* Guardrails
 The compliance score is a calculation of the total number of rules in the system with warnings, weighted by their severity and
justification state, as compared to the overall total number of rules. This score is based on all the rules available to this
application, except the properties and any rules in Pega provided rulesets.
 Both justified and unjustified rules affect this score. So the only way to ever get a full 100 is to have no rules with warnings.
 Among the rules that do have warnings, our best option is to fix the rule and remove the warning. Otherwise we should
provide a good justification why this rule requires breaking the guardrails.
 The last section of the landing page contains a view to how alerts have trended over the last four weeks. These can be helpful
in identifying the impact of correcting warnings and how the system is trending overall

* Guardrail Reports
 Summary - The summary report provides at a glance the state of the system
 All Warnings - The all warnings report provides the same information as the Summary report, but in tabular form
 Charts - Just like the other reports, the charts report provides the same information but you have a visual comparison
 Alternative Reports - The Application Inventory landing page contains another report to be used to identify rules w/ warnings
 Heat Map - the system displays the categories with warnings, shaded according to the percentage of warnings in that category

* Best Practices for Performance

Cleanup the Clipboard – for pages that are temporary ones used for interfaces, data mapping, and used to power controls on UI.
Minimize the Number of Rules – remove unnecessary rules in the system by increasing reuse
Minimize the Number of Ruleset Stacks – minimizing the number of ruleset stacks we help to keep the rule cache clean (every
unique ruleset stack receives its own copy of the rule cache – the personal ruleset should be disabled for every operator
Dedicate a Back-end Processing Node – one or more nodes in the cluster should be set aside for back end processing or if it is not
possible, then any back end processing should be delayed to run in the non-working hours if it is not required to be near real time
If We Don’t Use it, Turn it Off - eliminate any agents and listeners that are unused
Different Performance Needs for Development, QA and Production - best practices need to be applied to every environment
* Tune the Rule Cache
 The size of the rule cache directly relates to the amount of memory used on the system.
 Having too small of a cache results in the cache needing to prune itself.
 This results in poor performance as the system constantly needs to remove one cache entry for every new one it needs.

* Viewing the cache details

 Having pruned values indicates that the rule cache has been exceeded at some point. This doesn’t necessarily mean there is a
problem just that we need to do more investigations. This is especially true in development environments where there is a
high turnover in the number of rules instances.
 In order to determine if this is a one-time occurrence or an ongoing problem, we will need to clear the cache by clicking the
‘Clear Cache’ button and then thoroughly run the system. A good time to do this test is during load testing as the load test will
ensure the system has been thoroughly executed.
 Once the system has been fully run, with multiple scenarios representing the current business case, we can review this report
a second time and validate if instances are still being pruned.
 If there are still instances being pruned, our next task is to see if we can reduce the overall rules in the system. This should be
done and the process of clearing the cache should also be done. Then we should re-run the system in order to evaluate if the
rule cache still needs to be tuned.
 If all of these actions have taken place and we still are encountering pruned records, it may be necessary to increase the cache.
Increasing the cache has its own impact on performance by increasing the system’s possible memory footprint, which is why
this approach should only be taken once all other possible solutions to reduce the number of rules have been exhausted.
58
CSSA Complete Study Guide for Pega 7 – January 2016

* Setup the Purge and Archive Agent

 One of the important tasks for maintenance is to ensure we archive old work objects out of the system.
 Most businesses only need to keep old work around for anywhere between one to seven years.
 By cleaning out the old work objects that exceed this limit, we can keep the work tables lean and improve performance.

* Configuring the Purge and Archive wizard

 PRPC provides an easy to setup wizard for establishing an archival strategy called the Purge and Archive wizard.
 The first step of the wizard requests for the work pool that we want archived. Remember that work tables are mapped to
work pool entries.
 The next screen allows us to specify specific classes within that work pool. In most cases, we’ll want to select all the classes of
the work pool. Rarely do we require archiving the classes at different intervals.
 On the third step, we specify how many days old an object needs to be in order to get archived.
 It’s important to note that this tool only archives work that has been seen through to completion and does not impact any
inflight work. Work status is not a part of the configuration because it must be at a completed state to be effected.

* Scheduling the purge and archive agent

 Scheduling the wizard can be achieved from the same Purge/Archive sub-menu as the configuration.
 An important item to note here is the option to either Archive and Purge, or just Purge the identified work objects. In most
cases, we will only need to use Archive in production.
 Other information we set up deals with the number of items to process during each run and how often to process. In most
cases, it is sufficient to retain the default 30 day cycle.

* System Administrator - Every project needs at least one person who acts as the system administrator.  This person should be
responsible for these additional tasks and the overall maintenance of the system.  The kinds of tasks expected of this person include:
 Working with the database administrator to identify database indices to be tuned for this specific application.
 Using the performance tools available and making sure developers are adhering to the performance best practices.
 Installing hot fixes and updates in the system.
 Monitoring AES (if installed) and addressing any alerts.
 Rolling log files off the server to keep the physical disk space lean.

59