Sub-Process Vs Start Process

In Appian, sub-processes are like smaller, specialized workflows within a larger process. They help organize and manage complex logic by breaking down the application flow into manageable parts. Using sub-processes is a recommended best practice because it makes the application easier to maintain and understand.

However, before you implement sub-processes, there are a few things to consider. It’s essential to understand the sub-process node and the start process smart service. These are two key components in Appian that control how and when sub-processes are triggered.

• Sub-process Node: This is a part of the process model that calls another process. It’s useful when you need to reuse a specific set of actions across different parts of your application.
• Start Process Smart Service: This service initiates a new process instance, allowing for more flexibility in when and how processes are started.

The architecture behind sub-processes involves understanding these components and knowing when to use each based on the specific use case. By leveraging sub-processes effectively, you can build applications that are more modular, scalable, and easier to debug.

Generally, we Have two types of processes:

1. Asynchronous Processes: The parent process does not wait for the child process to complete, and data cannot be passed back from the child process.
2. Synchronous Processes: The parent process waits for the child process to finish, allowing data to be passed back from the child process.

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 writing the data to the database(Write Records), and kicking off tasks. This node is best used for synchronous processes where the remaining nodes after the child process depend 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.

Let’s say you have a process that runs every morning to send a custom email to users who have overdue tasks. If we have 1000 users, in the worst case, we can potentially be loading 1000 processes onto one execution engine. This will lead to performance issues for the environment.
Hence we Need to Have a Process time-based escalation so it’s not Coming in the Category of a running process.

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 is 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.

Here’s a detailed summary of the comparison between the Sub-Process and Start Process in Appian:

Sub-Process

• Process Type:
• Supports both Synchronous and Asynchronous processes.
• Synchronous: Parent process waits for the child process completion and data can be passed back.
• Asynchronous: The parent process does not wait for the child process completion and no data is returned.
• Node Instances:
• Allows for multiple node instances (MNI), enabling the initiation of multiple concurrent instances[instanceindex] of the sub-process.
• Engine Load:
• All processes initiated by the Sub-Process node are handled by the same engine[Execution Engine]. This means they are not distributed but rather processed by a single engine.

Start Process

• Process Type:
• Only supports Asynchronous processes. The parent process does not wait for the child process to finish, and data cannot be returned from the child process.
• Node Instances:
• Allows for multiple node instances as well, enabling multiple concurrent initiations of the process.
• Engine Load:
• Processes are distributed using built-in load balancing. This means that the workload is evenly distributed across different engines, optimizing resource utilization and performance.

Choosing Between Sub-Process and Start Process

When deciding which method to use, consider the following questions:

1. Do I need data back from this process?

• If yes, use Sub-Process (Synchronous), as it allows data to be returned[pv!processInfo].
• If No, either method can be used, but Start Process (Asynchronous) may be preferable for load balancing.

1. Do I need to kick off multiple processes?

• If multiple processes are required, both methods can be used, but Start Process (Asynchronous) offers better load distribution.

1. How many processes might be started in the worst case?

• For large numbers of processes, Start Process (Asynchronous) with load balancing might be more efficient to avoid overloading a single engine.

This approach helps in determining the best method based on the specific requirements of your process.

Have a Good Day.

Please Share with Your Friend if You are liking Our Content.