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).
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.
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.
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.
***Edited by Moderator Marissa to update Platform Capability tags****
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 :
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.
Change the Processing mode to "Stateful" in Service Package.