Blue Prismベストプラクティス 構築編 4 ケースのリカバリーとプロセスの継続性
唐突ですが、どんなプロセスでもWork Queueを必ず使いましょう。
Blue Prismの良さは、このWork Queueの機構にあると言っても過言ではありません。スケーラビリティ（拡張性）とリカバビリティ（耐障害性・回復性）つまり、ロボットの無人運転化の実現を支える、非常に強力な機能です。逆に言うと、これがなければあなたのロボットは、「人間が付き添う」ただのデスクトップオートメーションです。インテリジェントな自動化とは呼べません。
Work Queueについては、今後記載予定の、設計編においても、詳しく解説していきます。
ケースとは
このWork Queueに格納される一件一件の処理単位を、Case（ケース）と呼びます。Get Next Itemで取得される、一つの仕事の指示内容ですね。
さて、100件の請求書の入力処理を夜番ロボットに任せる、というプロセスがあったとします。ある夜、50件まで正常にできて、51件目でエラーが発生した場合、残りの49件、プロセスが落ちてしまったがために、処理がされずに残りました。。。それを朝出社して気付きました。そして思うわけです。
おい、ロボット、お前、夜中何やってたんだ。
途中で変なデータが来たからって、夜中残りは何もせず遊んでたのか。
他のデータはどうだったんだ？ 確認したのか？
問題なきゃ、他のもやっとけよ。
。。。ブツブツ言いたくもなりますよね。。。。分かります。
しかし、ここはじっとこらえて、確実に、そして着実に育てましょう。
エラー復旧と処理の継続という考え方をうちのロボットに教え込みましょう。
プロセスにおける仕事の進め方
ロボット構築でのプロセス内で、Work Queueを使ってどのように仕事を処理していくか、ですが、以下のような感じになります。
1. インプットとなる情報（複数の仕事指示；例えば、請求書一覧など）をExcelファイルやメールのINBOXの受信メール一覧などから読み込みます。
2. 読み込んだ複数件の仕事をWork Queueに格納します。（Add to Queue）このとき、入力情報は、ひとつのロボットのみが「読み込んでWork Queueに格納する」仕組みにしておきます。同じ仕事を複数ロボットが何十にも実行してしまうこと回避する為に、Environment Lockなどの仕組みを使って、排他制御することを盛り込みます。
3. Blue Prismが唯一無二に管理しているデータベース上のWork Queueから、Get Next Itemにて1件ごとに読み込みます。
4. この読み込んだ1件について、メイン処理を行います。
5. もしこの1件が例えばデータ不正などによりエラーが発生した場合、Mark Exceptionを呼び出すことで、この仕事は、「エラーが発生したよ、あとで人間さん対応してね」とマークし知らせます。もし正常に処理が完了すれば、Mark Completedとして、その仕事単位は正常終了したことをマークします。
6. 次のGet Next Itemにて1件読み込み、処理を続けます。
7. これをWork Queueが空になるまで、すべての仕事単位＝Caseが終わるまで、ループします。
ここで大事なのは、二つです。
1. ループすること
2. エラーが発生しても、当該データにはマーク（Mark Exception）し、そのあと、次のデータの処理を続行（Get Next Item）すること
これを必ず実装するようにします。これにより、52件目以降も処理が続行されることになります。
エラーが発生したCaseに対する同じCaseのリトライ
上記で、エラーが発生し、Mark Exceptionしたものについて、自動的にリトライをかけることができます。もちろん、入力データが不正な場合など、何度やっても同じ結果になるのであれば、リトライは無駄な時間と労力になりますので、回避すべきですが、例えば、システムダウンが頻発するようなアプリケーションに対しては、タイミングによっては、同じデータの再試行を自動的に行ってくれれば、人間によるリカバリ対応を減らすこともできるのです。そんな仕組みを入れてみて下さい。
ただし、最大リトライ回数をWork Queueの設定で定義することも忘れないようにして下さい。
エラーが頻発する場合は通知して終了
100件処理している中で、例えば30件も40件もエラーが発生するようだったら、何かがおかしいのでしょう。そのような場合は、すべて処理しきるのではなく、途中で止めてしまうのも必要な手かもしれません。エラー発生件数あるいは割合の閾値を設定し、通知・終了するようなプロセスの実装にしておくのもお勧めです。
データアイテムのリセット
オブジェクトは、プロセスから何度呼ばれても、メモリ上にあるものが再利用されます。つまり、一度使われたデータ変数の値は、そのプロセスが終わるまで、そのまま残ります。よって、エラーが発生しようとしまいと、オブジェクトのデータアイテムは、呼び出すたびにリセットすること（されること）を意識して下さい。
回復性・復元可能性について
また、以下の３つの要素について、それぞれ、どう回復すべきか、考えておく必要があります。これらは設計のタイミングで考えておくべきことですが、実装する際にも、開発者の頭の片隅にはおいて、ロボットを構築すべきです。詳細は、設計編で解説していきます。
ケースリカバリー
ある一つのケースを作業中に途中でBlue Prismのプロセスがまるっと落ちてしまった場合など、そのケースを再実行（再開）する場合に、どこから再開すべきか、を適切に指示することです。これには、あるひとつの仕事単位が（Get Next ItemからMark Completed／Exceptionまでの）どこまで行われたのか、正しくステータスを保持できるような仕組みが必要です。これについては、またの機会でご説明します。（ヒントは、Item StatusというWork Queueアイテムのパラメータ値を利用する、ということです。）
システムリカバリー
例えば、対象となるアプリケーションのシステムがダウンしている、ネットワーク接続ができない、画面遷移が想定外になった、本来あるべきフィールドやボタンが存在しなくなった、など
このような場合では、
・ その場でリトライしてみる
・ ホーム画面へ戻ってみる
・ 一度アプリケーションを立ち上げなおし、最初のメニュー遷移からやり直してみる
・ 何度リトライしてもダメな場合は終了し、システム管理者へ連絡する
などのハンドリングが考えられます。
。。。操作対象のフィールドがなくなったら、それは、、、ロボット修正ですよね。そんなことが突然、本番稼働中に発生しないように、アプリケーション仕様が変更になることは、アプリチームからロボット管理チームに伝達されるような運用も必要です。
データベースリカバリー
本番稼働環境がハード障害や天変地異などによって突然落ちてしまい、バックアップからリストア（復元）しなくてはならない場合、などです。
バックアップからリストア後、リストア済みの状態から、再度ロボットを稼働させた際に、エラーが発生した直前の処理が二重に実行されないように、適切に対応する仕組みも検討しておく必要があります。
まとめ
Add To Queue、Get Next Itemとループの処理、適切なエラーハンドリングが組み込まれていれば、プロセスでエラーが発生しても業務が続行される、といった業務継続性を担保できることになります。
また、複数ロボット（Blue Prismで言うラインタイムリソース）での並列同時実行がそのまま行えます。複雑なQueueアイテムの排他制御や順序制御は、Blue Prismが自動的に担ってくれます。拡張性の高さ・回復性の高さを利用しないのはもったいない。
どんなロボットでも、たとえ今は1件しか仕事しないことが分かっていても、Work Queueを利用するようにしましょう。
ロボットの無人運転を実現しましょう。
※本投稿は、別ブログで掲載・公開していた内容に加筆・修正を加え再掲載しています。