Use the Performance tool to understand the system resources consumed by processing of a single requestor session, or the SQL statements sent to the PegaRULES database by the requestor session.
Process Commander always accumulates cumulative resource statistics for the Performance tool. Use the tool to display these statistics, and to identify incremental resources (in the delta rows) consumed by your processing. Because this feature displays existing data, its use does not degrade processing.
The Performance tool is sometimes known as PAL. Run > Performance
Monitoring SQL operations with DB Trace
You can monitor the interactions between Process Commander's server engine and the PegaRULES database or other relational databases, and the operation of the rule cache. Familiarity with SQL is required to interpret the output. To use this facility:
Open the Full details window.
Unlike the resource statistics feature, the DB Trace feature is normally off. Use the DB Trace feature only for a brief interval. When enabled, DB Trace processing can produce voluminous output and may adversely affect session performance.
The DB Trace tool link is not displayed in a production system — a system with the Production Level on the System form set to 5. In addition, the DB Trace is available only to users who have the PegaRULES:SysAdm4 access role. These access roles provide access to the standard privilege named Code-Pega-.PerformanceTools.
You can start and stop this tool from an activity, by calling the standard activity Code-Pega- Requestor.SetRequestorLevelDBTrace to turn the DB Trace tool on and off. This activity sets the
pxRequestor.pyDBTraceEnabled property; the tool closes the output text file when tracing is turned off.
System-wide database trace
An alternative approach that provides comprehensive tracing of SQL statements sent to the PegaRULES database is the dumpStats parameter in the prconfig.xml file.
To enable this feature:
1. Update the <database> node of the prconfig.xml file to add this element: <entry key="dumpStats" value="true" />
2. Stop and restart the application server.
This setting generates a system-wide database trace file in the ServiceExport directory that can become very large quickly, and can affect system performance. Use this setting only for brief periods, and when a single-requestor DB trace is not suitable.
DB Trace Dialog.
This Local Flow action will be available in all the Assignments in the Flow.
2) List Rule
A list rule is an instance of the Rule-Obj-List rule type.
A list defines an ordered array of property names from the class. Lists are referenced only in activities, using the Obj-List method.
A list rule determines which properties of a specified class are copied into embedded pages when the Obj-List method runs. When only a fraction of all the properties of an object are needed on the clipboard, using a list rule improves processing efficiency by reducing memory and disk demand. When we create a Data Table out of a Data Class, A List rule is created inside our Data Class (Normally with Name EditList). It Contains the List of properties in the Data Class.
3) Modifying a Data Table
If we modify our Data Class by adding a new property, It’ll not reflect in the Data Table.
We need to modify the List Rule (EditList) in our Data Class. Then Open the Data table with Data Table wizard, the new property will appear in the Data table.
4) Lock mechanism between cover and covered work objects.
If the covered objects are locked, the Cover object is also locked. Locked means only one requestor can access it at a time. The Activity that maintains this lock is Determine Lock String in Work- class of Pega-Procom rule-set.
The covered work objects can be of different work classes (types), but Cover and Covered work objects should be a part of same workpool.
Locking: By default, locking a covered work object also locks the cover work object. This is desirable because the cover work object may contain totals, balances, counts, or other derived values that require single-threaded access.
Page Names: By convention, a cover work object occupies a clipboard page named pyCoverPage; the covered work object is on a page named pyWorkPage. Many standard activities depend on these naming conventions.
Ticket: The standard ticket rule Work-Cover-.AllCoveredResolved alerts a cover flow that all themember work objects are resolved. If your application is to incorporate this constraint, include this ticket in the flow rule or rules for the cover work object.
Flow actions: The standard local flow actions Work-.AddToCover, Work-.AddCovered, and Work- .RemoveFromCover allow user management of cover contents.
Harness rules: The Work-.NewCovered harness rule supports entry of a new cover and cover members.
Process Engine API: Activities Work-.AddCoveredWork, Work-.AddCovered, and others support operations with covers.
Folders:
A work object folder is a work object in a concrete class that inherits from the Work-Folder- class. A folder object holds a collection of one or more other work objects (which themselves may be basic work objects, other folders, or covers) providing access for analysis and reporting. By convention, the work object ID of folders has the format F-99999.
Covers and folders are two built-in facilities that allow your application to support collections of work objects. In contrast to covers:
One work object may be associated with multiple folders, but only with one cover.
Members of a folder can belong to different work types, which need not belong all in a single work pool.
The relationships between folder work objects and their contents may be many-to-many These standard rules support folders:
Work-.AddToFolder flow action — Add a work object to a folder
Work-.RemoveFromFolder flow actions — Remove a work object from a folder
Work-Folder-.Review harness — Show folder work object, includes the View Folder Contents button ( ) to access contents
Work-Folder-.Perform harness — Update folder work object and contents
Who decides the pyWorkPage as default page for new W.O ?
Standard Activity: createWorkPage in Work- class of Pega-Procom rule-set.On the Requestor page of the clipboard, the property pxRequestor.pxCurrentWorkPool
holds the value of a user's current work pool.
SYSTEM PULSE
The Pega-RULES agent performs periodic processing known as a system pulse.
This processing synchronizes the contents of the in-memory rule cache on that node with rules stored in the PegaRULES database. The pulse helps each node coordinate processing and synchronize operations, including the contents of the rule cache.
In a multinode clustered system, a rule updated by a user on node North is retained in the rule cache on node North, and also committed to the PegaRULES database. For a brief interval, users at another node in the cluster — for example South — may have a stale copy of that rule in the rule cache on the South server node. When pulse processing for South completes, the South rule cache has the current rule.
Between pulses, updated rules are noted in the pr_sys_updatescache table, corresponding to the System-Updates-Cache class.
The Agent Schedule data instance named Pega-RULES.<node> defines the pulse interval. The default interval is 60 seconds.
REQUESTOR
A requestor is the process and data associated with a user (guest or authenticated) of your Process Commander system, or the processing and data associated with a request into your system started by an outside system, such as a Web Applications Server or an Active Server Page on a Web site.
Each HTTP response that presents the Process Commander log-in form results in the creation of a guest requestor, one that is authenticated and has only access to the RuleSets and Versions in the PegaRULES:Unauthenticated access group. To avoid tying up system resources, the default time- outperiod for idle guest requestors is a minute.
Information about each type of requestors your system supports is defined in instances of the Data- Admin-Requestor class.
Important facts about the context of each requestor are contained in the pxRequestor page of the clipboard for that (human or electronic) requestor.
H — Interactive, browser-based requestor B — Background requestors, such as agents A — Listeners and services
P — Portlet
When installed, Process Commander contains four requestor types. Typically, these are all you need.
Name Purpose
APP For listeners and for access to Process Commander from an external client system, such as through a service
request (other than JSR-168 requests using Rule-Service-Portlet rules). Requestor sessions using this requestor type instance have requestor IDs that start with the letter A.
BATCH Background processing, such as performed by, listeners, services, agents, and daemons. Requestor sessions using this instance have a requestor ID that starts with the letter B. As initially installed, all BATCH requestors have access to the PegaRULES:Agents access group.
BROWSER
For HTTP or HTTPS access to the Process Commander portal using Microsoft's Internet Explorer Web browser on a Windows workstation, or from a browser presenting a Pega Composite Application. Requestor sessions using this instance have a requestor ID that starts with the letter H.
As initially installed, all BROWSER requestors have access to the PegaRULES:Unauthenticated access group.
PORTAL For HTTP access as a portlet in conjunction with Service Portlet rules. Requestor sessions using this instance have
a requestor ID that starts with the letter P.
Agents can broadly be classified into 2 categories. Task Driven and Schedule Driven.