Edit online

Queue processors

Following is the list of queue processors that are available in Pega Client Lifecycle Management and KYC application. By default, the application makes use of most of the queue processors in this list and organizations should review at the time of implementation that their default configurations meet their needs. Queue processors only used for certain optional functionalities are highlighted in the following table so that they can be disabled as required.

Queue processor

Functionality

Attributes Description

SPU Master

SPU (CLM)

Threads: 1

Max attempts: 3

Initial delay: 5

Delay factor: 2.0

Used by default: Yes

The KYC regulatory watch dog periodically checks for updates in the regulatory stack (see KYCWatchDog at Job Schedulers). When a change is detected, this queue processor is triggered to start the Surgical Policy Update (SPU) process.

This queue processor retrieves the application policy stack hash and fetches the list of inflight KYC cases for which latest regulations are to be applied. Each of the cases found are queued to the SPUCore queue processor for applying the latest KYC policies on them.

If the number of cases that are to be processed exceeds the threshold specified in PegaKYC RecordsThresholdForSPURequeue DSS, this queue processor requeues itself to continue in a subsequent execution the unprocessed records.

This queue processor can be disabled if the organization has disabled SPU.

For more information, see the Surgical policy updates.

SPU Core

SPU (CLM)

Threads: 5

Max attempts: 3

Initial delay: 5

Delay factor: 2.0

Used by default: Yes

When a due diligence case is queued to this queue processor as part of SPU (see SPU Master), it applies the latest regulations to the case. During that process, existing responses are retained by temporarily persisting the KYC types of the case into the Policy Memory. The queue processor then re-applies the latest regulations on the case and, based on configuration, take the case back to the appropriate stage of the process.

This queue processor can be disabled if the organization has disabled SPU.

For more information, see the Surgical policy updates.

TrackKYCTypeUpdates

Audit (CLM)

Threads: 3

Max attempts: 3

Initial delay: 1

Delay factor: 2.0

Used by default: Yes

While performing due diligence for a customer, the KYC questionnaire are stored in the Policy Profile at different points in the process. It is then when the Policy Profile of the customer is queued into this queue processor for the detection and audit of changes within the KYC types. Any change (add, update, or delete) in a response to a KYCItem since the last time that the same KYC Type was persisted at the Policy Profile is identified and recorded at the fsf_changetracker audit table.

This queue processor can be disabled if the organization is not using the KYC Type audit capabilities. Queue should be clean periodically using administration tools.

For more information, see the Data traceability.

GenerateAndAttachPDF

Due Diligence (CLM)

Threads: 3

Max attempts / Initial delay / Max attempts: 3

Initial delay: 1

Delay factor: 2.0

Used by default: Yes

When a due diligence case is approved, the KYC Reviewer can opt for generating the snapshot of the due diligence data captured as part of the case as a proof. When opted, the request is queued to this queue processor, which generates a PDF document with the due diligence information captured in the KYC case. It also attaches the PDF document to the case and associates the document to the customer's document list.

For more information, see the Generating a PDF documentation.

RNGDMSOutboundSync

Requirements (CLM)

Threads: 2

Max attempts: 3

Initial delay: 1

Delay factor: 2.0

Used by default: No

Queue processor that manages the outbound synchronization of document metadata to external systems like DMS. During the creation or update of document metadata, an entry is queued to this queue processor if the following Dynamic System Settings are enabled:

PegaRequirements Requirements /DMS/OutboundAsyncModeEnabled

PegaRequirements Requirements /DMS/OutboundSynchronizationEnabled

If any of the settings above is set to false, the queue processor can be disabled.

For more information, see the Integrating with a DMS system.

SyncUpPoint

Group Onboarding (CLM)

Threads: 1

Used by default: Yes

This queue processor checks for the cases triggered from the group onboarding journey and, if all of them are finished, it collects some data from them and resolves the main Group Onboarding journey.

This queue processor can be disabled if the organization is not using group onboarding functionality.

EDAProcessEvent

Event Driven Architecture / Perpetual KYC (CLM)

Threads: 5

Max attempts: 3

Initial delay: 1

Delay factor: 2.0

Used by default: Yes

In Event Driven Architecture, events can be injected into the EDA Engine through multiple channels, including this queue-processor, which triggers the execution of the EDA channel on the event that has been queued. The queue processor is configured for immediate execution; for a delayed execution, look at Event Driven Architecture.

This queue processor can be disabled if the organization is not using Event Driven Architecture (2G) nor Perpetual KYC.

For more details on Event Driven Architecture, see Event Driven Architecture

EDAProcessEventScheduled

Event Driven Architecture / Perpetual KYC (CLM)

Threads: 5

Max attempts: 3

Initial delay: 1

Delay factor: 2.0

Used by default: Yes

In Event Driven Architecture, events can be injected into the EDA Engine through multiple channels, including this queue-processor, which triggers the execution of the EDA channel on the event that has been queued. The queue processor is configured to execute events on a schedule basis; for immediate execution, see Event Driven Architecture.

This queue processor can be disabled if the organization is not using Event Driven Architecture (2G) nor Perpetual KYC.

For more details on Event Driven Architecture, see Event Driven Architecture

EDAProcessEventBundle

Event Driven Architecture / Perpetual KYC (CLM)

Threads: 1

Max attempts: 1

Initial delay: 1

Delay factor: 2.0

Used by default: Yes

This scheduled queue processor is associated to a bundle registered at Event Driven Architecture and it oversees the generation of new events that represents the bundle, and that taken through the EDA channel, will result in the execution of the process associated to bundles.

This queue processor can be disabled if the organization is not using Event Driven Architecture (2G) nor Perpetual KYC.

For more details on Event Driven Architecture, see Event Driven Architecture

AsyncProcessing

Asynchronous Processing (Pega FS)

Threads: 5

Max attempts: 3

Initial delay: 1

Delay factor: 2.0

Used by default: Yes

For processes where the waiting period is excessive, the system uses asynchronous processing for performing the task in the background and gives back the control to the users as soon as possible. AsyncProcessing queue processor manages cases that are queued for asynchronous processing that require immediate processing.

This queue processor can be disabled if the organization has disabled the use of Asynchronous Processing.

For more information, see the Configuring asynchronous processing.

AsyncProcessingDelayed

Asynchronous Processing (Pega FS)

Threads: 3

Max attempts: 3

Initial delay: 1

Delay factor: 2.0

Used by default: Yes

For processes where the waiting period is excessive, the system uses asynchronous processing for performing the task in the background and gives back the control to the users as soon as possible. AsyncProcessingDelayed queue processor manages cases that are queued for asynchronous processing with a delayed start.

This queue processor can be disabled if the organization has disabled the use of Asynchronous Processing.

For more information, see the Configuring asynchronous processing.

FSEventQueueConsumer

Event Driven Architecture

Threads: 5

Max attempts: 3

Initial delay: 1

Delay factor: 2.0

Used by default: Yes

In Pega Client Lifecycle Management, there are certain business events that are monitored so that the application can create Customer Review journeys on customers. By default, the application monitors changes in the risk level of a country, expiration of documents, customer next review date and explicit requests from the application for a customer review. All these events are queued into this queue processor, which creates the appropriate Customer Review journey based on the event type.

This queue processor can be disabled if the organization is not using the automatic creation of Customer Review journeys.

For more information, see the Event Driven Architecture

.

In a typical implementation, there is usually no need to make changes to these queue processor rules. However, some organizations might want to review the parameters to meet their specific needs. In those situations, a copy of the queue processor rule must be made at the application-level rulesets and the required changes made there. These are some of the most important parameters to be considered:

Configuration Description
Number of threads

Number of threads per node available for processing of the configured activity.

It is important to note that there is a limit to the number of threads that can be available for a given queue processor in a cluster. For example, having 3 background nodes with a configuration of 5 threads per node does not guarantee 15 threads available. The limit is imposed by the size of the underlying Kafka topics associated with a queue-processor, which by default is 7.

Look at PEGA0137 to determine whether the limit at cluster level should be adjusted and, if required, use activity pxAlterStreamPartitions.

Max attempts The number of attempts that you want your queue processor to perform before the item is moved to the broken items queue. The default value is 3.
Initial delay (in minutes) The number of minutes for the processor to wait before retrying to process an item. The default value is 1.
Delay factor The factor by which the initial delay value is multiplied to calculate the period between successive retry attempts. The default value is 2.

If, for any reason, you do not want the system to run a particular queue processor, make a copy of the queue processor and disable it.