プロセスの途中で他のアプリのプロセスを起動する「アプリ接続」は、「見積プロセス」から「受注申請プロセス」、あるいは「納品業務プロセス」から「請求業務プロセス」など、業務プロセス同士を連携させたいケースで利用されます。また、大規模なアプリを分割したり一部の業務をサブルーチンとして独立させたりする場合に利用されます。アプリを分割することで視認性が高まり、また業務改善をより円滑に進めることができます。また、一部の業務、例えば翻訳作業や法務審査などが独立したアプリとして定義されていれば、そのアプリを呼び出す設定だけでフローに業務工程を組み込むことができます。
本記事では、アプリを分割し親アプリから子アプリを起動する仕組みを例として具体的な設定方法を説明します。また「サブプロセス編」(近日公開予定)では親アプリから子アプリを起動し、子アプリのデータを親アプリに渡す、サブプロセスを構築する方法について説明します。
ワークフローアプリを分割する
ワークフローアプリでは、業務の開始から終了までの業務の流れや各処理工程の担当者、受け渡しされる業務データなどが、あらかじめ定義されています。
しかしながら多くの部署が関わるような業務の場合には、各部署で必要となる手順やデータを定義しようとすると、ワークフローアプリは大がかりなものになりがちです。
受注~発送~請求フロー
受注から始まり、発送~請求業務の流れが定義された以下の業務アプリがあるとします。

このアプリでは業務が「営業部」「配送部」「経理部」と部門をまたいで進められます。
今回は、部門ごとにワークフローアプリを分割して定義することにします。分割されたアプリを HTTP 通信で接続することにより、同じように業務を進められることを確認します。
- 本記事では部門ごとに分割したアプリのうち「営業部」と「経理部」とのアプリ接続までを説明します(参照 M411: “納品プロセス” から “請求プロセス” が自動開始されるように設定する)
- 「営業部」と「配送部」とのアプリ接続については「サブプロセス編」にて説明します
ワークフローアプリ接続に使用するアイテム
アプリ接続には HTTP 通信を行うアイテムを使用します。子アプリ(呼び出される側)には HTTP リクエストを受信してプロセスを開始する[メッセージ開始イベント(HTTP)]を、親アプリ(呼び出す側)では受信を待ち受けている[メッセージ開始イベント(HTTP)]に HTTP リクエストを送信する設定がパッケージ化されている[サービスタスク(子プロセス開始)]をそれぞれ設置して使用します。
メッセージ開始イベント(HTTP)

サービスタスク(子プロセス開始)

サンプルアプリ
前述のアプリを分割する形で「営業部の受注業務アプリ」と「経理部の請求業務アプリ」の2つのアプリを作成、接続します。

「営業部上司」が「2. 受注確認」工程で承認すると経理部の「請求業務アプリ」が起動されて請求業務が始まるように設計します。経理部の「請求業務アプリ」起動時に「受注先の名称」「住所」「明細表」「合計金額」のデータが受け渡されます。経理部門では受け取った情報をもとに請求書を発行、送付して入金を確認するという流れを想定しています。
- 簡単にするために工程やデータの数を少なく設定しています
- 連携設定以外の設定についての説明は割愛します
経理部の「請求業務アプリ」(呼び出される側)
まず経理部の「請求業務アプリ」から作成します。
先頭に[メッセージ開始イベント (HTTP)]を配置し、プロパティ画面の[編集の可否]にて営業部の「受注業務アプリ」からデータを受け取り保存するデータ項目を[ 編集可]に設定します。

データ項目
データ項目名 | データ型 | フィールド名 | 必須 | 説明 |
件名 | – | – | – | |
請求先名称 | 文字型 (単一行) | q_billing_name | ||
送付先住所 | 文字型 (複数行) | q_billing_address | ||
請求金額 | 数値型 | q_billing_amount | ✓ | |
請求明細 | テーブル型 | q_details | テーブルの列(テーブル項目)設定は呼び出すアプリと同一にしなければなりません。 | |
PDF ファイル名 | 文字型 (単一行) | q_filename | ||
PDF File | ファイル型 | q_pdf |
「請求開始」([メッセージ開始イベント (HTTP)])
データ項目 | 編集の可否 |
件名 | ![]() |
請求先名称 | ![]() |
送付先住所 | ![]() |
請求明細 | ![]() |
請求金額 | ![]() |
PDF ファイル名 | ![]() |
PDF File | ![]() |
設定が完了したら編集画面を閉じてアプリを[リリース]します。画面上部の[アプリID](m数字)と[アプリ名]を確認してください。
営業部の「受注業務アプリ」(呼び出す側)
経理部の「請求業務アプリ」が完成し[リリース]したら、次に営業部の「受注業務アプリ」を作成します。

データ項目
データ項目名 | データ型 | フィールド名 | 必須 | 説明 |
件名 | – | – | – | このデータ項目に入力された文字列が他のアプリでのプロセス件名になります |
受注先名 | 文字型 (単一行) | q_name | – | |
受注先住所 | 文字型 (複数行) | q_address | – | |
合計金額 | 数値型 | q_amount | – | |
売上明細 | テーブル型 | q_table | – | テーブルの列(テーブル項目)設定は呼び出すアプリと同一にしなければなりません。 |
「請求書発送依頼」([サービスタスク(子プロセス開始)])
サービスタスク(子プロセス開始)とは
「受注確認」工程の後ろに「経理部」のアプリを呼び出して開始させる[サービスタスク(子プロセス開始)]のアイコンを設置します。アプリ編集画面のパレットの[自動処理タスク]> [他のワークフローアプリとの連携]から、先に作成した経理部の「請求業務アプリ」を見つけてください。

- [サービスタスク(子プロセス開始)]とは同等の機能のアイコンの総称であり、個々のアイコンの名称は「アプリ ID、アプリ名、ノード番号、工程名」となっています
- リリース済アプリに設置されている[メッセージ開始イベント(HTTP)]の数だけあります
各設定項目の項目名が経理部の「請求業務アプリ」でのデータ項目名になっています。設定するデータの指定は[参照を挿入する…]から受け渡したいデータのデータ項目名を選択するとセットされます。文字型以外はドロップダウンメニューでデータ項目名を選択します。
項目名 | 設定内容 |
At: 件名 | #{processInstanceTitle}(「件名」を選択) |
A0: 請求先名称 | #{#q_name}(「受注先名」を選択) |
A1: 送付先住所 | #{#q_address}(「受注先住所」を選択) |
A5: 請求明細 | 売上明細(を選択) |
A2: 請求金額 | 合計金額(を選択) |
受け渡すデータに以下のような不備があれば、自動処理がエラーとなりアプリの起動に失敗します。
- 受け取り側で[必須]設定のデータ項目にデータを渡さない(空のデータを渡す)
- 受け取り側のデータ項目で設定されている最小/最大文字数や満たすべき正規表現などの入力チェック内容を満たさないデータを渡す
- テーブル型データ項目で列数が一致しない、対応する列のサブタイプが異なる
ここまでで設定は完了です。[この工程のみデバッグ]を実行して、経理部の「請求業務アプリ」の工程が開始され、データが受け渡されていることを確認します。
- 開始された経理部の「請求業務」のプロセスもデバッグプロセスとなります
- 開始されたデバッグプロセスにおけるヒューマンタスクは、経理部の「請求業務アプリ」の最終編集者に割り当てられます

まとめ
アプリ接続の設定は次の2段階で行われます。
- 呼び出される側(子)のアプリと呼び出す側(親)のアプリに接続ポイントを設置する接続設定
- アプリ間で受け渡すデータを指定するデータ連携設定
呼び出される側のアプリに[メッセージ開始イベント (HTTP)]が設置されていれば、呼び出す側のアプリに以下の設定を施すことで上記の2段階の設定が完了します。
- [サービスタスク(子プロセス開始)]を配置する
- 配置した[サービスタスク(子プロセス開始)]の設定項目で受け渡しを行うデータ項目を指定する
本記事では、「既にあるワークフローアプリを分割する」という形で説明しましたが、アプリの分割以外でもアプリ接続を検討するシーンが多くあります。
例えば、部署外からの依頼を受け付けて手動でプロセス開始しているような業務アプリでは、自動開始ポイント([メッセージ開始イベント(HTTP)])を追加することで、部署外(の業務アプリ)から直接プロセスを起動できるようになります。アプリ接続を利用することで、業務データの引き継ぎが容易になり、手動開始の手間を省いたり、入力誤りといったヒューマンエラーを回避したりすることが可能となります。
ワークフローアプリ接続の基本的な仕組みと設定方法を理解し、実際のアプリ運用で活用してみてください。
次の「サブプロセス編」(近日公開予定)では親アプリから子アプリを起動した後、子アプリ終了後に子アプリのデータを親アプリに渡す仕組み(サブプロセス)を構築する方法について説明します。