Blue Prismベストプラクティス 設計編 2 プロセスの分割と設計（後編）
今回は設計編 2 プロセスの分割と設計（後編）です。
前回の前編もご参照ください。
ソリューション全体設計
長大な業務フローをBlue Prismで自動化したい場合、どのように実装していくべきでしょうか。
設計書で言う「Solution Design Document」（SDD；ソリューション設計書）にあたる部分になります。
前回の記事にも記載しましたが、通常の設計フローの流れで言うと、SDDで全体設計して、それを受けてブレークダウンした個々の１プロセスをPDIで設計する、という手順で設計内容を落とし込んで（詳細化して）いきます。
ポイントになるのは、業務フローをどの単位で分割してBlue Prismのプロセスにしていくか、ということです。
理想は、なるべく細かくプロセスを分割する、ということです。
これは、拡張性（多重度を上げることによる負荷分散対応など）、回復対応のし易さ、ステータス管理のし易さ、修正メンテナンスのし易さ、といった理由からのお勧めです。
プロセス分割の勘所
先ず一つ、簡単なのは、人から人へ業務がハンドオーバーされるのであれば、それは複数のプロセスに分割すべきです。
日付を跨いだり、何かのトリガーを待ったりすることが発生するのであれば、そこも分割ポイントになります。複数の別システムに対して、それぞれ更新をかける、といったことがあるのであれば、それも分割ポイントになりえます。（これは、トランザクション管理の観点から、議論が必要ですが。）
システム的な言い方をすれば、ポーリング処理、実処理、メール返信処理なども、それぞれ分割して3つのプロセスに分けるような考え方が望ましいです。
分割されたプロセス間のハンドオーバー
複数分割したプロセス間を繋ぐのに、Work Queueを使います。
1. 先行するプロセスが、介在用のWork Queueに、Queueアイテムを追加し、
2. 後段のプロセスが、そのWork QueueからQueueアイテムを取得して、
3. 処理を実行する、
というやり方になります。
親子関係、シーケンシャル関係、いずれでも、Work Queueを中心にプロセスのハンドオーバーを行います。原則、Sub Processを呼び出す、という形はとらないようにします。
複数分割したプロセス間で介在させるWork Queueの効率的な操作の仕方については、別記事で言及する予定です。
サブプロセスとラッパーオブジェクト
サブプロセスは、Sub Processです。
ラッパーオブジェクトは、”早口の語りを担当する”オブジェクトのことでも、”ビートに合わせた語りに社会的な主張を盛り込んだ”オブジェクト、でもありません。
包む方です。
サブプロセスの呼び出し（親プロセスから子プロセス＝Sub Processを呼び出すような実装）は、原則、回避しましょう。（イギリス本国のコンサルの中には、「サブプロセスを呼び出す機能なんて、廃止してしまうべき」というかなりラジカルな意見もあるくらいです。）
特に、ループ処理の中で、何度も子プロセスを呼び出す実装は、ダメです。
プロセスは、実行マシン上にて、呼び出される度に都度メモリを確保して、終了したら、.NETにメモリの開放を依頼しますが、ループ処理があまりに大量に高速に処理されると、.NETによるメモリ開放と再利用が追い付かずに、当該マシンのメモリをどんどん食いつぶしていく場合があります。
ループ処理内で共通処理をどうしても呼ばなくてはならない場合、ラッパーオブジェクトという形で、オブジェクトによる実装を行うようにして下さい。
但し、オブジェクトは逆に、呼び出し元プロセスが終了するまで、永続的に同じ領域にメモリを確保します。データアイテムは同じものが再利用されますので、呼び出すたびにデータアイテムをリセットするような仕組みが必要です。
複数プロセスの形
ながーい、もしくは、複雑な要件を持つ業務を自動化しようとすると、よくあるのが、以下の４つの形です。
・ 複数過程プロセス
・ 親子関係プロセス
・ ワークフローシステム駆動プロセス
・ リアルタイム要求駆動プロセス
複数過程プロセス
間に、人が介在する複数の自動化業務がある場合、もしくは、一定期間（日ベース、時間ベース）あけて、ステータスベースで処理が行われる必要があるような場合です。
複数過程、例えば二つの処理ステップでも、
一つのWork Queue ＋ 一つのプロセスで実現する場合
と、
二つのWork Queue ＋ 二つのプロセスで実現する場合
といったやり方があります。
前者は、Work QueueのDefer（Add To Queueでの保留・先延ばし指示パラメータ）の機能とWork QueueのItem Statusの機能を使って、最初の過程（ステップ）の実施有無を制御したりする方式です。
ひとつのプロセスの実装ロジックがより複雑になります。過程間の間隔が分単位など狭い場合に有効です。
後者は、最初の過程用のプロセスが、おおもとのWork Queueをトリガーに処理を実施し、完了したら、後段のプロセスがトリガーとするWork QueueにQueueアイテムを登録する、という方式です。
シーケンシャルあるいは数珠繋ぎに複数のステップ（プロセス）が実行されるようなケースです。
先ほどのケースと比較して間隔が日単位だったり、間に人の介在、システムの応答などが必要とされる場合に有効です。
それぞれのプロセスの仕様はシンプルになり、メンテナンスし易くなりますし、拡張性も高いです。
親子関係プロセス
複数のExcelファイルとその中にある対応する（あるいは関連する）複数行が処理対象になるようなケースで、Excelファイル単位で一連の処理を纏めて行う必要があるケースなどが、これにあたります。
また、メイン処理を実行したら、当該処理それぞれについて、纏めてEmailを送信しなくてはならないケース、なども含まれます。いずれも、関係性が１：ｎの処理対象があるような場合です。
これも、それぞれ複数のWork Queue（親用、子用それぞれ別のWork Queue）を用意し、関連する親キー情報をQueueアイテム紐づけ補足情報として登録しておく、という関連付けを取ります。このとき、QueueアイテムのTag機能を使うのが有効です。関係性の整合性を担保する仕組みを検討する必要もあります。
ワークフローシステム駆動プロセス
他のワークフロー管理システムなどから指示を受けて、Blue Prismプロセスが起動されるようなソリューションです。
ワークフローシステム上にて管理されるタスクアイテムを一括でBlue Prismプロセスが取りに行き、それを一件ずつ処理していく場合と、ワークフローシステムが1件ごとにBlue Prismプロセスを実行する場合とで二通りの実装形式が考えられます。
いずれのケースにおいても、Blue Prism上では、Work Queueを設定し、それをトリガーに処理を行う設計としておくべきです。
リアルタイム要求駆動プロセス
トリガーが発生した場合に即座にBlue Prismプロセスが対応する必要があるケースです。Web Service化されたBlue Prismプロセスを外部システムから呼び出す場合などが実装方式として考えられます。
この場合でも、Work Queueを使うべきです。
外部システムからコールされるBlue Prismプロセスは、
1. 受信とWork Queueへの登録、
2. 受付完了返信
だけを担う、軽い処理ステップとして置きます。
そして、後段のメインプロセスは、あくまでもWork Queueをトリガーとしてメイン処理が実行される、といった、疎結合の仕組みが推奨されます。
まとめ
一見ひとつに見える業務フローを、頑張って一つのプロセスで実現することは、時として非常に難しく、非効率であることが多いです。極力、細かく業務ステップを分解し、それぞれ複数のプロセス＆Work Queueで実現することを検討しましょう。それを実現する為の仕組みが、Blue Prismには備わっています。
適切な全体ソリューション設計が、自動化された業務プロセスの堅牢性、拡張性、管理効率性を劇的に向上させます。
次回以降引き続き、ベストプラクティス 設計編 シリーズで、プロセス設計における注意点、考慮ポイントを記載していきます。
※本投稿は、別ブログで掲載・公開していた内容に加筆・修正を加え再掲載しています。