2022 年 4 月

Automation Cloud の Orchestrator の 2022 年 4 月のリリース ノート

2022 年 4 月 18 日

複数のアカウントが登録されたコネクションのサポート

注:

この機能は個人用ワークスペースでのみ利用可能です。

To accommodate automation projects with multi-account connections, we implemented a new feature that allows personal workspace owners to see those accounts and specify one for launching the job. You can change the account on the Package Requirements tab when creating a process or editing an existing one.

A drop-down is available for each connection with multiple accounts allowing you to see the entire list of available accounts and change the active account as needed.

コネクションを管理したり、新しいコネクションを追加したりする場合は、 アイコンを選択すると Integration Service にジャンプします。

コネクションについて詳しくは、『Integration Service ガイド』をご覧ください。

Cookie からトークンベースの認証へ

We migrated from cookie-based authentication to token-based authentication. Following this change, user login attempts are no longer saved in Orchestrator. As a result, the /odata/UserLoginAttempts({key}) endpoint and corresponding Login Attempts section on the My Profile page in Orchestrator have been deprecated and only return login attempts made prior to this change (i.e. login attempts with cookies).

From now on, login attempts made using access tokens can be accessed solely via Audit Logs in Automation Cloud. Contact your administrator to request this data.

トークンベースの認証では、ユーザーの最終ログイン時刻を 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 での API 呼び出しを認可する

Swagger UI で、OAuth2 を使用して API 呼び出しを認可できるようになりました。

アクセス トークンの取得方法、要求の送信方法、アクセスの取り消し方法について詳しくはこちらをご覧ください。

その他の改良点

エラスティック ロボット オーケストレーション

• エラスティック ロボット プールをフォルダーに追加すると、そのすべてのサブフォルダーにもプールが追加されるようになりました。このため、サブフォルダーからでもエラスティック ロボット オーケストレーションを使用してジョブを実行できます。
• フォルダーごとにプールを 1 つしか設定できない制限を解除しました。

CyberArk CCP

• Orchestrator がサーバー ルート CA 証明書として .cer 形式の証明書をサポートするようになりました。
• 証明書の構成エラーのメッセージに、問題の原因に関する詳しい情報が表示されるようにしました。

2022 年 4 月 5 日

Cloud ロボット - サーバーレス (プレビュー)

この機能は Community プランのユーザーのみが利用できます。

オートメーションが実行されるインフラストラクチャのことをユーザーが気に掛けなくて済む、新しい機能を追加しました。

UiPath は過去数か月にわたり、その実現を最優先事項としてきました。今回のリリースでは、 UiPath Automation CloudTMロボット - サーバーレス、略して Cloud ロボット - サーバーレス を追加しました。

サーバーが不要な Cloud ロボットを使用することで、必要なインフラストラクチャのことを気に掛ける必要なくバックグラウンド オートメーションを簡単に実行できます。基となるインフラストラクチャのプロビジョニング、管理、保守、スケーリングは、すべて UiPath 側で完全に管理されます。このため、コンテナーや仮想マシン、物理サーバーをユーザー側で用意・管理する必要がありません。

Automation Cloud ロボット - サーバーレスとその設定方法について詳しくは、こちらをご覧ください。

2022 年 4 月 4 日

ロールの変更に伴う API の変更

API: ロールを割り当てるための新しいエンドポイント

既存のアカウントにロールを割り当てる、または割り当てられたロールを上書きすることのできる、新しいエンドポイントを Orchestrator API に追加しました。

投稿/odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles

新しいエンドポイントではロール名ではなくロール ID に基づいてロールが割り当てられるため、既存のユーザー エンドポイントと比較すると信頼性が向上しています。

新しいエンドポイントは、Orchestrator API の Swagger (<OrchestratorURL>/swagger) で確認できます。

API ガイド: Assigning roles (ロールを割り当てる)

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 連携内で今回の変更の影響を受ける要求を特定し、特定された要求ごとに以下の手順に従います。

1. ユーザー ID と、影響を受ける API 要求によって割り当てられるロール名をメモします。
2. /odata/Roles に GET 要求を送信し、現在のロールのリストを取得します。
3. 先ほどメモしたロール名の ID をメモします。
4. (任意ですが推奨) API 連携内で、影響を受ける要求からロール名プロパティを削除します。 この変更によって、この要求ではロールが割り当てられなくなります。今後は次の手順で追加する要求によってロールの割り当て処理が行われます。 割り当て済みのロールは次の手順の要求によって上書きされるため、この要求からロール プロパティを削除しないことも可能です。
5. 影響を受ける要求の直後に、/odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles への POST 要求を追加します。要求の本文にはロール ID を含めます。

{key} の値は、影響を受ける要求のユーザー ID である必要があります。

これによって、先ほど特定した影響を受ける要求によって割り当てられるロールは、正しいロールで即座に上書きされます。

B. ロール名を更新する

より簡単ですが効率的ではない修復方法は、影響を受ける要求を新しいロール名で更新することです。

注:

この方法は簡単ですが、後からロール名が変更された場合に対して連携が強化されるため、代わりに前の方法の使用を検討することをお勧めします。

この修復方法では、お使いの API 連携内で今回の変更の影響を受ける要求を特定し、特定された要求ごとに以下の手順に従います。

1. /odata/Roles に GET 要求を送信し、現在のロールのリストを取得します。
2. 影響を受ける要求によって割り当てられるロールの、現在の名前をメモします。
3. API 連携内で、影響を受ける要求のロール名プロパティの値を、新しいロール名で更新します。

API: 非推奨化のお知らせ

ここ最近のロール名の変更を鑑みて、また、ユーザーに影響を与えずにロールを今後も更新できるようにするため、Orchestrator API のロール名プロパティの使用を非推奨とすることを決定しました。

今後も、最低 6 か月間はこのプロパティのサポートを継続する予定です。

ただし、このプロパティの非推奨化に伴う重大な変更の影響を受けないよう、新しいエンドポイントを使用してロールを割り当てるための移行作業を開始することをお勧めします。

改良点

ロール名に使用できる文字数の上限を 32 文字から 64 文字に増やしました。

追記 2022 年 11 月 2 日: テスト ケースの jobs.created Webhook のペイロードに、ジョブの実行に使用された特定のロボット ID とマシンが表示されるようになりました。

バグ修正

モダン フォルダーでジョブを開始または作成する要件として、ロボットの表示権限を追加しました。このため、ジョブの [開始] ボタンは、必要な権限がユーザーに割り当てられるまでは非アクティブ状態で表示されます。必要な権限は、ボタンのツールチップに表示されます。以前は、モダン フォルダーでジョブを開始または作成すると、「You are not authorized! (#0)」というエラー メッセージのみが表示されていました。