Queue processors
-
- Last UpdatedSep 21, 2022
- 7 minute read
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.