2017年頃からBlue Prismの仕事に関わっていますが、3年前の自分にBlue Prismを教えるとしたらここだけは伝えておく！というポイントをまとめてみました。
Blue Prismで何ができるのかを知る
下の図はタスクをためて、複数人でさばいて、結果を報告する業務を行う例です。
割とオーソドックスな例ですが、こういった業務を完全自動で行う仕組みを構築できます。
Blue Prismでよく使う用語と意味も合わせて描いてみました。
バージョン管理ができる
プロセス、オブジェクトのバージョン管理ができます。バージョン間の差分比較もできます。
履歴コメントにチケットNoと修正の詳細をきちんと書くなどして、バグ対応一覧のようなドキュメントとの突合もしやすくしておくと良いかもしれません。
複数ユーザーで同時開発ができる
複数の開発ユーザーで同じプロセスやオブジェクトを編集しようとすると、下図の画面が出てきて排他制御がかかります。チーム開発を想定した機能がライセンスコストを気にすることなく使えるのはいいですね。
（Blue Prismは本番環境での同時実行ロボット数＝ライセンス数となる。同時開発人数に制限なし）
いっぱいログを残してくれる
監査に対応すべく、Blue Prismでの操作のログを細かく取ってくれます。
環境別にUIの色を変えられる
開発/本番環境でUIの色を変えられます。リリース先を間違えるなどのミスを防ぐためにも、環境ごとに色は変えておきましょう。
開発を始める前に…
Blue Prismの使う前に、開発ルールや作るものの設計書をざっくりでも作っておくことをおススメします。
運用編でも触れますが、Blue PrismはROM（Robotic Operating Model）という開発・運用の方法論を持っており、その中で開発ドキュメントについて「こういうの作ったらいいよ☆」というのを紹介しています。
詳しくは↓にまとめてますので、読んでみてください。
ROMとは?
やりたいことの手順書を作る
自動化したい業務のイメージを関係メンバーに共有するために、画面キャプチャで簡単な操作フローを作ることをおススメします。
時系列に画面キャプチャを貼り付けていき、補足コメントを残すくらいで十分だと思います。
画面操作に複数パターンがある場合は、あらかじめこの資料に網羅しておくと後々手戻りが減ります。
input / outputの表を作る
どのシステムのどの画面のどの項目に、どこから値を取ってきてどのように入力するのか
を整理した資料があると良いです。
業務担当者との認識のズレは、「画面操作の流れ、パターン」「入力項目と入力値」でよく起こります。
なので、認識のズレによって手戻りが起こらないよう、操作フローとin/outの表で仕様の認識を合わせておきます。
エラー一覧を作る
操作対象システムの各画面別にエラーを洗い出し、
- どのエラーをハンドリングするのか？
- 業務担当者にどのようなメッセージで通知するのか？
- エラーが発生したら業務担当者はどうリカバリするのか？
を資料化しておくと良いです。
詳細設計書に正常系と異常系処理のどっちも書き込んでいくと、例外パターンが多い画面だと設計書がぐちゃぐちゃになりがちです。
エラー一覧とそれらのハンドリングについては別の資料にまとめたほうがスッキリします。
命名規則を定義しておく
Blue Prismで開発する様々なコンポーネントの命名規則をなるべく早い段階から定義しておきましょう。
後になって、いろんなプロセスから参照されまくってる状態でリネームしようとすると、入力・出力のパラメータがはがれてしまい再設定するハメになります。
なので、後からリネームする手戻りを極力避けるために、開発メンバー間で命名規則の定義はしっかり共有しておきましょう。
例えば、プロセス名は頭に連番を振るのか、「システム名_〇〇」と命名するのか。Salesforceを操作するオブジェクトの名称を「SF_〇〇」とするのか、「Salesforce_〇〇」とするのか、など。
代表的な命名規則について列挙しておきます。
| コンポーネント名 | 命名規則の例 |
|---|---|
| プロセス | XX_システム名_業務名（※） |
| オブジェクト | システム名_画面名 |
| ワークキュー | プロセス名 + キュー |
| 環境変数 | システム名_用途（Salesforce_URLなど） |
| 認証情報 | ランタイムリソース名 |
| 認証情報の各プロパティ | システム名_用途（Salesforce_ユーザー名など） |
（※）1業務を複数プロセスで繋いで実行する場合、時系列で連番を振っておくと見やすいです。
アプリケーションモデラーの命名規則の例
| 画面要素 | 命名規則の例 |
|---|---|
| ウインドウ | window_〇〇 |
| タイトル | title_〇〇 |
| リンク | link_〇〇 |
| ボタン | button_〇〇 |
| テキストボックス | text_〇〇 |
| チェックボックス | check_〇〇 |
| コンボボックス | combo_〇〇 |
| ラベル | label_〇〇 |
プロセスを上手に作るコツ
プロセスとは？
例えば、
①処理対象の申込収集 ⇒ ②顧客登録 ⇒ ③承認 ⇒ ④申込内容登録 ⇒ ⑤メール通知
といった大きな業務の流れがある場合、プロセスは5つになります。
複数のロボットにタスクを分散させたい業務単位＝プロセス、と考えると分かりやすいかもしれません。
プロセステンプレートを使う
Blue Prismが推奨しているプロセスのフレームワークです。
よほど簡単なプロセスでない限りは、この型に当てはめる形でプロセスを作っていくと良いです。
プロセステンプレート
仕組みをざっと理解する
下の図を理解できればまずはOK。
前述した「やりたいことの手順書を作る」の図と流れが似ていることが分かる…はず。
プロセステンプレートをちょっと改良する
基本的にはプロセステンプレートに沿って作っていけば良いのですが、
例えば「スタートアップ」では、さばくべきタスクあるなし関わらず、まずはログインしようとします。
さばくべきタスクがないなら、ログインする操作は無駄ですよね。
…といった具合にプロセステンプレートもいくつか改善の余地がありますし、作ろうとしているプロセスの仕様次第でもカスタマイズが必要になります。
基本的な流れ（タスクをとる⇒さばく⇒完了マークする）は変えないようにしつつ、パフォーマンスを上げるための修正が必要になるかも…とだけ頭の片隅に置いておきましょう。
グループの分け方
プロセスをグルーピングすることができます。
部署間でシステムを共有することが多いと思うので、ルートはシステム名、サブフォルダは各業務名にすることが多い気がします。
同じ業務でも部署によってやってることが違う場合は、プロセスの入力やワークキューのタグによって処理を分岐させます。
ページの分け方
「ワークステップ1」などのページをどのくらいの粒度で分割すべきかですが、個人的には画面単位で良いと思います。
その他Tips
データアイテムを美しく配置する
本来「ブロック」ステージは、TryCatchの範囲指定をするためのステージなのですが、
データアイテムの配置の見栄えをよくするためにも使います。見やすい実装を目指しましょう。
ワークキューを理解する
ワークキューとは？
さばくべきタスクを溜めるための箱です。
タスクをただ溜めるだけではなく、
- 優先度を設定
- タスクに付箋を貼る（同じ人に振る作業でも、付箋の色によって作業を分けてほしい）
- 「〇時以降にさばいてほしい」タスクを設定
などなど、溜め方を工夫することでいろんなことができます。
また、ワークキューに溜まっている各タスクはケースと言ったりします。
タグを上手に使う
- タスクに付箋を貼る（同じ人に振る作業でも、付箋の色によって作業を分けてほしい）
これは「タグ」という機能を使うことで実現できます。
タグはとても便利な機能で、前述した「特定の人にさばいてほしいタスクを設定」とかもできちゃいます。
例えば、ロボットAが登録した顧客情報に対して、承認処理を行うのはロボットA以外にしたいという場合を考えてみます。
この場合、タグには登録をしたロボット名を設定しておき、承認処理を行うプロセスでケースを取るときに、以下の図のとおり「タグの〇〇というパラメータが含まれていないケースを取得する」ようにフィルターをかければOKです。
他にも、タグの値によって同プロセス内で処理を分岐させたり、直接処理には影響しないけどキー以外にも目印にしたい値がある場合はタグ付けしておくことで、エラー発生時に原因究明の時短に繋がったりします。うまく使いこなしたい機能です。
グループの分け方
ワークキューもグルーピングできます。
1業務を複数プロセスに分割して行っている場合、その業務名をグループとすると良いと思います。
ワークキューは数が増えるとごちゃごちゃしやすく、コントロールルームで目的のワークキューを探す時間がもったいないので、できるだけグループ化して見やすくしておくと良いです。
オブジェクトを上手に作るコツ
オブジェクトとは？
主に操作対象のシステムの操作をまとめたパーツです。
システムの操作以外にも、例えばExcelの操作をまとめたオブジェクトや、コレクションの編集を行ったり、ファイル操作を行うオブジェクトがあります。
これらはVBO（Visual Business Object）と呼ばれ、Blue Prism標準で用意されています。
グループの分け方
プロセスと同様、オブジェクトもグルーピングすることができます。
オブジェクトの場合、メニュー単位でグルーピングすることが多いです。
アクションページ
各オブジェクトにはアクションページと呼ばれる単位があります。
画面操作のオブジェクトの場合は、「〇〇ボタン押下」といった操作単位でアクションページを作っていきます。
基本的には、アタッチ ⇒ 画面表示を確認（待機） ⇒ 操作、の流れで実装することが多いです。
画面遷移を伴う場合は、必ず遷移先の画面であることを確認する処理を挟みます。
検索ボタン押下後など、データ件数によって表示時間が変わるような操作の場合は待機時間を多めにとっておくなどして工夫します。
よく使うVBOを覚える
よく使うのは以下4つです。扱いに慣れておきましょう。
‐ MS Excel VBO
‐ MS Outlook Email VBO
‐ Utility - Collection Manipulation
‐ Utility - File Management
その他Tips
- ループ処理や判断ステージ（業務判断）は入れない
- 無条件の待機ステージは極力入れない
- 入力パラメータは汎用的に使えるように定義する
- 値が固定のデータアイテムは極力作らない ⇒ ブラックボックス化を防ぐため
- 環境変数を参照したい場合はオブジェクトに直接書くのではなく、プロセスからインプットさせる
アプリケーションモデラーを上手に作る（マジで大事☆）
アプリケーションモデラーとは？
操作対象システムの画面要素（ボタン、コンボボックス、テーブルなど）をBlue Prismが認識できるようにパーツ化したものです。
画面操作を行うオブジェクトを作る際は、このアプリケーションモデラーを定義するところから入ることが多いです。
この定義のコツを知っていないと手戻りが凄まじいことになります…（体験済）
属性の選択とパラメータ定義
下図のように画面の各要素をパーツ化していくためには、Blue Prismに画面要素を認識させる（＝スパイする）作業をしていきます。スパイするとその画面要素を特定するための「属性」が自動的に選択され、定義されます。
属性の選択はケースバイケースなことも多いのですが、
座標系の属性のチェックは外す
値が空白のものはチェックを外す
URLはチェックを外す
開発と本番環境でURLが異なる場合など、環境差異に対応するため。
マッチインデックスにチェックを入れる
同じようなボタンが並ぶような画面では、何番目のボタンかを明示することで認識ミスが防げる。
パスの定義には注意
表示されるデータ件数が変わったり、入力パターンによって構成が変わるような画面の場合、インデックス番号を埋め込みにしておいたり、チェック自体を外して他の属性でカバーするなど工夫が必要。
ただし、要素を一意に特定するには有効な属性ではあるので、画面構成が特殊でなければ極力チェックを入れる。
といったことに注意していれば、まずは大丈夫そうです。
属性を外しすぎると複数の要素にマッチしてしまいますし、多すぎると環境差異に対応できない可能性もあります。この辺りはやっぱりケースバイケースになってしまいますね。。。
環境ロック
例えば、Excelの処理結果一覧に累積で結果を記入するといった処理をする場合、複数の人が同時にExcelを編集すると、前の人の書き込みに上書きしてしまう恐れがあります。
また、タイミングによっては複数の人が同じシステムに同じアカウントでログインする可能性がある場合、排他制御によって誰かがはじき出されてしまいます。
そうならないように、「環境ロック」と呼ばれる仕組みを使って、同時にされると都合の悪い処理をする前にロックをかけてから行うことができます。
使い方は↓にまとめてますので、読んでみてください。
認証情報
ランタイムリソース自身へのアカウント情報や、操作対象システムへのアカウント情報をまとめた領域のことです。
ランタイムリソースの端末名＝認証情報名としておくことが多いです。
プロセステンプレートの冒頭で認証情報を取得する前に、自身の端末名を取得しておき、その端末名で認証情報を探しに行き、もしあったらその認証情報のプロパティを使ってシステムにログインする
といった使い方をよくしています。
環境変数
その名の通り、環境によって値が変わる変数のことです。
例えば、参照するファイルのパス、メールの宛先などですね。
また、仕様が変わりうる箇所に関連する変数も環境変数として定義しておくと便利です。
例えば、
- 開発環境とは違って本番環境が安定稼働しないといった状況の場合、リトライの回数を変えられるようにしておく
- 処理対象のデータ取得件数の上限値を持っておくことで、タスクが溜まってきてしまった場合に値を大きくすることで一気にさばく
など。
また、環境変数を別環境にインポートすると値は上書きされません。
本番環境にすでにある環境変数に対してインポートをしても、本番環境の値は開発環境の値に上書きされません。
まとめ
参考資料のベストプラクティスが理解できれば、Blue Prismエンジニア（？）としてバリバリ現場で活躍できるはずです☆
他にも大事なことが思いついたら随時加筆していきます。