How to call a child activity asynchronously

Hi,

If you call a child activity from an activity, it is executed synchronously in general - that means, the parent activity waits for the child activity to end, and then moves down to the next step. Sometimes you may want to move forward without waiting for the child activity completion. For example, external system sends a REST request to Pega, and then Pega triggers a Service Activity that calls a number of child activities. Each child activity is heavy and you want to return HTTP status code without having to wait for all the child activities to end. In this case you can consider calling an activity asynchronously (a.k.a. “fire-and-forget” style).

  • Approaches

No

Approach

Description

Note

1

Queue method

At runtime, system uses Batch requestor. This is shared with Agent and other developer’s Queue method usage, if any. The default of Java thread pool size is 5. In the PegaRULES log, it is recorded as “PegaRULES-Batch-X” where X is 1 to 5.

You can raise the number of Java thread pool size from 5. If your child activity is heavy, the occupancy time gets longer and it is advised to increase the number. You can do so by creating a Dynamic System Settings as below.

Owning Ruleset: Pega-Engine

Setting Purpose: prconfig/agent/threadpoolsize/default

2

Call-Async-Activity method

As the name implies, it is possible to call an activity asynchronously using this method, but if you use it within a REST Service Activity, it may get unstable. If your settings of processing mode in a Service Package is “Stateless”, the queue information on memory gets deleted and execution of the child activity is not guaranteed. Java thread pool that is used is different from Batch requestor. In the PegaRULES log, it is recorded as “Async-Services-X”.

I’ve verified that when I change the processing mode in a Service Package from “Stateless” to “Stateful”, all the child activities are called. If this is “Stateless”, some of the child activities were called, but others were not. However, it is not standard to select “Stateful” for a REST Service.

3

Queue-For-Processing method

This approach uses Kafka for queue processing. Compared to above legacy two approaches, this is the new standard.

This method is available from Pega 8, and now it's our recommendation (*).
  • My customer started their implementation with No.2 approach and noticed execution of child activities is unstable. Per our investigation, we figured that the queue gets deleted randomly if the processing mode is “Stateless”. We did not want to change the processing mode, so we discussed pros and cons of No.1 and No.3 approach and decided to go with No.1. Kafka is a high-performance distributed streaming platform but if you have any concern about its stability in your environment, you can also choose Queue method.

Thanks,

@KenshoTsuchihashi Hope option#2 been reported; did we do any research why such deletions are happening. Thanks for sharing.

@ManiM

Yes, this issue was originally reported to me from my customer and I’ve raised an SR (INC-179303). Please see below for GCS’s analysis by @eppik :

Root cause:

For stateless REST invocations the Requestor is immediately returned back to the requestor pool. In the process of this returning all the information related to that requestor even the async tasks are cleared off from queue even before they could be executed. So given the small time frame before the cleanup kick in, only a few of the async activities are able to execute, rest get cleared up.

Solution:

  1. Change the Processing mode to “Stateful” in Service Package.
  2. Assign a POOL ID to all the Async calls and use a Connect-wait for the POOL ID to complete executions(Pegasystems Documentation).
  3. You can also use Queue or Queue-For-Processing methods if the operations being performed in Async activities are huge or time taking as Call-Async-Activity is designed for simple operations like Data Page loading(Pegasystems Documentation).

Thanks,

@KenshoTsuchihashi very informative. Thank you.

@KenshoTsuchihashi Thanks for the article, If I am not using a service activity then can i use call-async-activity method ?

Also the link for call-async-activity method says to use only for load-datapage method but Load-Datatpage method itself loads the Dpage in a background so what is the benefit of calling call-async-activity method instead?

@KenshoTsuchihashi: we are discussing on Choosing the option 1 as currently we faced issue with Option 3 Queue processors. With large load the nodes went down. Could you please explain how queue method is more stable? It was mentioned by you here

so we discussed pros and cons of No.1 and No.3 approach and decided to go with No.1. Kafka is a high-performance distributed streaming platform but if you have any concern about its stability in your environment, you can also choose Queue method.