In the Splitting Apps and Sub-process sections, we explained how to invoke a child app using [Service Task (Start Child Process)] and how to return the results in the child app to the parent app. In the child App invoked from the parent App, the flow was advanced by the person in charge of handling the human task.

In this case, we consider the case where a sub-process consists only of automated steps. Suppose you have a child app which consists only of automated steps, and you call them from the parent App. In this case, you would only need to set up one step in the parent App that calls the child App, and the process in the child App would be incorporated into the parent App’s process. For example, let’s say there is an App that works with the storage service Box to create a folder, upload a file and notify the file download URL, which consists of only automated steps (transferring the file via Box). When this App is called and the series of steps is executed, the invoking step on the calling side can be considered that one automatic step that transfers the file via Box has been executed. In this way, you can easily incorporate automatic processes that transfer files to various operations (apps) simply by setting up a step that calls the child app.

This article explains how to create and use sub-processes consisting solely of automated steps, as well as their significance and benefits.

What are Automated Sub-Processes?

[Service Task (Start Child Process)] is an automated step that invokes the targeted child App to start a process.

If the child App has only one automated step, then what is processed is the same, like in the two cases shown below. This means that in the parent App, [Service Task (Child Process Start)] (“Box upload app calling process” in the diagram below) has the same meaning as the automated step in the child App.

So what if the child app consists of several consecutive automated steps?

In this case, too, the result of the process will be the same between the stand-alone workflow App and the combination of parent and child Apps. Furthermore, the parent App that invokes the child App is no different from the earlier child App with only one automated step. This parent App’s [Service Task (Start Child Process)] plays the role of incorporating a series of steps from the child App into the workflow with only one step.

In this way, if a sub-process (child App) consists solely of automated step, the content of the sub-process can be replaced by placing a single [Service task (Start Child Process)] step in the parent App. A sub-process that consists solely of automated steps is referred to as an [Automated Sub-Process].

Questetra provides single-function automated processes such as [Create] and [Get] for various web services. By creating Automated Sub-Processes that combine them, more advanced automated processes can be defined.

Incidentally, the series of steps in the child App in the diagram above are for passing files to the recipient of an email via Box. In other words, in the parent App, the [Service Task (Start Child Process)] that calls this child App can be regarded as an icon for the automatic process of delivering files via Box.

On the other hand, if the series of steps includes a [Human Task], the next step will not proceed until the person in charge of handling the Human Task has completed it. A distinction is made between [automated sub-processes], which consist solely of automated steps, and [sub-processes] that contain Human Tasks.

Benefits of Automated Sub-Processes

Consider the benefits of creating and operating an sub-process consisting solely of automated steps.

Workflow diagrams can be organised
Even multiple automated processes can be called from a single step in the parent App if they are organised into sub-processes. This means that the workflow diagram in the parent App is tidier and easier to navigate.

Can be created with no code
In [Script Tasks], you can write scripts that perform the same function as with a combination of automated steps. However, this requires a high level of programming skill: the various automated steps offered in Questetra allow you to define sub-processes with no code.

Easy to install
If no sub-processes are provided, the same settings have to be made individually for several Apps that perform similar functions. If sub-processes are provided, the creation/editing of Apps is simplified because you only need to place the step that calls them.

Can be called up from various departments/Apps.
Initiation from a [Message Start Event (HTTP)] is not affected by the Operator settings or organisational structure. It can be called from any App on the same workflow platform.

Let the child App have the add-on definition (Add-on.xml) when using automated add-on steps
An automated add-on step can also be placed in a sub-process. When deploying the same add-on in multiple Apps, add-on definition files must be registered in [App shared add-ons], but there is a limit to the maximum number of add-ons that can be registered. By placing an add-on definition file in a sub-process App, the add-on can be used in multiple Apps without consuming one of these registrations.
In addition, although maintenance is required for the automated add-on step, this saves time and effort compared to registering add-on definition files in individual Apps.

Create Automated Sub-Processes

Create an automated sub-process with reference to the Apps described in Using Box to Send Files to People Outside the Company.

The main difference from the reference App is that the [Start Event] is replaced by a [Message Start Event (HTTP)] and there is no [Human Task] following it.
The Human Task in the reference App, replaced by the input in the File Attachment Step, receives the necessary data in the [Message Start Event (HTTP)].

Data Item Name	File Attachment Step (Reference Apps)	Message Start Event (HTTP) [Editing permitted]
Title	Editable
ID of the folder to be shared	No display
Shared Link URL	No display
Shared Files	Editable
Apply Watermark	Editable
Shared Address	Editable
Mail Subject	Editable
Email Body	Editable

I wrote that it can be set up exactly the same as the reference App and there are no problems as far as operation is concerned. However, as a sub-process that is called from various Apps/departments, it needs to be more versatile.

For example, in the reference App, the downloadable period (number of days the timer waits) is fixed at 3 days.
#now.addDays(3)
Expression that adds a [numeric type] item to a data item and refers to its value.
#now.addDays(#q_shareDays)
to dynamically determine the sharing period according to the specification in the parent process.
In addition, data [initial value] (set to the [email body] in the reference App), for example, should be set in the parent App, so as not to narrow the versatility of the sub-process.

Set up Automated Sub-Processes to be Called

To call a sub-process, place a [Service Task (Start Child Process)]. If the [Wait for child process to finish] option in [Service Task (Start Child Process)] is unchecked, the flow of the parent App and the child App will behave as if they are concurrent processes.

In the data item settings, prepare the items for passing values to the sub-process. When receiving the results of a sub-process, also prepare an item to store the received values.

For example, suppose that an App that sends attached files using a [Throwing Message Intermediate Event (email)] is in operation. If the business rule is changed to discontinue sending files via email attachments and switch to sharing via Box, the change can be handled by deleting the [Throwing Message Intermediate Event (email)] and replacing it with a [Service Task (Start Child Process)] that calls the sub-process created above.

In the [Values to be passed to the Child process] tab of the [Service Task (Start Child Process)], select and specify values using the previous data item settings, such as the destination address. On the other hand, data items that have not been set before, such as Select-type data with/without applying a watermark or Numeric-type data for the number of days on hold, are specified by adding new data items.