0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

(BizRobo)簡易で漏れのないエラーハンドリング方法の一例

Last updated at Posted at 2023-01-28

はじめに

※こちらの記事は以前noteで投稿していた記事の移植版です。

今回はBizRobo!でのエラーハンドリング方法の一例です。

あくまで一例ですし、何が最適解なのかはケースバイケースだと思っていますので、こういう方法や考え方もあるんだなーぐらいの気持ちで見ていただければと思います。

ただし、記事自体は長いので少し覚悟してください。



BizRobo!でのエラーハンドリングの組み方については、私がBizRobo!に携わることになった2017年からずっと考えてきて、実装の間違いが起きにくく、初心者でも比較的作りやすく、分かりやすく、それでいて網羅性があり、運用が楽になる作り方がないか模索してきました。



もちろん要件によって何が最適かは変わりますし、できるできないもあります。

しかしある程度のところまでカバーできて運用保守の観点でも悪くなさそうな方法がようやく見えてきた気がするので記事にします。

よくあるエラーハンドリング方法

まず、よくある方法として考えられるのは、エラー発生時はトライステップ分岐からエラー処理用のフローに進ませるため、各ステップのエラーハンドリングでトライステップに進ませるように設定するものがあると思います。

↓こういうやつですね↓

よくあるエラー処理

BizRobo!でのエラーハンドリングの課題

しかし、ここでBizRobo!の仕様上課題がありました。



・「次のトライステップに進む」に設定するとデフォルトで「エラーとしてログ記録」のチェックが外れてエラー時にログが記録されなくなるため、ログ記録させたいときはひとつひとつチェックをつけ直さなくてはならない

・複数ステップまとめての設定ができない

・各ステップからどこのトライステップに進むかはステップの設定を確認しなくては分からない



下図のようなフローもあり得るわけです。

エラー処理例

何がどうなるのかパッと見では分かりにくいですし、

私はロボットの改修やエラー発生時の調査時等にあちこちにある分岐をいちいち確認するのは手間だと感じます。

ましてや、いちいちエラーハンドリングタブを見て内容確認するなどなるべくしたくありません。

※そのために直近のトライステップにしか進ませないよう開発ルールとして定めているユーザーさんもいらっしゃると聞いたことがあります

また、開発時にエラー記録のつけ忘れや諸々の設定漏れが出る可能性もあります。

これらの課題を改善するため、次章で解説する作り方を考えました。

いっそエラーハンドリングを設定しない

まず今回の肝は、本来ロボットにやらせたいメインの処理を行うフロー内では、細かくエラーハンドリングを設定するのをやめて全てデフォルトの「後続のステップすべてをスキップ」にしてしまうことです。

したがってエラーが起きてもトライステップには進ませません。

厳密には、最終的にはトライステップでの分岐を利用しますが、なるべく設定箇所は少なくします。



そもそも個別のステップに設定させなければ設定漏れや設定間違いなどしようがないという逆転の発想です。

miniをお使いの方や、Kapplet等でAPI実行を利用する場合、エラー時にAPI例外でロボットが止まってしまうので、API例外のチェックだけは外してくださいね。

API例外

◆参考ナレッジ

ロボットの実行方法によるAPI例外発生時の挙動の違い

https://knowledge.bizrobo.com/hc/ja/articles/360036376152



まず、エラーハンドリングをスキップのままにする、ということは実線の分岐(ブランチ)がある場合には、エラーが発生してもロボットは停止せずそのまま次の処理に移ってしまうということになります。

ブランチの場合

前段の処理がエラーなく完了していることが前提になっている場合、そのまま処理してしまうとさらなる問題が発生する場合もあるため、本来は後続の処理をさせないようにしないといけない場合が多くあります。



そういう場合のためにトライステップに進ませて停止させることも多いのですが、先ほどのようにいちいち全ステップ設定するのは、長い長いフローを作っているとなかなかの苦行です。

かといってエラーが多く発生すると想定される数ステップだけの設定では、それ以外のステップで想定外の事象が発生した際、ハンドリングできずに不測の事態が発生しかねません。

具体的な設定方法

上記の問題を防ぐためにどうするかというと、エラーが発生しているかどうかを判定するためのフラグ用のグローバル変数を用意し、

フローの最初でフラグ変数をオンにし、エンドステップの手前でフラグ変数を解除します。



図にするとこんな感じです。

処理フラグ

次のブランチに移ったときにフラグ変数の値を確認し、フラグがオンの場合には後続処理に進ませないようにします。



そして、最後の後処理用のブランチでも判定させ、エラーが発生していたらエラーメールの送信やログ記録等エラー時の処理をし、

エラーが発生していなかったら正常終了として完了メール送信、といった感じにします。



これだけでもひとまずエラーが発生したかどうかの処理は分けられるのですが、じゃあどこでエラーが出たの?どう対応すればいいの?というのもメールで送ったりログに残せたら便利だと思いませんか?



もちろんManagement Consoleではエラー発生ステップのログ等は残ります。

しかし、例えば業務担当者にメールで次のアクションを教えたいとかってこともあると思います。



そのために必要なことは以下の通りです。

・Excelファイル上に、処理内容やその処理のエラー時にどう対応するか等をあらかじめ一覧化し、付番する

・ロボット上で大まかな処理のまとまりに入る際、Excel上で付番した通りの番号を記録する

・エラー処理時にExcelを参照し、エラー発生時点の番号に従ってエラー内容を抽出する



こうすれば、単純にロボットの処理が簡単になるだけでなく、Excelを見ればロボットを細かく見ることなく、想定されているエラーの内容がわかりますし、文言を変更したいときもExcelに書いてある文言を変えればOKになり、保守が楽になります。



設定例を見てみましょう。



■Excel

各番号と処理内容、対応内容等を記載しておきます。

画像6

■DSのフロー

大まかに見るとこんな感じです。

エラーハンドリングフロー例

■付番

変数の割当で各ステップに番号を記載していきます。

エラーNo割当

■付番通りにエラー内容を参照

付番通りに参照するには「名前付き範囲設定」を利用して番号を記録した変数をセルパターンに指定して検索します。

セルパターン

以下ナレッジもご参考ください。

「名前付き範囲設定(Set Named Range)」ステップ

https://knowledge.bizrobo.com/hc/ja/articles/360049840052



名前付き範囲が設定できたら、その範囲を頼りにセル位置を指定して値抽出します。

画像10

流れとしては概ねこのような感じです。

ログ記録やトライステップに進ませるための設定が漏れるというのも、そもそもはじめから設定などしなければ設定漏れは発生しませんし、想定外の箇所でエラーが出てエラーメールを送信できないとか、次の処理に進ませたくないのに進んでしまうということもありません。

まとめ

長々と書いてしまいましたが、いかがでしたでしょうか。

こちらの記事が皆様のロボット作成に少しでも参考になれば幸いです。

なお、今回は細かく触れませんが、複数ファイルやExcelで複数行を繰り返し処理させ、エラーになっても続行して後続ファイルやほかの行を処理したいから処理を止めたくないということもあると思います。

この場合でも少し工夫すれば上記の方法を利用できます。

詳しいことは別の機会に書ければと思いますが、エラーが発生したファイルや何行目かを記録しておくことは容易に可能です。



まだまだ模索中ですので、もし、こんな方法もあるよ!もっとこうしたらどう?みたいなことがあればコメントいただけますとありがたいです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?