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


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.

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.

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

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.

Note: If you configure several connectors to run in parallel, ensure the response data is mapped to separate clipboard pages, and 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 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.

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:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

67% found this content useful

Want to help us improve this content?

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