Enterprise Blue Ocean ◮

神谷町RPAブログ

  • Blue Prism の 製品概要 がよくわかるWebページ動画取材記事
  • Blue Prism の Blue Prism 事始め!オンボーディングの記事はこちら
  • Blue Prism を 無料で利用する 方法はこちら
  • Blue Prism で Excelを操作 する記事はこちら
  • Blue Prism の ベストプラクティス 記事はこちら
  • Blue Prism の 逆引きナレッジ wiki こちら。ご活用ください☆

プロセスの任意実行 <③ メール受信トリガーによる実行>

どもども、ジャナイホーによるシリーズ

プロセスの任意実行。

  ~ もう、約束の時間を待つばっかりは、いやなの。私から、私のタイミングで、始めたいの。~

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

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

 

全体構成イメージ 

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

 

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

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

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

f:id:EnterpriseBlueOcean:20190828115000p:plain

 

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

  1. 実行ユーザは、プロセスを実行したいタイミングで、ロボットアカウントのメールアドレスに、実行指示メールを送ります。
  2. 次に、メール受信・振り分け用のプロセスがスケジュール起動され、ロボットアカウントの受信ボックスを確認します。
  3. そこで、ユーザから実行指示メールが来ていれば、その情報を読み取り、実処理用のワークキューに書き込みます。
  4. 実処理用のプロセスがスケジュール起動され、実処理用のワークキューからデータを読み取り、実際の自動化処理を開始します。
  5. この間、各ステップでその状況を依頼元実行ユーザに通知するメールを送信します。(メール送信は、メール送信専門のプロセスが担います。他のプロセスは、「メール送信依頼ワークキュー」への登録=メール送信指示(送信先、本文、題名などを渡す)だけを行います。)
    • メール受信・振り分け用のプロセスが、メールを受信した旨を通知
    • 実処理用のプロセスが、処理を作業開始した旨を通知
    • 実処理用のプロセスが、処理を作業完了した旨を通知
    • もし実処理内でエラーが発生した場合、実処理用のプロセスが、エラー発生した旨を通知

 

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

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

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

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

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

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

 

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

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

 

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

f:id:EnterpriseBlueOcean:20190828112809p:plain

 

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

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

f:id:EnterpriseBlueOcean:20190828112839p:plain

 

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

  1. メール受信ボックスを確認し、メールを読み込み
  2. 読み込んだメールの内容/題名に従い、実行指示用のワークキューへ振り分け、登録
    (このとき、受信ボックスから、退避用のフォルダへメールを移動する)
  3. 受領した旨伝えるメッセージを送信(実際は送信依頼をかけるだけ)
  4. 上記、1~3をメールのメッセージぶんだけ繰り返す。
  5. メール受信ボックスが空になり、読み込み対象メールが無くなれば、処理を終了する

 

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

f:id:EnterpriseBlueOcean:20190828113013p:plain

 

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

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

f:id:EnterpriseBlueOcean:20190828113044p:plain

 

実処理のプロセスの中身

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

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

f:id:EnterpriseBlueOcean:20190828113122p:plain

 

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

  1. ワークキューからデータを取得
  2. 処理開始メールを送信(実際は依頼ワークキューへ書き込むのみ)
  3. メイン処理を実行(上記図で言うと「1-経費レポートの作成」から「3-領収書無しの設定」)
  4. 処理完了通知メールを送信(実際は依頼ワークキューへ書き込むのみ)
  5. 1つの仕事指示ごとに、2~4を繰り返す。
  6. 仕事指示(ワークキューアイテム)が空になれば、処理を終了する

 

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

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

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

f:id:EnterpriseBlueOcean:20190828113209p:plain

 

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

f:id:EnterpriseBlueOcean:20190828113237p:plain

 

実装のポイント

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

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

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

 

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

 

www.ebocean.work

www.ebocean.work

 

まとめ

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

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

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

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

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

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

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

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

 

本シリーズの次回記事では「ファイル受信トリガーによる実行」をご紹介します。