Sub-processes in Appian are a great way to break up logic and structure your application flows. It is best practice to implement subprocesses in your Appian applications. But, there are some things to consider before implementing sub-processes.
In this post, we will review the sub-process node and the start process smart service. We will take a deep dive on the use cases for both and discuss the architecture behind each.
Types of Processes
Before diving into the technical details of the differences it is important to understand the types of processes in the context of Appian. There are two types of processes, asynchronous and synchronous processes.
Asynchronous
This type of process means that the parent process does not wait for the child process to finish. This means the data cannot be passed back from the child process.
Synchronous
This type of process mean that the parent process DOES wait for the child process to finish. This means the data can be passed back from the child processes.
When to use Sub-Process Node
The sub-process node allows you to start a child process from a parent process. This is useful when you need to encapsulate logic not related to the parent process. Some examples are sending email notifications, writing the data to the database, and kicking off tasks. This node is best used for synchronous processes where the remaining nodes after the child process depends on the data that is returned.
Potential Issues with the Sub-Process Node
The sub-process node can also be used for asynchronous processes as well. It is generally okay to use for most cases.
However, issues may arise when you kick off multiple node instances (MNI) for asynchronous processes. Why? Processes that are initiated with this node are loaded on the same execution engine. This means that there is the potential for a large amount of processes to be loaded on one engine which could lead to performance degradation.
Lets say you have a process that runs every morning to send a custom email to users who have overdue tasks. If we have 500 users, in the worst case, we can potentially be loading 500 processes onto one execution engine. This will lead to performance issues for the environment.
Start Process Smart Service
In the case detailed above, this is where the Start Process smart service is useful. This smart service allows a parent process to start asynchronous processes just like the sub-process node but, one of the differences are that the start process node allows for built in load balancing for the execution engines.
This means that the processes will not be loaded on one single engine but will be evenly distributed among all engines. By doing this, the environment is less likely to experience performance issues.
There is a limitation with this smart service. Start process does not allow for synchronous processes.
Side by Side Comparison
A quick look at the main differences are the following:
Sub-Process
- Allows for Synchronous and Asynchronous Processes
- Allows for multiple node instances (MNI)
- All processes started by this node will be loaded on the same engine
Start Process
- Allows for only Asynchronous
- Allows for multiple node instances
- All processes started by this node will use the built in load balancing and be evenly distributed to the engines
Ultimately it is up to the developer to decide which method to use depending on the requirements for the process. The rule of thumb I use for choosing which services to use are the following.
- Do I need the data back from this process?
- Do I need to kick off multiple processes?
- If so, how many in the worst case?
By asking yourself these three questions you can lay out the path on which way to implement the spawning of child processes.
If you found this useful or learned something new, let us know in the comments! Let us know if we missed anything or if you consider other things when choosing between the two.
