fbpx
■サイト内検索:
RPA.biz
RPA Biz > 2020年

キューの使い方って?~キューとトランザクションについてと管理画面の説明~

2020.04.14

データテーブルやエクセルの表のようなデータの集合体を処理する際に便利なOrchestratorの機能「Queue キュー」を使用したロボットの作り方について何回かに分けて開発現場で使用した例をもとに解説していきたいと思います。

今回はキューとトランザクションについての説明と、キューの作成方法と画面の解説をしていこうと思います。

 

 Queue(キュー)とは?

ざっくり説明すると、無期限にデータを保管できる収納機能といえます。

キューに格納されたデータをロボットが処理を実行しその実行結果や実行日、実行ログ等をOrchestratorより確認できます。

そのためOrchestratorを使用されていて且つ大量データの処理を行う場合は、キューを使用すると処理対象のデータ管理や結果確認等が簡単に行えるかと思います。

 

もう少し細かくキューについて説明していきます。

顧客データや商品IDなど様々なデータ項目の事をキューアイテムと言います。

このキューアイテムは、Studioアクティビティ「キューに追加 Add Queue Item」を使用してデータをセットすることができます。

 

Studioアクティビティ「キューを取得 Get Queue Items」等を使用しキューアイテムの処理を行うとトランザクションになります。

 

図を使って説明すると下記のように上から下に向かって処理が進み、その過程でキューアイテムからトランザクションへと移り変わります。

この例では処理対象データをエクセルより取得し、取得したデータをキューに追加します。

キューに格納されたデータはキューアイテムとなります(未処理のデータ)。

次に格納されたキューアイテムをロボットが処理を行うとトランザクションとなり、処理結果やステータスがトランザクションに追加されます。(処理済みのキューアイテム)

 

よりキューとトランザクションについて詳しく知りたい方はこちらをご確認ください。

 

 

キューとトランザクションについてイメージがついてきたでしょうか?

続いてはキューを使用する場合に必要なロボットの処理をあげていきます。

業務の処理を除いた場合ざっくり分けると下記の2つの処理が必要になります。

 

 

――――――――――事前準備――――――――――

Orchestrator上のキューに格納する先(収納スペース)を作成

 

――――――――――キューにデータを追加――――――――――

  • 処理データを取得
  • 取得したデータをキューに格納

 

――――――――――トランザクション処理――――――――――

  • キューアイテムを取得
  • 取得したデータを処理(自動化対象の業務)
  • トランザクションステータスを更新

 

 

よくあるパターンは、キューにデータを追加処理トランザクション処理でロボットを分けることが多いです。

理由は、処理データが追加されるタイミングと、実際にデータを処理するタイミングが異なる場合が多いためロボットを分けて実行する方が、実行ロボットを長時間専有せずに済むからです。

 

 

 キューの作成

始めに処理データを格納するキューを作成しましょう。

Orchestratorにログインし管理画面(ダッシュボード)を開いてください。

左側のメニューバーのオートメーション>キューを開きます。

 

表示された画面には、作成したキューの一覧が表示されここから実行結果やステータスを確認することが可能です。

 

 

 

右上にある+(追加)ボタンをクリックすると、キューの新規作成画面が表示されます。

 

                                                                                                                                                  

【必須】名前:キューの名前

【任意】説明:キューに格納するデータの説明文

【任意】一意の参照:

はい:追加されるデータに一意の参照を設定するように指定できます。

いいえ:重複した参照を持つデータをキューに含めることができます。

【必須】自動リトライ:

はい:エラー(アプリケーション例外)発生時に再試行を行います。

いいえ:いかなる場合でも再試行を行いません。

【必須】最大リトライ回数:エラー(アプリケーション例外)発生時に再試行する最大回数。

 

上記の項目を入力後、「追加」ボタンをクリックすると新しくキューが作成されます。

  

 

キューの処理終了後に各データの実行結果を確認する場合はロボットの実行ログから確認するよりも、トランザクションを表示から確認するとわかりやすいと思います。

 

次はトランザクションの確認方法について説明していきたいと思います。

 

 トランザクションの確認

「トランザクションを表示」より、かくトランザクションの実行結果や実行日などが確認できます。

表示方法はキューの管理画面の対象トランザクションが格納されているキューの右側にある「…」(その他のアクション)をクリックし「トランザクションを表示」をクリックすると各トランザクションの詳細情報が表示されます。

 

 

トランザクションの一覧ページです。ステータスや実行ロボット、実行日などを確認することができます。

より詳細情報を確認したい場合は、対象のトランザクションデータ行の右側にある「…」(その他のアクション)より「詳細を表示」をクリックします。

 

 

対象のトランザクションの詳細、コメント、履歴を確認することができます。

 

  

  

今回はキューとトランザクションについてとキューの管理画面についてご紹介しました。

開発者以外の方でもトランザクションの実行結果を確認する機会があるかもしれませんのでここでご紹介した方法は覚えておくと便利かもしれません。

 

次の「キューの使い方は?」では

・キューにデータを追加するロボット

・トランザクション処理を行うロボット

の簡単な作成方法についてご紹介いたします。

 

Uipathの導入、運用についてお困りの際は
是非、弊社に問い合わせをしていただけたらと思います。

<RPA.biz問い合わせフォーム> 

UiPathでExcel操作をしてみよう

2020.03.17

普段の業務でよく使用するエクセルでの単純作業やルーティーン作業は、もしかすると自動化できるかもしれません。

そんなときにどんなことが自動化に向いているか、あるいはどういった方法で自動化が実現できるかご紹介させていただきます。

ここでは前提条件として、端末にMicrosoft Excel アプリケーションがインストールされていることとします。

 

まずはUiPathで出来るExcel操作の一部を簡単にご紹介いたします。

 

①データの読み込み/出力

・シートの読み込み/出力

・列の読み込み

・行の読み込み

・セルの読み込み/出力

・セルの色を取得

 

②テーブル操作

・テーブルを作成

・ピポットテーブルを作成/更新

・テーブルを並び替え

・テーブルをフィルター

 

③その他の処理

・マクロを実行

・範囲をコピーしシートに貼り付け

・シートのコピー

 

 データの読み込みや書き込み

今回はよくつかわれるデータの読み込みや書き込みの自動化についてご紹介させていただきます。

 

UiPathExcelの自動化を行う方法は2通りありますが、ここでは「UiPath.Excel.Acrivities」を使用した方法をご紹介いたします。

 

 

Excelアプリケーションスコープとは?

Excelワークブックを開きエクセルへの処理が終了したら対象のワークブックを終了します。Excelの自動化アクティビティはすべてこのアクティビティ内に配置するようにします。

 

Excelアプリケーションスコープを配置

1.アクティビティタブを開き、検索ウィンドウに「Excel」と入力し検索し、「Excelアプリケーションスコープ」をダブルクリックし配置します。

 

 

2.処理対象のエクセルファイルのファイルパスを入力ウィンドウ内に記載します。

この時、ファイルパスは半角の“”(ダブルクォーテーション)で囲ってください。

Dドライブ直下にある「TEST.xlsx」ファイルを処理対象のエクセルファイルとします。

 

 

処理対象のエクセルファイル:シート名「処理データ」

 

 

セルのデータを読み込む

まずはセルのデータを取得してみましょう。

1.「セルを読み込み」アクティビティを実行シーケンス内に配置します。

2.データを取得したいセルが存在する「シート名」と「セル」を指定します。

3.取得したデータを格納する変数を作成し指定します。

プロパティの「結果」入力ボックス内で「Ctrl+K」を押下し変数名を入力すると作成できます。

 

 

TEST.xlsx」のA1にはIDが入力されていますので、取得結果は「ID」となります。

 

 

シート内のデータを取得

例で使用している「TEST.xlsx」のような各列に同一のデータが記入されているシート情報を取得する際に便利です。取得したデータは「DataTable型」となり、各行のデータを基準とした処理によく使用されます。

 

1.「範囲を読み込み」アクティビティを実行シーケンス内に配置します。

2.データを取得したいシート名を指定します。

3.データを取得する範囲を指定します。指定しなければシート内全てとなります。

4.プロパティを開き「ヘッダーの追加」にチェックを入れると先頭行がヘッダーとして読み込まれます。チェックを外すと先頭行もデータとして読み込みます。

5.取得結果を格納する変数を指定します。(作成方法は先ほどと同様)

 

 

 

データの出力(同一ブック内)

同一ブック内のシートより取得したデータを別シートに出力してみます。

 

1.「範囲に書き込み」を実行シーケンス内に配置します。

2.出力先のシート名を指定します。

3.出力開始セルを指定します。

4.先ほど取得した「GetDataTable」をデータテーブルに指定します。

5.プロパティを開き「ヘッダーの追加」にチェックを入れるとヘッダーとデータ行が出力され、チェックを外すとデータ行のみ出力されます

 

 

データの出力(別のワークブック)

データ取得元のエクセルファイルとは別のエクエルファイルに出力したい場合の処理についてご紹介させていただきます。

ここで使用する「範囲に書き込み」アクティビティはバックグラウンドで実行されるアクティビティで、実際にExcelワークブックを起動することはありません。違いについては後ろの方に記載していますので興味があればご確認ください。

 

1.検索ウィンドウで「write」と入力し、ワークブック配下の「範囲に書き込み」を配置します。

 

 

2.出力するエクセルファイルのパスを指定します。

※指定したファイルが存在しない場合は指定したパスで新しく作成されます。

3.出力するシート名を指定します。

4.出力開始するセルを指定します。

  1. 先ほど取得した「GetDataTable」をデータテーブルに指定します。

6.プロパティを開き「ヘッダーの追加」にチェックを入れるとヘッダーとデータ行が出力され、チェックを外すとデータ行のみ出力されます

 

処理結果は下記になります。

 

別のエクセルファイルへ出力で使用した「範囲に書き込み」アクティビティはOffice Excelアプリケーションがインストールされていない場合にも使用可能なアクティビティで、Excel配下にある「範囲に書き込み」アクティビティとは少し異なります。ただ、アクティビティの処理結果は同じで、データテーブルをシートに出力ですのでOffice Excelアプリケーションがインストールされている環境でしたらどちらのアクティビティを使っても問題はありません。

 

 

データの追記

指定されたシートの末尾にデータテーブルを追記する方法です。

ここでは「TEST.xlsx」の取得結果シートの末尾に処理データシートの内容を追記します。

 

1.「範囲を追加」アクティビティを実行シーケンス内に配置します。

2.追記するシート名を指定します。

3.追記対象のデータテーブルを指定します。

 

 

色のついたセル範囲は追記したデータとなります。

 

これらのExcelデータの入出力アクティビティを使用し、業務システムへのデータ入力や検索結果のデータを

エクセルファイルに貼り付ける等の作業を自動化することが可能です。

 

また、エクセルファイルから業務システムだけではなく、エクセルファイルからエクセルへの処理も単純なものでしたら

マクロを一から作成するよりも簡単に自動化を実現することが出来るかと思います。

 

以上、UiPathでExcel操作を行う際の説明をしました。

Uipathの導入、運用についてお困りの際は
是非、弊社に問い合わせをしていただけたらと思います。

<RPA.biz問い合わせフォーム>

UiPathでConfigファイルを使う

2020.03.05

今回は、UiPathでConfigファイルを使う際の説明を行っていきたいと思います。

 

Configファイルとは

UiPathでファイルパスを指定したり、何かを入力したりする際など、変数へ直にそれを打ち込んではいないでしょうか。
例えば「C:\hoge\fuga.csv」というファイルを指定する際に、代入アクティビティや変数パネル内で変数「piyo」に「”C:\hoge\fuga.csv”」と指定しているのを指します。
当然、このファイルパスが正しければ変数piyoを使用した際呼び出されるのはfuga.csvというファイルになります。

 

ただ、もしこのfuga.csvというファイルがhogeフォルダからhogehogeフォルダに移動となった場合はどうなるでしょう?

 

XAMLファイルを開き、該当箇所の変数(ここではpiyo)に規定されている「”C:\hoge\fuga.csv”」を「”C:\hogehoge\fuga.csv”」に直さなくてはエラーとなってしまいます。
Studioをすぐに編集できる環境であるならばこれでも問題はないでしょう。
ですが、Studioを編集できる人とロボットの使用者が異なっていた場合はそう簡単ではありません。
また、XAMLファイルを利用者が簡単に編集できていいのか、という保守性の問題も浮上します。

 

そこで作成されるのが、Configファイルです。

 

Configファイルの作り方

ConfigファイルはExcelで作成します。
もしロボットを運用するPC上にExcelが入っていなくても、ファイルがあればExcel上での作業は必要ないので動作の心配はありません。
読み込めれば問題ないです。
編集の際は、使用者のローカルPC上などで作業してファイルだけを入れてあげればよいでしょう。

 

Configファイルで必要なのは、「Key」と「Value」という列です。
ただ、それだけではどれが何を指すのか分からなくなってしまうでしょうから、その隣に説明用の列を作ってあげると親切です。
また、シート名も初期のSheet1などのままではなく、Settingなどわかりやすい名前を付けます。

 

Key」と「Value」は二つで一つです。単語帳のように、ひとつのKey(単語)にひとつのValue(意味)があります。
Keyを呼び出してあげるとValueの値が入るように設定をします。

 

以下の画像はConfigファイルの中身のサンプルです。
KeyValueの行は色を付けてわかりやすくしておくと良いでしょう。
Keyは変数と同じようにわかりやすいネーミングを付けます。
Valueのほうは、ここでは「String型(文字列)」「Int型(数字)」「Boolean値(True or False)」「Timespan値(時間)」を入れました。
これらの呼び出し方は後述いたします。

 

  

Configファイルの読み込み方

 Configファイルを使うために、KeyValueをセットにしてUiPathで読み込んであげなくてはなりません。
この際使うのが「Dictionary型」です。

「単語帳」のイメージがあるので近しいものを感じられるのではないでしょうか。

では、UiPathの画像を使用しながらConfigファイルの読込を説明いたします。
Configファイルの読込は、多くのロボットを開発する環境だと共通フローとしてInvokeできるようにすることが多いのですが、
今回はInvokeを考慮しないサンプルです。

Configファイル読込は「シーケンス」で作成します。
フローチャートを使うほど大型でも複雑でもないので、これで十分です。

 

代入アクティビティを使用し、新しい辞書型の入れ物を作成します。

わかりやすく「Config」という変数名を設定しました。
この段階ではまだGeneric型なので、これを辞書型にします。
(ダークモードのUiPathを使用しています。異なるのは色だけなので操作や中身は変わりません。)

 

ここを開いても辞書型は最初から出ていません。
一番下の「型の参照」をクリックします。

 

種類選択画面が開くので、「型の名前(N):」の横にある入力ボックスに「dictionary」と入力します。
いくつか候補が出てくるのですが、選択するのは「mscorlib[4.0.0.0]」→「System.Collections.Generic」→「Dictionary<TKey, TValue>」です。
これを選択すると、先ほどの型の名前入力ボックスの下にKeyValueに対して使用する型を選ぶプルダウンのボックスが出現します。
Excel上のConfigファイルは、Key値がStringなのでStringを、Value値には今回の場合様々な型が入っているのでObjectを設定します。
基本的にはString, Objectと覚えておいて問題はないでしょう。

設定するとConfig変数は下図のようになります。

これで左辺の設定は終了しました。

次に、右辺に移ります。ここには

 

  「New Dictionary(of String, Object)

 

 と入力します。

これは「Config」という変数の中に新しい「文字列KeyとオブジェクトValueを持つ辞書の枠組み」を作成していることになります。
ちなみに左辺でValue値をObjectに設定しているため右辺もObjectを設定していますが、Stringで設定しているのならば右辺もStringにします。

枠組みができたので、Excelファイルから中身をこの辞書に入れていきます。
Excelファイルが一行ずつ書かれていることからわかるように、For Each Row(繰り返し(各行))アクティビティを使用します。

 

まずはConfigファイルを「ReadRange(範囲を読み込み)」アクティビティを使用してデータテーブルに出力します。
ファイルパスとシート名を設定し、プロパティパネルにある出力欄でデータテーブルを指定します。
(※システム→ファイル→ワークブックに含まれる「範囲を読み込み」アクティビティを使用しています)

ここではConfigファイルのパスを変数で指定しています。
プロジェクトのフォルダ(Main.xamlのあるフォルダ)にConfigというフォルダを作り、そこにConfigファイルが格納されている想定です。
また、この場合は相対パスで読み取ってくれます。
シート名も変更している場合は忘れずに設定します。
また、範囲に関してはシート全体を読み取ってもらうので設定不要です。

プロパティパネルのデータテーブル入力箇所で変数を作成すると自動的にDataTable型にしてくれます。

 

まずは繰り返しの設定です。

コレクションの欄には先ほど出力したデータテーブルを設定します。
これで、Configファイルを読み込んでくれる設定ができました。

読込をするのはKey列とValue列が空ではない行だけにしたいと思います。
そこで、条件分岐を中に入れてから設定値をセットしていきます。

 

 少々わかりにくいので個別に解説します。

 

まず、条件分岐のコンディションに入れるのは

 

              Not string.IsNullOrEmpty(row(“Key”).ToString) and Not String.IsNullOrEmpty(row(“Value”).ToString)

 

長くて難しく感じられますが、「and」の部分で区切りがあります。
前はKeyが空欄ではないかの判定、後はValueが空欄ではないかの判定です。
先頭についている「Not」はそのあとに続くものの否定となります。
String.IsNullOrEmpty」はこの後にかっこ書きで指定する引数の文字列がNullか空である場合を指します。
(row(“Key”).ToString)」は「Key列を文字列型にしたもの」を指します。
and以降はKeyValueになっただけであることがわかると思います。

つまり、「文字列(”Key)がNullか空ではない、そして文字列(”Value)がNullか空ではない」ことがTrueのときにThenの処理をします、という意味になります。

 

Thenの処理ではKeyからValueを呼び出せるようにセットする処理を行います。
画像では切れてしまっているのですが、左辺には

 

              Config(row(“Key”).ToString.Trim)

 

という式が入っています。
これは「変数Config(列(“Key”)を文字列に直して前後のスペースを消したもの)」を表しています。

Configファイルの中身を例にとって表すと、

 

              Config(“StringTest”).ToString.Trim=「“文字列の表示をします。

 

が一行目を実行したときの結果になります。

こうしてあげることで、KeyValueが結びつき、簡単に呼び出すことが可能になります。
この各行の処理をKey列とValue列の両方が空になるまで繰り返せばConfigファイルの読み込み設定は終了です。

 

KeyからValueの呼び出し方

まずは基本である、文字列の呼び出し方です。

メッセージボックスアクティビティを見ればわかるように、Config(“Key”)で設定したValueの値である「文字列の表示をします。」が表示されていることがわかります。
しかし、最初にDictionary型で設定した通りこのValue値はObject型をとっています。
なので、条件分岐やInvokeで引数の既定値として使用する場合は「ToString」を使用して文字列にしてあげなくてはなりません。

また、ファイルパスも同様に.ToStringをつけることで使用が可能です。

 

最初にValue値を設定した際様々な型を設定しました。
そして、今呼び出したValueObject型だ、というのもご理解いただけていると思います。

ではどうやってこの型を当てはめてあげるのか、に移っていきます。

 

・数字を使用したい場合(Int型)

わかりやすいように、

「Int型に設定したIntTestという変数にConfigファイルのKeyIntTestValue68が入っています)を代入する」

というケースを想定して説明します。

これはただConfig(“IntTest”)と入れた場合です。
エラーが出てしまっていて、曰く「ObjectからIntegerへの暗黙の型変換はできません」とのことです。
IntTestという変数がInt型なのに、ConfigValueObject型なので自動的にそれをInt型に変換することはできない、というわけです。
なので、明示的にこのConfig(“IntTest”)Int型だといってあげれば解決します。

その際使用するのが「CInt」です。

代入の右辺には式エディタに表示されている式が入っています。
CIntConfig(“IntTest”)Int型に変換してあげることで、エラーが消えたことがわかります。
このままメッセージボックスにIntTestの変数を入れて実行すると、「68」が表示されます。

 

TrueFalseを判定したい場合(Boolean値)

先程文字列の条件分岐を行った際は文字列が含まれてるかどうか、という判定を行いました。
しかし、ConfigからTrueFalseを判定したい、例えば本番環境とテスト環境で動作を分けたい場合、
本番環境はTrue、テスト環境はFalseとして分岐させたい場合もあるでしょう。

そこで使用するのが「CBool」です。
これを使用することで、ここの条件分岐のConditionは「Configの“BooleanTest”の値がTrue」という設定になります。
そしてConfigファイルでの設定はTrueになっているので、Thenに進んでメッセージボックスには「Trueです」という表示がされます。

 

・時間を設定したい(Timespan型)

リトライの間隔や待機(Delayアクティビティの使用には賛否がありますが、使用しなくてはならない場合もあるかとおもいます)などで使われているのがTimespan型です。
Excel上ではHH:mm:ssを文字列として書き込みます。

リトライや待機の間隔をそろえたい際、Configファイルに書き込んで一度に設定できるようにしたいときに使用するのが

 

  Timespan.Parse

 

です。

これは文字列をTimespan型として表示する際に使うので、Configファイルからの呼び出しでは下図のような設定となります。

Configから呼び出すときに文字列型にしないとエラーが起きますのでご注意ください。

これで待機を実行すると、下のようになります。

5秒間の待機が発生したことがわかります。

Configファイルの値を変更すれば、10秒、1分といったように一括で管理することが可能です。

 

 

ユーザ側の編集も簡単かつ、同じ変数を使用していれば一括で管理できますのでConfigファイルの使用方法は覚えておくべきでしょう。
また、変数やじかに表示させるだけではなく、それぞれの表記方法を使用することでInvoke WorkFlowで呼び出したフローの引数へ既定値として設定させることも可能です(当たり前ではありますが、両方が同じ型であることに注意してください)。

 

以上、UiPathでConfigファイルを使う際の説明をしました。

Uipathの導入、運用についてお困りの際は
是非、弊社に問い合わせをしていただけたらと思います。

<RPA.biz問い合わせフォーム>

UiPath の各種ライセンスについて

2020.01.14

今回は、RPAツールの一つであるUiPathの各ライセンスの説明を行っていきたいと思います。

 

UiPathでは使用するロボットの特性に応じて様々なライセンス形態を準備していますので、
それぞれの特徴、どのような用途に向いているのか、などを詳述してまいります。
また、各ライセンスの金額についてはリセラー様により変動しますのでこのブログでは割愛いたします。

 

※これから述べる情報は2019年12月時点のものであり、
将来的にUiPathのほうで他の新ライセンスや既存ライセンスの仕様変更が行われる可能性もあることを留意していただけたらと思います。

 

 

 

UiPathのライセンス形態は複雑ですので、まず大枠の話をします。

UiPathのライセンスはまずその用途から、

・Studio

・Attended Robot(以後ARと略します)

・Unattended Robot(UR)

・Orchestrator(OC)

上記4つに分かれます。

 

Studio まずはこれが無いと始まらない

Studioはシナリオの開発(xamlファイルの作成)をする際に必要な開発ツールです。

これはライセンスという形で購入することもできますが、
まずは初心者の方向けにUiPathが無料のトライアル版を公開しているので、それをダウンロードして試すのが良いでしょう。

Studio内の各種機能詳細については、UiPathの公式ページや他サイトでも書かれているので、
ここでは、特にそのライセンスの特徴について述べていきます。

 

・本職では無いがもちろん「実行」もできる

RPAのシナリオ作成をする際に、当たり前ですが都度作成したシナリオをテストとして動かす必要があります。
なので、完成したシナリオを後述する実行用ロボットであるAR/URに行わせずに、Studioで実行させる運用も理論上は可能です。

ですが、実現場ですと開発者と日々RPAを使用するユーザーは異なることが通常ですので、実運用となると実行用にAR/URを購入するのが一般的です。

 

・リセラーからAR/URを買うときはセットで付けさせられる

RPAツールは、本来エンドユーザーでも開発できること
(これを業界用語でエンドユーザーコンピュ―ティング、略してEUCと呼びます)を理想として謳っていますが、
会社によっては「開発は絶対ベンダー任せ」のところもあるかと思います。

そういう時に、よく言われるのが「実行用のAR/URは買うから、Studioは買わないようにできない?」というご質問です。

これはUiPath側のポリシーとして基本的には禁じられています。
ユーザー側の企業がAR/URをご購入する際は、最低1つのStudioライセンスも購入する前提でいていただけたらと思います。

 

・Studio XはEUC向け

2019年秋よりUiPathから新しいStudioツールである「Studio X」が公開されました。
こちらは、従来のStudioと比べ、より現場ユーザー向けの簡潔な仕様となっています。

プログラミング未経験者の現場ユーザーが従来のStudioを扱うと、かなり柔軟に細かく設定ができる一方、
ボタンやアクティビティが多く、とっつきにくい印象を持たれていたと思います。
(ちょっと画像加工をしたいビギナーの方がAdobe IllustratorのUIを見た時に受ける印象と一緒です。)

そこで、新たに開発されたStudio XではよりEUC向けに、ボタン数もぐっと減り、
アクティビティ名もプログラミングにあまり明るくない方にも分かりやすくなるように表示されています。
またXで作ったxamlは、今までのStudioへの変換が可能です。

但し、従来StudioからXへの互換性はありませんので注意が必要です。

 

AR/UR 実運用段階で必須。狭義の意味でのRobotはこれを指す

・ARは安価だが手動で起動、URは高価だが自動で起動もできる

まずARとURの違いは、手動でしか起動できないか/否かで分かれます。

ARのAがAttendedであることを示す通り、人間が起動時に在席していることが前提のロボットとなります。
従って、深夜や祝日に起動させたい業務内容の場合、ARは向きません。

一方、URは手動での起動ももちろんできますが、OCと繋げることで予めスケジュールを設定しておけば自動で起動します。
その代わり、URのライセンス料金はARよりも4倍弱高価であるのが相場となっています。

 

・Windowsタスクスケジューラ起動でもURが前提~ただ基本的にURはOC前提のRobotです

ここでよくクライアント様に言われるのが、Windowsのタスクスケジューラとの関係です。
テクニカルに言えば、ARであってもタスクスケジューラを経由して自動起動させることはできます。

ただ、こちらはUiPath側としては認めておらず、規則を守るのであればURを使用することが求められます。

ただ、そうは言っても基本的にはURは、後述するRobot管理用のツールであるOCがあってこそその威力が活きるRobotです。
OC無しのユーザー企業がURを導入するケースはほぼ無く、あったとしても将来的にOCを入れる前提で過渡期としてOC無しでURを導入するケースがあるくらいです。

 

・実行用の端末をどうするか問題~それは会社によって異なります

本ブログのテーマであるライセンスの話から少し脱線してしまいますが、
ここで敢えてAR/URを動かす端末の話をしたいと思います。

前述したとおりARは手動での起動が前提、URは自動での起動が可能という特徴があります。
その場合、それぞれのRobotが実装される端末は以下のパターンに分かれます。

 

 

 

まずARでは、実際にRobotが動作するときに社員も同席しているような業務を行う為、一般的なPC上で動作させることが多いです。
エクセルのマクロのような感覚で手軽に使いたい場合は社員自身のPC内でクリックしてARを起動させる事も可能です。

ただ、その代わりその間、社員は他の作業ができませんので、現実的に多いのが、専用のPCを設けるパターンです。

 

もしくは、あまり頻度はそこまで多くはありませんが、このARの段階からサーバ上のVM(仮想マシン)で動かすケースもあります。
その場合、社員は自分のPCからリモートデスクトップでVMに繋ぎ、そこからARを起動させる手順となります。

 

次に、URの場合ですが、この段階になると多くの企業がVMを採用します。

原理的には物理的なローカルPCでもURを動かすことはできますが、URになると実働時に人間が介入することはなくなるので、
ネットワークの安定性やセキュリティの観点からVMに実装させることのほうが多いです。

 

・AR→URのライセンス切り替えはできない

OC導入の過渡期のクライアント様の中には、OC前はARにしてOC入れたらURにしようというような方もいらっしゃるかもしれません。
しかし、基本的にARの契約期間中にURにアップグレードすることは認められておらず、
ユーザー側は別途URライセンスを購入する必要があります。
(そしてARは契約期間になったらそのまま終了させる。)

なので最終的にOC導入後にARを使う予定の無いユーザー様については、最初のOC導入前段階からUR購入しておく必要があります。

 

・実際にOC導入後のAR/URの構成も会社によって様々

先ほどURは基本的にOC前提のRobotと申し上げましたが、もちろんARもOC環境下で動かせます。
実際に大手企業様でUiPathを活用している場合だと、ARとURのライセンスを両方購入して、うまく業務内容に応じて使い分けています。

 

・開発環境でもAR/URはあったほうが良い

最後はAR/URの開発段階での活用についてです。

Studioでシナリオは作成されますが、Studio上で「実行」が上手くいったとしても、
本番環境のAR/URで動かした時になぜかエラーが起きてしまうこともあります。
これは両者の実行スピードが異なる等の理由が挙げられます。

 

例えばStudioではdebugモードで実行するとスピードが落ちるのですが、AR/URで動かすと高速になり、
そのためサイト上のボタンやデータを掴めないでエラーが出るなどのケースです。
また、Studioは基本的にローカルのPC端末で動かしますが、
URはサーバ上のVMで動かすとなると環境自体が違うのでやはりエラーがでる可能性はあります。

このようなケースに対処するために必要なのがステージングの考え方です。
ステージング/UATのために開発段階においてもAR/URを使えるようにし、
本番環境と同じ条件下でテストできるようにしておくことが重要になってきます。

その際に、UiPathが提供開始したのが、Non-Productionと呼ばれるライセンス形態です。
これはAR/UR両方に適用できます。
このライセンス形態は本番環境で使わないことが規約上求められているのですが、
通常のライセンスにくらべて格段に安くなっています。

 

OC 随分、お手軽に始められるようになりました

Orchestrator(OC)は、特にRPAロボットが増えた状況下で有益となるRobot管理ツールです。

Blue Prism等では、このような管理ツールは有無を言わさず最初から導入しておくのが前提となっていますが、
「小さく始めたい」ユーザーニーズも拾う志向が強いUiPathではオプションという位置づけです。

とはいえ、このOC、以前は1種類しかなくかなり高価な代物であり、
UiPathを試験導入した企業にとって一寸敷居が高く感じるものでした。

ただ2019年秋より「Orchestrator Basic」という(今までのはOrchestrator Standardと呼ばれるようになりました)、
より価格を抑えたタイプが発売され、今後導入する企業が増えることが期待されています。

まず、このBasicとStandardの違いを説明する前に、
このOCで何ができるようになるのか、その特徴を伝えていきたいと思います。

OCでできることは細々と多くありますが、
ここでは特にユーザー様側で理解しやすいメリットを中心に述べていこうと思います。

 

・特徴1 スケジュール設定によるRobotの自動起動ができる

これはAR/URの章で既に述べておりますが、
OCを導入することでURに「毎週●曜日●時●分にこの業務を行いなさい」と指示を出す事が出来ます。

このタイムスケジュール管理はOCが持つ強力な機能の一つです。
本来RPAで最も効果が高く、人間の生産性向上に結び付くのはこのような「完全自動化」対象となる定型業務です。

いちいち人間側がロボットをキックさせなくても決められた時刻に、
例えば深夜にロボットを起動させることができれば翌朝、人間はロボットが終わった処理から業務をスタートすることができます。

また、本来本当の意味で「毎日」行うべき外部サイトからのデータスクレイピング業務についても、
人間だと土日に行うのは無理ですが、このOCの機能を使うと可能になります。

 

この時間設定の機能について詳細が気になる方も多いかと思います。
例えば、「ロボットに作業させたい日時が月によってかなり変動する。どのように時間設定を変更できるのか」というようなご質問もあるかと思います。
この時間設定の機能がOCでコントロールしている以上、それはOC側で設定する事項となります。

ただその時に、「一般ユーザーにOCにアクセスしていじらせてしまってよいものか。。。」という難題が出てきます。
通常、OCにアクセスして細々とした設定変更を行うのは
情報システム部などのごく一部の限られた人たちだけにするのが一般的です。

ユーザー部門から新しい日時を情報システム部が受けOC設定するのも可能ですが、
あまりにもその頻度が多すぎると情報システム部の負荷が増え敬遠されます。

そのような時に、アイデアとしては「OCの時間設定変更用のロボットを新たに作る」というものがあります。
ユーザー側に何かエクセルなりで時間設定変更の申請書をメール/フォルダ格納で提出させ(承認フローが必要でしょうが)、
ロボットがその情報をもとにOCの設定を更新する方法です。

このやり方だと、そのロボットにだけOCアクセスの権限を付加すればよく管理上の手間およびリスクは軽減されます。

 

・特徴2 ID/Pass等のクレデンシャル情報をOC側に持たせ、漏洩リスクを防げる

これは特にURに自動で業務をさせるときに必要になります。
ARの場合、人間が同席しておりますので、
Robotを起動させる端末のWindowsログイン情報およびSAP等の外部システムのID/Passといった情報は人間に入力させれば事たります。

しかし、URの場合、どこからかその情報を取ってこないといけないので、その管理方法を考える必要が出てきます。

その方法としては一般的に「Windows資格情報の機能を使う」か「アクセス権限のある特定のフォルダにエクセル等で格納」か、
そして最後に「OCに持たせるか」の3つに分かれます。

ただし、この3つの方法が選べるのは外部システムのID/Passについてです。
URのロボットが起動する端末のWindowsアカウント情報については、「OCに持たせる」しか選択肢はありません。
(それかURが起動する端末マシンを常にログイン状態にしておくか、です)

そもそも人間が介在しないURの場合、
最初にそのロボットが動く端末のWindowsにログインして起動状態にしておかないといけません。
URの場合、それをOCの指示で行います。
従ってWindowsのアカウント情報だけはOC側で管理しておく必要があります。

実際にロボットが起動したあとに業務上必要となる外部システムのID/Passについて、上記3つの方法いずれでも技術上可能です。
そこで外部システムのID/Passを管理する一手段としてOCのクレデンシャル情報管理機能(GetCredential)が使えます。

ロボット側が作動毎にクレデンシャル情報をOCからもらって使用する形態になります。
これによりクレデンシャル情報はロボット端末側で管理する必要はなく漏洩リスクは軽減されます。

また、開発段階ではテスト環境下での仮ID/Passを開発ベンダーに教えて、
本番環境についてはGetCredential機能を使わせるようにすれば開発ベンダーに本番のID/Passを教える必要は無くなります。

 

・特徴3 ライセンスのシェアが可能になる

この機能もOC導入を促す強力な要素です。
RPAの利用が拡大していくと、それこそ自社のEUC用途やベンダー向けに複数のStudio ライセンスが必要になりますし、
またAR/URの数も膨大になります。

OC無しの環境下では、基本的にStudioやAR/URのライセンスは
「ユーザー単位(大雑把に言うとWindowsアカウント単位)」もしくは「PC端末単位」で付与されます。
これをUiPathの用語では、「Named User」と「Node Locked」という呼び方で表現します。

一寸、色々なライセンス形態の話が出て来るので混乱してしまう方もいらっしゃると思いますが、
StudioやAR、URのそれぞれのライセンスの下で「Named User」や「Node Locked」といったタイプを選べると思っていただければと思います。
(正確に言うとURではNamed Userの概念が無かったりしますがここでは割愛します。)

 

つまり「Named User」のライセンス形態の場合、ユーザーが同じであればPCが変わっても利用が可能です。
ただし、同時に動かせるのは1ライセンス1台のみとなります。

一方、「Node Locked」になると、PCが同じであればユーザー数は問いません。
この形態は、例えばARにおいて複数の派遣社員の方々が同じ端末だけど
ログインアカウント変えてRobotを使用する時などに向いています。

いずれにせよ、この「Named User」や「Node Locked」では、
ライセンスがユーザーやPC端末に縛られていまい柔軟に付け替えできない問題があります。

これは例えば、実際には「同時」には最大3人ぐらいしか使わないのに、
開発するユーザーアカウントが10人分必要だからStudioライセンスを10購入しなければならない。。といった非効率を生みます。

このような特に役に立つのが、OC下でのみ可能となる「Concurrent」というライセンス形態になります。
(正確にはConcurrentも更にUserとRuntimeに分かれますが、ここでは割愛します。)

 

 

 

 

「Concurrent」においては、複数のユーザー/PC端末間でライセンスのシェアができます。
つまり、開発者が10人いたとしても、同時利用が最大3人であればStudioライセンスは3つで足り、
さらにAR/URにおいても同時刻に行われる業務が最大5つ程度であれば、5ライセンスで足ります。

この観点は、特にRPAを利用する部門やベンダーが多岐に渡るようになってきたときにライセンス消費を効率化する点で重要になります。

 

この場合、そのライセンス枠から外れてしまった場合、
例えば3つのUR(Concurrent)ライセンスしかないのに4つ目の業務が来てしまった場合、
その実行を先行する業務が終わるまで「待たせる」機能もつけることができます。
(Queue(キュー)とTransaction(トランザクション))

 

ちなみに補足ですが、OC導入前にUR(Node Locked)を購入し、
OC導入後に同ライセンスをUR(Concurrent)に途中切り替えするのは可能です。
詳細はリセラーのポリシーにもよりますが、
現行ではNode Locked→Concurrentは追加費用なしで切替できるところが多いようです。
(Named User → Concurrentの場合はおそらく追加費用が発生)

 

このように色々と便利な機能が付くOCですが、今まで問題となっていたのが、その金額の高さです。

大手で本気でRPA導入を進めている企業であれば、年間システム開発費に比べて微々たる額だとは思いますが、
これからRPAを本気で取り組むべきか否かまだ迷っている企業様においては無視できない金額でした。

 

そこでUiPathが2019年秋より公開したのが「Orchestrator Basic」です。
このBasicの特徴について述べていきたいと思います。

 

・Basicは安価だが接続台数に制限有り

OCのBasicでは、接続可能なUiPath Robot(AR/UR)およびUiPath Studioはそれぞれ5つとなります。
またOC内で設定するテナント(ライセンスを管理するグループ単位)の利用可能数は1つになります。

一方、通常のOCだと、接続可能なRobotおよびStudioの数は無制限です。
但しBasicの価格より高価になります。

 

・Basic → Standard への途中切り替えは有り

これはリセラー側のポリシーによるところもあるのですが、
現時点ではOC BasicからOC Standardへの契約期間中の変更は可能であり、
残り期間中のBasicとStandardの価格差分だけを支払うことになるケースが多いです。

 

以上、UiPathのライセンス概要について説明しました。
UiPathのライセンス形態は複雑で、初心者の方にとっては折角RPAをやろうとしているのに、
いきなり心が折れるような気持ちなるかもしれません。

そのような時は是非、弊社に問い合わせをしていただけたらと思います。

<RPA.biz問い合わせフォーム>

topへ
© RPA.biz