Skip to main content

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

Configuring asynchronous processing

Updated on February 16, 2021

Heavy processes that run during a user's session can create delays between the last action that the user took (for example, submitting an assignment) and the return of the control to the user, either by showing the confirm harness or by opening the next active assignment. For processes where the execution time takes a few seconds and where the current operator is likely to take the next action, this waiting period is acceptable. It is not acceptable, though, in cases where the execution time goes beyond 10 or more seconds and the next task will be likely performed by a different team.

For processes where the waiting period is excessive, the system uses asynchronous processing. This gives control back to the users as soon as they take action on the case, so that they can keep working on other cases while the system processes the slower case. The system works asynchronously until human intervention is required or the case is resolved.

By default, the following cases work asynchronously:

  • Navigating from capture Stage to enrich stage (CaptureToEnrich)
  • Navigating from enrich to due diligence stage (EnrichToDuediligence)
  • Creation of Local KYC cases (LKYCCases)

For more information about asynchronous processing, see the Asynchronous processing article.

Do the following tasks to enable, configure, and extend asynchronous processing.

Enabling asynchronous processing

A dynamic system setting enables or disables asynchronous processes throughout the entire application. By default, the system is configured with this setting enabled.

To disable asynchronous processing throughout the entire application, do the following steps.

  1. In Dev Studio click RecordsDynamic System Settings.

  2. Search for and select clmfs/AsyncProcessingSwitch.

  3. In the Value field, enter false.

To enable individual asynchronous processes, see Enabling individual asynchronous processes.

Enabling individual asynchronous processes

If you do not want all of the default asynchronous processes to run, you can specify which individual processes you want to run asynchronously. For example, you can decide that from the processes configured by default, only two of them should be enabled, while others should remain running in foreground as they did in previous versions of the product.

This configuration is stored in a decision table that stores all the trigger points (processes) where asynchronous processing is used.

  1. In Dev Studio search for the AsyncProcessingSwitchTriggerPoint decision table rule.

  2. Enable or disable a certain trigger point by setting the value to true (enabled) or false (disabled) in the row corresponding to the trigger point. By default, all processes are enabled. If you set the clmfs/AsyncProcessingSwitch to false, the configuration of this table is irrelevant, and no process will be run in asynchronous. The following asynchronous processes are enabled by default.

    Navigates from the Capture stage to the Enrich stage. It includes, as required, the notification to stakeholders after the Capture stage, third party data incorporation, welcome pack generation, and customer investigation.
    Navigates from the Enrich stage to the Due diligence stage. It includes the synchronization with the system of record and the generation of all the Global KYC, Regulatory, Tax, Credit and Legal due diligence cases, including their automated solution, if applicable.
    Creates LKYC cases after the completion of the initial stages of Global KYC cases (Related party Global KYC and Customer investigation).

Configuring the underlying asynchronous process infrastructure

The asynchronous processing functionality is implemented using Pega queue processors that process cases according to certain parameters. Customers may need to change the default configuration to meet the needs of their specific implementations. For more information, see the Asynchronous processes.

  1. In Dev Studio search for the AsyncProcessing or AsyncProcessingDelayed rules and select the queue processor.

  2. Save the rule into your implementation layer. For additional information about locked and unlocked rulesets, see Copying a rule or data instance.

  3. Make the necessary changes.

  4. Click Save.

  5. To ensure that the new configuration is recognized by the system, ensure that your application is considered by the system by the new System Context mechanism do the following steps.

    1. Open the application model by clicking <application name>Definition.

    2. Expand the Advanced section and ensure that Include in background processing is selected.

Extending asynchronous processes

You can configure your own processes to follow the asynchronous processing pattern by including a reusable sub-flow into your flows and configuring the trigger point.

  1. In Dev Studio add the AsyncProcessing sub-flow to the flow of the stage to which you want to add asynchronous processing.

  2. Double-click the AsyncProcessing flow shape, and name the trigger point in its parameters.

  3. Search for the AsyncProcessingSwitchTriggerPoint decision table, add the new trigger point, and set it to true to enable it.

  4. Search for the AsyncProcessingConfig decision table to configure the amount of attempts, and how often to retry those attempts, and so on.

For more information on these extension points, see Asynchronous process extension points.

Asynchronous process extension points

The following rules can be configured to modify the behavior of both default processes and custom processes.

For example:
Flow used to run a process in the background using agents and queue processors. It must be invoked as a sub-flow, which creates an event and waits at an assignment shape and proceeds in the background with the help of an agent. The flow requires a TriggerPoint parameter, which needs to be passed when the flow is invoked. This trigger point is used to capture the location where the flow has been invoked. The same parameter needs to be configured in the AsyncProcessingSwitchTriggerPoint decision table. While customers are expected to add this flow into their own processes, it is not expected that the flow itself is modified to obtain custom behaviors.
Decision table used for capturing all trigger points where asynchronous processing is used. When the AsyncProcessing flow is invoked in each stage, it passes a parameter from this decision table.
An extension data-transform which can be used to set values on the case before it is queued for asynchronous execution.
An extension data-transform which can be used to set values on the case after it is queued for asynchronous execution.

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