Skip to main content

Asynchronous integration 

Pega Platform™ offers several mechanisms for asynchronous processing. For example, an application can call a back-end system and continue processing without blocking the process and waiting for a response from the external system. This approach is useful when:

  • The processing duration of the external system is a concern.
  • The result of the processing is not immediately required.

A similar feature is 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), the request is handled and processed immediately in the single requester context.
  • If the run mode is configured as asynchronous (queue for a run), the request is added to the queue and processed later.
     

Commonly-used approaches for asynchronous integration

Two commonly used asynchronous approaches are:

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

Use the Call-Async-Activity method to load data pages asynchronously (into background threads) to allow other processing to continue. 
To run an activity asynchronously, set usage on the activity’s security tab to “Asynchronous". Asynchronous activities can make a call to the Load-DataPage method and Connect-wait method. Use the Load-DataPage method to load a data page in a background thread, and then pause for the Data Page to load by using the Connect-Wait step method. For more information, see Call-Async-Activity. 

If a slow-running connector is used to source a Data Page, you can preload the Data Page using the Load-DataPage method in an Activity to ensure that the data is available without delay when needed. You can group several Load-DataPage requestors by specifying a PoolID. Apply the Connect-Wait method to pause for a specified interval or until all requestors with the same PoolID have finished loading data. Several alerts might identify inefficient asynchronous Data Page processing, enabling you to identify code that needs modification 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 operate simultaneously by invoking them from an Activity using the Connect-* methods, with the RunInParallel option selected. With Run-In-Parallel, a connector operates as a child requestor, and the calling Activity continues running subsequent Steps. Apply 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 that 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, apart from Email and JSR94 Services. Service Types that support asynchronous processing use the standard Agent Queue. These Service Rules can be set to run asynchronously or to carry out the request asynchronously if the initial attempt to invoke the Service fails. In both scenarios, a Queue Item ID that identifies the queued request is given back to the calling Application. This Item ID corresponds to the queued item that logs the information and state of the queued request. When the Service Request is queued, the ProcessServiceQueue Agent in the Pega-IntSvcs Ruleset handles the queued item and invokes the Service. The Service Request results are stored in the Instance, and the Service Request stays in the Queue until the results are obtained.

Meanwhile, the calling Application that initiated the Service Request stores the Queue Item ID and proceeds with its run. In most scenarios, the calling Application calls back later with the Queue Item ID to obtain the queued Service Request results. The standard Activity @baseclass.GetExecutionRequest is employed as a Service Activity to retrieve the queued Service.

When you set up this option for the Service, a Service Request Processor that determines the queuing and dequeuing options needs to be established. The ProcessServiceQueue Agent uses this information as supporting data to perform its duties.

Asynchronous connector processing

Numerous Connector Rules offer an asynchronous run mode through the Queue functionality, similar to asynchronous services. When using this feature, the Connector Request is stored in a queued item for the ProcessConnectQueue Agent in the Pega-IntSvcs Ruleset to initiate the call to the Service later. The queued Connector operates in a fire-and-forget style, which implies that no immediate response is available from the Connector. Before choosing to use this asynchronous processing mechanism, evaluate if the fire-and-forget style meets your needs.
You can also set up a Connector Request Processor for the asynchronous mode of operation. This setup resembles configuring an asynchronous Service, with the distinction 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