1.はじめに
UiPath AcademyのLevel3に登場するReFramework。
利点はたくさんあるものの、複雑でとっつきにくい点もあります。
Academy Level3を進めた経験をもとに、備忘を兼ねて仕組みをざっくり記録しておくことにしました。
-
こちらの記事では、ステートマシンを利用したReFrameworkの仕組みの大まかな理解を目指します。
- それぞれの処理の詳細や処理を追記していく際のポイントなどは当記事には記載せず、別記事にする予定です。
- 詳細でスマートな記事を今すぐ読みたいという方はこちら(yuyu_heart_star様)
-
日本語版が発表されましたので、日本語版をベースに記載しています。
- 日本語版ReFrameworkはこちら
2.この記事のターゲット読者
- UiPath Academy Level2まではクリアしており、Level3に取り掛かりたい方
- 細かいことはとりあえず置いておき、仕組みを理解しておきたい方
3.前提知識
3-1.フレームワークとは
一般的には「枠組み」「骨組み」「構造」を示します。
SWOT分析やロジックツリーなどは課題解決のためのフレームワークにあたります。
RPAエンジニアの間では「アプリケーションフレームワーク」に近い意味合いで使われているようです。
誤解を恐れず、ものすごくざっくり言えば、
一般的に考慮するべきポイントや機能を実装済みのテンプレート
のようなものです。
シナリオが動き始めたときに必ず行う処理や、エラー終了時の処理など、
どのようなシナリオだとしても汎用的に実装する機能を予め実装しておけば、毎回同じ処理を実装する手間が省けます。
フレームワークを利用することのメリット
- シナリオ開発時の生産性の向上
- シナリオをイチから作る必要がなく、必要なポイントもすでに設計済みのため
- シナリオの品質向上
- 必要なポイントはフレームワークの中に設計済みで、考慮漏れを防止できるため
- 保守性の向上
- 同一のフレームワークを使用することで設計がある程度標準化されるため
ReFrameworkで考慮されているポイント例
- エラーハンドリング(Try-Catch)
- システム例外のCatch
※システム例外：処理対象の要素が見つからない・立ち上げるアプリが見つからない等のアプリケーションやシステム依存のエラー - ビジネス(ルール)例外のCatch
※ビジネス例外：入力データが想定と異なる等、システムに依存しないエラー
- システム例外のCatch
- ログ出力
- リトライ設定
- キューの使用(大量の入力データを処理する際に利用する仕組み。Orchestrator要)
- ワークフロー外に置いた設定ファイル(Config.xlsx)の使用
- 認証情報の取得
などなど...UiPath公式の解説はこちらです。
3-2.ステートマシンとは
ReFrameworkはステートマシンアクティビティとステートアクティビティで作成されています。
ステートマシンは（これまた誤解を恐れずに）ざっくり言うと、
とある状態（ステート）から別の状態に遷移する処理を表現する仕組み
です。これだけだと何が何やらなので、実際のステートアクティビティを見てみます。
このステートでは何をするか(Entry)、
このステートを終わるときに何をするか(Exit)、
次の遷移先となるステートや、そのステートに遷移するときの条件等(Transition(s))
を記載することで処理の流れを表現します。
このサンプルだとこのような感じです。(clickで展開)
・ 現在のステートは「初期化」
- Entryに記載された処理を実施
- Exitは空欄なので処理なし
・ 次の遷移先となるステートは条件により分岐
- 【成功】であれば「トランザクション データを取得」へ
- 【システムエラー】であれば「プロセスを終了」へ
これをシーケンスやフローで記載しようとすると、意外と複雑なことになります。
処理の結果により次に行う処理が複雑に分岐していくようなケースは、ステートマシンで表現するとすっきりするかもしれません。
■参考資料
公式ドキュメント：こちら
Qiitaでのまとめ記事：こちら(Umemaru様)
4.ReFramework全体像(Main.xaml)
日本語対応し、とてもわかりやすくなりました。
ステートを１つ１つ見ていきます。
4-1.初期化
Entry処理
設定ファイルの読み込みや使用するアプリケーションを事前に立ち上げるなど、本処理を行う前の下準備を行います。
処理の概要(Clickで展開)
InitAllSettings.xaml
・ ConfigファイルからSettingsシートの情報を読み込む
・ ConfigファイルからAssetsシートの情報を読み込む
KillAllProcesses.xaml【更新要】
・ 処理に使用するプロセスを強制終了する
- 処理前に立ち上がっていたら困るアプリのプロセスを閉じておく。よくあるのはブラウザ系
- 強制終了アクティビティで閉じるプロセスの指定が必要となる
InitAllApplications.xaml【更新要】
・ 本処理に使うアプリケーションを立ち上げておく
- 以降の処理で使用するWebページやアプリケーションを立ち上げる処理を追加する
その他
・ 本処理で処理対象となるデータの読み込み【場合によって追加要】
- 処理対象トランザクションを全件読み込んでおく処理を追加するケースがある
(キューを使用しない場合、等）
Transition(s)
- 処理に成功した場合、「トランザクションデータを取得」に遷移。
- システム例外がある場合、「プロセスを終了」に遷移。
4-2.トランザクションデータを取得
Entry処理
処理対象となる全データのうち、次に処理するデータを取得します。
処理の概要(Clickで展開)
GetTransactionData.xaml【場合によって更新要】
・ トランザクションアイテムを取得
- キューを使用する場合、更新不要
- キューを使用しない場合、取得したいトランザクションの型に合わせたデータ取得の処理を追加する必要がある
Transition(s)
- 新規トランザクションがある場合、「トランザクションを処理」に遷移。
- 新規トランザクションがない場合、「プロセスを終了」に遷移。
4-3.トランザクションを処理
Entry処理
取得したトランザクションデータに対して本処理を行う。
処理の概要(Clickで展開)
Process.xaml【更新要】
・ トランザクションデータに対して行うメイン処理を記述する
SetTransactionStatus.xaml【場合によって更新要】
・ トランザクションデータに対して行った処理の結果ステータスを設定する
・ 次のトランザクションデータを取得するための準備を行う
・ キューを使用しない場合、Orchestrator連携のアクティビティを削除する必要がある
TakeScreenshot.xaml
・ エラー終了時の画面をキャプチャする
Transition(s)
- システム例外がある場合、「初期化」に遷移
- Configファイルに事前に設定された回数分、「初期化」に遷移し処理をリトライする。
- ビジネス（ルール）例外がある場合、「トランザクションデータを取得」に遷移
- ログ（ビジネス例外を起こしたデータの情報）を出力し、次のデータ取得へ
- 処理に成功した場合、「トランザクションデータを取得」に遷移
- 次のトランザクションデータ取得へ
4-4.プロセスを終了
Entry処理
アプリケーションのプロセスを終了する。
処理の概要(Clickで展開)
CloseAllApplications.xaml【更新要】
・ 処理に使用したアプリケーションをすべて閉じる
・ 閉じるアプリケーションを指定する必要がある
5.各ケースの処理の流れ
各ステートの処理について大まかに理解したところで、
想定される処理ケースがどのような流れとなるか見ていきます。
5-1.正常ケース
トランザクションデータが全件正常に処理される際の流れです。
5-2.トランザクションデータに誤りがあるケース(ビジネス例外)
（後日追加します）
5-3.トランザクションデータ処理中にシステム例外が起こったケース
（後日追加します）
6.まとめ
一つ一つのxamlや変数を追っていけば処理している内容ややりたいことはわかるものの、いざ全体処理⇔部分処理を行き来しながら処理を実装していると混乱してしまうことが多かったです。
そのため、俯瞰的な情報を残したいと思い、記事を作成しました。
少しでもお役に立てれば幸いです。
7.おまけ。少し細かい話
各ステートで呼び出されるxaml＆各変数の役割の簡単解説です。
（後日追加します）