Edited at

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


自己紹介


  • 木野 雅富( @masatomix )

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

  • UiPathとの出会い:2017/04 くらいに Studioより先に Orchestrator と出会う。
    以後、野良ロボ統制などを目的としたユーザ様にOC導入をメインでやってます。


    • その片手間でC#でカスタムアクティビティを書いたり。。



  • Qiitaにいろいろ書いてます



  • https://twitter.com/masatomix

  • 趣味: ボルダリング



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


  • 設定ファイルを読み込むための処理を、別ワークフローからコピペして...。

  • エラー処理(例外処理)どうやる

  • ログ出力は?

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



そこで Attended Framework


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



デモ


  • テンプレートはメインの業務処理を Process.xaml に書いていく仕組み



    • Main.xamlProcess.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に色々書いてますので興味がありましたら、見てみてください。。



関連リンク


ご清聴ありがとうございました。