有名どころのRPAツールでロボットを粛々と作り、実際にクライアントへの導入もしてきました。
最近ではRPAは完全にプライベートで触るだけになってしまいましたが（苦笑）いったんハッキリさせたいことがあり、筆をとった次第です。
ぶっちゃけて言うと、BluePrism、UiPath（以下Ui）、WinActor（以下WA）それぞれ導入経験がある中で、個人的に一番将来性があると思ったのはBluePrismです。（以下BP）
他の方のブログなりネットに出ている情報のとおり、大規模向けRPAツールということで、敷居が高いのではないかと思われる人が大変多い。。。僕はこの現状が悔しくてならないｗ
敷居が高い、の「敷居」とは何なのか？
ライセンス費用？
月10万（年間120万）ですよ？
べらぼうに高いわけではないと思います。
難しそう？
Uiのほうが難しい感じがします。ほぼVB.NETのコーディングですしｗ
WAは違う意味で難しい。。。＞＜
英語なんでしょ？
たどたどしいところもあるけど絶賛日本語化中だよ？
そもそもBPがあまりに認知度がなさすぎて、どういうツールなのかも認知されていないのが現状のようです。
憶測で敬遠されてしまう前に、ざっくりBPがどういうツールなのか紹介したいと思います。
※細かい技術的な説明は他の方に譲りますw
スタジオ画面です。ロボットの一覧などを表示する画面ですね。
BPではプロセスとオブジェクトを組み合わせてロボットを作ります。
プロセスはロボットの作業手順をフローに表したもの。
オブジェクトはWAのライブラリに相当するもの。ロボットの部品にあたるものですね。
上図ではUtilityとしてまとめていますが、BP標準のオブジェクトが豊富に用意されており、UiでできたことはBPもできると思って良いです。
もちろん標準のオブジェクトを拡張することもできます。言語は基本的にVB.NETですがC#、J#が選べるようです。
欲を言えば、コーディングする際にインテリセンス機能がほしかった。。。
プロセススタジオ画面です。
一番目にする画面の一つ。図は交通費検索ロボットのメインプロセスです。
僕がBPを推す一番の理由はこのUIです。
なんか、かっこいいじゃないですか
まんまフローチャートなわけですが、このUIのメリットはとにかく全体像が分かりやすいことに尽きます。とにかくスケールしやすい。
画面左の各パーツは「ステージ」と呼びます。ステージを組み合わせてロボットを作るあたりはUiやWAと同じですね。
図の青い枠はブロックと呼ばれるステージなのですが、UiでいうところのTry～Catchの中を表します。
UiはVB.NETのコーディングチックに表現されていたのが、BPだと完全に図として表現されます。
個人的にはこっちのほうが分かりやすいし扱いやすいです。
あと、UiやWAだと変数は変数一覧としてまとめられていましたが、BPでは一つのステージとして表現されます。
つまり一つのパーツとして扱われます。これもUiより好きなポイントですね。
変数のスコープ設定は、正直Uiのほうが細かく設定できるのですが、BPもスコープ設定っぽいことはできます。
同プロセスの他ページから呼び出せるか、とかページ読込のたびに初期化するかを設定できます。
オブジェクトスタジオ画面です。
実装が面白くなってくるとこの画面からしばらく抜けられなくなりますw
ブラウザ操作など、ブラックボックス化してもロボットの作業フロー全体の流れを追うのに差し支えない部分をまとめて記述するのが定石みたいです。
余談ですが、ブラウザ操作に関してはちょいちょいウェイトを挟みつつ実装する関係で、整理しつつ作っていかないとすぐにゴチャゴチャします。
ただ、そのゴチャゴチャをいかに綺麗に表現するかにこだわると、芸術家のような気分になりますｗ
ホント、美しく描ける人、いるんですよ。。。
『フローチャートアーティスト』とか命名したいくらいですｗ
アプリケーションモデラー画面です。
Uiでいうところのセレクタ画面ですね。対象システム画面の各要素を設定していく画面です。
アプリケーションウィザードにて、
・対象はどういったシステムなのか？（Windowsアプリ？Java？ブラウザ？）
・（対象がWebの場合）どのWebサイトの要素を設定したいのか？
初期設定を行い、後はひたすら画面の要素をパーツ化していきます。
属性の多さもさることながら、各属性の意味が分かれば非常に扱いやすいUIになっています。
UiだとほぼDOMを書いてるようなもんでしたからね。。。
要素をつかむ際はスパイモードにします。
スパイモードにはいくつか種類があって、IE HTMLモード、Win32モード（Windowsアプリ向け）、Regionモード（画像認識）などがあります。
対象のシステムに合わせて要素をつかめるので、UiやWAと比べると操作できる対象は多いと思います。
コントロールルーム画面です。
キューやスケジューラを設定し管理する画面です。（スケジューラに関しては後日書く予定）
BPではキューを使って、ロボットの進捗状況を管理します。UiのOrchestratorのキューと全く同じです。
BPでロボットを作る際はキュー管理はほぼ必須なので、プロセスを組むときにキュー登録やキューのステータス更新等の処理も盛り込む必要があります。
キュー登録を行うと、登録されたキューのItem Keyが返されます。
そのItem Keyがキューデータを一意に特定する情報となるので、ステータス更新やタグ更新を行う場合はItem Keyを使ってキュー取得＆更新を行う形になります。
キューにはいろいろと情報を盛り込むことができて、コレクションデータ（≒Uiのデータテーブル）を登録できるし、タグ情報や（例外発生時は）例外詳細も登録できます。
交通費精算の場合だと、経路情報などはコレクションデータ、タグ情報は「ファイル名＋経路情報の連番」を登録しておく、といった感じです。
リトライ実行時の優先度、リトライ回数、キューをロックしてからマークするまでの処理時間など。。。使いこなせばかなり細かいレベルでロボットの動作をモニタリングすることが可能です。
キューはログ情報も持っていて、例外発生したときにどのプロセス、オブジェクトのどのステージで止まったのかが追いやすいのもGood。
ロボットの処理の流れとしては、
キューを作る
⇒キューを握る（ロックをかける）
⇒処理実行（随時ステータス更新）
⇒キューをマークする（完了 or 例外）
がよく見かける形です。UiのReFrameworkと同じです。
（ReFrameworkが先なのかBPが先なのかどっちなんやろ。。。？）
BPに限っては、キューを理解せずしてロボットを作るにあらず、ですね。
作るロボットにもよりますが、個人的にはヘッダーと明細を分けてキュー管理するのが分かりやすいかもしれないです。
例えば交通費精算ロボットの場合は、交通費精算書ファイルごとにヘッダーキューデータを登録し、経路は明細キューに登録するといった具合です。
ヘッダーキューと明細キューはItem Keyやタグで関連付けておくと良いでしょう。
よし、疲れたｗ
次回へ続く、かも。
0コメント