The ‘workflow app connection’, which launches another app’s in the middle of a process, is used in cases where you want to link business processes together, such as a ‘Quotation Process’ to an ‘Order Application Process’, or a ‘Delivery Work Process’ to a ‘Billing Work Process’. In addition, if some tasks, e.g. translation work or a legal review, are defined as independent apps, you can incorporate sub-processed business processes into the workflow simply by setting up the app to invoke them.
The Splitting Apps chapter explained how to set up an app that spans multiple departments, splitting the app by department and starting the downstream app process from the upstream app process.
This article describes how to build a sub-process that starts a child app from the parent app and waits for the child app to be completed then receive business data from the child app afterward.
(Reference M413: Settings: Calling a Sub-process Mid-Flow and Standing by for a Response)
Defining Sub-Processes
In many cases, work such as translating text or creating graphic designs is required in the middle of various tasks. If such tasks are defined in a simple workflow app for simple work requests, they can be carried out in response to requests from various departments.
The mechanism by which a workflow app is invoked and integrated as part of the business process is called a ‘sub-process’. Many sub-processes require a mechanism to return the business data of the resulting work (deliverable: translation text in the case of translation work) to the calling process.
This article describes how to set up a child process to not only automatically invoke the child process, but also to wait for the completion of the child process to return the business data of the child process’s work results to the parent process, based on the Order – Shipping – Billing Flow example from the Splitting Apps chapter.
Specifically, it is designed so that when the sales department supervisor approves the ‘2. Order confirmation’ process, the app in the delivery department is activated and the shipping process begins. In this case, the assumption is that the delivery completion is reported by passing the image file of the receipt upon completion of the delivery to the sales department’s order process. The sub-process is positioned as a shipping operation at the distribution centre, corresponding to the orders received at each branch office.
In this article, the process of the ‘Ordering App’ (Sales Department), which is the calling side, is referred to as the ‘Parent Process’ and the process of the ‘Shipping App’ (Shipping Department), which is the called side, as the ‘Child Process’.
Items Used for Workflow App Connections
Use the same items as those used in Linking and Operating Multiple Workflow Apps – Splitting Apps Edition. However, this time, as the process is defined so that processing proceeds after receiving the results of the sub-process, the [Wait for child process to finish] option in the [Service Task (Child Process Start)] is used.
[Wait for Started Child Process to finish] Option.
If the option [P2: Wait for Started Child Process to finish] in the Values received from the Child Process tab of the [Service Task (Start Child Process)] is enabled, the following behaviour is observed.
Stays until the end of the child process
It holds the token and stalls the flow until the child process has finished. The parent process monitors the initiated child process and the stall continues until the [state] of the child process is ‘terminated (or abnormally terminated)’.
Get data from child process
The parent process accesses the child process when it detects that the child process is finished and retrieves data from the child process. The data items whose values can be retrieved are limited to those permitted in the child process’s app settings.
Sample App
‘Shipping App’ of the Delivery Department (the one being called)
Similar to the procedure in the previous article, first create the ‘Shipping App’ (child process side) of the Delivery Department.
Place the [Message Start Event (HTTP)] at the top and set the Data Items that receive and save data from the Sales Department’s Order Accepting App to [
Editable] in the properties screen.
Data Items
| Data Item Name | Data Type | Field Name | Required | Description |
| Title | – | – | – | |
| Shipping Address Name | String-type (single line) | q_delivery_name | – | |
| Shipping Address | String-type (multiple lines) | q_delivery_address | – | |
| Shipping Details | Table-type | q_item_list | – | |
| Receipt | File-type | q_receipt | ✓ | |
| Caller Process ID | String-type (single line) | q_parent_id | – | Initial value：#{parentProcessInstanceId} |
- The EL expression set as the initial value for the Data Item ‘Caller Process ID’ sets the [Parent Process ID].
- A process initiated by an HTTP request from Questetra BPM Suite can refer to the Process ID of the calling parent process as the system variable [parentProcessInstanceId]
Shipping Start ([Message start event (HTTP)])
| Data Item Name | Editing Permission |
| Title |  |
| Shipping Address Name | |
| Shipping Details | |
| Shipping Address | |
| Receipt |  |
| Calling Process ID | |
The settings up to this point are the same as in the splittings apps chapter.
This time, set [Data Visibility from Parent Process] in the [Message Start Event (HTTP)] configuration screen. Click the button to open the settings screen and set [Allow] only for [Receipt]. The items set to [Allow] here will be added to the setting items in the [Values received from child process] tab of the parent app’s [Service Task ( Start Child Process)] settings screen.
When the settings are complete, close the edit screen and release the app. Check the [App ID] (m number) and [App name] at the top of the screen.
Sales department’s ‘Order Accepting App’ (caller)
Edit the Sales Department’s Order Accepting App (parent process side), which was created in the previous article.
Connect by installing an icon that calls the Shipping Department’s Shipping App from the palette Auto-Processing Tasks > Connecting with other workflow apps on the edit screen. If it is placed before the previously installed Billing Request step, the bill will be sent once the delivery has been confirmed. If it is placed behind, it will be dispatched once the payment has been confirmed.
Data Items (additional).
Add a Data Item to receive and save the [Receipt] file when the process of the Shipping Department’s Shipping App is terminated. In addition, add a Data Item to store the [Process ID] of the initiated child process.
| Data Item Name | Data Type | Field Name | Required | Description |
| Receipt | File-type | q_receipt | – | (Child process deliverables) |
| Child Process ID | String-type (single line) | q_Subprocess_ID | – | (Retrieved at the start of the child process) |
- Data of other data-types can also be passed on, e.g. String-type data, Datetime-type data, etc.
- The data-type of the Data Item to be saved must be the same
- Discussion-type and Guide Panel-type cannot be passed on
‘Delivery request’ step ([Service Task (Start Child Process)])
The setting items in the [Values passed to child processes] tab are set in the same way as in the Splitting Apps chapter. This setting represents ‘invoking the child process.’
| Item Name | Setting Details |
| At: Title | #{processInstanceTitle} (Select ‘Title’) |
| A0: Shipping Address Name | #{#q_delivery_name} (Select Name of Orderer) |
| A1: Shipping Address | #{#q_delivery_address} (Select Address of Orderer) |
| A5: Shipping Details | Sales Details (Select) |
On the [Values received from the Child process] tab, switch on the option [P2: Wait for Started Child Process to finish]. This setting represents `waiting for the completion of the child process.’ The Data Items of the child processes that can be retrieved are displayed as configuration items, so specify the Data Items to store them. This setting represents the ‘return the business data of the child process’s work results to the parent process.’
| Item Name | Setting Details |
| P1: Data item to save Started Child Process Id | (Select) Child Process ID |
| P2: Wait for Started Child Process to finish | Switch on |
| RT: Title | Not set this time (blank) |
| R3: Receipt | (select) receipt |
With the settings up to this point, the mechanism for calling a sub-process, waiting for the completion of the sub-process, and receiving the deliverable of the sub-process is complete.
Once this has been set up, try executing [Debug only this node] in the Delivery Request process. When this is executed, a child process will be started as a debugging process in the Shipping App. This time, execute all the steps in the child process. In the “2. Delivery confirmation” step, it is assumed that an image of the receipt taken with a smartphone is attached to the File-type data item. The Shipping Process is completed when the file is attached and the “2. Delivery Confirmation” step is finished.
Check the details of the process in the Order Accepting app where [Debug only this node] was executed. As the parent process is also terminated with the termination of the child process, find the relevant process in the [All Processes] list. You will see that the file attached to the Data Item Receipt on the detail screen is stored.
- In the Child Process Details screen, the Parent Process ID is linked instead of the [Process Start User]
- You can also open the details of a child process from the [All Processes] list and open the parent process from the link above
A [Service Task (Start Child Process)] step is complete when a series of processes have all been successfully completed. In this article, the series of processes is from the start of the sub-process (child process) to the point where the sub-process finishes and receives data.
If any defects occur in a series of processes, the [Service Task (Child Process)] step will be terminated with an error. Examples of faults are when an error occurs in data transfer, or when a child process does not terminate normally due to [Forced termination] or [Deletion].
If the process ends in an error, the token can also be advanced to an Error Boundary Event. Activate the option [Token will move to Error Boundary Event when processing fails] in the process settings.
There may be cases where you want to split the process after an Error Termination according to whether a child process has started or not. Specify the presence or absence of a value stored in the Data Item that stores the ID of the child process that started as a branching condition and allow the flow to branch.
When defining the process when a sub-process becomes an error, design the flow beyond the [Error boundary event] based on the above.
Appendix
When receiving data from a child process in a [Service Task (Start Child Process)], the flow of the parent process does not proceed until the child process is terminated.
For example, if you want to proceed with other tasks before the translation is completed, consider parallel branching.
