プロセスの任意実行 (3) メール受信トリガーによる実行
どもども、ジャナイホーによるシリーズ
「プロセスの任意実行。～ もう、約束の時間を待つばっかりは、いやなの。私から、私のタイミングで、始めたいの。～」
第三弾。メール受信トリガーによる実行、です。
「任意実行」だっつってんのに、「受信トリガー実行」って何言っちゃってくれちゃってんの、とお思いだと思います。
全体構成イメージ
メールをトリガーにして、任意実行を実現する仕組みの構成例です。
ユーザに実行させたい実処理用のプロセス（例えば、経理用プロセス、人事用プロセス、、、など）とは別に、メール受信用のプロセスを用意します。
メール受信用のプロセスは、定期的にメールの受信ボックスを確認し、ユーザからの実行指示メールを読み込み、実処理へ渡していきます。
これにより、Blue Prismの画面を立ち上げることなく、また、コマンドライン実行をさせることなく、ユーザは、任意のタイミングでメールを送るだけで、実行指示を出すことが出来ます。
つまり、こんな手順です。
実行ユーザは、プロセスを実行したいタイミングで、ロボットアカウントのメールアドレスに、実行指示メールを送ります。
次に、メール受信・振り分け用のプロセスがスケジュール起動され、ロボットアカウントの受信ボックスを確認します。
そこで、ユーザから実行指示メールが来ていれば、その情報を読み取り、実処理用のワークキューに書き込みます。
実処理用のプロセスがスケジュール起動され、実処理用のワークキューからデータを読み取り、実際の自動化処理を開始します。
この間、各ステップでその状況を依頼元実行ユーザに通知するメールを送信します。（メール送信は、メール送信専門のプロセスが担います。他のプロセスは、「メール送信依頼ワークキュー」への登録＝メール送信指示（送信先、本文、題名などを渡す）だけを行います。）
メール受信・振り分け用のプロセスが、メールを受信した旨を通知
実処理用のプロセスが、処理を作業開始した旨を通知
実処理用のプロセスが、処理を作業完了した旨を通知
もし実処理内でエラーが発生した場合、実処理用のプロセスが、エラー発生した旨を通知
メール受信ボックスの確認の間隔とライセンス消費
ここで、よくある懸念ですが、「メール受信用のプロセスだけでライセンスを消費してしまう」ということがあります。
確かに、ずぅっと「受信ボックス確認プロセス」を起動しっぱなしで、常時受信ボックスを確認する、という仕組みで実装すると、その間、常時、ライセンスを消費してしまうことになります。
ここで、提案ですが、このプロセスは、「受信ボックスに対象のメールが来ていなければ、終了する」という仕組みにしておきます。さらに、このプロセスを何分かおきに、定期的に起動するスケジュール設定をしておきます。
こうすると、定期的に「メールが来ていれば、振り分け処理だけさくっと実行」し、「メールが受信ボックスになくなれば、即座に終了」するので、その処理している間だけ、ライセンスを消費することになります。これは、大抵の場合、そんなに多くの時間はかからないはずですので、その確認プロセスだけでライセンスを占有してしまう、といったことは回避できます。
それ以外の時間では、ライセンスを実処理に振り分けてやることが出来ます。少ないリソース、少ないライセンスでの運用をしている環境でこそ、有効な手段と考えます。
スケジュールの間隔を1分おきに定義して、周期的にメール受信プロセスが起動するように設定しておけば、ほぼタイムリーに「メールによる依頼→処理開始」が実現できます。
もし、それでもどうしても、数分の遅延も許されないのであれば、「常時起動＆即座に受信チェック」のパターンにしておく必要がありますが、この場合は、ライセンスを常に消費することになります。
もし、日中の間（例えば、朝9時～夕方5時までなど）だけ、人がバックアップ対応できるから、周期的に起動したい、といったスケジュール定義も、可能です。
メール受信・振り分け用のプロセスの中身
つまり、メールの受信・振り分け処理では、以下のことを行います。
メール受信ボックスを確認し、メールを読み込み
読み込んだメールの内容／題名に従い、実行指示用のワークキューへ振り分け、登録
（このとき、受信ボックスから、退避用のフォルダへメールを移動する）受領した旨伝えるメッセージを送信（実際は送信依頼をかけるだけ）
上記、１～３をメールのメッセージぶんだけ繰り返す。
メール受信ボックスが空になり、読み込み対象メールが無くなれば、処理を終了する
ご参考まで、メールの受信ボックスを確認するフローを下記に示します。
そして、実際の振り分け処理の概要が、以下の流れで分かると思います。
メールの題名に従い、適切なワークキューへ登録（「実処理よ、仕事をせい！」と依頼）しています。
実処理のプロセスの中身
実処理のプロセスでも、プロセステンプレートを使った実装にします。
これにより、メール受信プロセスによって登録された、ワークキュー（この例では例えば「経費精算プロセスワークキュー」）の仕事の依頼情報をトリガーにして、適切な順序で処理が行われることになります。
この図にはメール送信の部分が表現されていませんが、以下のような処理が実装されていることが望ましいです。
ワークキューからデータを取得
処理開始メールを送信（実際は依頼ワークキューへ書き込むのみ）
メイン処理を実行（上記図で言うと「1-経費レポートの作成」から「3-領収書無しの設定」）
処理完了通知メールを送信（実際は依頼ワークキューへ書き込むのみ）
１つの仕事指示ごとに、２～４を繰り返す。
仕事指示（ワークキューアイテム）が空になれば、処理を終了する
メール送信処理のプロセスの中身
メール送信処理は、共通部品として作成することがおススメです。
エラーが発生した、だろうが、作業を開始した、だろうが、呼び出し元の状況をそのまま右から左を受け流す、感じで実装してやれば、共通部品化が実現できて、良いのではないか、と思います。
送信先メールアドレスのチェックなども実装してやって、誤送信や情報漏洩を避ける仕組みを担保している、とすると良いでしょう。
実装のポイント
この実装のカギとなるポイントは、ワークキューを使うこと、と、プロセステンプレートを使うこと、の二つです。
なぜならこれで、間違いなく、スケーラビリティが上がります（ここで言うスケーラビリティとは、処理対象データのボリュームが多くなった時に、ランタイムリソースの多重度を上げる、スケールアウトの容易性を言います）。
また、実装させる処理内容をそれぞれ単純化させ、役割分担を徹底することで、メンテナンス効率が上がります。
ワークキューとプロセステンプレートについては、下記の二つの記事を参考にして下さい。
まとめ
メール受信トリガーは共通化出来ます。汎用的に作ることが出来ます。
プロセスは、細かく、役割分担ごとに、それぞれの仕事だけをシンプルに行うように実装します。（これはベストプラクティスにも合致します）
いずれのプロセスも「自分の担当の仕事が無かったら、即座に終了する」という仕様で実装します。
いずれのプロセスも「周期的に起動する」ようにスケジュール定義します。
重要なポイントは、ワークキューを用いたテンプレートの活用です。
これにより、ライセンス消費を最小限に抑えつつ、将来の拡張に柔軟に対応できます。スケジュールが遅延することに依る、後続のプロセスが実行できない、という運用上の課題も解決できます。
ライセンスがいっぱいだったから、今は待ち行列に入れておいて、空きが出たら順序良く処理してもらいたい、というユーザのニーズにも対応できます。
ワークキューをいっぱい作らなくてはならない、ユーザがプロセス名を動的に指定したい、数多くのプロセスを任意実行の対象としたい、などの要件に対応するソリューションも、この考え方をベースにすると、検討しやすくなります。
※本投稿は、別ブログで掲載・公開していた内容に加筆・修正を加え再掲載しています。