Skip to main content


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

Configuring asynchronous processing

Updated on June 11, 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 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 ten or more seconds, and a different team likely performs the next task.

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 to 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 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 the navigation pane of Dev Studio, click Records.
  2. Expand the SysAdmin category, and then click Dynamic System Settings.
  3. Search for and select clmfs/AsyncProcessingSwitch.
  4. In the Value field, enter false.
What to do next: 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 only two of them should be enabled from the processes configured by default, while others must remain running in the foreground as they did in previous versions of the product.

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

  1. In the header of Dev Studio, in the search text field, search for the AsyncProcessingSwitchTriggerPoint decision table rule.
  2. In the row corresponding to the trigger point, enable or disable a certain trigger point by setting the value to true (enabled) or false (disabled).
    By default, all processes are enabled. If you set the clmfs/AsyncProcessingSwitch to false, the configuration of this table is irrelevant, and no process runs in asynchronous. The following asynchronous processes are enabled by default.
    CaptureToEnrich
    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.

    EnrichToDuediligence
    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.

    LKYCCases
    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 the header of Dev Studio, in the search box, search for the AsyncProcessing or AsyncProcessingDelayed rules and select the queue processor.
  2. Save the rule into your implementation layer by clicking Save as.
    For more information, see Copying rule or data instance.
  3. Make the necessary changes.
  4. Click Save.
  5. To ensure that the system recognizes a new configuration and considers your application 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

Configure your 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.
What to do next: For more information on these extension points, see Asynchronous process extension points.

Asynchronous process extension points

Configure the following rules to modify the behavior of both default processes and custom processes.

AsyncProcessing
The flow is 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 is 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.
AsyncProcessingSwitchTriggerPoint
The decision table is 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.
AsyncProcessingPreSetValues
An extension data transform can be used to set values on the case before it is queued for asynchronous execution.
AsyncProcessingPostSetValues
An extension data transform 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.

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

Close Deprecation Notice
Contact us