プロセスの任意実行 (3) メール受信トリガーによる実行
見出し画像

プロセスの任意実行 (3) メール受信トリガーによる実行

Blue Prism 公式 note

どもども、ジャナイホーによるシリーズ
「プロセスの任意実行。~ もう、約束の時間を待つばっかりは、いやなの。私から、私のタイミングで、始めたいの。~」

第三弾。メール受信トリガーによる実行、です。

「任意実行」だっつってんのに、「受信トリガー実行」って何言っちゃってくれちゃってんの、とお思いだと思います。

全体構成イメージ

メールをトリガーにして、任意実行を実現する仕組みの構成例です。

ユーザに実行させたい実処理用のプロセス(例えば、経理用プロセス、人事用プロセス、、、など)とは別に、メール受信用のプロセスを用意します。

メール受信用のプロセスは、定期的にメールの受信ボックスを確認し、ユーザからの実行指示メールを読み込み、実処理へ渡していきます。

これにより、Blue Prismの画面を立ち上げることなく、また、コマンドライン実行をさせることなく、ユーザは、任意のタイミングでメールを送るだけで、実行指示を出すことが出来ます。

つまり、こんな手順です。

  1. 実行ユーザは、プロセスを実行したいタイミングで、ロボットアカウントのメールアドレスに、実行指示メールを送ります。

  2. 次に、メール受信・振り分け用のプロセスがスケジュール起動され、ロボットアカウントの受信ボックスを確認します。

  3. そこで、ユーザから実行指示メールが来ていれば、その情報を読み取り、実処理用のワークキューに書き込みます。

  4. 実処理用のプロセスがスケジュール起動され、実処理用のワークキューからデータを読み取り、実際の自動化処理を開始します。

  5. この間、各ステップでその状況を依頼元実行ユーザに通知するメールを送信します。(メール送信は、メール送信専門のプロセスが担います。他のプロセスは、「メール送信依頼ワークキュー」への登録=メール送信指示(送信先、本文、題名などを渡す)だけを行います。)

    • メール受信・振り分け用のプロセスが、メールを受信した旨を通知

    • 実処理用のプロセスが、処理を作業開始した旨を通知

    • 実処理用のプロセスが、処理を作業完了した旨を通知

    • もし実処理内でエラーが発生した場合、実処理用のプロセスが、エラー発生した旨を通知

メール受信ボックスの確認の間隔とライセンス消費

ここで、よくある懸念ですが、「メール受信用のプロセスだけでライセンスを消費してしまう」ということがあります。

確かに、ずぅっと「受信ボックス確認プロセス」を起動しっぱなしで、常時受信ボックスを確認する、という仕組みで実装すると、その間、常時、ライセンスを消費してしまうことになります。

ここで、提案ですが、このプロセスは、「受信ボックスに対象のメールが来ていなければ、終了する」という仕組みにしておきます。さらに、このプロセスを何分かおきに、定期的に起動するスケジュール設定をしておきます。

こうすると、定期的に「メールが来ていれば、振り分け処理だけさくっと実行」し、「メールが受信ボックスになくなれば、即座に終了」するので、その処理している間だけ、ライセンスを消費することになります。これは、大抵の場合、そんなに多くの時間はかからないはずですので、その確認プロセスだけでライセンスを占有してしまう、といったことは回避できます。

それ以外の時間では、ライセンスを実処理に振り分けてやることが出来ます。少ないリソース、少ないライセンスでの運用をしている環境でこそ、有効な手段と考えます。

スケジュールの間隔を1分おきに定義して、周期的にメール受信プロセスが起動するように設定しておけば、ほぼタイムリーに「メールによる依頼→処理開始」が実現できます。

もし、それでもどうしても、数分の遅延も許されないのであれば、「常時起動&即座に受信チェック」のパターンにしておく必要がありますが、この場合は、ライセンスを常に消費することになります。

もし、日中の間(例えば、朝9時~夕方5時までなど)だけ、人がバックアップ対応できるから、周期的に起動したい、といったスケジュール定義も、可能です。

メール受信・振り分け用のプロセスの中身

メインページはこんな感じになります。

つまり、メールの受信・振り分け処理では、以下のことを行います。

  1. メール受信ボックスを確認し、メールを読み込み

  2. 読み込んだメールの内容/題名に従い、実行指示用のワークキューへ振り分け、登録
    (このとき、受信ボックスから、退避用のフォルダへメールを移動する)

  3. 受領した旨伝えるメッセージを送信(実際は送信依頼をかけるだけ)

  4. 上記、1~3をメールのメッセージぶんだけ繰り返す。

  5. メール受信ボックスが空になり、読み込み対象メールが無くなれば、処理を終了する

 ご参考まで、メールの受信ボックスを確認するフローを下記に示します。

メールの受信ボックスを確認するフロー

そして、実際の振り分け処理の概要が、以下の流れで分かると思います。

メールの題名に従い、適切なワークキューへ登録(「実処理よ、仕事をせい!」と依頼)しています。

実処理のプロセスの中身

実処理のプロセスでも、プロセステンプレートを使った実装にします。

これにより、メール受信プロセスによって登録された、ワークキュー(この例では例えば「経費精算プロセスワークキュー」)の仕事の依頼情報をトリガーにして、適切な順序で処理が行われることになります。

この図にはメール送信の部分が表現されていませんが、以下のような処理が実装されていることが望ましいです。

  1. ワークキューからデータを取得

  2. 処理開始メールを送信(実際は依頼ワークキューへ書き込むのみ)

  3. メイン処理を実行(上記図で言うと「1-経費レポートの作成」から「3-領収書無しの設定」)

  4. 処理完了通知メールを送信(実際は依頼ワークキューへ書き込むのみ)

  5. 1つの仕事指示ごとに、2~4を繰り返す。

  6. 仕事指示(ワークキューアイテム)が空になれば、処理を終了する

メール送信処理のプロセスの中身

メール送信処理は、共通部品として作成することがおススメです。

エラーが発生した、だろうが、作業を開始した、だろうが、呼び出し元の状況をそのまま右から左を受け流す、感じで実装してやれば、共通部品化が実現できて、良いのではないか、と思います。

送信先メールアドレスのチェックなども実装してやって、誤送信や情報漏洩を避ける仕組みを担保している、とすると良いでしょう。

実装のポイント

この実装のカギとなるポイントは、ワークキューを使うこと、と、プロセステンプレートを使うこと、の二つです。

なぜならこれで、間違いなく、スケーラビリティが上がります(ここで言うスケーラビリティとは、処理対象データのボリュームが多くなった時に、ランタイムリソースの多重度を上げる、スケールアウトの容易性を言います)。

また、実装させる処理内容をそれぞれ単純化させ、役割分担を徹底することで、メンテナンス効率が上がります。

ワークキューとプロセステンプレートについては、下記の二つの記事を参考にして下さい。

まとめ

メール受信トリガーは共通化出来ます。汎用的に作ることが出来ます。

プロセスは、細かく、役割分担ごとに、それぞれの仕事だけをシンプルに行うように実装します。(これはベストプラクティスにも合致します)

いずれのプロセスも「自分の担当の仕事が無かったら、即座に終了する」という仕様で実装します。

いずれのプロセスも「周期的に起動する」ようにスケジュール定義します。

重要なポイントは、ワークキューを用いたテンプレートの活用です。

これにより、ライセンス消費を最小限に抑えつつ、将来の拡張に柔軟に対応できます。スケジュールが遅延することに依る、後続のプロセスが実行できない、という運用上の課題も解決できます。

ライセンスがいっぱいだったから、今は待ち行列に入れておいて、空きが出たら順序良く処理してもらいたい、というユーザのニーズにも対応できます。 

ワークキューをいっぱい作らなくてはならない、ユーザがプロセス名を動的に指定したい、数多くのプロセスを任意実行の対象としたい、などの要件に対応するソリューションも、この考え方をベースにすると、検討しやすくなります。

※本投稿は、別ブログで掲載・公開していた内容に加筆・修正を加え再掲載しています。

みんなにも読んでほしいですか?

オススメした記事はフォロワーのタイムラインに表示されます!

©2022 “Blue Prism”, “Blue Prism”のロゴ、ならびにPrism製品はBlue Prism Limitedの商標または登録商標です。​Blue Prismの著作物である旨明示いただければ、複製、転載を許諾します。

ありがとうございます。ぜひ他の記事もお読みください
Blue Prism 公式 note
Blue Prism株式会社のnoteアカウントです。Blue Prism株式会社のメンバーが、製品の技術的な解説や活用Tipsなど、業務プロセスの自動化やDXに役立つ情報を投稿していきます。時に担当者の個人的な見解も含みます。© 2022 Blue Prism.