はじめに
RPAにはエラーがつきものなので、運用を回すにはエラー処理をどう設計するかが非常に重要です。
エラー処理を設計するにあたり、どんなことを考慮する必要があるか、私なりの観点をざっくばらんにまとめてみました。
目次
- ビジネスエラーとアプリケーションエラー
- 全停止 OR 処理継続
- 再実行
- その他考慮すべきこと
1. ビジネスエラーとアプリケーションエラー
まずRPAのエラー処理を考えるにあたって外せない概念が「ビジネスエラー」「アプリケーションエラー」です。
※ビジネスエラーは、「業務エラー」といったり、アプリケーションエラーは、「予期しないエラー」といったり、現場ごとに呼び名があったりすると思います。
※何をもって「ビジネスエラー」「アプリケーションエラー」とするか、現場・状況・業務によって変わってくると思います。
ビジネスエラー
業務で扱うデータの不備を起因とするエラー。
例）
-
社員情報を更新しようとした際に更新対象の社員番号が存在しない。
-
必須項目が空白だったり、業務上あり得ない値が入っていたりして、システム側でエラーメッセージが表示される。
エラーに対処するためには、データそのものを確認する必要があり、業務上の問題であるため業務担当者が対処する必要があります。
アプリケーションエラー
業務上想定しない技術的な問題を起因とするエラー。
例）
- ネットワークが重くてシステムにアクセスできない。
- 実行端末がフリーズしてしまう。
- システムの改修でクリックや入力対象の特定ができなくなる。
業務上の問題ではなく、実行環境やロボの実装に関する問題で、業務とは関係ない要素でエラーとなっているため、開発担当者が対処する必要があります。
ビジネスエラーとアプリケーションエラーを区別する意義
ビジネスエラーとアプリケーションエラーを分けることで、エラー原因を区別し、どんな対処が必要か、誰が問題に対処する必要があるかを明確化することができます。
2. 処理を停止 OR 次のデータの処理を続行
RPAで自動化する業務の多くは、同じ処理を複数のデータに対して繰り返し行うものが多いです。
繰り返しがある業務を前提とすると、複数あるデータの中の1つでエラーが発生した場合に、
- 処理を完全に停止
- 次のデータの処理を続行
という2つの処理パターンが想定されます。
処理を完全に停止すると、例えば100件あるデータのうち5件目でエラーが発生した場合、残りの95件は未処理のままとなります。
一方で、次のデータの処理を続行にすれば処理を最後まで流しきることができるものの、発生したエラーについての原因がわからないまま次のデータの処理を続行してしまうリスクがあります。
上記観点に、先ほどのビジネスエラー・アプリケーションエラーの観点も加えて、下記のようなパターンを考えてみました。
①ビジネスエラー／アプリケーションエラーのどちらも発生した時点で処理を完全停止させる。
②ビジネスエラーの場合は次のデータの処理を続行、アプリケーションエラーの場合は処理を完全停止させる。
③ビジネスエラー／アプリケーションエラーのどちらが発生しても次のデータの処理を続行させる。
※「ビジネスエラーの場合は処理を完全停止、アプリケーションエラーの場合は処理を続行させる」というケースも想定されますが、あまりやらないので割愛
それぞれのパターンについてみていきたいと思います。
①ビジネスエラー／アプリケーションエラーのどちらも発生した時点で処理を完全停止させる。
このパターンは、実質的にはエラー処理を組み込んでいないケースです。
先ほども触れたように、100件あるデータのうち5件目でエラーが発生した場合、残りの95件は未処理のままとなり、業務への影響が大きくなってしまいます。
RPA初心者の方がエラー処理の概念を知らないまま開発したロボットは、このパターンになっていることが多いです。
経験者が意図してこのパターンを採用することはほぼないと思います。
あるとしたら、よほど慎重にやりたい業務で、エラーが発生したら必ず状況を確認したいという状況でしょうか。
（そもそもそういう業務を自動化すべきではないと思います）
②ビジネスエラーの場合は次のデータの処理を続行、アプリケーションエラーの場合は処理を完全停止させる。
このパターンは、あらかじめ想定できるエラー（ビジネスエラー）であれば処理を続行しても問題ないが、アプリケーションエラーの場合は何が起きているか不明のため、安全をみて処理を全停止させようという考え方に基づいた、どちらかというと慎重派のエラー処理です。
アプリケーションエラーがほとんど起きないことが前提となります。
具体的には、
- 操作するシステムの画面が変わることはない。
- ネットワークや実行端末が安定している。
ことが前提となります。
でないと、頻繁にアプリケーションエラーが発生すると、いちいち業務への影響が発生してしまいます。
処理が完全停止してしまうことへの影響度が少ない業務であれば、支障ないかもしれません。
UiPath StudioXは、①②のパターンに基づいて開発することが想定されているように思います。
③ビジネスエラー／アプリケーションエラーのどちらが発生しても次のデータの処理を続行させる。
このパターンは、ビジネスエラー／アプリケーションエラーともに処理を全停止させず、次のデータの処理を続行させるという②と比較して楽観的？なエラー処理です。
アプリケーションエラーが発生してもクリティカルなインシデントにつながらない業務であることが前提となります。
そのうえで、下記のような業務で特に有効であると考えられます。
- ネットワークや端末が不安定である。
- 後続業務がある、処理件数が多い等、全停止時の影響が大きい。
RPAは、どんなに丁寧に作り込んでも、1%くらいは予期しないエラー（アプリケーションエラー）が起きてしまうことがあるので、クリティカルなインシデントが発生する要素がなければ、このパターンを採用するのがよいかなと個人的には思っています。
ただし、アプリケーションエラーが発生した場合、実行端末がどういう状態になっているかがわからないので、一度利用しているアプリケーションを落とし、再起動・再ログインが必要になるので、少し設計が複雑になってしまうデメリットはあります。
UiPath REFrameworkは、③のパターンに基づいて開発することが想定されているように思います。
3. 再実行
エラーが発生したデータについて、原因を特定して問題を解決した後、同じデータでロボを再実行させるという問題があります。
場合によっては再実行せず、手動で業務をリカバリーするということも想定されます。
手動でリカバリーする場合は、どのデータが処理済みで、どのデータが未処理（エラー）なのか、また、どのような原因でエラーとなったのかを業務担当者がわかるようにすれば、問題ないと思います（多くはExcelなどの処理結果ファイルに、ステータスとエラー内容を記録する）。
再実行するとなった場合、既に処理済みのデータを重複しても問題ないかを考える必要があります。
下記のケースは問題ないと言えます。
- 一度登録作業を終えたデータは、システム上で登録できなくなるのでビジネスエラーとして検知できる。
- 同じデータに何回同じ処理をしても問題ない。
- 再実行で処理済みのデータに同じ処理をするだけの時間的猶予がある。
下記のケースは問題ありなので、対処する必要があります。
- 一度登録作業を終えたデータについて再度登録ことができてしまい、かつ、それが業務上NGである。
- 再実行で処理済みのデータに同じ処理をするだけの時間的猶予がない。
問題ありのケースでは、下記の仕様を追加する必要があります。
- 前回実行時の処理結果ファイルをもとに、既に処理済みのデータをスキップするような仕様を組み込んでおく（処理結果列に「済」と入っているデータはスキップする等）。
- INPUTとなるファイルとOUTPUTとなるファイル（処理結果を記録するファイル）が一緒になるようにする（分けることも可能であるが、設計がかなり複雑になる）。
- 前工程でINPUTとなるファイルを作成・更新する場合、再実行モード等を用意して、前回分のINPUTデータ（前回の処理結果の記録あり）を読み込むようにする。
再実行にあたっては、上記のように色々と考慮する必要がありますし、運用も若干複雑になるのでユーザーへの運用方法説明が少し大変です。
その他考慮すべきこと
複数の工程がある場合
「全停止OR次のデータの処理を続行」に関連する観点として、処理に複数の工程が存在するか否かというものもあります。
例えば、システムAにデータ登録（処理Aとする）後、システムBに同じデータを登録（処理Bとする）するといったケースです。
処理Aが終わっていないデータは処理Bを実行できないという要件もあれば、処理Aが失敗しても処理Bを実行しても問題ないという要件もあります。
ここに踏み込むと記事の収集がつかなくなってくるので、あまり触れませんが、よくある考慮不足として、処理Aと処理Bの処理結果を一つにまとめてしまうケースです。
処理ABともにエラーになったのか、片方は処理済みかがわからなくなるので、基本的には処理AとBは別個に処理結果を記録したいところです。
ログイン失敗のエラー処理
システムへのログイン時に、パスワードの設定が間違っていることによるエラーが発生することがあります。
定期的にパスワード変更が発生するようなシステムでは置きがちなエラーだと思います。
このエラーが起きた際に「次のデータの処理を続行」してしまうと、データの数だけログインを試みることになります。
そうすると、ログイン失敗しすぎてアカウントをロックされる危険があります。
なので、パスワード間違いによるログイン失敗には特別なエラー処理を組み込んでおく必要があります。
エラー情報の記録
業務上のリカバリーという観点でも、その後の保守対応という観点でも、エラー発生時の情報はできる限り記録しておくことが望ましいです。
そのために下記のような処理を組み込んおくと役立ちます。
- システムでデータの不正があり、登録エラーが出た場合、システムに表示されているエラーメッセージ（「○○は必須項目です」など）を記録しておく。
- エラーが発生した瞬間のスクリーンショットを記録する（アプリケーションエラーの場合、スクリーンショットがないと原因を特定できないことが多い）。
- ロボ上のエラーメッセージを出力し、かつどのデータで何のエラーが発生したのかわかるような形でログ出力・処理結果出力を行う。
エラー通知メールがエラーになったケース
エラー通知をメールなどでユーザーに通知することがあると思います。
しかし、エラー通知メールを送る処理でエラーになるケースもあり得ます。
なので、ユーザーに「何もメールが来なかったらエラーになっている」ということを認識してもらう必要があります。
しかし、たいてい忘れているので、運用担当者が監視するのが現実的でしょうか。
個人的にはこういうケースがあるので、エラーをメールで通知するのはあまり好きではなりません。
処理結果ファイルを毎回確認してもらう運用にしたいなあと思って思っています。
エラー通知メール自体も見逃されがちなので、件名を工夫する必要があると考えています。
しょっちゅう同じような件名でメールが届くと無視されがちなので、よく起きるエラーの件名と、たまに起きるエラーの件名を変えておくことが大切だと思っています。
とりとめもなく、ざっくばらんにエラー処理について考慮すべき観点を書いてきました。
他にも観点はあると思いますし、開発者によって意見が分かれる部分もあると思います。
つまり、エラー処理って奥深いな、と感じました。