How to build for change

Business environments change, sometimes suddenly, in response to external change or internal decisions. PRPC allows you to design and implement applications that respond to change with agility and efficiency.

By recording business practices and policies in records rather than in code, all PRPC applications provide a degree of modularity and transparency that can simplify maintenance. For example, line managers can review and comment on a business process presented as a Process Modeler diagram, even without knowing Process Modeler how to maintain a flow record.

To go beyond this basic PRPC benefit, application developers can delegate responsibility for updating selected important parts of each application to business managers. This promotes:

Agile response to changing business conditions
Reduced workload for application developers of minor, low risk maintenance items
Shared responsibility for the success of production applications
A degree of empowerment of those closest to day-to-day operations
Experimentation and process innovation by line managers

Which records can managers update?

Users who have the PegaRULES:WorkMgr4 access role (or other roles that include the UpdateLimitedForm privilege) can view and update the leftmost tab of any delegated record. They can also view and update the History tab.

By design, the leftmost tab of the forms for ten rule types provides access to fields most likely to change over time. Although records of any type can be delegated, managers are most likely to learn and understand the following types:

Case match
Constraints
Decision table
Decision tree
Declare Expression
Flow
Flow action
Service level
Map value
When condition

Designing for delegation

To empower managers to change selected records:

Identify during design which records are useful to delegate to managers to maintain.
Choose record names and property names that are meaningful in the business context.
Choose Short Description text carefully for properties that may be referenced in the records.
After initial testing is complete, copy the records into a ruleset containing only the delegated records. This segregates any later changes to them from the rest of the application.
Delegate the records, and confirm that they can be accessed from the manager's dashboard, with meaningful labels.
Provide appropriate training and documentation to line managers.

	delegated rule
	How to delegate a rule PRPC documentation

Identifying a snapshot

The pxSnapshotType column identifies an important value needed to interpret the other values in a record. This column has one of six values:

INTERVAL — Records cumulative usage statistics for a requestor as of the end of an interval (typically a clock hour).
INITIALIZE — Records that a new requestor is initialized.
PASSIVATED — Records passivation of a requestor, such as occurs when a session times out. The PersistRequestor entry in the prconfig.xml file or Dynamic System Setting controls passivation.
TERMINATED — Records log-out, forced timeout, or other termination of a requestor.
PALCLEAR — Records that a requestor cleared PAL statistics.
MERGED_AGENTS — Records details from multiple agent requestors

Identifying an agent or daemon

For agents and daemons, the pyProcLabel property identifies the agent, the index of the row on the Rule-Agent-Queue form, and the activity. The subscript is zero-based; for example, the value:

Pega-ProCom:2:Assign-Corr.SendCorr

in a log identifies processing by the Assign-Corr.SendCorr activity listed the second row of Agent Queue form for the Pega-RULES agent.

For daemons such as the master agent, the pyProcLabel column is blank.

When the system adds to this class

A daemon known as the Usage Daemon commits instances of the Log-Usage class to the database table.

The Usage Daemon saves an instance of the Log-Usage class when a requestor terminates, passivates, activates, and at regular hourly intervals. To minimize the performance effect of new instances, the daemon's write operations are deferred and then committed as a group.

By default, INTERVAL operations record a snapshot at 59 minutes after each hour. For example, if an Operator signs on at 11:15 AM and signs off at 11:56 AM, no INTERVAL instances for that requestor are logged.

By default, this daemon wakes every 300 seconds, so the contents of the table may be stale or incomplete by as much as five minutes.

In a multinode cluster, the Usage Daemons on each node operate independently, so the presence of records in the database table with a recent pxSnapShotTime from one node does not imply that no more records with a similar or earlier pxSnapShotTime value will arrive.

Because agents are requestors, this daemon adds instances to the Log-Usage class for agents even when the system has no interactive users. This behavior is expected.

Some service requestors end a few seconds or less after they start; typically no INTERVAL instances appear for such requestors. If a service uses pooled requestors, INTERVAL instances may appear for those requestors in the pool once each hour.

Reporting

To facilitate reporting, all properties of the Log-Usage class are exposed as columns of the pr_perf_stats table; this table does not contain a Storage Stream column.

These standard reports are available:

Select > System > Tools > System Reports > Assembly Compilation Summary to run the Assembly Compilation Summary. This report is produced by the summary view report Log-Usage.pzAssemblyCompilationSummary. This report shows the number and time of assemblies and compilations, broken out by node.
Select > System > Tools > System Reports > Active RuleSet lists to run the basic performance data broken out by RuleSet list. Click a RuleSet list hash code to see the RuleSets and versions that are contained in that hash.
Select > System > Tools > System Reports > My Performance Details to see interaction end data for your Operator ID for the past week (both user and time range are configurable). The list is sorted by requestorID, and you can drill down into interval/passivation/termination records. You can then drill down further to get full details (similar to the Performance details screen).
Find and run summary view report Log-Usage.BrowseUsageStatistics.ALL to see the types of data in this table. (Summary view reports are limited to 10,000 records; only the first 10,000 rows in the table that meet your selection criteria appear.)

Except for the properties in the following table, the names and meanings of statistical properties in the Log-Usage class is identical to the names and meanings of those in the Code-Pega-PAL class, which supports the Performance tool. For a listing and brief descriptions of those properties, see Performance tool — Full details display.

For technical reasons, Log-Usage properties listed in the following table have a shorter name from the corresponding Code-Pega-PAL properties.

Code-Pega-PAL Property	Log-Usage Property
pxDeclarativeRulesInvokedBackgroundCount	pxDeclRulesInvokedBckGrdCnt
pxDeclarativeRulesInvokedElapsed	pxDeclRulesInvokedElapsed
pxDeclarativeRulesLookupElapsed	pxDeclRulesLookupElapsed
pxListRowWithFilteredStreamCount	pxListRowWithFilteredStrmCnt
pxListRowWithUnfilteredStreamCount	pxListRowWithUnfilteredStrmCnt
pxListWithUnfilteredStreamCount	pxListWithUnfilteredStrmCnt
pxSavedClipboardAfterInteractionCount	pxSavedCbAfterIntCount
pxSavedClipboardAfterInteractionCPU	pxSavedCbAfterIntCPU
pxSavedClipboardAfterInteractionElapsed	pxSavedCbAfterIntElapsed
pxSavedContextAfterInteractionCount	pxSavedCxtAfterIntCount
pxSavedContextAfterInteractionCPU	pxSavedCxtAfterIntCPU
pxSavedContextAfterInteractionElapsed	pxSavedCxtAfterIntElapsed

To improve access, the PegaRULES database indexes are defined for the pr_perf_stats table. You can access this table using the pxUserIdentifier, pxSnapshotTime, pxRequestorType, pxSnapShotType, or pxSystemNodeID property values.

Reporting with the System Management Application

Use the System Management application to report on aggregate system usage based on Log-Usage data, as follows:

Select> System > Operations > System Management App. You may be prompted for authentication credentials.
The System Management application starts. Select any node; your choice does not affect the report contents.
Select Logging and Tracing > Garbage Collector and Log Usage.
Click a radio button to select Log Usage Statistics. Enter a Start Time as five fields, for example Jan, 23, 2006, 16 00 for 16:00 on Jan 23, 2006.
Optionally, enter a Stop Time and Node Name to restrict the report.
Click the top VIEW button.

Trimming the pr_perf_stats table

In a production setting, the pr_perf_stats table can grow to contain millions of rows. By default, the system automatically purges records older than 30 days. If you do not need older rows for performance analysis, debugging, or other reporting, you can purge them by date (known as trimming) without affecting other system capabilities.

Once each day, the Pega-RULES agent starts a stored procedure that purges older rows of this table, passing the value of the pxProcess property as the number of days to retain. To set a retention period longer or shorter than the 30 days, add or revise the following element to your prconfig.xml file and restart the system:

where nnn is the number of days to retain.

As an alternative to the prconfig.xml file, you can use Dynamic System Settings to configure your application.
See How to create or update a prconfig setting.

Notes

Optionally, you can disable this facility through the Dynamic System Settings data instance Pega-RULES.
usage/usagetrackingenabled.

In releases before V5.2, instances of the Log-Usage class were stored in the pr4_log_usage table. The pr4_log_usage database table is not used in Version 5.2 or later. A separate table, pr4_log_rule_usage, supports the Log-RuleUsage class.

	daemon, license compliance facility, prconfig.xml file, Usage Daemon
	Using the Performance tool Working with the PegaRULES database - Log and miscellaneous tables
	Atlas — Standard classes derived from the Log- base class

SysAdmin category