はじめに

皆さんこんにちは。

世の中では新型コロナウィルスが話題ですが、他の感染症でも同様に予防と対処をしっかりすることが大切ですね。マスクやアルコール消毒をして予防し、病気になってしまったときは決められた手順に則り、迅速に連絡を取るなどの対応をする。そうすることで被害を小さくとどめることができ、再発防止にもつながります。

RPAでも同じことが言えるのではないでしょうか。あらかじめ起こりうるエラーを予想して対策を施し、起こってしまった予期せぬエラーには原因の特定という対処をする。それを可能にするのがエラーハンドリングです。各RPAツールではこのエラーハンドリングのための部品が用意されています。今回はAutomation Anywhereの最新版であるAutomation360を例にとってご紹介していきます。

エラーハンドリングは開発者寄りの話になります。ただユーザーの方も知っていれば、エラーが起きたときにどのような処理をしてほしいか伝えることができます。どちらの立場であっても、知っておいて損はないと思います。

Automation360については以下の記事でご紹介しているので、どのようなものか知りたい方はまずこちらをご覧ください。

BTC RPA

【最新！】Automation360のご紹介

Automation360におけるエラーハンドリング

Automation360ではエラーハンドリングパッケージがあらかじめ用意されています。内容としては試行(try)-キャッチ(catch)-最終(finally)とスロー(throw)です。他のツールにもあるものですが、どのようなものかご説明します。

• 試行：作成した処理をこの「試行」で囲います。この中でエラーが生じた場合、処理の進行を「キャッチ」内に移します。
• キャッチ：「試行」内でエラーが生じたときに行いたい処理を「キャッチ」で囲います。囲う処理として、エラーログの記録やエラーの通知等が考えられます。
• 最終：エラーが生じても生じていなくても、最終的に行いたい処理を囲います。開いていたファイルやウィンドウを閉じる等の処理が考えられます。
• スロー：スローは処理中の任意の場所に置くことができ、その場所で故意にエラーを起こします。エラーとして処理したい条件分岐の中にあらかじめ配置しておくと、処理を中断したり、「キャッチ」に処理を渡したりできます。

4つを組み込むと以下の画像のようになります。単純な処理の場合はこれで良いかもしれませんが、処理が複雑になると不十分になってしまいます。考えられる2つのケースを例にお見せしていきます。 

ケース①：リトライする場合

下の画像の例ではyahooのサイトを開き、キャプチャした検索窓にBTCと入力してEnterキーを押すという処理を行っています。もしブラウザを開くのに時間が掛かってしまうと、開くのを待たずに検索窓をキャプチャする処理が実行されてエラーになります。このようなエラーはリトライをすることで予防できます。

リトライは試行やキャッチを含めたすべての処理をループで囲うことで実現できます。ループを使用するとBreakが使えるようになります。Breakはループを脱して、ループの後の処理に進むという意味を持ちます。

つまり、

正常　→ループを脱して処理が終了。

エラー→キャッチに処理が遷移。

となります。

キャッチ中のIfでは、ループの回数(定義した変数loopCounter)が3であれば処理を中止するという条件が設定されています。これにより1,2周目のループでは何も行わず、ループの先頭に処理が戻ってリトライします。

ループを使うと、Breakの他に続行が使えるようになります。続行に進んだ段階でその周のループ内処理は終了し、次の周の先頭に処理が移ります。

続行を組み込んだ例を下に示します。4行目に追加したIfは「yahooのウィンドウが存在しない」という条件となっており、中に遅延と続行が入っています。

つまり、

正常　→Ifには入らず後続の処理に進行。

エラー→5秒間待機して次の周の処理を開始。

となります。

こうしてブラウザが開くまでループを周回するようになり、ブラウザが開かないことによるエラーを回避できます。ループやIfを用いることで、エラーハンドリングが柔軟になるのです。

ケース②：親子Botの構成にする場合

さらに複雑な親子Botの構成にする場合について見ていきます。親子Botとは特定の処理を担う子Botと、1つ以上の子Botを呼び出す親Botで構成されます。

例えば会員制サイトで処理を行いたい場合、ログイン処理、サイト内処理、ログアウト処理を組み込む必要があります。それらの処理を3種類の子Botに分けて作成し、子Botを順番に呼び出す親Botを実行Botとして用意します。この分割のメリットは、同サイトで違う処理を行うBotを作りたいときに、ログイン用とログアウト用のBotを再利用できる点にあります。追加で作成するBotが１つで済むということです。

ただしBotを分割するため、それぞれのBotに対してエラーハンドリングを組み込まなければなりません。

まずは親Botについて見てみましょう。親Botの処理を以下の画像に示します。画像中ではログイン、ログアウト用の実行部分を省略していますが、3つのBotを順番に実行していきます。10~18行が２つ目の子Bot「sub2」を呼び出す部分となっており、ここまでご説明してきた試行やループのBreakを組み込んでいます。

子Botの実行中にエラーが生じると、キャッチ内のファイルに記録する処理が実行されます。そのプロパティを以下の画像に示します。

ログファイルへ書き込むテキストは自由に設定できます。今回は3つの変数を用いて記録するようにしています。

１つ目がerrorCounterです。こちらは試行内のループにおいて、現在何周目なのかということを表します。キャッチ内での条件分岐にも使用しています。これを記録することで、生じているエラーが毎回同じなのか異なるのかを確認できます。

２つ目と３つ目はerrorLineNumberとerrorMessageで、エラーが起きた行番号と内容を表します。このerrorMessageに関して、実はただ設定するだけではあまり意味がありません。なぜかというと、子Bot内でエラーが生じた場合errorMessageには「子Botの実行に失敗しました」という旨のメッセージしか入らないからです。それしか記録されないのであれば、エラーの詳細が一目でわからず調査に時間を要してしまいます。

では子Botのエラーの詳細(エラー行や内容)を表示するためにはどうすればよいでしょうか？子Bot側の処理を見ていきましょう。

子Botの処理を以下の画像に示します。見ていただきたいのは16行目のスローです。今までと違ってキャッチ内に配置されています。これは、エラーが生じたことをメッセージとともに親に送る役割を担っています。スローの役割は重要で、これがなければ親Botはエラーを感知できません。スローがない場合、15行目でスクリーンショットを撮って子Botの処理が終了し、すべての処理が正常に終了したと親Botに判断されてしまうのです。

スローは故意にエラーを起こすことができると説明しました。つまりどのようなエラーが起きたのかを説明するメッセージも任意に設定できます。今回は次のように設定しました。

$errorMessage_sub$ $String:Enter$sub内 $errorLineNumber.Number:toString$ 行目で$errorMessage$

$で囲まれているのは変数です。errorMessage_subというのは画像内の3,8行目で設定しています。こちらは子Bot内をさらに分割し、どのパートでエラーが起きたかを分かりやすくするために追加しました。そのためステップが移るたびに中身を代入しなおしています。

次のString:Enterは改行という意味です。Automation360の仕様上、改行をこのようにして定義しています。

そしてerrorLineNumberとerrorMessageが登場しています。こちらは親Botの説明でも出てきました。同名でややこしいのですが、今回は子Bot内のエラー行と内容を表します。例えば5行目で名前を入力するはずが、入力欄が見つからないとします。errorLineNumberには5が入り、errorMessageには入力欄が見つからない旨のエラーメッセージが入ります。また10行目のスローに処理が進んだとします。errorLineNumberには10が入り、errorMessageには「ウィンドウが見つかりません」という10行目で設定している独自のメッセージが入ります。

この設定したメッセージが親BotのerrorMessageに代入されることで、以下のようにログファイルに子Botで起きたエラーの詳細が記録されるようになるのです。

終わりに

今回はAutomation360を例に、エラーハンドリングについてご紹介しました。エラーハンドリングをどの段階まで実装するのかは正直開発者次第なところがあります。ずさんな状態のまま完成品を受け入れてしまっては、エラーが頻発して運用に支障をきたすこともあるかもしれません。エラーハンドリングに関わらず、ユーザーと開発者双方が意識を向けることで製品のクオリティは高まります。このコラムがその1つのきっかけになれば幸いです。

RPAツールの導入を検討されている方はこちらからお問い合わせください。