こんにちは。前田です！
今回はA2019でよりパワーアップした、
エラーハンドリングについてご紹介していこうと思います！
目次
AAE A2019バージョン：A2019.14
AAE A2019ビルドバージョン：5322
１．はじめに
RPA化を行う中で、Bot実行時のエラーの発生は避けて通れるものではありません。
毎日正常に動作しているBotでも、タイミングやネットワークの問題などで、
ある時だけ、実行に失敗してしまうこともあります。
Botが止まってしまうだけでなく、固まってしまったり、異常な結果を出力してしまったり。
はたまた、前のBotの実行が完了しておらず、必要なファイルが生成されていなかったり。
もしかしたら、担当者が、データを投入するシステムのメンテナンスを忘れて、Botのスケジューリングをスキップするのを忘れてしまっているかもしれません。
では、Automation Anywhere A2019では、このようなエラーの発生をうまく検知して、エラーハンドリングを行うことはできないのでしょうか？
答えは、できます！
A2019では、V11より、より柔軟なエラーハンドリングを行うことができるようになりました。
「エラーハンドラー」パッケージを使ってエラーハンドリングを行いましょう！
２．エラーハンドリングアクション
A2019では、「エラーハンドラー」と呼ばれるパッケージが存在します。
エラーハンドラーパッケージでは、以下の４つのアクションを使用して、ハンドリングを行っていきます。
- 試行（Try）
- キャッチ（Catch）
- 最終（Finally）
- スロー（Throw）
プログラミングを経験されたことがある方は、聞き覚えがあるかもしれません。
V11のエラーハンドリングコマンドでは、以下の図のように、エラーが起こった時に行える行動が制限されていました。
A2019では、各ブロックの中に入れる処理に制限はありませんので、
より自由度の高い、柔軟なエラーハンドリングが行えます。
では、それぞれのアクションはどういったものなのでしょうか。
３．それぞれのアクションの仕様
エラーハンドラーパッケージの以下4つの機能について、
一つずつどのような動きをするのか、見ていきましょう。
・試行
自動化する処理を作成するブロック。
この試行ブロックの中でエラーが発生した場合、キャッチブロックの中に遷移する。
・キャッチ
エラーが起こった時に実行されるブロック。
エラーが起きた時に、Bot終了までに行いたい処理をここに記載する。
e.g.)エラー時のログ出力、メール通知
・最終
エラーの有無にかかわらず、最後に必ず実行されるブロック。
処理の実行後に、エラーの有無に依存しない、共通の後処理を行いたい場合に使用する。
e.g.)処理結果のログ出力、ファイル・システムのクローズ
・スロー
エラーを任意のタイミングで発生させることができる。
業務エラーをBot実行エラー発生時と同じ扱いにすることができる。
４．実際の動き
これら４つのアクション（ブロック）を組み合わせて、
エラーが起きても運用に大きな影響を与えないBotの作成を行うことが可能になります。
それでは、実際にどのように動いていくのか/動かしていくのかを、見ていきたいと思います。
まず、用意したのが以下のBotとExcelファイルです。
BotはExcelの内容をループしてメッセージボックスに表示させる、簡単なものです。
Excelファイルは、ヘッダに改行が入っている表データを用意しました。
メッセージボックスの表示の際、取得する指定ヘッダ名には改行の制御文字が入っていませんので、
こちらを実行すると、以下のように、対象のヘッダが見つからないエラーになります。
Tips
改行文字を含むヘッダを指定したい場合、対象のExcelのセルごとコピー＆ペーストを行い、
入力された内容から「"」を削除することで、改行の制御文字ごとコピーされ、入力されるため、正常に取得することができます。
それでは、このBotに対してエラーハンドリングアクションを入れてみましょう。
エラーハンドリングを入れた後のBotがこちらになります。
※それぞれの処理が見やすいように、フロー表示にしています。
それでは、それぞれのブロックの内容を見ていきましょう。
まずは、試行のブロックから見ていきます。
試行のブロックでは、通常行いたい処理を記載します。
開始ログの出力→Excelファイルオープン→一行ずつのループでメッセージボックスの表示
を行っています。「何件目のデータを処理しているところでエラーが起きたか」をエラー時に確認したいので、
数値型変数で件数をインクリメントして、カウントしています。
続いて、キャッチのブロックの内容を見ていきましょう。
キャッチアクションの設定では、すべてのエラーをキャッチして、
エラーメッセージを「vErrorMsg」、エラーが発生したBotのソース行番号を「vErrorLineNum」に格納するように設定しました。
そして、キャッチブロック内では、
「vErrorLineNum」と「vCount(試行ブロック内ループ件数の格納変数)」は数字型の変数ですので、
ログに出力するために、文字列に変換し、エラー内容・エラー行数・エラー発生件数についてログファイルに出力するように設定しました。
それでは、最後に、最終のブロックの内容を見ていきましょう。
こちらは、エラー発生/正常終了に関わらず実行されるブロックですので、
後処理としてのExcelのクローズや、処理終了ログの出力などを行っています。
それでは、こちらのBotを実行してみます。
Botの内容はそのままで、正常に実行完了しています。
それでは、ログの中身を見てみましょう。
エラーログにはエラーメッセージやエラー行数、実行中だった件数が出力され、
また実行ログには、開始と終了のログが出力されています。
このように、エラーハンドラーパッケージを利用することで、
エラーが起きても、後処理やログの出力を行うなど、柔軟なエラーハンドリングを行うことができます。
では、最後に、スローアクションのご紹介をしていこうと思います。
今度は、Excelの電話番号を正しく指定して取得したのちに、
対象のセルにデータが入っていなかった場合、スローアクションでエラーを発生させるようにします。
Excelファイルのデータはこのように、電話番号のデータに穴ができるよう変更しています。
このBotを実際に実行してみると、どのように動くのでしょうか。
まず、データが存在する行は、対象の電話番号データがメッセージボックスで表示されます。
そして、データが存在しない行まで到達すると、Botが正常終了しました。
では、ログを見てみましょう。
スローで任意にエラーを発生させたため、エラー内容は設定したメッセージになっています。
このように、スローを行うと、TaskBotとしての実行にはエラーが出ていないものの、
内容としてエラーにしたい場合にエラーと同じ動きを行うことができるのがお分かりいただけたかと思います。
５．さいごに
A2019では、V11と比べて、柔軟かつ強固なエラーハンドリングを行うことができるようになりました。
特に、スローアクションにより、「任意にエラーを発生させる」という処理を行えることは、Bot運用において大きな改善点となっています。
エラーハンドリングには方針によって様々な設定を行う必要があります。
A2019のエラーハンドラーパッケージを利用して、よりBotをいいものに、RPAを便利なものにしていきましょう！
みなさんもぜひ、活用してみてくださいね！
他のおすすめ記事はこちら
著者紹介
先端技術推進統括部
RPAﾋﾞｼﾞﾈｽ推進部
前田 由委
