The ‘workflow app connection’, which launches another Apps in the middle of a case, is used in cases where you want to link workflow Apps together, such as a ‘Quotation App’ to an ‘Order Application App’, or a ‘Delivery Work App’ to a ‘Billing Work App’. In addition, if some tasks, e.g. translation work or a legal review, are defined as independent Apps, you can incorporate workflow Apps 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 case from the upstream app case.
This article describes how to build a Sub-App 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-App Mid-Flow and Standing by for a Response)
Defining Sub-Apps
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 App is called a ‘Sub-App’. Many Sub-Apps require a mechanism to return the business data of the resulting work (deliverable: translation text in the case of translation work) to the calling case.
This article describes how to set up a child App to not only automatically invoke the child App, but also to wait for the completion of the child case to return the business data of the child case’s work results to the parent case, 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’ Step, the app in the delivery department is activated and the shipping case 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 case. The Sub-App is positioned as a shipping operation at the distribution centre, corresponding to the orders received at each branch office.
In this article, the case of the ‘Ordering App’ (Sales Department), which is the calling side, is referred to as the ‘Parent case’ and the Case of the ‘Shipping App’ (Shipping Department), which is the called side, as the ‘Child Case’.
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 App is defined so that processing proceeds after receiving the results of the Sub-App, the [Wait for child Caseto finish] option in the [Service Task (Start Child Case)] is used.
[Wait for Started Child Case to finish] Option.
If the option [P2: Wait for Started Child Case to finish] in the Values received from the Child Case tab of the [Service Task (Start Child Case)] is enabled, the following behaviour is observed.
Stays until the end of the child Case
It holds the token and stalls the flow until the child Case has finished. The parent Casemonitors the initiated child Case and the stall continues until the [state] of the child Case is ‘terminated (or abnormally terminated)’.
Get data from child Case
The parent Case accesses the child Case when it detects that the child Case is finished and retrieves data from the child Case. The data items whose values can be retrieved are limited to those permitted in the child Case’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 Case 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 Case ID | String-type (single line) | q_parent_id | – | Initial value：#{parentProcessInstanceId} |
- The EL expression set as the initial value for the Data Item ‘Caller Case ID’ sets the [Parent Case ID].
- A Case initiated by an HTTP request from Questetra BPM Suite can refer to the Case ID of the calling parent Case 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 Case ID | |
The settings up to this point are the same as in the splittings apps chapter.
This time, set [Data Visibility from Parent Case] 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 Case] tab of the parent app’s [Service Task ( Start Child Case)] 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 Case 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 Case of the Shipping Department’s Shipping App is terminated. In addition, add a Data Item to store the [Case ID] of the initiated child Case.
| Data Item Name | Data Type | Field Name | Required | Description |
| Receipt | File-type | q_receipt | – | (Child Case deliverables) |
| Child Case ID | String-type (single line) | q_SubCase_ID | – | (Retrieved at the start of the child Case) |
- 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 Case)])
The setting items in the [Values passed to child Cases] tab are set in the same way as in the Splitting Apps chapter. This setting represents ‘invoking the child Case.’
| 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 ChildCase] tab, switch on the option [P2: Wait for Started Child Case to finish]. This setting represents `waiting for the completion of the child Case.’ The Data Items of the child Cases 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 Case’s work results to the parent Case.’
| Item Name | Setting Details |
| P1: Data item to save Started Child Case Id | (Select) Child Case ID |
| P2: Wait for Started Child Case 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-App, waiting for the completion of the Sub-App, and receiving the deliverable of the Sub-App is complete.
Once this has been set up, try executing [Debug only this node] in the Delivery Request App. When this is executed, a child Case will be started as a debugging Case in the Shipping App. This time, execute all the steps in the child Case. 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 Case is completed when the file is attached and the “2. Delivery Confirmation” step is finished.
Check the details of the Case in the Order Accepting app where [Debug only this node] was executed. As the parent Case is also terminated with the termination of the child Case, find the relevant Case in the [All Cases] list. You will see that the file attached to the Data Item Receipt on the detail screen is stored.
- In the Child Case Details screen, the Parent Case ID is linked instead of the [Case Start User]
- You can also open the details of a child Case from the [All Cases] list and open the parent Case from the link above
A [Service Task (Start Child Case)] step is complete when a series of Steps have all been successfully completed. In this article, the series of Steps is from the start of the Sub-App (child Case) to the point where the Sub-App finishes and receives data.
If any defects occur in a series of Steps, the [Service Task (Child Case)] step will be terminated with an error. Examples of faults are when an error occurs in data transfer, or when a child Case does not terminate normally due to [Forced termination] or [Deletion].
If the Case 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 Step settings.
There may be cases where you want to split the processing after an Error Termination according to whether a child Case has started or not. Specify the presence or absence of a value stored in the Data Item that stores the ID of the child Case that started as a branching condition and allow the flow to branch.
When defining the processing when a Sub-App becomes an error, design the flow beyond the [Error boundary event] based on the above.
Appendix
When receiving data from a child Case in a [Service Task (Start Child Case)], the flow of the parent Case does not proceed until the child Case is terminated.
For example, if you want to proceed with other tasks before the translation is completed, consider parallel branching.
