UiPath RPA Academy Level 2 - Orchestrator 2016.2 トレーニングの動画字幕(一部)
ひさびさの更新はものすごく実用というかなんというか。
動画の字幕と実際の動画のズレがひどくて見られたものじゃなかったので、字幕だけを、ズレはじめる部分から書き出した。
主にアセット、キューについての解説部分。
権利関係的に指摘があればすぐに消すが、しかしどう考えてもひどい動画を公開していることが問題だろう。
以下、字幕。
今度は、ワークフローに戻ってアセットの値を要求するためにワークフローを変更しましょう。
Get Assetアクティビティを使用すると、指定したアセットの値を抽出し、変数として出力できます。
ハードコードのテキストをGet Assetアクティビティを利用して出力変数に置き換えてみましょう。
これで、このワークフローを保存して公開することができます。
このプロセスを最新バージョンに更新してOrchestratorからこのジョブを実行しましょう。
3つのロボットがすべてこのジョブの実行を開始しました。
Cancelを押すと、すべてのロボットが「Hello UiPath!」を入力したことに気づくでしょう。
これはアセットを作成した際にアサインした値でしたね。
今度は、ロボットに何か他の文章を入力させたいとしましょう。これは、先ほど作成したアセットを編集して、異なる値を入力するだけでよいのです。
ここでは、「Hello world!」に変更しましょう。
再度ジョブをトリガして結果を確認してみましょう。
見てください、「Hello world!」になっていますね。
なんと、もっとできます。それぞれのロボットに別々の文章を入力させたいとします。
それぞれのロボットに対して異なる値を指定すれば、それも可能です。NotepadTextアセットを再度編集し、今回はPer Robotを選択しましょう。
ロボットを1つずつ選択して、入力する値をそれぞれの名前として使用しましょう。
では、プロセスを再度実行して結果を確認してみましょう。
ご覧のように、これらのロボットで使用しているプロセスやアセットは同じものです。
しかし、アセットレベルに少しでも変更があれば、それぞれのロボットが異なるメッセージを入力します。
アセットは資格情報を格納する際にも使用できます。今回は、usernameとpasswordという2つの値を与えることにしましょう。
ワークフローのGet AssetアクティビティをGet Credentialアクティビティに置き換えて、先ほどのusernameとpasswordという出力を2つ設定します。
それでは次のトピックスに移りましょう。
Orchestrator Queuesについて説明していきます。このキューは、複数のロボットで処理される必要があるアイテムリストを格納するために使用します。
たとえば、大量のレコードリストを扱う場合や、結果に重複がないか確かめたい場合などにキューを使用すると、すばらしい効果を発揮します。
行数の多いExcelファイルや電子メールが大量にある場合、このシナリオは両方ともOrchestrator Queuesを使用する良い例になります。
2つのワークフローを使ってより詳しく説明しましょう。
1つ目のワークフローでは、Excelファイルから値を読み取り、キューにその値を追加します。
ロボットのジョブが完了しました。使用したキューのdetailsセクションを見てみましょう。
ご覧のようにそれぞれのアイテムに、それぞれ特定の値を持つ3つの引数が存在しています。
この3つのロボットを使用してこれらのトランザクションを処理してみましょう。
それぞれのロボットが異なるアイテムをOrchestrator Queueから取得して、デモアプリケーションに値を入力します。
ここで、ロボットの1つがそのアプリケーションを閉じてトランザクションが処理できないことに留意してください。
キュートランザクションを処理するパッケージはすでに公開したので、次はプロセスを作成する必要があります。
ジョブを開始して、3つのロボット全てを選択しましょう。
実行がトリガされて、ダイナミックにタスクを分担しながら、すべてのロボットが1つのチームのように動作を開始しました。
このジョブが終了すると、Transactionsページに切り替えて、キューで処理されたアイテムすべてのステータスを分析することができます。
フィルタを追加して、キューからFailedのアイテムのみを確認できるようにしましょう。
対象のアイテムは2つあるようです。Detailsボタンを使用して何が起きたかチェックしてみましょう。
たとえば今回は、「these are not numbers」が原因のBusiness Exceptionが確認されました。
さて今度は、キューにあるアイテムが持つ可能性のあるステータスを確認していきましょう。新しいアイテムをキューに追加した場合、ステータスがNewで自動的に追加されます。
このアイテムがロボットに送られると、すぐにステータスがIn Progressに変化します。
トランザクションが処理されると、そのステータスはSuccessfulもしくはFailedのいずれかに変わります。
ここで、FailedにはApplicationとBusinessという2種類のエラーがあります。
キューのプロパティにあるAuto-Retryが有効になっている場合は、Orchestratorが再処理のためにこのアイテムをロボットに再度送ります。
この場合、アイテムのステータスがRetriedに変化します。最後に、アイテムがキューで進行中かつ24時間以内に処理されていない場合は、このステータスは自動的にAbandonedに更新されます。
では、1つ前のステップに戻って、この例が作られたか見てみましょう。
まずはOrchestratorでデモのキューを作成しましたね。次に、名前を追加してAuto-Retryを有効にするという非常に単純な作業を行いました。
先ほど説明しましたが、トランザクションがAuto-Retryが有効な状態で、Application Exceptionのエラーを起こした場合、RetriesフィールドのMaximum Numberで指定した回数だけ、Orchestratorがアイテムをロボットに再送信します。
UiPath Studioでは、キューの処理に使われるアクティビティは3つありました。
1つ目はAdd Queue Itemアクティビティです。
これはステータスがNewのアイテムを指定したキューに追加します。このアクティビティでは、プロパティのQueue NameとPriorityが入力必須になります。
これは、ロボットの優先順位に基づいてこのアイテムが処理するロボットに送られるためです。
プロパティのDefer DateおよびDue Dateでは、キューアイテムを処理する期間を追加できます。
たとえば、アイテムを最大で24時間以内に処理しなければならない場合は、Due Dateを使用するのがよいでしょう。
2時間以内に処理しなければならない場合であればDefer Dateを使用するのがよいでしょう。
いいでしょうか。2つ目のアクティビティはGet Transaction Itemです。
これは指定したキューからアイテムをリクエストします。このアクティビティではQueue NameとTransaction Itemという2つのプロパティを出力として必ず入力しなければなりません。
このアクティビティがループに存在する場合は、すべてのアイテムを指定したキューで反復処理します。
3つ目のアクティビティはSet Transactions Statusです。
これは処理したアイテムのステータスをFailedもしくはSuccessfulに更新する際に使用します。
ただし、ロボットがアイテムのステータスを24時間以内に更新しない場合は、ステータスが自動的にAbandonedに変更されることに気を付けてください。
プロセスの入力として、表示されているExcelファイルを使用しました。ロボットがファイル全体を読み込み、各行に対して新規のアイテムを以前作成したキューに追加する必要があるはずでしたね。
それぞれのアイテムには3つの引数が含まれていたはずです。
Excelにある3つの列の値をそれぞれの引数に対応させましょう。ここではキュー内の重複を避けるため、ロボットは1つしか使用しません。
それでは、2つ目のワークフローがどのように作成されたか確認してみましょう。
まずはGet Transaction Itemアクティビティを使用しました。
このアクティビティはキューからアイテムを要求します。キューに再試行するアイテムや新規アイテムがない場合、Get Transaction ItemアクティビティはNull値を返すので、これをチェックする必要があります。
このような状況でロボットがキューの最後に到達した場合、ロボットはメッセージを残します。
新しいキューアイテムが利用できる場合は、ワークフローで値を取得して使用する必要があります。つまり、3つのAssignアクティビティを使用して3つの変数でそれらの値を格納します。
引数の値にアクセスするには、SpecificContentパラメータを使用して引数名を指定する必要があります。
どんな値がキューに格納されるかわからないので、ここではString型の値を使用しましょう。
抽出された値が数字かどうかをロボットがチェックするのがワークフローでの次のステップになります。
その結果が失敗だった場合、このトランザクションのステータスはBusiness Exceptionが原因のFailedに設定されます。
この値がinteger型の場合は、ロボットは次のステップに進み、デモアプリケーションが開いているかチェックします。
このアプリケーションが閉じている場合は、今回のトランザクションのステータスはApplication Exceputionが原因のFailedになります。
このデモアプリケーションが開いている場合、ロボットは値を入力してAcceptボタンをクリックします。
これらのステップをすべて完了したら、Set Transaction Statusアクティビティを使用して、現在のアイテムのステータスがSuccessfulに設定されます。
このアクティビティを思った通りに動作させるには、トランザクションアイテムの変数を入力してProperties panelで適切なステータス(Successful)を選択する必要があります。
Orchestratorに戻り、他に処理されたアイテムをチェックしてみましょう。ご覧のように、Application Exceptionが原因のFailedアイテムはありませんね。
これは、Application Exceptionが原因のアイテムは再試行され、最後に処理された段階でSuccessfulになったためです。
Application Exceptionが原因でエラーになったアイテムにのみ利用できる、マニュアルのステータスは3つあります。
In Reviewはチームの他の人にこのアイテムがチェック中であることを通知します。
このチェックが完了すると、主導でアイテムをRetryすることで、このステータスはVerifiedに変更されます。
覚えておいて欲しいのは、いったんアイテムがVerifiedになってしまうと、手動では再試行できません。
あともう一つ説明することがあります。
Postpone Transaction ItemアクティビティではアイテムのDeferおよびDue Dateを変更できます。
ここで、あるアイテムがロボットに送られたものの、アイテム処理の準備をまだEnvironmentができていなかったとします。
この場合、Postpone Transaction Itemを使用して、2つのプロパティを変更することができます。
それでは、Queuesページに戻ってキューで生成した統計情報を確認しましょう。
このページではまだ実行する必要のあるアイテムの数や平均実行回数、問題なく完了したアイテム数、Application Exceptions、Business Exceptionsの数を表示しています。
これに加えて、それぞれのキューに対して折れ線グラフが利用できるので、トランザクションステータスの進行状況を指定した時間幅で簡単に確認することができます。
ロボットやジョブに対するステータスは別として、Orchestarator Dashboardはすべてのキュートランザクションに対して折れ線グラフを表示することもできます。
概要をよりわかりやすくするために、時間フィルタを直近1時間、1週間、30日と変更することができます。
要約すると、UiPath Orchestratorは全てのリソースを効率的な方法で自由に管理できるウェブアプリケーションです。
Orchestratorに展開されたBusinessプロセスは、複数のロボットで同時に実行することができ、かつ任意のタイミングで実行をスケジューリングすることができます。
Orchestratorのプラットフォームは自動化プロセスを容易にし、さらにStudioを使うことでチームでの仕事を合理的に行うことができます。
以上