Blue Prismベストプラクティス＜設計編⑦＞ 通知・アラート
「ジャナイホー」による「ベストプラクティス」シリーズ、いよいよ最終回、設計編⑦ 通知・アラート についてです。
プロセスの実行状況や実行結果を、管理者や要求元に対して、どのように知らせるか、についても、設計フェーズでちゃんと考える必要があります。
こういうのって、あとから色々と「あーしとけば良かった。こーしとけば良かった」というのが出てくるもんです。
ちょっとアイデア出しをしておきますので、是非、ご検討下さい。
本番運用開始後、プロセスの稼働状況を監視することになるわけですが、常にコントロールルームとにらめっこしているわけにはいかない人も多いでしょう。
Blue Prismが提唱している、運用モデル「ROM（Robotic Operating Model）」においては、「プロセス監視者」をアサインして運用しろ、と言っています。
現に、海外での大規模導入事例ではそうしていますが、なかなかそれも難しい、ということも多いのではないでしょうか。業務の役割分担も明確ですしね、特に欧米人は。
日本では、業務と兼業、片手間で見てる、とか、開発者と監視者が同一、とかが多いと思います。
片手間な人に、タイムリーにどう情報を伝えるか。
いくつか手段があります。
- Blue Prismのアラート機能を使う
- メール送信する
- 外部システムへ伝達する
、、、です。
コントロールルームへの伝達
先ずは最低限、正しく「正常終了」「異常終了」をコントロールルームへ伝えましょう。
プロセスのメインページで、Endで終わらせるか、Exceptionをスローされて終わるのか、です。
どのケースの場合は、異常終了なのか、どのケースの場合は、正常終了なのか、これも、予め設計標準で決めて、正しくプロセス監視者に伝わるようにしましょう。
良くないのは、すべてEndに繋げてしまって、コントロールルーム上ではすべて「Completed」と表示されてしまうことです。これでは、正しくプロセス監視者に異常発生が伝わりません。
アラート機能
先ずは、アラート機能です。
（先ずは、って、、、どうよ。どうなのよ。）
「Alert」機能とは、プロセスのエラー終了時など、特定の事象が発生した場合に、システム管理者の作業端末画面上へポップアップでエラーを通知する機能です。
以下の手順で設定・表示します。
- プロセススタジオにて、Alert通知を導入したいプロセスに対して、Alertステージを追加する。
（例外ハンドリング処理などに追加する） - Alert通知先のユーザにAlert通知方法、通知対象プロセスを選択する。
- プロセスをスケジュール実行する。
- プロセスがエラー終了した際に（追加したAlertステージを通過した場合）、
ポップアップ通知がユーザに表示される。
１は、プロセス開始時に行う作業です。
２、３は、開発完了したプロセスを本番へデプロイする際に行う作業です。
４が本番稼働中に発生する通知です。
ですので、事前の定義、設定が必要、ということになります。
（もちろん、あとから追加で定義、設定できますが。）
1. プロセススタジオにて、Alert通知を導入したいプロセスに対して、Alertステージを追加する。（例外ハンドリング処理などに追加する）
2. Alert通知先のユーザにAlert通知方法、通知対象プロセスを選択する。
3. プロセスをスケジュール実行する。
（※スケジュール実行するには、BPServerを起動する必要があります。）
4. プロセスがエラー終了した際に（追加したAlertステージを通過した場合）、
ポップアップ通知がユーザに表示される。
詳しくは、オンラインヘルプを見てみて下さい。
「alert」で検索してみて下さい。（雑だな、おい。）
※重要！！！
Version 6.3、6.4だと、現在、そのプロセスをスケジュール実行しても、正常にAlertが通知されません。
バグで対応中です。修正されると、BG-2451でリリースノートに載ると思われます。修正を待ちましょう。
メール送信する
プロセスの完了時、エラー終了時に、エラーを送信する仕組みを実装します。
Outlook MAPIEx VBOを使ったり、E-mail – POP3/SMTP VBOを使ったりして、メールを送信します。
ポイントは、メール送信するプロセスと、コア処理を行うプロセスとを分割して実装することです。
コア処理でエラー発生時に、メールを送信したい場合は、メール送信用のプロセスが参照するWork Queueに対して、Add to Queueをして、メール送信の指示だけを行うようにします。
メール送信用のプロセスは、Queueに指示が来たら、通知メールを先のVBOなどを使って、送信します。
コア処理のプロセスでは、Work Queueに書き出すだけ、です。決して、コア処理のプロセスでは、メール送信VBOを呼び出さない、ような実装にしてみて下さい。
この考え方は、これまでのプロセス設計のベストプラクティスでお話してきました。
必ず、分けて実装しましょう。
外部システムへ伝達する
他にも、ワークフローシステムへAPI経由で伝達／登録／発信して、伝える、などの仕組みがあると思います。
IT・システム管理部門が管轄する、監視管理用のデータベースシステムやジョブ管理システムへの登録・更新もあるかと思います。
サポートサービスのチケット発行・管理システムへの連携も良いかもしれません。
このような、全社IT基盤で必要とされる要素がないかどうか、事前に確認、調整しておくことが望ましいです。
ログとレポーティング、分析
これに合わせて、以下のような情報をファイルやデータベースに吐き出す仕組みも検討下さい。
- それぞれのプロセスのログ（開始、終了時刻）
- 実行状況（ステージ、ステータスなど）
- 何件のQueueアイテムが日々処理されるのか
- 一つのQueueアイテムの処理にどの程度時間がかかるのか
- 依頼者、依頼部門
運用開始後、どんな分析がしたいか、で必要な情報を溜めていく仕組みがあると良いです。
使用状況から、展開や廃止の根拠に使えます。
BIソフトを使って、かっちょいいグラフを作ってVisualizationして下さい。
まとめ
このような、通知の仕組みは、全プロセスで統一の仕組みで実装されるべきです。
だいぶ作り切ってしまい、あとから、共通通知処理を追加していくのは、かなり大変な作業になります。
よって、設計のタイミング、しかも、初期導入の段階で、どのような通知を誰にする必要があるのか、検討し、設計標準やコーディング規約に記載することが肝要です。
いかがでしたでしょうか。
Blue Prismは、真のエンタープライズRPAです。
ベストプラクティスでロボットを実装することの目的を再掲します。
- 無人化を達成できる、高度なロボットを構築する（耐障害性、回復性）
- 同時に複数プロセスを複数ロボットで並列稼働させる（拡張性）
- 部品の再利用を促進し、開発・メンテナンスの生産性を向上する（再利用性）
最初の実装はもしかしたら、「めんどくさい」という感触もあるかと思います。
ただ、のちのちのこと、運用開始後、1年、2年先の未来を見据えて、しっかりとした設計、実装で、ハッピーなお仕事ライフを実現してみましょう。
Blue Prismなら、それができます。
あなたなら、それができます。
なぜなら、もう、あなたは、あなたの組織の「無人で仕事がデキルロボット育成委員会」の委員長ですからぁっ！
【番外編】（↓）もお時間があるときに、是非。
① 自律型ロボット
② Blue Prism World London 2019 での構築ベストプラクティス
⑥ テキシコー
