Understanding the Pega-RULES agents

By default, this agent runs the standard Code-.SystemCleaner activity once each day for housekeeping tasks, including purging older records (instances) from log tables, any requestors that have no activity during at least 48 hours, and any nodes that have not responded to the pulse for 30 days.

If desired, you can add an activity similar to Code-.SystemCleaner to another agent to purge outdated information and recover tablespace. Make sure the agent has access to the needed RuleSet Versions, and take care not to purge instances that are referenced in other tables.

Similarly, you can change the idle requestor purge criteria to a value less than 48 hours, by overriding the test in the called activity System-Requestor-Context.CleanupExpired.

Once each day, this activity calls Log-Usage.UsageCleaner, which trims older rows of the pr_perf_stats table (corresponding to the Log-Usage class). This activity starts a stored procedure, passing a number of days to retain based on the value of the pxProcess.pxLogUsage RetentionPeriod property. (Through a prconfig.xml setting, you can set this retention period. The default is 30 days.)

System pulse processing, defined by the activity Code-.SystemPulse, typically occurs every 60 seconds. Rows of the pr_sys_updatescache database table (corresponding to the System-Updates-Cache) class form the input queue. Rows of this table have one of five record types in this table:

• CACHE — Notify all nodes of rules created, deleted, or updated since the most recent pulse.
• INDEX — Records the need to incrementally update Lucene indexes (typically indexes are created and saved only on one node of a cluster)
• DELLC — Indicates that the Lookup List Cache (LLC) — was deleted on this node, so other nodes are to delete their own LLC. Deleting this cache is a manual option in the System Management application.
• RFDEL — Indicates that a static-content rule (from one of the Rule-File-* rule types) was deleted, so all nodes are instructed to delete the extracted static file.
• RUF-X — Indicates that a library was regenerated on one node, so that other nodes are instructed to regenerate this library.

In a multinode system, changes to the contents of the rule cache are synchronized during the pulse operation. Accordingly, changes to a rule that a developer saves on one node may in some cases not be reflected in processing that occurs on another node, for up to a minute (or another value depending on pulse configuration). Processing on the first node accesses the updated rule from its cache, but processing on the second node may temporarily access a stale copy from its cache.

To see a list of updates not yet posted by pulse processing, review the standard report System-Updates-Cache.InstanceList.All. (Use the System Management application to find more complete information.)

Pulse processing also notices updates to access groups made on one node and makes them effective on the current node.

After a developer clicks the Generate Library   button on the Packages tab of a Library form (or equivalently selects the Compile Libraries check box on the Import Archive form), the system promptly extracts and compiles (on the developer's node) the functions in that library. At the next opportunity, system pulse processing on each other node of a multinode cluster compiles that library, thus keeping the compiled versions synchronized across all nodes.

The standard activity Code-.SystemIndexer updates the search index cache that supports Find and Find Content operations of the Advanced Search facility. Typically, this runs every 60 seconds. Accordingly, when you save a rule, it may not be retrieved by the Rule content Find operation for up to a minute.

(You can enable or disable index processing through Dynamic System Settings instances.)

The standard activity Code-.RuleUsageSnapshot normally runs once every 24 hours. If the system has run for at least an hour since startup, this activity takes a snapshot of the rule assembly cache, writing out instances of the Log-RuleUsage class and Log-RuleUsage-Details class.

Data in those classes is accessed during the next system startup, to populate the rules assembly cache. See Working with the rules assembly cache.

The standard activity Code-.StaticContentCleaner deletes (or "prunes") files from the server file system containing static content, such as images (JPG, PNG, or GIF file type), style sheets (CSS file type) and JavaScript files (JS file types) in the StaticContent folder. Normally running once an hour, this activity deletes extracted static content that is older than NNN days, where NNN is the value of the following setting in the prconfig.xml file:

<env name="http/staticcontentminpruningage" value="NNN" />

In a production system, if the prconfig.xml file contains no http/staticcontentminpruningage entry, the activity uses 30 days as the default retention period, purging the static content directories and files that are more than 30 days old. In a non-production system (based on a production level setting of 1, 2, 3, or 4), if the prconfig.xml file contains no such parameter, the default retention period is 3 days.

Eliminating older static content reduces the number of files and subdirectories in the server's StaticContent directory, saving disk space and improving file access. If a user with a specific RuleSet list later attempts to access a static content file that was purged, the file is re-extracted from the Rule-File-zzzz rule in the PegaRULES database on demand.

The DateTime property pxProcess.pxAdminSystem.pxLastStaticContentPruning on the Process page identifies the last time this activity started.

In a production setting, RuleSet lists, images, CSS style sheets, and JavaScript files — mostly derived from rules — change only infrequently. Changing the prconfig.xml setting to a larger value than 3 days may improve some user response times slightly by reducing on-demand extractions.

The SystemWorkIndexer agent periodically updates Lucene indexes to support text-based searches for work objects. Lucene indexes for work objects are created only when the dynamic system setting PegaRULES:indexwork/enabled is set to true. A check box on the Advanced tab of the Class form controls which work objects are indexed. See How to enable and control the full text search facility.

To search for work objects from the Developer portal, select Edit > Advanced Search and then select Work in the Find Content panel at the right.

Application users accessing Process Commander from the User composite portal (or another composite portal that incorporates the @baseclass.FindWork section) can search for work objects using full-text search.