Edited at

【RPA】【Blueprism】ことはじめ

More than 1 year has passed since last update.

image.png

RPAツール(Blueprism)での開発において、注意すべきことなどをまとめました。


綺麗なフローを書く

Blueprismでは、一般的なプログラミングによる開発ではなく、フローチャート(以下、フロー)のような図を描くことにより、ロボットの処理を実装する。

ホントにきれいなフローを描く人は、電気回路のような美しいフローを描く。

逆に汚いフローを描こうと思えばいくらでも描ける。例えば、線と線が斜めに交差して入り乱れていて、処理の流れが追いづらかったり、上から下に流れるフローではなく、右や左に流れたりしていると、読む側は非常にストレスとなる。


他アプリを操作する処理はオブジェクトに記述する

EXCELを開く処理をサブプロセスに記述。親プロセスから呼び出すと、サブプロセス終了時にEXCELが閉じてしまう。

これは、Excel VBOのCleanUpでClose All Instancesされるため。

また、例えばEXCELファイルAをオブジェクトAの関数を用いて開き、そのファイルをオブジェクトB(EXCELを開いたオブジェクトとは異なるオブジェクト)で閉じようとするとエラーとなる。


アプリケーションモデラーの定義

image.png

オブジェクトのみ、ブラウザ(IE)やデスクトップアプリケーションのラベル、ボタンなどをパーツとして登録することができる。

属性の定義がゆるいと、予期していないものをつかんでしまう可能性がある。

例えば、複数のダイアログが立ち上がってて、全てに「完了」ボタンがあった場合に、全ての完了ボタンをつかんでしまい、本来押下したかったボタンが特定できずエラー、などといったことが発生しうる。


変数の扱いに注意

変数が宣言されているプロセス、オブジェクトのページが実行されるたびに、その変数を初期化させることができる。

しかし、例えば、ループ内で使用する変数を定義した際は、1ループごとにその変数を初期化する処理を挟まなければならない。(変数初期化の最小単位はページ実行単位であるため)

また、同一プロセスの他ページでも参照できる変数を作った場合、その変数がどのページで定義されているのかを追いづらく、変数が画面に散らかりがち。

スコープの短い変数は処理の近くに置き、長い変数はMain Pageに配置するなど、ルール化したほうが良い。


ウェイトを挟む

ロボットの操作対象のアプリケーションによっては、ロボットの処理が速すぎて、ボタンをつかめなかったり、入力欄にパラメータを入力しそびれる、といった事象が稀に発生する。

そのため、適度にウェイトを挟みながら処理を進める必要がある。

(例)画面を開く⇒ウェイト1秒⇒画面をアクティブ⇒ウェイト1秒⇒ボタンにフォーカス⇒ウェイト0.5秒⇒ボタン押下


チーム開発

一般的な開発だとGitなどでソース管理をするが、blueprismでは難しそう。

各プロセス、オブジェクトをxml形式でエクスポートすることはできるが、アプリケーションモデラーの中身までは吐き出されないので不十分。

また、チーム開発する際は、同じプロセス、オブジェクトを複数人で開発することはできない。


とにかくエラーハンドリング

正常系を作るのはそれほど時間はかからないが、異常系のパターン洗い出しとその実装に時間がかかる。

ロボットが操作する対象のアプリの仕様を把握しておかないと、想定外のエラーが出たときにロボットがエラーハンドリングができない。

ログイン失敗パターンや、各画面の入力パターン、エラー、警告などのポップアップ表示箇所を網羅するなど、ロボット実装前の調査にも時間をかけたほうが良い。


EXCELの脆さに留意しておくこと

EXCELに記載されたパラメータをアプリケーションに入力する、といったロボットを作る際は、EXCELを操作するユーザーのEXCELスキルを期待しすぎないこと。

例えば、セルに日付が入るはずなのに「#####...」と変換されてしまい、ロボットがそれを解読できない、とか。

ユーザーが気を効かせてセルの書式などを変更したことで値が読めずエラーとなることもあるので、ブック全体に保護をかけておくなどして、予期しない変更を許容しないようにする工夫が必要。

また、ロボットが稼働してから分かったことだが、ユーザーは思った以上にEXCELに妙な加工を施すことが多く、EXCEL操作系のエラーはかなり頻発する。


Utilityを信用しすぎない

ライブラリに相当するのが「Utility」。ファイル操作、コレクション操作(Blueprismでは配列のことを「コレクション」と言う)など、汎用的な処理がまとめられている。

実態はVB.NETのソースであり、ソースを新規で作ったり、改修することにより、Utilityを拡張することが可能。

ただし、既存のUtilityの完成度はあまり高くない。エラーハンドリングが記載されていなかったり、そもそも使われていない引数があったりする。

また、改修する際は、既存のUtilityをコピーして別のUtilityを用意し、そちらを改修するのが良いかも。(バージョンアップでUtilityが上書きされる可能性が高いため)


リリース

リリースするプロセス、オブジェクト、環境変数は「パッケージ」として1セットにまとめることができる。が、なぜか環境変数だけは新しい環境変数の定義をリリースしても上書きされない。

(バージョンアップで改善される?)