ケースの途中で他のアプリのケースを起動する「ワークフローアプリ接続」は、「見積アプリ」から「受注申請アプリ」、あるいは「納品業務アプリ」から「請求業務アプリ」など、ワークフローアプリを連携させたい場合に利用されます。また、一部の業務、例えば翻訳作業や法務審査などが独立したアプリとして定義されていれば、そのアプリを呼び出す設定だけでワークフローにサブアプリ化された業務工程を組み込むことができます。
「アプリ分割編」では、複数の部署をまたぐアプリを部署ごとに分割し、上流アプリのケースから下流アプリのケースを開始する設定について説明しました。
本記事では、親ケースから子アプリを起動し、親ケースが子ケースの完了を待ち受けて子ケースから業務データを受け取るという、サブアプリを構築する方法について説明します。
（参考 M413: フロー途中でサブアプリを呼び出し、その処理結果を待つように設定する）
サブアプリを定義する
文章の翻訳作業やグラフィックデザインの作成作業などは、様々な業務の途中で必要とされる場合は少なくありません。このような作業が単純な作業依頼のワークフローアプリとして定義されていれば、様々な部署からの依頼に応じて作業を行うことができます。
ワークフローアプリが呼び出されて業務の一部として組み込まれる仕組みは「サブアプリ」と呼ばれます。多くのサブアプリでは、作業結果（成果物：翻訳作業であれば翻訳文）の業務データを呼び出し元のケースに返す仕組みが必要となります。
本記事では「アプリ分割編」で例に挙げた「受注～発送～請求フロー」を土台に、子アプリを自動で呼び出すだけでなく、子ケースの作業終了を待って作業結果の業務データを親ケースに返すための設定方法について説明します。
具体的には、「営業部上司」が「2. 受注確認」工程で承認すると配送部門のアプリが起動されて発送業務が始まるように設計します。今回は、配送完了時の受領証の画像ファイルを、営業部門の受注業務のケースに受け渡すことで配送の完了を報告するという想定です。サブアプリの位置づけとしては「各支社での受注に対応する、配送センターでの発送業務」と考えられます。
なお、本記事では呼び出す側の「受注業務アプリ」（営業部）のケースを「親ケース」、呼び出される側となる「発送業務アプリ」（配送部）のケースを「子ケース」と呼ぶこととします。
ワークフローアプリ接続に使用するアイテム
「複数のワークフローアプリを連携させて運用する ー アプリ分割編」で使用したアイテムと同じものを使用します。ただし、今回は子ケースの処理結果を受け取ってから処理を先に進めるように定義するので、［サービスタスク（子ケース開始）］の［子ケースの終了を待つ］オプションを利用します。
［子ケースの終了を待つ］オプション
［サービスタスク（子ケース開始）］の［子ケースから受け取る値］タブにある［P2: 子ケースの終了を待つ］オプションを有効にすると以下のように動作します。
子ケースの終了まで滞留
子ケースが終了するまでトークンを保持し、フローを滞留させます。親ケースは開始された子ケースを監視（ポーリング）し、子ケースの［状態］が「終了（または異常終了）」となるまで滞留が続きます。
子ケースのデータを取得
親ケースは、子ケースの終了を感知したときに子ケースにアクセスし、子ケースのデータを取得します。値を取得できるデータ項目は、子ケースのアプリ設定にて許可されているものに限られます。
サンプルアプリ
配送部の「発送業務アプリ」（呼び出される側）
前記事での手順と同様に、配送部の「発送業務アプリ」（子ケース側）から作成します。
先頭に［メッセージ開始イベント (HTTP)］を配置し、プロパティ画面の［編集の可否］にて営業部の「受注業務アプリ」からデータを受け取り保存するデータ項目を［
編集可］に設定します。
データ項目
| データ項目名 | データ型 | フィールド名 | 必須 | 説明 |
| 件名 | – | – | – | |
| 配送先名称 | 文字型 (単一行) | q_delivery_name | – | |
| 配送先住所 | 文字型 (複数行) | q_delivery_address | – | |
| 発送明細 | テーブル型 | q_item_list | – | |
| 受領証 | ファイル型 | q_receipt | – | |
| 呼出元ケース ID | 文字型 (単一行) | q_parent_id | ✓ | 初期値：#{parentProcessInstanceId} |
- データ項目「呼出元ケース ID」の初期値に設定している EL式は［親ケース ID］をセットするものです
- Questetra BPM Suite からの HTTP リクエストで開始されたケースは、呼び出し元の親ケースのケース ID をシステム変数［親ケース ID］として参照できるようになります（parentProcessInstanceId）
「発送開始」（［メッセージ開始イベント (HTTP)］）
| データ項目名 | 編集の可否 |
| 件名 |  |
| 配送先名称 | |
| 発送明細 | |
| 配送先住所 | |
| 受領証 |  |
| 呼出元ケース ID | |
ここまでの設定は「アプリ分割編」と同様です。
今回は、［メッセージ開始イベント (HTTP)］設定画面にある［親ケースからのデータ可視性］の設定を行います。ボタンをクリックして設定画面を開き、「受領証」のみ［許可］に設定します。ここで［許可］に設定された項目は、親アプリの［サービスタスク（子ケース開始）］設定画面の［子ケースから受け取る値］タブでの設定項目に追加されます。
設定が完了したら編集画面を閉じてアプリを［リリース］します。画面上部の［アプリID］（ｍ数字）と［アプリ名］を確認してください。
営業部の「受注業務アプリ」（呼び出す側）
前記事で作成した営業部の「受注業務アプリ」（親ケース側）を編集します。
編集画面のパレットの［自動処理タスク］＞［他のワークフローアプリとの連携］から配送部の「発送業務アプリ」を呼び出すアイコンを設置して接続します。先に設置されている「請求書発送依頼」工程の前に設置すると「配送完了を確認したら請求する」という流れとなります。後ろに設置すれば「入金を確認すれば発送する」となります。
データ項目（追加）
配送部の「発送業務アプリ」のケースが終了したときに、「受領証」ファイルを受け取って保存するためのデータ項目を追加しておきます。さらに開始された子ケースの［ケース ID］を保存するデータ項目も追加します。
| データ項目名 | データ型 | フィールド名 | 必須 | 説明 |
| 受領証 | ファイル型 | q_receipt | – | （子ケースの成果物） |
| 子ケース ID | 文字型 (単一行) | q_Subprocess_ID | – | （子ケース開始時に取得されます） |
- 文字型データ、日時型データなど他のデータ型のデータも受け渡しできます
- 保存するデータ項目のデータ型を同じにしておく必要があります
- 掲示板型とガイドパネル型は受け渡しの対象にできません
「配送依頼」工程（［サービスタスク（子ケース開始）］）
［子ケースに渡す値］タブでの設定項目は「アプリ分割編」と同様に設定します。これが「サブアプリを呼び出す」設定となります。
| 項目名 | 設定内容 |
| At: 件名 | #{processInstanceTitle}（「件名」を選択） |
| A0: 配送先名称 | #{#q_name}（「受注先名」を選択） |
| A1: 配送先住所 | #{#q_address}（「受注先住所」を選択） |
| A5: 発送明細 | 売上明細（を選択） |
［子ケースから受け取る値］タブで［P2: 子ケースの終了を待つ］オプションをオンにします。これにより「親ケースが子ケースの終了を待ち受ける」設定になります。オプションをオンにすると取得可能な子ケースのデータ項目が設定項目として表示されますので、格納するデータ項目を指定します。これで「子ケースが終了したらデータを受け取る」設定となります。
| 項目名 | 設定内容 |
| P1: 開始した子ケースの ID を保存するデータ項目 | 子ケース ID（を選択） |
| P2: 子ケースの終了を待つ | オンにする |
| RT: 件名 | 今回は設定しません（空白） |
| R3: 受領証 | 受領証（を選択） |
ここまで設定できれば、サブアプリを呼び出し、子ケースの終了を待ち受けて子ケースでの成果物を受け取る仕組みが完成です。
「配送依頼」工程にて［この工程のみデバッグ］を実行してみましょう。「配送依頼」工程が処理されると「発送業務アプリ」で子ケースがデバッグケースとして開始されます。今回は子ケースの工程を、全て処理してください。「2. 納品確認」工程では、ファイル型データ項目「受領証」にスマートフォンで撮影した受領証の画像を添付する想定です。ファイルを添付して「2. 納品確認」工程を終了すれば配送部の「発送業務」ケースが終了します。
［この工程のみデバッグ］を実行した「受注業務アプリ」のケースの詳細を確認します。子ケースの終了をもって親ケースも終了しているので、［全ケース］一覧から該当するケースを見つけてください。詳細画面のデータ項目「受領証」に添付したファイルが格納されていることが確認できます。
- 子ケースの詳細画面では、［ケース開始ユーザ］の表示箇所に［親ケース ID］が代わりにリンク表示されます
- ［全ケース］一覧から子ケースの詳細を開いて、上記リンクから親ケースを開くこともできます
［サービスタスク（子ケース開始）］工程は、一連の処理がすべて正常に完了すれば［処理完了］となります。本記事では、子ケースを開始するところから、子ケースが終了してデータを受け取るところまでが一連の処理です。
一連の処理で何らかの不具合が発生した場合、［サービスタスク（子ケース開始）］工程は［エラー終了］となります。不具合の例として、データの受け渡しでエラーが発生した場合や、子ケースが［強制終了］や［削除］などで正常終了しなかった場合があげられます。
［エラー終了］となる場合、トークンを［エラー境界イベント］の接続先へ進めることもできます。工程の設定にて［処理失敗時に、トークンをエラー境界イベントに移動］オプションを有効にしてください。
［エラー終了］した後の処理を、子ケースが開始したかどうかで分けたい場合が考えられます。［開始した子ケースの ID を保存するデータ項目］に保存された値の有無を分岐条件に指定して、フローを分岐させてください。
サブケースがエラーとなった場合の処理を定義する際は、以上を踏まえて、［エラー境界イベント］の先のフローを設計してください。
Appendix
［サービスタスク（子ケース開始）］で子ケースからデータを受け取る場合は、子ケースが終了するまで親ケースのフローは進みません。
例えば「翻訳が完了するまでに他の作業を進めたい」場合は並行分岐を検討します。
