- リリース ノート
2022 年 2 月
Orchestrator の資格情報を保存できるプラグインの選択肢を増やし、資格証明書ストア「BeyondTrust」を Orchestrator と新しく連携させました。設定手順については、「BeyondTrust との連携」をご覧ください。
今回のリリースでは、OAuth 2.0 フレームワークを認証プロトコルの基盤として使用する、新しいロボット認証メカニズムを実装しました。Unattended ロボットが Orchestrator に接続する際に、マシン テンプレート オブジェクトを介して生成されたクライアント ID とクライアント シークレットのペアを使用することができます。クライアント ID とクライアント シークレットのペアで生成したトークンによって接続が認可され、Orchestrator リソースへのアクセス権がロボットに付与されます。
クライアント資格情報を使用すると、UiPath Robot はユーザーを偽装することなく、自身の資格情報を用いてリソースにアクセスできます。ロボットが Orchestrator からリソースを要求する際は、認証にユーザーが関与しないため、操作を実行するための認可がロボット自体に付与されている必要があります。
クライアント資格情報の機能を使用するには、v2022.2 以降の UiPath Robot が必要です。
一般的なリリース スケジュールでは Community プランの公開日の 1 週間後に Enterprise プランでも機能が利用できるようになりますが、クライアント資格情報の機能については、エンタープライズ版 UiPath Robot v2022.4 の公開とともに、エンタープライズ版 Cloud Orchestrator でも機能が利用できるようになります。
ロボットの認証について詳しくは、こちらをご覧ください。
管理者向けの、クライアント資格情報の管理方法 (新しい資格情報の作成、アクセス権の取り消し) については、こちらをご覧ください。
RPA 開発者および Attended ユーザー向けの、Robot を Orchestrator に接続する方法については、こちらをご覧ください。
Orchestrator では既定のロールが数種類用意されています。既定ロールによって、主なユース ケースに対応したアクセス権の割り当てを簡単に行うことができ、Orchestrator の環境を利用し始めたばかりの新規ユーザーにとっては機能の基盤としての役割を果たします。ユーザーはまずエコシステムに慣れ、自動化の特定のユース ケースを理解し、その後で既定のロールを編集したり、ニーズに合わせて新しいロールを作成したりできます。
しかし、既定のロールの権限の組み合わせも基準として使えるよう、いつでも利用できるようにしておく必要があると考えました。
このため、特にモダン フォルダーの既定ロールに関するロールや権限に対して、いくつかの改良を行いました。
既定のロールの追加作業が不要に
Orchestrator の設定画面から既定のロールをテナントに追加することなく、ロールを既定で利用できるようになりました。この変更は、新規のテナント、およびこれまで既定ロールが手動で追加されてこなかった既存のテナントに対して適用されます。
これに伴い、テナント レベルの [設定] ページの [全般] タブから、ロールを追加するオプションを削除しました。
既定のロールが読み取り専用に
既定のロールを編集できなくなりました。ロールに含まれる権限を表示することはできますが、権限の変更はできません。
ロールのカスタマイズが必要な場合は、必要な権限を含むロールを新しく作成する必要があります。
既定のロールをカスタマイズすると、ロール名の末尾に「Custom」が追加されます。
過去に既定のロールの権限をカスタマイズした場合でも、そのロールの利用を続けることができますので、ご安心ください。カスタマイズ済みのロールの名前は「ロール名 - Custom」に変更されているため、既定のロールと、カスタマイズ済みの既定ロールを見分けることができます。
たとえば、既定ロール「Automation User」の権限をカスタマイズすると、ロール名は以下のようになります。
|
ロール |
作成元 |
編集可能 |
割り当て可能 |
権限 |
|---|---|---|---|---|
|
Automation User |
システム |
n |
Y |
標準 |
|
Automation User - Custom |
ユーザー定義 |
Y |
Y |
カスタム |
ロールの複製とカスタマイズ
既存のロールをコピーしてカスタマイズできるオプションを追加しました。このオプションは、既定のロールとカスタマイズされたロールの両方で使用できますが、混合ロールでは使用できません。
既定のロールが読み取り専用になったため、既定のロールを編集して使用したい場合は、今回からはこの方法を使用します。
このオプションを使用するには、[テナント] > [アクセス権を管理] > [ロール] に移動し、行の右側にある 
[その他のオプション] をクリックして、[複製してカスタマイズ] を選択します。
ロールのエクスポートとインポート
既存のロールを CSV 形式にエクスポートし、そのファイルを Orchestrator にインポートできるようにしました。これにより、編集したロールの組み合わせを複数の組織やテナントで利用できます。
Orchestrator の資格情報を保存できるプラグインの選択肢を増やし、資格証明書ストア「HashiCorp Vault」を Orchestrator と新しく連携させました。設定の手順について詳しくは、「HashiCorp Vault」をご覧ください。
- キュー アイテムのデータが追跡されないよう、API を使用して
SpecificContentキーの値を削除できるようになりました。この操作には、エンドポイントPUT /odata/QueueItem({Id})を使用します。ペイロードの種類は、こちらからご確認ください。
キュー トリガーによるジョブの開始方法について、度重なる変更が生じておりましたが、再び検討を行った結果、挙動を改めて変更することとしました。なお、今回の変更が最終決定となる予定です。
以前の問題点: キューに追加された新しいアイテムの数が、処理中のアイテム数を下回っていると、ロボットがアイドル状態であっても追加のジョブが開始されませんでした。以前の算出方法では、実行中のジョブ (キュー アイテムをアクティブに処理しているジョブ) の数が、実行可能なジョブ (新しく追加されたアイテムを処理するのに必要なジョブ) の数より大きくなることが多く、その都度この問題が発生していました。
最初の修正: 実行可能なジョブの数を算出する際に、新しいアイテム数だけではなく、新しいアイテムと処理中のアイテムの合計数を考慮するようにしました。しかし、この方法には問題があることが分かりました。
最新の修正: Orchestrator では、実行可能なジョブの数を算出する際に新しいアイテムの数を考慮しますが、新しいジョブの開始可否を決定するために、保留中のジョブの数も確認します。以下の例をご確認ください。
-
キューに新しいアイテムが 2 つ存在し、保留中のジョブが 2 つ存在する => 新しいジョブは開始されません。
-
キューに新しいアイテムが 2 つ存在し、保留中のジョブが 1 つ存在する => 新しいジョブが 1 つ開始されます。
これにより、過度ではない適切な数のジョブを開始し、新しいアイテムをすべて処理できるようになりました。
- ジョブまたはトリガーの設定ミスに気付けるよう、ジョブの開始時やトリガーの設定時に、特定のランタイムが該当フォルダーに設定されているかどうかを簡単に確認できるようにしました。
ジョブの設定時には、フォルダー内のマシンに割り当てられているランタイムのみを選択できます。未割り当てのランタイムは選択できず、その旨を示すツールチップが表示されます。
トリガーの設定時には、フォルダー内のマシンに割り当てられていないランタイムを選択することはできますが、それらのランタイムには警告アイコンが表示されるため簡単に見分けられます。
-
以前は、Studio からのリモート デバッグや、Orchestrator での動的割り当てで使用できたのは NonProduction または Unattended ランタイムのみで、Testing ランタイムは使用できませんでした。今回のリリースでは、どちらのシチュエーションでも Testing ランタイムを利用できるようになりました。
-
Automation Cloud™ ロボットの使用時に、[ジョブの再開時にアカウントとマシンの割り当てを維持する] チェックボックスをオンにしてジョブを開始すると、ジョブの再開時には同じプールの任意のマシンが使用されるようになりました。つまり、マシンの種類は同じですが、まったく同じマシンが使用されるとは限りません。
-
キューのトランザクションを、トランザクションを処理したロボットで絞り込めるようになりました。ロボット フィルターのドロップダウン メニューを展開すると、該当するモダン フォルダーに存在するロボットが表示されます。フォルダー内のロボットを表示するには、ユーザーに対する [表示] 権限が必要です。
- テスト セットとテスト スケジュールの実行が失敗し、分散トランザクションがサポートされていない旨を示す次のようなエラーが表示されることがありました。
System.Data.Entity.Core.EntityException: The underlying provider failed on Open.System.PlatformNotSupportedException: This platform does not support distributed transactions. Test sets and test schedules are now executed with no errors. - 以前は、Azure のストレージ バケットを含む Orchestrator のフォルダーを削除すると、すべてのデータが Azure からも物理的に削除されていました。今回のリリースでは、フォルダーを削除すると Orchestrator 側では論理的な削除が実行され、Orchestrator ユーザーがデータを利用できない状態になりますが、Azure にはデータが利用できる状態で残されるようになりました。
