More than 5 years have passed since last update.

株式会社プライム・ブレインズ

Attended Framework テンプレートを使ってみた(Slide版)

Last updated at 2019-08-06Posted at 2019-08-05

1 / 20

自己紹介

木野雅富( @masatomix )
株式会社プライム・ブレインズ
UiPathとの出会い：2017/04 くらいに Studioより先に Orchestrator と出会う。
以後、野良ロボ統制などを目的としたユーザ様にOC導入をメインでやってます。
- その片手間でC#でカスタムアクティビティを書いたり。。
Qiitaにいろいろ書いてます
- https://qiita.com/masatomix
https://twitter.com/masatomix
趣味: ボルダリング

ワークフロー作成時にいつもやる・考えること

設定ファイルを読み込むための処理を、別ワークフローからコピペして...。
エラー処理(例外処理)どうやる
ログ出力は？

→ いつもやることなので、共通化・ルール化したほうがよいですよね。。

そこで Attended Framework

UiPath 社が UiPath Go!で公開している「Attended Framework」テンプレートを用いることで、これらの**「メンドクサイ、、だけど大事」な部分をテンプレートにおまかせする**ことができます。

デモ

テンプレートはメインの業務処理を Process.xaml に書いていく仕組み
- Main.xaml が Process.xaml をInvokeする
(デモ実行) 設定ファイルを読み込むサンプル

いいところやTIPS集

設定ファイル読み込みの標準化

Data/Config.xlsxに、設定値をKey/Value形式で管理する機能を提供してくれます。

in_Config("logF_BusinessProcessName")  → AttendedFramework

設定ファイル読み込みの標準化(Cont.)

in_Config("logF_BusinessProcessName") = AttendedFramework
in_Config("Enable_Screenshot") = False
...
in_Config("logF_RobotType") = Attended
in_Config("Framework_Version") = 1.1.2.0

Excelファイルに追記することで、もちろん任意の値を追加することが可能です。
例: 入力データのディレクトリ、出力ディレクトリ、スクレーピング先のURL、、etc..

エラー処理(例外処理)

Process.xaml はテンプレートのTry/Catchに囲まれているので、Process.xaml がスローした例外は全てテンプレート側が後処理を行ってくれます。

テンプレートがやってくれること

例外が発生しなかったとき
- 正常終了のログ出力("Process successful.")
BusinessRuleExceptionがスローされたとき、
- 特に何もせず、発生した例外を再スロー
それ以外の例外がスローされたとき
- スクリーンショットをとって、発生した例外を再スロー

テンプレ自体は、、。

デフォルトのテンプレはたいしたことをしていないので、各社のRPA導入プロジェクトでルールを定め、定めた処理をココに追記し、それを自社独自のテンプレとして配布するようにしましょう。
「BusinessRuleException をつかって業務例外とそれ以外を分けましょう」というUiPath社の指針が示されていると理解。

各社で定めるべき例外処理の例

**「Process.xaml を作成する開発者は、業務例外(ビジネス例外)発生時はBusinessRuleExceptionをスローすること」**としておき、Framework側が、
- BusinessRuleExceptionがスローされたら、Message Boxでワークフローを起動した本人にエラーを通知
- それ以外の例外がスローされたら、(たとえば周辺システムの)想定外の障害の可能性があるので、システム管理者にもメールで通知

してあげる、などが考えられます。

ちなみにRE Frameworkなどはビジネス例外以外は処理をリトライする、などもっと高機能です:-)

ログ機能について

→時間の都合で割愛します (´Д`;)

テンプレートが「ログフィールドを追加」アクティビティで、いくつかログのフィールドを追加しています。

ワークフロー終了時に自動出力される実行ログ( C:\Users[ユーザ名]\AppData\Local\UiPath\Logs]\2019-08-03_Execution.log など)にも、

{
  "message": "AttendedFramework02 の実行が終了しました",
  "level": "Information",
  ... 省略
  "machineId": 4,
  "totalExecutionTimeInSeconds": 17,
  "totalExecutionTime": "00:00:17",
  "fileName": "Main",
  "logF_BusinessProcessName": "UiPath Developer Community vol.12 向け業務",  ← コレ
  "logF_TransactionStatus": "ApplicationException"  ← コレ
}

と追加フィールドが出力されるようになりました。

とくにlogF_TransactionStatus は先の条件分岐のどこを通ったかを示す結果ステータスなので、このフィールドを確認することでワークフローの正常/異常を確認することができます。

ログ機能について補足

Orchestrator/Elasticsearch/Kibana を導入している場合 アップされた大量のログを使って、ワークフローの稼働件数や稼働時間を集計することができたりします。
Kibanaは「処理件数」「エラー件数」「ロボごとの、時間帯ごとの稼働件数」「指定した時間帯のエラーメッセージ」などなど、ユーザが統制上必要とする情報をキレイに可視化することができて、とてもイイですね。

下記のキャプチャはElasticsearchに蓄積された大量ログのうち、実行完了ログだけをKibanaで抽出し、Kibanaのダッシュボードでロボット達の稼働状況の可視化を行ったサンプルです。

まとめ

設定ファイル読み込みを自動でやってくれるのはとても助かる
定番の例外処理も、BusinessRuleException などUiPath社の指針が示されているので、例外設計がしやすくなる。
例外処理などはRE Frameworkとも思想が類似しているので RE Frameworkを使うまえの題材としてもちょうどよい
ログ出力もElasticsearchやKibanaなどによる集計を見据えたフィールド追加がされているのがよい
UiPath Go!にサインアップしないとダウンロード出来ないのは非常にメンドクサイ

などなど。目先の作業をさらっと自動化するなど、小規模の場合でも生産性は落ちないので、使わない手はないなーーとおもいました。

まとめ2

「テンプレート自体に更新がはいったとき」どうやって各開発者の端末に反映させるの？
開発時と本番で設定ファイル替えたいんだけどどうする？
RE Framework とのちがいは？どっちがイイの？

などなど他にもいろいろ話したいのですが時間切れです。
Qiitaに色々書いてますので興味がありましたら、見てみてください。。