Blue Prismベストプラクティス＜設計編④＞ リカバリー設計
「ジャナイホー」による「ベストプラクティス」シリーズ、今回は、設計編④ リカバリー設計 についてです。
業務自動化において、無人運転を目指すロボット構築では、このリカバリー（回復性）を考え、適切に実装することが非常に重要です。
回復性
その為には、障害に対する３つの種類の回復策を考えておく（つまり、設計しておく）必要があります。
ケースリカバリー
もし、ロボットがある一つのケースの作業中に、何らかの外部要因で、プロセスごとBlue Prismがまるっとが落ちた場合、Blue Prismを再起動すると、その途中まで実施されたケースは、どのように処理されるでしょうか。
特段何も特殊なハンドリングをせずに実装していると、途中まで実施された処理（落ちる寸前まで行われていた処理）は、再起動後にもう一度、同じ処理が行われることになります。
これに対応する為に、これには、あるひとつの仕事単位が（Get Next ItemからMark Completed／Exceptionまでの）どこまで行われたのか、正しくステータスを保持できるような仕組みが必要です。
Work QueueのStatusの機能を使うことが有効です。
（これは、前回の記事にも記載しています）
システムリカバリー
例えば、
- 対象となるアプリケーションのシステムがダウンしている、
- ネットワーク接続ができない、
- 画面遷移が想定外になった、
- 本来あるべきフィールドやボタンが存在しなくなった、
などです。
このような場合、エラーハンドリングを実装するのは、もちろんですが、その際に、「ロボットがコントロールを取り戻す」ということが大事になります。
どのように「コントロールを取り戻す」ことができるでしょうか。
例えば、以下が考えられます。
- その場でリトライしてみる
- ホーム画面へ戻ってみる
- 一度アプリケーションを立ち上げなおし、ログインしなおし、最初のメニュー遷移からやり直してみる
- 何度リトライしてもダメな場合は終了し、システム管理者へ連絡する
設計時点で、このような「Unhappy Path」を考えることが理想的です。
（ただ実際は、開発者が構築の段階で実装していくことになる、ことが多いようですね。）
ホーム画面へ戻ってみたり、アプリケーションの再起動からやり直してみたり、という部分は、下記のようなイメージで実装されていると、分かり易いですかね。。。
あと、そもそも、操作対象のフィールドがなくなってたりしたら、それは、、、
、、、ロボット修正ですよね。
そんなことが突然、本番稼働中に発生しないように、アプリケーション仕様が変更になることは、アプリチームからロボット管理チームに伝達されるような運用も必要です。
ただし、アプリケーションの仕様変更・実装変更は、発生するもの、と想定しましょう。
毎月発生するようなシステムの自動化は考え物ですが、ある程度変更は発生することを想定して、メンテナンス性が高いオブジェクトの実装にしておくことが必要です。
この点については、以下の記事などを参考にして下さい。
データベースリカバリー
本番稼働環境がハード障害や天変地異などによって突然落ちてしまい、バックアップからリストアしなくてはならない場合、などです。
Work Queueのケースアイテム100件処理している途中、例えば30件処理完了して、残り70件のタイミングで、落ちた場合。どうしても、バックアップからリストア（復元）が必要なんですが、その復元元が、最新でも昨晩バックアップしたものしか残っていない場合。このリストア済みの状態から、再度ロボットを稼働させると、実は、処理済みの30件が再度処理されてしまい、二重処理が発生してしまうことになりかねません。
このようなことを排除する為に、処理対象レコードに対する、「足跡」をチェック・登録する仕組みを実装することが必要になります。この「足跡」は、Blue Prismではなく、例えば登録対象ターゲットアプリケーションや関連する他のシステム上のデータベースデータなど、が有効です。
もしくは、ログファイルをチェックする、管理台帳ファイルを使う、なども有効でしょう。
まとめ
ケースリカバリーをすべてきっちり実装すれば、完全な無人運転を目指せます。
何か想定外のエラーが発生したことを、適切にハンドリングして、極力「通常の状態に戻す」ことができるようにしておくことが重要になります。
設計者は常に、正常系を実現するだけではなく、「Unhappy Path」を考えて実装の形を定義するようにしましょう。
稼働後に「あ、こんなことが発生した。だからこんなエラーハンドリング実装を書き加えよう」を繰り返すような設計、実装は、好ましいものではありません。（現実では、どうしてもそんなプロジェクトになりがちだとは思いますが。。。）
リカバリーの観点で、
「二重で処理しない」「漏れてしまって処理されずに残ってしまう」ということが、発生しないように
また、これらを回避する為に、
「人が介在して目視でチェックしながら、リカバリー対応を行う」ということが発生しないように
ロボットの機構で対応できるようにしておくと、ロボット管理者／ロボット監視者の手間や工数を削減できるようになります。
目指すは無人運転です！！
あなたの自動化は、
「人の介在を必要とする、ただのデスクトップオートメーション」
ではありませんか？
しっかり設計すれば、それを実装し、実現できるのが、Blue Prismです。
シリーズ 「Blue Prismロボット構築のベストプラクティス」、＜設計編＞ 次回は、
内部統制対応（ログの保存やパージ、認証情報、機密情報セキュリティ） について、解説していきます。
