Skip to main content
Verify the version tags to ensure you are consuming the intended content or, complete the latest version.

Asynchronous integration 

Pega Platform™ provides multiple mechanisms to perform processing asynchronously. For example, an application can 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 processing time of the external system might be an issue.
  • 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 the run mode is configured as synchronous (immediate), then the request is handled and processed in the single requester context immediately. 
  • If the run 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 two methods:

  • Load-DataPage method
  • Run-In-Parallel option with the Connect-Wait method.

Load-DataPage

The system loads data pages 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 Connect-Wait step method.

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, you can preload the data page by 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 to modify to improve performance.

Note: Data pages loading asynchronously cannot run declarative expressions, triggers, and other rules that belong to a declarative network.

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. With Run-In-Parallel, 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.

Note: If you configure several connectors to run in parallel, ensure the response data is mapped to separate clipboard pages and that error handling is set up.

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 use 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. In both cases, a queue item ID that identifies the queued request is returned to the calling application. 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 as 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 using 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, which 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.

You also configure a connector request processor 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.

Check your knowledge with the following interaction: 

This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Yes
No

Want to help us improve this content?
Suggest an edit

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice