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.
In Dev Studio click.
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 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.
In Dev Studio search for the AsyncProcessingSwitchTriggerPoint decision table rule.
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.
In Dev Studio search for the AsyncProcessing or AsyncProcessingDelayed rules and select the queue processor.
Save the rule into your implementation layer. For additional information about locked and unlocked rulesets, see Copying a rule or data instance.
Make the necessary changes.
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.
Open the application model by clicking.
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.
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
The following rules can be configured to modify the behavior of both default processes and custom processes.
- 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.