Async Start Process smart service queries

If I remember correctly, the main reason to use the old Start Process smart service was to allow the sub-process to be asynchronously load balanced to another execution engine. There were ways to get activity chaining working, but they weren't well documented.

Could you please clarify a few things for us?

• Is the desired outcome to have an existing sub-process be called asynchronously or synchronously? If async - why?
• Does the sub-process have a user input task that is activity chained into?
• Is the parent process called from an API or a user-facing interface?
• Are you using the Start Process smart service or the Sub-Process node?

It is possible that you might need to re-make the node with these activity chaining considerations. An execution engine will not follow an async sub-process's chain when started with the Start Process smart service.

I'm not sure what you're asking exactly.

To clarify, the ONLY setting for the Start Process NODE originally was ASYNCHRONOUS.  Meaning when the parent process reached that node, an asynchronous instance of the child process would be launched and run (on a distributed execution engine when relevant) and the parent process would move on instantly.  Chaining did not play into this whatsoever.

If you're referring to the Start Process FUNCTION, however, that's different.  The old behavior (and continued behavior of the "old version" of the function, which can still optionally be used), was that the launched process would execute in a synchronous style, following activity chaining until the first break, and then execute the "completion saves".

If you want more accurate answers though, i'm afraid you'll need to specify which thing you're referring to, because you're using terms interchangeably for two different things that have different behaviors and different configurations.

Asynchronous Start Process runs asynchronously even with subprocess activity chaining.
Subprocess chaining only affects its own internal node execution; It doesn't block the parent, which continues immediately.
Use Synchronous Start Process or Sub-Process node to wait for completion.

But in our scenario, Asynchronous Start process running synchronous which we have validated in the Process nodes execution time. Reason behind it looks like due to child process is activity chained.

Understood! Parent process activity chaining through the Async Start Process node executes child's chained nodes before resuming, mimicking sync.
Disable Activity Chaining on the parent's Start Process node for true async.

We have disabled activity chaining before the Start process node already for parent process, but child process has activity chaining due to it is reused by other process we dont want to remove.

We were able to resolve the issue by switching to the Asynchronous Sub‑Process smart service. However, the question remains: Why does the Async Start Process smart service not behave in the same non-blocking manner?

Shantanu Bhowmick said:

Why does the Async Start Process smart service not behave in the same non-blocking manner?

It might be due to activity chaining across process boundaries.
Async Start Process launches a separate process instance (load-balanced), so parent chaining extends into child's initial unattended nodes before resuming; causing observed block.
Async Sub-Process runs in the same instance (same engine), with no boundary crossing parent resumes instantly.

Shantanu Bhowmick said:

Although this smart service is configured as Asynchronous, it still takes around 10 seconds to complete because it appears to wait for the child process to finish execution.

That's a valid point - if this is true I expect you're experiencing the legacy functionality similar to how the original Function version of Start Process would wait for internal chaining to complete.  I'm not clear whether this is the current expected behavior according to Appian or a legacy corner case.

An easier workaround than just reverting to "Legacy Subprocess" nodes (which Appian seems to be moving away from) might be to pass in an optional value to the child process to indicate instances where it should execute asynchronously, and in those cases, break chaining (i.e. a dedicated output of an XOR gateway where the chain is intentionally broken). 

At the same time, you might raise this issue with Appian to see whether it is really still the intended behavior even with the newest Start Process nodes.  (But if possible, you might consider double-checking first, and using a brand new copy of the Start Process node configured with the same child process, to see whether the behavior persists (just to make sure you're not accidentally using a more "legacy" version than you assume).