Understanding the Pega-RULES agents

By default, this agent runs the standard Code-.SystemCleaner activity once each day for housekeeping tasks, which include purging:

• Older records (instances) from log tables
• Any requestors that have had no activity during at least 48 hours
• Rows from the pc_events database table according to the EventsRetentionPeriod Dynamic System Setting (the default retention period is 90 days).
• 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 an entry in the prconfig.xml file or the Dynamic System Settings, 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 checkbox 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 the operations of the full-text search facility for rules and data instances. Typically, this runs every 60 seconds. Accordingly, when you save a new or updated rule, the changed information may not be reflected in search results for a minute or so.

You can enable or disable full-text index processing through the System Settings landing page. See System category — Settings page.

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, this activity runs once an hour.

In a production system, this activity deletes extracted static content from the static content directories that is older than 30 days. In a non-production system (based on a production level setting of 1, 2, 3, or 4), the default retention period is 3 days (72 hours).

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 — typically those items derived from rules — change only infrequently. Changing the prconfig.xml setting or Dynamic System 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 items. Lucene indexes for work items are created only when the dynamic system setting PegaRULES:indexwork/enabled is set to true. A checkbox on the Advanced tab of the Class form controls which work items are indexed. See Search Landing page.

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

You can enable or disable full-text index processing through the System Settings landing page. See System category — Settings page.