「アプリ分割編」や「サブプロセス編」では、［サービスタスク（子プロセス開始）］で子アプリを呼び出す方法や子アプリでの処理結果を親アプリに戻す方法を説明しました。親プロセスから呼び出された子プロセスでは、処理担当者がヒューマンタスクを処理することによりフローが進められました。

今回はサブプロセスが自動工程のみで構成されているケースについて考えます。複数の処理が自動工程のみで構成されている子アプリがあり、それを親アプリから呼び出すとします。この場合、親アプリに子アプリを呼び出す工程を１つ設置するだけで、子アプリでの処理を親アプリのプロセスに組み込むことになります。例えば、ストレージサービスの Box と連携して「フォルダを作成する～ファイルをアップロードする～ファイルのダウンロードURL を通知する」という一連の処理（Box 経由でファイルを受け渡す）が、自動工程のみで構成されたアプリがあるとします。このアプリが呼び出されて一連の処理が実行されると、呼び出した側のプロセスでは「Box 経由でファイルを受け渡す」という１つの自動工程が処理されたとみなせます。このように、子アプリを呼び出す工程を設置するだけで、様々な業務（アプリ）に「ファイルを受け渡す」自動処理を簡単に組み込むことができます。

本記事では、自動工程のみで構成されたサブプロセスを作成して利用する方法と、その意義やメリットについて説明します。

自動処理サブプロセスとは？

［サービスタスク（子プロセス開始）］は、対象とする子アプリを呼び出してプロセスを開始させる自動工程です。

もし、子アプリが「自動工程が1つだけ」であるならば、処理される内容は下図のいずれの場合も同じです。つまり親アプリの中で［サービスタスク（子プロセス開始）］（下図の「Box アップロードアプリ呼び出し」工程）は子アプリ内の自動工程と同等の意味を持っていることになります。

では、子アプリが「連続する複数の自動工程で構成されている」場合はどうでしょう。

この場合も、単体のワークフローアプリと親子アプリの組み合わせとでは処理の結果は同じものになります。しかも子アプリを呼び出す親アプリは、先の「子アプリが自動工程が1つだけ」の場合と変わりません。この親アプリの［サービスタスク（子プロセス開始）］は、子アプリでの一連の処理を、一つの工程だけでワークフローに組み込む役割を果たしています。

このように、サブプロセス（子アプリ）が自動工程のみで構成されている場合、親アプリに［サービスタスク（子プロセス開始）］工程をひとつ配置することで、サブプロセスの処理内容を置き換えることができます。自動工程のみで構成されているサブプロセスを、［自動処理サブプロセス］と呼ぶこととします。

Questetra では様々な Web サービスに対して、「作成する」「取得する」といった単機能の自動工程が提供されています。それらを組み合わせた［自動処理サブプロセス］を作成することで、より高度な自動処理を定義できます。

ちなみに、上図の子アプリでの一連の処理は「Box 経由でメールの受信者にファイルを受け渡す」ためのものです。すなわち、親アプリ内ではこの子アプリを呼び出す［サービスタスク（子プロセス開始）］は「Box 経由でファイルを受け渡す」自動処理工程のアイコンである、とみなすことができます。

一方で、一連の処理にヒューマンタスクが含まれていれば、処理担当者が処理を完了しなければ次の工程へは進みません。自動工程のみで構成されている［自動処理サブプロセス］と、ヒューマンタスクが含まれている［サブプロセス］とは区別されます。

自動処理サブプロセスのメリット

自動工程のみで構成される「自動処理サブプロセス」を作成して運用することで、どのようなメリットがあるのか考えてみましょう。

ワークフロー図を整理できる
複数の自動工程でも、サブプロセスにまとめられていると、親アプリでは「呼び出し工程」1つで呼び出せます。つまり、親アプリのワークフロー図が整理され、視認性が高まります。

ノーコードで作成できる
［スクリプトタスク］には、自動工程を組み合わせた場合と同等の処理を実行するスクリプトを記述できます。しかし、それには高度なプログラミング技能が必要です。Questetra で提供されている様々な［自動工程］を利用すれば、ノーコードでサブプロセスを定義できます。

設置が簡単
サブプロセスが用意されていない場合、同様の処理を行う複数のアプリに同じ設定を個別に行う必要があります。サブプロセスが用意されていれば、それを呼び出す工程を配置するだけなので、アプリの作成/編集が簡単になります。

様々な部門/アプリから呼び出せる
［メッセージ開始イベント（HTTP）］からのプロセス開始は、処理担当者設定や組織の構造に影響を受けません。同一ワークフロー基盤であれば、いかなるアプリからでも呼び出すことができます。

アドオン自動工程を利用する時に子アプリにアドオン定義（Add-on.xml）を持たせる
サブプロセスにはアドオン自動工程も配置できます。複数のアプリで同じアドオン工程を配置する場合は［アプリ共有アドオン］にアドオン定義ファイルを登録しますが、最大登録数の制限があります。サブプロセスのアプリにアドオン定義ファイルを搭載することで、この登録数を消費せずに複数のアプリでアドオンを利用できることになります。
また、アドオン自動工程にはメンテナンスが必要となりますが、個別のアプリにアドオン定義ファイルを登録している場合よりメンテナンスの手間が省けます。

自動処理サブプロセスを作成する

「Box を活用して、ファイルを社外の人へ送る」で紹介したアプリを参考に、自動処理サブプロセスを作成してみましょう。

参考アプリと大きく異なるのは、［開始イベント］が［メッセージ開始イベント（HTTP）］に置き換えられていることと、それに続く［ヒューマンタスク］が無いことです。それら以外、データ項目や各自動工程は全く同じ設定で構いません。
参考アプリのヒューマンタスク、「ファイル添付」工程での入力に変えて、［メッセージ開始イベント（HTTP）］で必要なデータを受け取ります。

データ項目名	「ファイル添付」工程（参考アプリ）	メッセージ開始イベント (HTTP)［編集許可］
件名	編集可
共有するフォルダの ID	非表示
共有リンク URL	非表示
共有ファイル	編集可
すかしを適用	編集可
共有先アドレス	編集可
メール件名	編集可
メール本文	編集可

「参考アプリと全く同じ設定で良い」と書きましたが、動作としての問題はありません。しかし、様々なアプリ/部門での業務から呼び出されるサブプロセスとして、より汎用性が高くなるように工夫が求められます。

例えば、参考アプリではダウンロードできる期間（タイマーの待機日数）が 3日で固定されています。
#now.addDays(3)
データ項目に［数値型］項目を追加してその値を参照する式
#now.addDays(#q_shareDays)
に書き換えれば、親プロセスでの指定により動的に共有期間を決定できます。
また、データの［初期値］（参考アプリでは「メール本文」に設定されている）などは、親アプリに設定するようにし、サブプロセスの汎用性を狭めないようにします。

自動処理サブプロセスを呼び出す設定をする

サブプロセスを呼び出すには［サービスタスク（子プロセス開始）］を配置します。配置場所は、サブプロセスに渡すデータが揃う時点や、サブプロセスの処理による成果物が必要となる時点などを考慮して決定します。［サービスタスク（子プロセス開始）］の［子プロセスの終了を待つ］オプションをオフにすると、親プロセスのフローと子プロセスの処理は、同時並行処理のように振る舞います。

データ項目設定では、サブプロセスに値を渡す項目を用意します。サブプロセスでの処理結果を受け取る場合は、受け取った値を格納する項目も用意します。

例えば、［メッセージ送信中間イベント（メール）］を使用して添付ファイルを送信するアプリが運用されているとします。「メール添付によるファイル送信は廃止し、Box 経由での共有に切り替える」という業務ルールの変更であれば、［メッセージ送信中間イベント（メール）］を削除し、上記で作成したサブプロセスを呼び出す［サービスタスク（子プロセス開始）］に置き換えることで変更に対応できます。