Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

Configuring surgical policy update processors

Updated on June 30, 2021

The SPU engine uses two queue processors to perform the policy update of cases in the background. These queue processors are named SPU Master and SPU Core. The SPU Master fetches those cases that need to be updated from the database and queues them in the SPU Core for processing. The SPU Core accesses and updates each outdated inflight case.

The queue processors come by default configured to run with multiple concurrent threads – a configuration that you may need to adjust to your needs.

  • SPU Core: 5 concurrent threads
  • SPU Master: 1 concurrent thread

This is the number of concurrent threads that the system processes per node in the cluster. One thread translates into one case being processed. A configuration of 3 threads in, for example, a cluster of 4 nodes configured for background processing, provides an overall throughput of 12 simultaneous cases. You may need to adjust this number based on your volumes and the size and performance of your system.

The queue processors are also configured to manage error scenarios. This is the configuration that comes with KYC by default:

Max Attempts: 3
In some situations, the system can find errors while processing a case. For example, an external system may be down or there is an unexpected situation that prevents the process from finishing. Retying for 3 times is usually enough to resolve those situations. After the max number of retries is reached, the case goes to the broken-process status and an administrator needs to take action.
Initial delay (in minutes): 5
This is the time that the system waits between a first failed execution attempt and a second attempt.
Delay factor: 2
This is a correction factor applied to the initial delay between subsequent retries. For example, if the initial delay was 1 and the delay factor is 2, the system waits 1 minute between the first attempt and the second, 2 minutes between second and third, 4 minutes between the third and fourth attempts and so on.

You can modify these settings in the implementation to yield a higher or lower throughput as desired. To change the settings do the following steps.

  1. In the navigation pane of Dev Studio, click Records.
  2. Expand the SysAdmin category, and then click Queue Processor.
  3. Select the queue processor to be modified (SPU Core or SPU Master).
  4. Save the queue processor rule into one of your rulesets.
  5. Make the appropriate changes in the new rule.
  6. Save the rule and, if required, check it in.
What to do next: Any queue processor that runs for more than fifteen minutes generates a PEGA00131 alert. If you have deployed your application on Pega Cloud, this alert results in marking the node as unhealthy, and in shutting the node down. Therefore, to keep a check on the period of time that the SPU Master queue processors runs for, the processor is configured to re-queue after processing every 5,000 records, which takes approximately 10 minutes to execute. You can configure the threshold of the number of records before the SPU master is re-queued, and therefore the duration. You can change the value by updating the PegaKYC/RecordsThresholdForSPURequeue Dynamic System Setting.

Have a question? Get answers now.

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

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us