Using Subprocesses in APIs

Subprocesses allow you to move some of the integration logic into reusable components. These Subprocesses can be used by multiple Processes. This is also true for Processes linked to API Endpoints. Using Subprocesses you can move common functions out of the Linked Process and only implement parts of the functionality into Linked Process which is unique for that particular Endpoint.

Another useful case for Subprocesses is move of Process execution to another Agent Group. This Subprocess call is called Remote Subprocess. This allows you to host your API in one Agent Group while executing some of the functionalities in another Agent Group.

Next we will look at couple of use cases for both of these scenarios.

Let's say you have two different API Endpoints for fetching customers from a database. From first API Endpoint you can fetch all customers. From second and API Endpoint you can get a customer with a specific ID. Both of these API Endpoints will be fetching the same data, but the second one returns only one customer. We can implement all of the logic to both Processes which will be linked to the API Endpoints, but it would be better to implement a Subprocess in which you can implement the actual fetching of data. You can parametrize the Subprocess so that you can pass the customers ID to the Subprocess or you don't pass anything to the Subprocess. This way you can implement logic to support to different queries: one for fetching all customers and one for fetching only one customer using the customers ID. You can then attach this Subprocess to both Linked Processes. This way you don't have to implement same functionality twice.

After you have released an API you shouldn't modify it, but rather create a new version of the API with modifications or new features. This way users can keep using the old version of the API and switch to new version once it has been released. In Frends this means that you need to copy the existing OpenAPI Specification to a new OpenAPI Specification with different version. This is easy to do for the Specification, but you cannot attach existing Linked Processes to the new Specification, since one API Trigger can only be linked to a one OpenAPI Specification. To add functionality to the new version of the Specification we need to create new Linked Processes. Subprocesses are a useful tool for this situation. You can transform the logic of the older version's Linked Process into a Subprocess which you can then call in the old Linked Process. Then in the new Linked Process you can call the same Subprocess and then build on top of that in the Linked Process itself. This way you don't have to implement and maintain two Linked Processes with same functionality, but you can use one Subprocess to implement same functionality to multiple API versions.

Let's say that you want to create an API from which users can fetch data through the API from your database. The database is protected by a firewall and only a specific Agent can access the database. Normally this would mean that you have to host the API in that specific Agent so Linked Processes can execute queries to the database. However often this is not an option, since this would require granting access from public web to the Agent. To solve this problem we can host the API in another Agent and execute database queries using the Agent which has access to the database. Remote Subprocesses can be used to implement this, since they allow splitting execution of a Process to multiple different Agents. Requirement for this solution is that the Agent Group in which the API will be hosted and the Agent Group which contains the Agent which has access to the database have to be in the same Environment, since you cannot split execution of Process steps between different Environments, only between Agent Groups which exist in the same Environment.

The next article is Introduction to Writing API Specification.