- リリース ノート
2022 年 4 月
オートメーション プロジェクトのコネクションに複数のアカウントが登録されている場合に対応した新機能を追加しました。個人用ワークスペースの所有者は複数のアカウントを確認し、ジョブを開始する際に使用するアカウントを指定できます。アカウントの変更は、プロセスの作成時、または既存のプロセスの編集時に、[パッケージ要件] タブで行うことができます。複数のアカウントが登録されたコネクションにはドロップダウン リストが表示されます。このリストには利用可能なアカウントがすべて表示されるので、それらを確認し、必要に応じてアクティブなアカウントを変更できます。
コネクションを管理したり、新しいコネクションを追加したりする場合は、
アイコンをクリックすると Integration Service に移動します。
コネクションについて詳しくは、『Integration Service ガイド』をご覧ください。
/odata/UserLoginAttempts({key}) およびそれに対応する Orchestrator の [マイ プロファイル] ページの [ログイン試行] セクションは非推奨となり、今回の変更より前に行われたログイン試行 (Cookie を使用したログイン) のみが返されます。今後は、アクセス トークンを使用して行われたログイン試行のデータには、Automation Cloud の監査ログからのみアクセスできます。このデータが必要な場合は管理者にお問い合わせください。
トークンベースの認証では、ユーザーの最終ログイン時刻を Orchestrator が算出する方法が変わります。今後は、Orchestrator をアクティブに使用しているユーザーに対して、最終ログイン時刻が 1 時間に 1 度算出されます。
たとえば、ユーザーが 14:10 から 15:00 の間に Orchestrator を使用しているとします。14:10 に認証が行われた場合、1 時間後の次回の確認までの間は、最終ログイン時刻として 14:10 が表示されます。Orchestrator を 16:00 まで使用している場合は、ユーザーの最終ログイン時刻として 15:10 が表示されます。
ユーザーの最終ログイン時刻の算出方法の変化は、Orchestrator の以下の UI で確認できます。
- [ロールを割り当て] ページ ([テナント] > [アクセス権を管理])
-
[個人用ワークスペース] ページ ([テナント] > [フォルダー] > [個人用ワークスペース])
注: 一般的なリリースのスケジュールと異なり、この機能が Enterprise プランのユーザーに公開されるのは Community プランの公開日の 1 週間後ではなく、5 月 2 日の週となります。
Swagger UI で、OAuth2 を使用して API 呼び出しを認可できるようになりました。
アクセス トークンの取得方法、要求の送信方法、アクセスの取り消し方法について詳しくはこちらをご覧ください。
エラスティック ロボット オーケストレーション
- エラスティック ロボット プールをフォルダーに追加すると、そのすべてのサブフォルダーにもプールが追加されるようになりました。このため、サブフォルダーからでもエラスティック ロボット オーケストレーションを使用してジョブを実行できます。
- フォルダーごとにプールを 1 つしか設定できない制限を解除しました。
CyberArk CCP
- Orchestrator がサーバー ルート CA 証明書として
.cer形式の証明書をサポートするようになりました。 - 証明書の構成エラーのメッセージに、問題の原因に関する詳しい情報が表示されるようにしました。
この機能は Community プランのユーザーのみが利用できます。
オートメーションが実行されるインフラストラクチャのことをユーザーが気に掛けなくて済む、新しい機能を追加しました。
今回のリリースでは、UiPath Automation CloudTM ロボット - サーバーレス (Cloud ロボット - サーバーレス) を公開しました。
サーバーが不要な Cloud ロボットを使用することで、必要なインフラストラクチャのことを気に掛ける必要なくバックグラウンド オートメーションを簡単に実行できます。基となるインフラストラクチャのプロビジョニング、管理、保守、スケーリングは、すべて UiPath 側で完全に管理されます。このため、コンテナーや仮想マシン、物理サーバーをユーザー側で用意・管理する必要がありません。
Automation Cloud ロボット - サーバーレスとその設定方法について詳しくは、こちらをご覧ください。
API: ロールを割り当てるための新しいエンドポイント
既存のアカウントにロールを割り当てる、または割り当てられたロールを上書きすることのできる、新しいエンドポイントを Orchestrator API に追加しました。
/odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles新しいエンドポイントではロール名ではなくロール ID に基づいてロールが割り当てられるため、既存のユーザー エンドポイントと比較すると信頼性が向上しています。
<OrchestratorURL>/swagger) で確認できます。
API: 重大な変更
ロール機能のここ最近の改良 (詳しくはこちら、およびこちらをご覧ください) によって、一部のロールの名前が変更されています。このため、新しいロール名を使用するには、名前が変更されたロールを参照する API 呼び出しをすべて更新する必要があります。
この変更により、次の API 呼び出しに影響があります。
-
既定ロールをカスタマイズしたロール (新しい名前:
Role name- カスタム) に関連する API 呼び出し重要: こういった呼び出しは変更作業を行わなくても動作し続けますが、期待どおりの結果は得られません。現在この呼び出しを使用すると、カスタマイズされたロールではなく既定のロールが割り当てられます。 -
以前の Tenant Administrator ロール (新しい名前: Orchestrator Administrator) に関連する API 呼び出し
指定した名前のロールを見つけることはできないため、この呼び出しを使用するとエラーが発生します。
影響を受けるエンドポイント
ロール名に基づいてロールを割り当てることができる API 要求は、以下のとおりです。
- POST
/odata/Users - PUT
/odata/Users({key}) - PATCH
/odata/Users({key}) - POST
/odata/Users({key})/UiPath.Server.Configuration.OData.ToggleRole
修復方法
この問題に対処するため、ロール名ではなくロール ID に基づいてロールを割り当てることのできる新しいエンドポイントを使用できます。
この変更の影響を受ける API 連携を更新し、期待どおりに動作させる方法には、以下の 2 種類があります。
A. 2 つ目の API 呼び出しを追加する (推奨)
既存の API 要求をそのまま残すことができます。ロールを割り当てる各呼び出しの後ろに新しいエンドポイントに対する呼び出しを追加することで、一度割り当てられたロールを正しいロールで上書きします。
/odata/Users に POST 要求を送信してテナントの管理者アカウントを作成するとします。この場合、アカウント作成処理の一環として、この要求では Tenant Administrator ロールを割り当てようとします。しかし、このロールは Orchestrator Administrator ロールに名前が変更されています。そこで、この要求の後に /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles に送信する新しい POST 要求を追加します。このエンドポイントによって Orchestrator Administrator ロールのロール ID が渡されるため、ロールが正しく割り当てられます。
この修復方法では、お使いの API 連携内で今回の変更の影響を受ける要求を特定し、特定された要求ごとに以下の手順に従います。
- ユーザー ID と、影響を受ける API 要求によって割り当てられるロール名をメモします。
/odata/Rolesに GET 要求を送信し、現在のロールのリストを取得します。- 先ほどメモしたロール名の ID をメモします。
-
(任意ですが推奨) API 連携内で、影響を受ける要求からロール名プロパティを削除します。
この変更によって、この要求ではロールが割り当てられなくなります。今後は次の手順で追加する要求によってロールの割り当て処理が行われます。
割り当て済みのロールは次の手順の要求によって上書きされるため、この要求からロール プロパティを削除しないことも可能です。
-
影響を受ける要求の直後に、
/odata/Users({key})/UiPath.Server.Configuration.OData.AssignRolesへの POST 要求を追加します。要求の本文にはロール ID を含めます。{key}の値は、影響を受ける要求のユーザー ID である必要があります。
これによって、先ほど特定した影響を受ける要求によって割り当てられるロールは、正しいロールで即座に上書きされます。
B. ロール名を更新する
より簡単ですが効率的ではない修復方法は、影響を受ける要求を新しいロール名で更新することです。
この修復方法では、お使いの API 連携内で今回の変更の影響を受ける要求を特定し、特定された要求ごとに以下の手順に従います。
/odata/Rolesに GET 要求を送信し、現在のロールのリストを取得します。- 影響を受ける要求によって割り当てられるロールの、現在の名前をメモします。
- API 連携内で、影響を受ける要求のロール名プロパティの値を、新しいロール名で更新します。
ここ最近のロール名の変更を鑑みて、また、ユーザーに影響を与えずにロールを今後も更新できるようにするため、Orchestrator API のロール名プロパティの使用を非推奨とすることを決定しました。
今後も、最低 6 か月間はこのプロパティのサポートを継続する予定です。
ただし、このプロパティの非推奨化に伴う重大な変更の影響を受けないよう、新しいエンドポイントを使用してロールを割り当てるための移行作業を開始することをお勧めします。
ロール名に使用できる文字数の上限を 32 文字から 64 文字に増やしました。
jobs.created Webhook のペイロードに、ジョブの実行に使用された特定のロボット ID とマシンが表示されるようになりました。
