More than 5 years have passed since last update.

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

いろいろなUiPath構成(Studio単体からOrchestratorまで)を速攻解説

Last updated at 2019-09-12Posted at 2019-09-10

概要

UiPathについてですが、まず初めは無償のCommunity Editionを用いて、このようなシンプルな構成ではじめたりすることが多いかと思います。

システム構成：最小構成

UiPath Studioをインストールして、Studio上からロボット(以下、ワークフローって呼びます¹)を実行するスタイルですね。

ところでみなさま、UiPath Studio以外のプロダクトも使っていますでしょうか？？
UiPath製品には、ロボットたちをサーバから管理するためのOrchestratorというプロダクトがあったり、UiPath社謹製のフレームワーク(テンプレート)が存在したりするのですが、それらを便利につかって実運用をしようとすると、たとえば全部のせで、こんな構成になったりします。。

システム構成：全部のせ構成

うーん、ごちゃごちゃですね┐('〜`;)┌。

さて本記事では**「最小構成」から「全部のせ」までいくつかの構成パタンを定義し、要所ででてくるプロダクトの簡単なご紹介**をしたいと思います。

使ったことのない構成がありましたらぜひとも興味を持っていただき、さわってみようというきっかけになればなー、、とおもってます。

構成1: 最小構成。UiPath Studioだけ

はじめに書いた、UiPath Studioだけをインストールした構成です。Community Editionは無償ですし²、1台のPC上で個人作業を自動化する目的なら、これで必要十分です。

UiPath Studio

プロダクト
- UiPath Studio
できること/メリット
- Studioだけあれば自動化できる
- 構築が簡単
できないこと/デメリット
- 他のPCでワークフローを実行出来ない

**商用版のUiPath Studioを使用する際には、本番運用時はロボットをアクティベーションして利用することが必須になりますのでご注意ください。**また、Community Editionを業務利用するには会社規模など一定の条件がありますので、そちらもご注意ください。

参考:https://www.uipath.com/ja/freetrial-or-community

さて、他のPC上でワークフローを実行したい場合は、次の構成となります。

構成2: Studio/Robot で開発と実行を分離

開発するPCと実行するPCを分けたときの構成はこうなります。UiPath Studioで「パブリッシュ」を行うと、ワークフロー名.nupkgみたいなzipファイルが出来ます。このファイルをUiPath Robotがインストールされた他のPCへ転送(メールでもファイルサーバ経由でも)³ することで、開発したワークフローを他のPCで実行することが出来ます。

パブリッシュ中

UiPath Robot(他のPC) からワークフローを実行

プロダクト
- UiPath Studio(開発PC)/Robot(実行PC)
できること/メリット
- ワークフローの開発と、ワークフローの実行を別々の環境にすることができる
できないこと/デメリット
- 転送(配布)が面倒くさい
- hogehoge_20190909_02.nupkgみたいな、よく分からないバージョンの nupkgファイルが発生し、バージョン管理がカオス化する
- 知らないところで、知らない人が作成したnupkgが運用される(いつの間にか作成者が辞めちゃってたり)

開発と実行が分離されましたが、開発PCと実行PCが複数台になってくると**「このnupkgは、どのPCで実行してよいワークフロー？？」「このバージョンって、xx対応入ってる？」など、管理が大変**になってきそうですね。

構成3: Orchestratorで統制する

前の構成に、サーバ製品である「UiPath Orchestrator」を導入した構成です。特徴は

リリース/配布する「ワークフロー」の管理
「ワークフロー」を実行するPCの管理
「ワークフロー」のリモート実行、スケジュール実行
他システム連携
StudioとRobotのライセンスの管理
カスタムアクティビティの管理

などがあります。Orchestratorは高機能で重要なプロダクトなので、すこし詳細に見てみます。

3.1 リリース/配布する「ワークフロー」の管理と、実行PCの管理

Orchestratorのワークフロー(*.nupkg)を管理する仕組みは以下の通り。

開発者が「パブリッシュ」を行うと**nupkgが Orchestratorサーバに送信**される
図中の運用担当者が、WEB画面を使って**「リリース作業」行うと、Orchestratorに送信されたnupkgが実行PCへ自動配布**される

このnupkgの配布の仕組みにより、運用担当者がOKをだしたバージョンだけ本番リリースすることができます。また運用担当者がリリースをするときに「どのコンピュータ(ロボット)で実行してよいか」を指定することができるので、ワークフローを実行可能なPCの管理 もおこなう事が可能です。

開発者が、Orchestratorへパブリッシュする画面。

運用担当者のリリース作業を実施する画面

3.2 「ワークフロー」のリモートからの実行、スケジュール実行

リモート実行は、ある意味Orchestratorの目玉機能かもしれません。Orchestratorで管理されるロボットには**「Attended Robo(AR)」「Unattended Robot(UR)」**というライセンス形態があります。ARは通常のロボット同様にヒトがワークフローを起動する、有人運用向けのライセンスで、URはリモート実行が可能な、無人運用向けライセンスです。

URなロボットはWindowsが起動さえしていれば(ログインすら不要) OrchestratorのWEB画面上からの指示により「ワークフロー」を遠隔から実行可能となります。

またURはスケジュール実行が可能なので、毎日夜間に処理をさせるなどバッチ的な使い方ができたりします。

こういう海外製品のスケジュール機能って、日本固有の祝日や業界固有の休日(証券取引所の営業日とかね)とかに弱くてつかえないことも多いんですが「非稼働日設定」ができたり、それなりにつかえそうな機能です。

3.3 他システム連携

たとえば先の「非稼働日設定」などでも機能不足だったり、もしくは独自のスケジューラ(JP1とか千手とかね)をすでに持ってたりするばあい、他システムからOrchestratorの機能を呼び出したくなります。

そんな、**他システムからOrchestratorのいろいろな機能を呼び出すために、OrchestratorはRESTのAPIをもっています。**それを用いることで、独自のスケジューラからAPIを叩いてワークフローを実行することもできます。

また、実行されたワークフローの完了などは、OrchestratorのWebhookで通知を受け取ることが出来るので、実行から正常終了まで、他システムで制御することができそうですね。

うまく使うことで、ワークフロー間の連携に使うことも出来そうです！⁴

3.4 StudioとRobotのライセンスの管理

このへんからなんか仕事っぽい(?)話になってきますが⁵、、、、。

Orchestrator管理下のStudioやRobotたちは、いわゆる新規やライセンス更新時のライセンスアクティベーションが自動で行われます。ライセンスの管理なんてなんかうれしい？？っておもうかもしれませんが、ウン十台のロボットを各ユーザが自身で操作してライセンス更新するなどは、なかなか大変だったりします。Orchestrator管理下のPCたちは、それらの作業から解放されるということです。

またOrchestrator配下のロボットには**「同時利用ライセンス(Concurrent)」というライセンス形態**があり「Studioは同時起動xx台まで」とか「ARは実行可能状態にできる台数は何台まで」みたいなライセンス形態で利用することが可能です。とても便利です。

3.5 カスタムアクティビティの管理

このあと出てくるカスタムアクティビティ開発ですが、カスタムアクティビティはワークフロー同様ほかのPCへの配布をどうやるかが課題となります。Orchestratorは開発したアクティビティを配布する機能を持っていますので、カスタムアクティビティを積極的に開発するのであれば、Orchestratorを置くととても運用が楽になります⁶。地味に重要なポイントです。

さてさて Orchestratorによって「ワークフローや、それを動かす実行環境」の統制が出来ることがわかりました。。つづいて「開発する環境」の統制、いわゆる開発の標準化を見てみます。

構成4: Attended Framework/RE Framework

前構成に、UiPath Studio 開発PC上に**「Attended Framework/RE Framework」を追加**しました。

複数人で開発しているとよくでてくる「エラー処理(例外処理)」とか「ログ出力形式」など、定型化・共通化・ルール化したい大事なことについて、Framework(テンプレート)におまかせすることができます。

Attended Framework

プロダクト(前構成との差分)
- UiPath Studio(開発PC)上に「Attended Framework/RE Framework」テンプレート
できること/メリット
- ワークフロー開発者の負担軽減
- Attended Frameworkは小規模でも生産性が落ちない(くらいシンプル)
- RE Frameworkは、OrchestratorのQueue/Transaction機構を使ったベストプラクティスな運用が出来る
できないこと/デメリット
- RE FrameworkについてはOrchestrator導入が前提となっている
- RE Frameworkは多少複雑なので、小規模だと重厚長大すぎる(学習コストが開発規模を上回る可能性)

Attended Frameworkについては別途整理したことがあるので、興味がある方は以下をご参照ください。

参考: UiPathの Attended Framework テンプレートを使ってみた

以下は重厚長大だと言った、RE Frameworkです。。ステートマシンを使ってて、わりと複雑に見えますね。。

構成5: カスタムアクティビティ開発

UiPathには、すでにたくさんのアクティビティが存在しますが、たとえば「自社ルールのチェック処理」など、アクティビティは存在しないけど自社の開発者が横断的で共通化したい処理などがあったりしますよね。「自社独自のエラー処理(xxログを出してxxへメール通知とか)」とかもそんな類です。

そういった独自のアクティビティを開発したいばあい、Visual StudioとC#をつかって「カスタムアクティビティ」を開発することが可能です。

独自に開発した、カスタムアクティビティ

それを開発するVisual Studio

プロダクト
- カスタムアクティビティを開発するための、Visual Studio
できること/メリット
- 独自の処理をアクティビティとして開発・配布できる。
- 存在するアクティビティを使って記述したXamlを実行できる「Invoke Workflow File」アクティビティとの違いは、
  - カスタムアクティビティは、他のアクティビティ同様の使い勝手(左ペインからDrag&Dropなど)で利用できる。
  - そもそも「Invoke Workflow File」はすでにXamlを実行するだけで、C#などを使うための機構ではない
できないこと/デメリット
- C# など、プログラミングスキルが必要

ところでカスタムアクティビティの配布は「NuGetサーバ」というWEBサーバが必要ですが Orchestratorがその機能を持っているので、図のようにOrchestratorからアクティビティの配布が可能です。

ちなみに「Invoke Workflow File」などで実行出来るXamlを「カスタムアクティビティ」として使用する「ライブラリ」機構というのもあり、それを使うと C#を使わなくてもカスタムアクティビティを作成することは可能です。既存のワークフローを手っ取り早くカスタムアクティビティにするにはこの機構が適していますが、アクティビティのGUIを緻密に設定したい場合や、そもそも既存のアクティビティで実現できない処理を実装したい場合は、C#を用いたカスタムアクティビティ開発をする必要がありそうです。

参考: UiPath Studio 2018.3 Early access - Beta release をさわってみた2 (カスタムアクティビティ)

構成6:「全部のせ」。Elasticsearch/Kibana 追加

いよいよ最後です。

さて**「リリース時や実行環境の統制」も出来ましたし「開発時の開発標準の整理」も出来ました。あとは日々の運用に入ったときのコトを考えてみます。Orchestratorを導入したことで無人運用や夜間運用など、人の目をはなれたところでロボットたちが稼働している状況です。そうするとロボットたちがちゃんと働いているかな？？とかサボってるヤツ(使われていないロボットって意味ね)はいないかな？とか、やたら時間がかかるワークフローを動かしているロボットがいないかな？などなどを日々チェックしたくなります**よね。

ただOrchestratorのダッシュボード(トップ画面)はとっても質素です。

Orchestrator ダッシュボード

そこでOrchestratorのログを分析してくれるElasticsearchと、それをグラフィカルに表示してくれるKibanaを導入します。Orchestratorに蓄積されたロボットたちの稼働ログを Elasticsearch/Kibanaに格納することでさまざまな切り口でロボットの稼働状況を閲覧することが可能になります。

ダッシュボードはいろいろカスタマイズ可能になっています。たとえば上記はKibanaのダッシュボードのサンプルですが、Orchestratorのログをつかって、

ある時間帯の処理件数
ある時間帯のエラー件数
ある時間帯のワークフローごとの処理件数
ロボごと、ある時間帯の1分ごとの稼働件数
ある時間帯の1分あたりの処理件数
ある時間帯に発生したワークフローのエラーメッセージ

などなどをグラフィカルに表示したモノです。

こういったツールを導入することで、ロボットが正常に動いているかはもちろん、たとえば利用頻度が低いロボットのライセンスを見なおすとか、やけに時間のかかっているワークフローの処理を見なおすとか、**ロボットたちの未稼働時間帯をみつけてもっと働かせる(!)**とか、そういったことが可能になるわけですね。

補足: その他

補足として、さきほど記載した「ライブラリ」機構(既存のワークフローを手っ取り早くカスタムアクティビティにする機構)と、ソースコードを管理するためのGit/Subversion/TFS を追記しました。

UiPath Studio上でプロジェクトを新規作成する際「ライブラリ」を選択、そして共通処理をStudioで記述して(つまりxamlです)パブリッシュします。するとOrchestratorにカスタムアクティビティとしてアップロードされ、Orchestrator配下のStudioやRobotたちから、そのxamlがカスタムアクティビティとして使用可能になります。

ほとんどワークフローのパブリッシュとおなじ

またソース管理については、いままで TFS/SubversionしかつかえなかったStudioですが、2019.xのバージョンから待望のGit対応がされました。Git使いとしてはうれしい限りです :-)。

まとめ

なかがったですね。さいごに各構成をまとめてみます。

| 構成 | 主要プロダクト |特徴/目的 |
|:-----------|:------------|:------------|:------------|
| 構成1: UiPath Studioだけ|UiPath Studio|シンプル|
| 構成2: Studio/Robot で開発と実行を分離 |UiPath Studio/Robot|別環境で実行|
| 構成3: Orchestratorで統制 | UiPath Orchestrator|リリース運用・実行環境の統制|
| 構成4: Attended Framework/RE Framework |Frameworkテンプレート| 開発フレームワークで標準化|
| 構成5: カスタムアクティビティ開発 | Visual Studio|C#で共通処理|
| 構成6: Elasticsearch/Kibana |Elasticsearch/Kibana|運用状況の可視化|
| 補足: その他 |Library/Git/Subversion/TFS|ライブラリとソース管理|

UiPath製品群の構成例、いかがだったでしょうか？
これらはUiPathを使っていく上で重要な技術要素になってくると思いますので、これからもこれらをもうすこし掘り下げていきたいと思います。とくにカスタムアクティビティ開発やOrchestratorまわりでElasticsearch/Kibana を使う件などはまだまだネットにも情報が少なく、これから情報を収集・発信していきたいコンテンツですね。

これからもよろしくおねがいします。
おつかれさまでした。。。