Skip to main content


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

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.

Asynchronous processing

Updated on September 10, 2021

The asynchronous processing functionality is implemented by using Pega queue processors that process cases according to certain parameters. Customers might need to change the default configuration to meet the needs of their specific implementations.

The application contains the following queue processors:

  • AsyncProcessing – manages all cases that are queued for asynchronous processing that require immediate execution. With the default configuration, this queue is used for all cases.
  • AsyncProcessingDelayed – manages cases that are queued for asynchronous processing with a delayed start. Most of the time, this working mode is not needed but, if required, it checks the AsyncProcessing flow and, where the AsyncProcessingQueue activity is invoked, sets the parameter Deferred to true.

Both queue processors come with the following configuration (available under Records > SysAdmin > Queue Processors):

  • Number of threads per node: 3 – This is the number of concurrent threads that the system can process per node in the cluster. One thread equals one case being processed. For example, a configuration of three threads in a cluster of four nodes, configured for background processing, would provide 12 simultaneous cases. This number might need to be adjusted based on your volume and the size and performance of your system.
  • Max Attempts: 3 – In some situations, the system can find errors while processing a case. For example, an external system might be down or there is an unexpected situation that prevents the process from finishing. Retying three times is usually enough to resolve those situations. After the maximum number of retries is reached, the case goes to the broken-process status and an administrator needs to take action.
  • Initial delay (in minutes): 1 – 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 one minute between the first attempt and the second, two minutes between second and third, four minutes between third and fourth, and so on.

Most of the time, the default parameters are sufficient. If you need to make changes to these parameters, see the Pega Client Lifecycle Management for Financial Services Implementation Guide.

Note: The queue processors shipped with the application are both configured to only run in those nodes of the cluster that are configured with the BackgroundProcessing node type. If required, change the associated node type in the new Queue Processor rule or configure some of the nodes of your cluster to use that node type.

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.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us