力が欲しいか、くれてやる
はい。
どうやったらBlue Prismをマスターできるかと日々悶々としています。
RPAをやっている人とBlue Prism Worldで知り合いましたが、
マジで間接業務どげんかせんといかんと頑張ってる人ばかりです。
https://ciprogram.jp/rpa/blue-prism-world-tokyo-2019/
欲しいのは開発すれば、魔法のように永続するエンチャント
自分が手を動かすのには限界があります。
極限までショートカットを駆使して、マクロを駆使して業務遂行スピードをあげても担当者が変われば、その流れは断ち切れます。
自分を極限まで最適化しても、引き継ぎ相手はどうでしょうか。
RPAはそのショートカットや効率化のアイディアをフローチャートと共に保存し――保守は必要ですが――よくメンテナンスすれば永続化可能です。
担当者が変わって品質やスピードが変わることもない――
ドキュメントを読もう。さすれば道は開かれる
ということで、BluePrismPortalからドキュメントを読みあさりました。
会社から過去のくだらない手作業を片っ端から消し去るには、要否を検討するには遠回りです。
なぜなら不要と判断されずにずっとやり続けられた業務だから今更不要の判断が下せないのです。
であれば、片っ端から自動化する気概で戦おう。
正論を言えば要否から検討したいけど、そんな時間が残されてないのよねぇ。
ということで、誰かの助けになればと墓標のように勉強ノートを置いておきます。
Blue Prismドキュメントで目を通してほしいところ
ブラウザ自動化ガイド
2.3 プロセス名経由で起動する
Blue Prism 提供VBOのUtility - EnviromentのStart Processアクションでプロセスアタッチがいけるのね。
アタッチができなくて躓くところがあるから、この方法は道具箱にしまっておいて困ったときに試したいところ。
3.2 スパイモード
この辺り、項目をスパイできるかどうかで手探りで使っていたことは否めない。
ドキュメント内の要素名の命名時にスパイモードを末尾につけるという指摘も運用上メンテしやすくなるベストプラクティスだな。
- Win32 - IEウィンドウそのものを操作。ということは、最大化や、画面全体へのキー送信ができるわけですな。
- HTML - HTML要素だけを認識
- AA - 上記でスパイできない場合使用
3.8 ポップアップ
新しいオブジェクトを作成する必要あり。Win32かAAでスパイする。
IE固有のポップアップ結構あるから、Utilてきなものにまとめれば再利用性が高まりそうだな。
5.6 Javaアプリケーション
WebアプリケーションからJavaアプレットを起動するシステムもたまにある。
そういう時にはAMの設定時にJava統合技術を有効にする（Enable java integration technique）にチェックを入れれば
操作できまっせ。
環境変数とセッション変数
環境変数を使うメリットはオブジェクトやプロセスにパラメータをハードコーディングすると
パラメータファイルの場所が変更になった場合、オブジェクトやパラメータに変更が必要です。
可変もしくはマスタ的なパラメータは環境変数で管理しておいた方が無難。
じゃあ、どんなものが対象になるのというと――
- URL
- データ定義しているパス
- ファイル出力先パス
- 電子メールの設定情報（SMTPサーバのIPやポートなど）
- アプリごとのタイムアウト値
- アプリのログイン環境名
- アラートメール送信先
- その他修正が予想される変数
っていう感じです。
あまりRPAっぽくはないですが、DB接続先なども環境変数にするかどうか検討すべきですね。
環境変数名についてもルールを決めておいた方がいいでしょう。
システム名、プロセス名、部門名を入れて識別しやすくするなど。
例：人事システム - URL
これら開発標準として定義しておくべきかもしれませんね。
オブジェクト設計ガイド
少し触れましたが複数人で開発するなら命名規則も決めておいたほうがいいですね。
例えばオブジェクトであれば――
アプリケーション名 - 画面名
とか。
AMでスパイした要素に対してもこの辺りは定義しておいた方がいいですね。
一例ですが――
- txtユーザーID（UI）
- btnログイン（Win32）
上記の例では、要素がどんな種類のものか接頭辞で表しています。
txtであればテキスト入力項目で、btnはボタンですね。
そしてお尻にはどんなモードでスパイしたようそなのか。
これ地味に効いてくると思います。
開発中は試行錯誤してスパイするので朧げ覚えてますが、
しばらくたったら何でスパイしたっけとなり、オブジェクト内でその要素だけスパイモードが浮いているということも。
まあこの辺りはどれだけ厳密にコントロールしたいか、保守性を考えるかというところとのバランスですね。
オブジェクトに業務判定を実装しない。それはプロセスの役割
オブジェクト設計にあたり守る必要があるのは
オブジェクトには業務判定をゆだねないことです。
これをしてしまうと再利用性がぐんと下がります。
パラメータ渡しで切り分ければええやんという意見もありますが、
保守性を考えれば、小さなオブジェクトで作り分けたほうが俄然疎結合が実現できます。
ベストプラクティス
特にオブジェクトレイヤーの考え方は押さえておきたいところ。
- 待機ステージでレイテンシ吸収し、タイムアウトは例外をthrow
- 任意の待機を使用しない
- オブジェクトから公開されたアクションを呼び出さない
- オブジェクトで業務上の決定を下さない
- 例外を適切に設定
ほかにもたくさんありますが、特に重要だと感じた部分を抜粋しました。
1に関してはどのRPAでも同じですが、レイテンシが吸収できなくて、画面遷移前に項目探しに行っておちるだのっていうのは
良くある話。
ちゃんと項目が表示されたら、そこに値を設定するなどのWaitを入れましょうという話ですね。
2も同じく、だいたい10秒待てばいけるっしょ、いやいや、NWに負荷がかかったときに実行して良く止まるというのもありがち。
3は疎結合にしておきましょうということです。オブジェクトから非公開のアクションならいいですが、公開したオブジェクトを呼び出すと
呼び出した公開したオブジェクトを変更したくなった場合影響範囲が大木ですよという話。
プロセスで呼び出そうぜってことですね。
4は前述したとおり、これも再利用性を高めるのに重要。
5はtry catchをExceptionでしか処理しない人もいるけど、ちゃんと処理例外でわけて、例外ごとに振る舞いを替えようねという話です。