Asynchronous integration
Pega Platform™ provides multiple mechanisms to perform processing asynchronously. For instance, an application may initiate a call to a back-end system and continue processing without blocking and waiting for the external system’s response. This approach is useful:
- When the external system processing time can be an issue
- When the result of the processing is not required immediately
A similar feature is also available for services allowing you to queue an incoming request (for example, the Service-REST /Service-File rule).
- If execution mode is configured as synchronous (immediate), then the request is handled and processed in the single requester context immediately.
- If execution mode is configured as asynchronous (queue for execution), the request is handed out to the queue and processed later.
Commonly-used approaches for asynchronous integration
Commonly-used asynchronous approaches include the:
- Load-DataPage method
- Run-In-Parallel option with the Connect-Wait method.
Load-DataPage
Data pages are loaded synchronously by default. To load data pages asynchronously so that users can take action on a work item while other content is still being loaded, perform the following actions:
- Use the Load-DataPage step method in an activity, and then wait for the data page to load by using the step method Connect-Wait.
- For more information, see Load-DataPage and Connect-Wait.
An asynchronous data page can be an optimal design pattern for any process that selects filtered rows from the same overall record set. Retrieving the same large record set over and over again is a waste of processing resources.
Suppose a slow-running connector is used to source a data page. In that case, the data page can be preloaded using the Load-DataPage method in an activity to ensure the data is available without delay when needed. Grouping several Load-DataPage requestors by specifying a PoolID is possible. Use the Connect-Wait method to wait for a specified interval or until all requestors with the same PoolID have finished loading data.
Several alerts identify asynchronous data page processing that might be inefficient so that you can identify code that can be modified to improve performance.
Running a Connector in the Background using Run-In-Parallel and Connect-Wait
Most connector rules can run in parallel by invoking the connectors from an activity using the Connect-* methods with the RunInParallel option selected. When the run-in-parallel option is selected, a connector runs as a child requestor. The calling activity continues the execution of subsequent steps. Use the Connect-Wait method to join the current requestor session with the child requestor sessions.
Less commonly-used approaches to asynchronous integration
Less commonly used asynchronous integration approaches include:
- Asynchronous service processing
- Asynchronous connector processing
Asynchronous service processing
Most service types support asynchronous processing. Email and JSR94 Services are exceptions. The service types that support asynchronous processing leverage the standard agent queue. These service rules can be configured to run asynchronously or to perform the request asynchronously after the initial attempt to invoke the service synchronously fails. A queue item ID that identifies the queued request is returned to the calling application in both cases. This item ID corresponds to the queued item that records the information and state of the queued request. Once the service request is queued, the ProcessServiceQueue agent in the Pega-IntSvcs ruleset processes the item queued and invokes the service. The service request results are stored in the instance, and the service request is kept in the queue until the results are retrieved.
In the meantime, the calling application that initiated the service request stores the queue item ID and continues its execution. In most cases, the calling application calls back later with the queue item ID to retrieve the queued service request results. The standard activity @baseclass.GetExecutionRequest is used as a service activity by the service to retrieve the queued service.
When configuring this option for the service, a service request processor that determines the queuing and dequeuing options must be created. The ProcessServiceQueue agent uses this information for supporting information to perform the tasks.
Asynchronous connector processing
Several connector rules offer an asynchronous execution mode through the queue functionality similar to asynchronous services. When leveraging this capability, the connector request is stored in a queued item for the ProcessConnectQueue agent in the Pega-IntSvcs ruleset to make the call to the service later. The queued connector operates in a fire-and-forget style. This means that there is no response immediately available from the connector. Before choosing to use this asynchronous processing mechanism, assess whether the fire-and-forget style suits your requirements.
A connector request processor must also be configured for the asynchronous mode of operation. This configuration is similar to an asynchronous service configuration, with the difference being the class of the queued object.
This Topic is available in the following Module:
Want to help us improve this content?