This content has been archived and is no longer being updated. Links may not function; however, this content may be relevant to outdated versions of the product.
Close popover

New Agent rules in Pega 7.4

Understanding agents and agent queues is critical to managing your Pega deployment effectively. This article explains the new Agent rules introduced in Pega 7.4.

Prerequisites
New rules introduced in Pega 7.4
Pega-DecisionEngine: StartSimulationRun
Pega-RulesEngine: PersistNodeState () (For Hazelcast & Ignite clusters)
Pega-RulesEngine: PersistClusterState () (For Hazelcast & Ignite clusters)
Pega-SearchEngine: FTSConflictsHandler
PegaAESRemote: PushDBStatsData
PegaAESRemote: PushDBTableUsageData

Prerequisites

Before you read this article, you should have fundamental knowledge of the Pega 7 Platform, especially the following Pega 7 concepts, tasks, and reference information:

  • How to develop rules for an application
  • Pega Agent concepts and terms and related topics
  • What Agents are available in earlier releases and how to upgrade to Pega 7.4
  • How to create and schedule Agents on multiple nodes of a cluster (two or more Web Application Servers)
  • How to create, modify, and schedule Agent Queues
  • Information in the Pega 7.3 article, Working with Agents in Pega 7.3.

Refer to Related Content for links to all prerequisite information and other references cited throughout this article.

New rules introduced in Pega 7.4

Several new Agent rules are available in Pega 7.4.

Pega-DecisionEngine: StartSimulationRun

Node Type: BackgroundProcessing

Initiates Activity: pzRunScheduledSimulation

Why is the agent StartSimulationRun enabled by default for StartSimulationRun on the BackgroundProcessing nodes?

This agent is enabled by default because it does not require any configuration. See the Pega 7.4 Help topic, Pega-DecisionEngine agents.

The StartSimulationRun agent helps you simulate business strategies against a segment of customers at a scheduled time. The agent runs at a specified interval (in seconds) to start simulation tests that are based on the System-Queue-Simulation queue items. The agent initiates the pzRunScheduledSimulation activity and runs simulation tests by starting the corresponding data flow run at a scheduled time.

Pega-RulesEngine: PersistNodeState () (For Hazelcast & Ignite clusters)

Node Type: RunOnAllNodes

Initiates Activity: pzPersistNodeState

Why is the agent PersistNodeState enabled by default for PersistNodeState to RunOnAllNodes, while the agent rule PersistClusterState is enabled by default to run on BackgroundProcessing nodes?

The purpose of this agent is to collect the system state so that the developer can download the details.

PersistNodeState persists node-specific information, for example, JVM arguments. Because of the need to capture the node-specific information for all nodes in the cluster, this agent is mapped to RunOnAllNodes.

Pega-RulesEngine: PersistClusterState () (For Hazelcast & Ignite clusters)

Node Type: BackgroundProcessing

Initiates Activity: pzPersistClusterState

Why is the agent PersistClusterState enabled by default for PersistClusterState to run on BackgroundProcessing nodes, while the agent rule PersistNodeState is enabled by default to RunOnAllNodes?

The purpose of this agent is to collect the system state so that the developer can download the results.

PersistClusterState persists cluster-specific information such as the count of rules in a ruleset, the number of tables in the rules and data schema, and similar information. Because this agent does not need to run on all the nodes in the cluster, it is mapped to the default BackgroundProcessing DNodeType, which might be one or more nodes in the cluster. See the Pega 7.4 Help topic, Downloading the system state.

Pega-SearchEngine: FTSConflictsHandler

Node Type: BackgroundProcessing

Initiates Activity: pzFTSConflictsHandler

Why is the agent FTSConflictsHandler enabled by default for FTSConflictsHandler to run on BackgroundProcessing nodes?

The agent FTSConflictsHandler is part of the Pega 7.4 feature supporting dedicated indexes for classes and datatypes in Elasticsearch. This agent keeps track of data type conflicts when a dedicated index is created on a class, and it updates the dedicated index status on the Search landing page.

Data type conflict
How it works
Use case

Data type conflict

A data type conflict can occur when an Elasticsearch index contains two fields with the same name but different types. For example, you place data instances of multiple classes into one and the same index and retain their proper types. One class might have a property named Color specified as type String, and another class might have Color specified as type Integer. Because Elasticsearch prohibits this situation, a document with this data type conflict would not be indexed.

How it works

The agent FTSConflictsHandler is enabled by default. From the time you create a dedicated index on a class, an entry is populated in the table pr_sys_queue_ftsconflict for every property created or updated. At every 60-second interval, the agent calls the activity checkForConflictsAPI. This activity retrieves the list of properties that conflict with the property entries that are added into the table and marks the corresponding index status in the Search landing page. The marked index status on the Search landing page prompts you to investigate the conflicts for the Data-CustomProperties-Search instance on that class. The table population starts only after the first creation of a dedicated index on any class. Until that point, checkForConflictsAPI does nothing because there are no entries in the pr_sys_queue_ftsconflict table.

Use case

The primary use case for this agent is to support aggregations on data stored in the Elasticsearch index. This capability would be possible only when data type support for Elasticsearch is available. Until that support is available, all the properties in Pega are stored as strings, and performing aggregations results in incorrect data. Data type support is currently provided only for dedicated indexes and not for the Pega-provided indexes (Rule, Data, or Work). Therefore, unless an application needs to have a dedicated index created for a particular class, this agent can be disabled.

PegaAESRemote: PushDBStatsData

Node Type: BackgroundProcessing

Initiates Activity: pzPushDBStatsData

The agent PushDBStats populates all the index information, creates XML, and sends it to Autonomic Event Services (AES) and Predictive Diagnostic Cloud (PDC).

PegaAESRemote: PushDBTableUsageData

Node Type: BackgroundProcessing

Initiates Activity: pzPushDBTableUsageData

The agent PushDBTableUsageData populates all of the database table usage information, creates XML, and sends it to Autonomic Event Services (AES) and Predictive Diagnostic Cloud (PDC).


100% found this useful


Related Content

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.