Configuring asynchronous processing
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 knowledgebase 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.
- In the navigation pane of Dev Studio, click Records.
- Expand the SysAdmin category, and then click Dynamic System Settings.
- Search for and select clmfs/AsyncProcessingSwitch.
- In the Value field, enter false.
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.
- In the header of Dev Studio, in the search text field, search for the AsyncProcessingSwitchTriggerPoint decision table rule.
- 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.
- Navigates from the Capture stage to the
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.
- In the header of Dev Studio, in the search box, search for the AsyncProcessing or AsyncProcessingDelayed rules and select the queue processor.
- Save the rule into your implementation layer by clicking Save
as.For more information, see Copying rule or data instance.
- Make the necessary changes.
- Click Save.
- To ensure that the system recognizes a new configuration and considers your
application by the new System Context mechanism, do the following steps.
- Open the application model by clicking .
- 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.
- In Dev Studio add the AsyncProcessing sub-flow to the flow of the stage to which you want to add asynchronous processing.
- Double-click the AsyncProcessing flow shape, and name the trigger point in its parameters.
- Search for the AsyncProcessingSwitchTriggerPoint decision table, add the new trigger point, and set it to true to enable it.
- Search for the AsyncProcessingConfig decision table to configure the amount of attempts, and how often to retry those attempts, and so on.
Asynchronous process extension points
Configure the following rules to modify the behavior of both default processes and custom processes.
- 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.
- 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.
- An extension data transform can be used to set values on the case before it is queued for asynchronous execution.
- An extension data transform can be used to set values on the case after it is queued for asynchronous execution.
Previous topic Configuring event-driven architecture Next topic Master Profile cache