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.

IBM RPAでの例外ハンドリングについて考えてみる

Last updated at Posted at 2022-07-25

業務ユーザーによるボットの実装の注意点

RPA(Robotic Process Automation)はビジネス・ユーザーにも実装しやすいソリューションではありますが、ビジネス・ユーザーによって実装された場合には以下の様な問題が起きがちです。

  • エラーハンドリングの不備
  • テスト不足
  • パフォーマンスの低下
  • ネーミング・ルールなどが無いことによるスクリプトのメンテナンス性の低下

これらの領域にはやはりIT部門に一日の長がありますので、RPAのプロジェクトであっても、IT部門を巻き込むことが重要です。この記事では、IBMのRPA製品であるIBMRPAを用いて、実際の例外ハンドリングの方法について整理したいと思います。

例外の処理方針

一番大切なのは、例外が起きた時にどのように処理するか、基本的な方針として決めておくことです。これが正解!という完璧な方針があるわけではないのですが、例えば以下のようなものです。

  • あらかじめ想定できる例外でリカバリー可能なものはハンドリングしてリカバリーする

例えば、エクセルのファイルを開こうとしてユーザーが開ていたために、開けないことが良くあります、このような典型的なケースではあらかじめ例外が想定できるので、
 1. RPA側から開いているファイルを閉じる
 2. ユーザーに、ファイルを閉じることを依頼するダイアログを表示させ、閉じてもらう
 といった対応をさせ、その場でリカバリーの手段を講じます。

  • 想定外の例外が発生した場合、"正しく"終了する

想定外の例外が起きたケースにおいては、どのように対応するか判断できないため、リカバリーすることができません。かといって、例外が起きたという情報を握りつぶして、ボットとして正常終了させることは好ましくありません。ログを出力する、あるいは、通知したのちに、ボットを異常終了として終了させる必要があります。そこで、
 1.エラーが起きた場合にはログを出力すること。
 2.スクリプトを異常終了として終了させること。
といった、共通の対応方法を規定しておくことが大切です。

  • ユーザーにシステムのエラー・メッセージを極力見せない。

ユーザーに対してどのような形でエラーが起きたとことを示すのか、それも方針といってよいでしょう。一般的にシステムの詳細な情報が含まれるログをユーザーに見せることは好ましくありません。

  1. エラーコード
  2. 一定時間後の再試行やシステム部門への連絡を促すメッセージ
    といった表示の内容などを統一しておきましょう。

中身としては、一見当たり前のことかもしれませんが、大切なのはこれらのことをすべての開発者が理解して開発することです。プロジェクトの開始前などに、基本的な例外ハンドリングを実装したサンプルなどを共有して、方針を確認することをお勧めします。

IBMRPAによる例外のハンドリング

IBMRPAには例外ハンドリングのために以下のコマンドや機能を提供しています。

  • エラーを処理
    image.png
    「エラーを処理」コマンドを使用することで、このコマンド呼び出し以降のスクリプト内(サブルーチンを含む)でエラーが発生した場合に、コマンドやサブルーチンを呼び出して実行することができます。エラー・ハンドリングの際に共通のエラー処理用サブルーチンを呼び出すのに適しています。サブルーチンの処理が完了すると、スクリプトはエラーとして終了します。スクリプトを終了させず、処理を継続するには次に述べる、「エラーからのリカバリー」コマンドを呼び出す必要があります。

  • エラーからのリカバリー
    image.png
    「エラーからのリカバリー」コマンドは、例外をエラーから回復する際に使用します。このコマンドを呼び出すことで、エラーが発生した直後のコマンドからスクリプトを再開することができます。

  • 正常終了フラグの活用
    多くのコマンドでは、処理が正常に終了したかどうかを示すフラグを返します。例えば、HTTPの呼び出しで404が返ってきた場合などは、呼び出し処理自体は正常に行われているのでエラーは発生しません。場合によってはこのフラグを確認して判断して対応する必要があります。

  • エラー情報の取得
    IBM RPAでは、エラーが発生した際にその情報を環境変数${wdg:error}に格納します。エラー発生時にはここに含まれる情報をログ出力するなりして、問題解析の際に使用できるようにしましょう。

  • 例外のスロー
    ユーザーがカスタム・メッセージを定義して独自の例外をスローし、呼び出し元のコンポーネントに例外を通知することも可能です。例外をスローする際には、「例外のスロー」コマンドを使用します。
    image.png
    メッセージのフォーマットなどを統一しておくことや、定義した例外の一覧などを管理しておくことも重要です。

まとめ

いかがでしたでしょうか?この記事では例外ハンドリングの基本的な考え方と、IBMRPAの例外に関する機能について紹介しました。RPAであっても、基本的な例外ハンドリングの思想は、他のプログラミング言語と変わりありません。プロジェクトの開始前に、例外ハンドリングの方針をしっかりと決め、開発者向けのガイドやサンプルを共有することで、一貫した例外のハンドリングを実装することをお勧めします。

※Japan Business Automation User Groupのご紹介

IBMのコミュニティーである、Japan Business Automation User Groupでは、IBMのBusiness Automation製品関連の様々な技術情報、イベント情報の参照や、フォーラムを介した技術的な質問を行うことが可能です。是非ご参加ください。 http://ibm.biz/JPBizAutomationUG

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?