2021.10

パッチのドキュメントに関する UiPath の方針

UiPath では、ビジネス ニーズに応じて修正と改善を含むパッチを定期的にリリースしています。パッチがリリースされる際は、対象の製品バージョンのドキュメントを更新し、そのバージョンの最新のパッチの内容が反映されるようにします。

たとえば、2021 年 3 月に v2020.4.5 のパッチがリリースされた際は、Orchestrator v2020.4 のドキュメントが、v2020.4.5 のパッチの変更内容に基づいて更新されました。

パッチによって導入された変更点は、そのパッチのリリース ノートに記載されます。

公開日: 2021 年 11 月 3 日

Automation Suite

Orchestrator が、新しく Automation Suite でもデプロイできるようになりました。Automation Suite は、UiPath が提供する Web ベースの製品のインストール、アップグレード、および管理を、簡単かつスムーズに一貫性のある方法で行えるように設計されたバンドルです。詳しくは、『Automation Suite ガイド』をご覧ください。

公開日: 2021 年 10 月 25 日

今回 v2021.10 が公開されるまでの間に、UiPath ではオートメーションを「有人/無人」、「フォアグラウンド/バックグラウンド」、「リモート/サービス」のカテゴリで区分するようになりました。

急速に発展し続ける IT 技術とともに、UiPath が提供する自動化ソリューションの選択肢もそれだけ発展し多種多様化してきたのです。

今回のリリースでは特に有人/無人オートメーションの間の利便性の差を解消することに注力し、ローカル マシンを使用しない「リモート オートメーション」をすべてのユーザーが利用できるようにしました。

Orchestrator の新しいデザイン システム

今回のリリースより、Orchestrator では新しいデザイン システム「Apollo」が採用されます。このデザイン変更により、Orchestrator とその他の UiPath 製品との間でユーザー インターフェイスの一貫性が保たれるようになり、サービス間の移動が簡単になりました。また、ユーザー インターフェイスの改良もいくつか行われました。

Orchestrator の機能自体への変更はありませんが、特に重要な情報は以下のとおりです。

• 新たに追加されたヘッダー (a) はどのページを開いていても常に表示されるため、ユーザー メニュー (b) とクイック オプション (c) にいつでもアクセスできます。

  
  

  

  
  
• 一部のコントロールを、Orchestrator のメニューからヘッダーに移動しました。以前 Orchestrator ページの右上にあったユーザー メニューは、画面左上に表示されるようになりました。このメニューでは、ユーザーの言語、テーマ、およびサインアウトのオプションを選択できます。

システム管理者向けの新しいポータル

ユーザー エクスペリエンスを向上させるため、システム管理者が利用するホストレベルの設定オプションを整理し、適切な管理インターフェイスをより簡単に見つけられるようにしました。よりシンプルになった ID 管理ポータルでは、連携中のアプリのみが表示されます。ホスト管理ポータルでは、インストールに対するグローバルな設定を変更できます。Orchestrator ホスト ポータルでは、Orchestrator 自体に固有のホストレベルの設定のみを管理できます。

なお、機能自体は大きく変更されておりませんのでご安心ください。

各種ホスト ポータルと、それぞれのポータルで利用可能なオプションについて詳しくは、ホスト管理ポータルについてのこちらのページをご覧ください。

無人オートメーション

自動化できるテクノロジの種類は日々増えています。これに伴い、支障なくオートメーションを活用するためにインフラストラクチャを適切に計画・管理する必要がある場面も多くなりました。

今回は、無人オートメーションの運用全般に関わる管理者の課題を解決する一連の新機能を追加しました。以下ではそれらの機能について詳しく説明します。

無人オートメーション用のロボット アカウント

新しく「ロボット アカウント」を利用できるようになりました。

ロボット アカウントは、人間以外のユーザーを表す ID です。通常のユーザー アカウントと同じ方法で設定できますが、プラットフォーム全体でロボットとして明確に識別されます。このアカウントは、Windows がサービスの実行に使用するアカウントに似ています。このアカウントを使用することで、無人オートメーションを実行するためのダミーのユーザー アカウントを作成する必要がなくなります。

ロボット アカウントへの移行

無人プロセスにユーザー アカウントを使用している場合は、ロボット アカウントを使用するように移行できます。

次の手順で行います。

1. ロボット アカウントを作成します。

2. 無人オートメーションに使用するロボット アカウントを、ユーザー アカウントと同じ手順で設定します。

   プロセスが問題なく実行し続けられるよう、ロボット アカウントにはユーザー アカウントと同じロールを割り当て、同じロボットの設定を構成します。 ロボット アカウントにはユーザー ライセンスは必要ありません。

3. ユーザー アカウントが割り当てられていたフォルダーにロボット アカウントを割り当てます。

   詳しくは、「アカウントまたはグループをフォルダーに割り当てる」をご覧ください。

4. 必要に応じて、ユーザー アカウントで不要になったロールがないか確認し、削除します。

   詳しくは、「ロールを確認する」をご覧ください。

無人オートメーションの設定の効率化

Studio で新しいオートメーション プロジェクトを作成する際、開発者はまず最初に、オートメーション プロジェクトの基になるターゲット フレームワークと、対応するオペレーティング システムを選択するよう求められます。これはその後プロセスを実行するために必要な設定です。

Studio のターゲット フレームワークについて詳しくは、こちらをご覧ください。

以下の表では、プロセスの実行に必要な Robot のバージョンをターゲット フレームワークおよび対応 OS 別に示します。

ターゲット フレームワーク	オペレーティング システム	Robot のバージョン
.NET Framework 4.6.1	Windows - レガシ	すべて
.NET 5.0+	Windows	2021.10+
.NET 5.0+	クロスプラットフォーム	2021.10+

Studio の [プロジェクト設定] に、[バックグラウンドで開始] オプションを追加しました。プロジェクトをユーザーの操作が可能な状態 (フォアグラウンド) で実行するのか、または単にバックグラウンド プロセス (バックグラウンド) として実行するのかを定義できます。Unattended ロボットはセッション 0 の NT AUTHORITY\LOCAL SERVICE でバックグラウンド プロセスを処理します。このセッションでは UI が表示されないため、ユーザー セッションとは対話できません。

バックグラウンド プロセスの自動化について詳しくは、こちらをご覧ください。

フォアグラウンド プロセスの実行には資格情報が必要ですが、バックグラウンド プロセスには不要です。

このため、今回からはバックグラウンド プロセスを実行する Unattended ロボットに対し、資格情報の設定を任意としました。

以下の表では、ロボットの資格情報の有無に応じた、フォアグラウンド/バックグラウンド プロセスの実行に必要な Robot のバージョンを示します。

プロセスの種類	ロボットの資格情報	Robot のバージョン
バックグラウンド	資格情報あり	すべて
フォアグラウンド	資格情報あり	すべて
バックグラウンド	資格情報なし	2021.10+
フォアグラウンド	資格情報なし	無効な設定です。フォアグラウンド ジョブを実行するには資格情報が必要です。

資格情報の定義が任意となるアカウントは次のとおりです。

• ロボット アカウント - サービス (無人) のオートメーションで使用するアカウント
• ユーザー アカウント - ユーザーの ID 下で実行する必要のある、個人 (リモート) のオートメーション専用のアカウント

[フォアグラウンド オートメーションを実行 (資格情報が必要)] トグルを切り替えるだけで資格情報の要否を簡単に設定できます。以下の画像をご確認ください。

無人オートメーションのインフラストラクチャの最適化

無人プロセスのワークロードでは、その時々でさまざまなインフラストラクチャの条件が求められます。効率を最大限に高め、無駄を最小限に抑えるには、ワークロードに対して適切なリソースを組み合わせることが重要です。

このため、新しいコントロールを 2 つ追加し、特定のマシンに実行させるジョブの種類を幅広い条件で指定できるようにしました。

具体的には、マシン テンプレートとそれに関連付けられたマシン インフラストラクチャで実行できるプロセスの種類や対応 OS を制限できます。マシン テンプレートを作成または編集する際に、以下のオプションを使用して設定できます。

フィールド	説明
プロセスの種類	このマシン テンプレートを使用するインフラストラクチャ上で実行できる実行できるプロセスの種類を以下から選択します。 フォアグラウンド プロセスのみ (1) バックグラウンド プロセスのみ (2) バックグラウンド プロセスとフォアグラウンド プロセスの両方 (3)
プロセスの対応 OS	このマシン テンプレートを使用するインフラストラクチャ上で実行できる実行できるプロセスの種類を以下から選択します。 Windows 対応プロセスのみ (4) クロスプラットフォーム プロセスのみ (5) Windows 対応プロセスとクロスプラットフォーム プロセスの両方 (6)

詳しくは、ドキュメントをご覧ください。

個人用ワークスペースでの無人オートメーションの実行

有人/無人オートメーションの間の利便性の差を解消するため、すべての RPA 開発者が個人用ワークスペースから RPA プロセスをリモートで無人実行できるようにしました。これは「個人 (リモート) オートメーション」として区分されます。

新規のユーザーには既定で個人用ワークスペースが設定され、そこから無人オートメーションを実行できます。このため、企業が管理する仮想マシン上でオートメーションを簡単にリモート実行できます。

すべての新規ユーザーに対する個人用ワークスペースの有効化

すべてのオートメーション ユーザーが有人オートメーションを実行できるよう、Attended ロボットを使用するユーザーを新しく追加すると、個人用ワークスペースが既定で有効化されるようにしました。

なお、この変更後に Orchestrator で参照されるユーザー グループや、自動的にプロビジョニングされるユーザーに対して Attended ロボットが既定で有効化されるわけではありませんのでご注意ください。管理者は、Attended ロボットを必要とするグループおよび/またはユーザーに対して、明示的に Attended ロボットを有効化する必要があります。

この変更により Orchestrator の既存の機能の一部が不要になったため、個人用ワークスペースの設定に関連するインターフェイスを以下の画像のように変更しました。

既存のユーザーやユーザー グループに対しては元の設定が保持されますので、ご安心ください。また、個人用ワークスペースの使用は強制ではありません。新規ユーザーやユーザー グループに対しては個人用ワークスペースが既定で有効化されますが、必要に応じてユーザー/グループごとにいつでも無効化できます。

個人用ワークスペースでの無人オートメーションの実行機能

テナント内のすべての RPA 開発者に対して無人実行機能を有効化するには、管理者がワークスペースにマシン オブジェクト (マシン テンプレートまたは標準マシン) を関連付ける必要があります。これにより、オートメーションを無人実行するためのインフラストラクチャ (マシンがキーによって Orchestrator に接続されている状態) が構成され、すべての個人用ワークスペースからオートメーションを無人実行できるようになります。

この操作は、テナント コンテキストの [フォルダー] > [個人用ワークスペース] から行えます。

マシン オブジェクトを関連付ける範囲を、特定のワークスペースに限定することはできません。マシン オブジェクトの設定は、すべてのワークスペースに関連付けるか、どのワークスペースにも関連付けないかのいずれかです。

マシン オブジェクトには、テナント内のすべてのワークスペースでオートメーションを実行するために必要な数のランタイムを割り当てる必要があります。

RPA 開発者による無人オートメーションの実行

管理者があらかじめ必要な設定を行えば、RPA 開発者は上述の無人実行にかかわる機能をすべて利用できます。

RPA 開発者が行える操作は次のとおりです。

A. トリガーを使用して、あらかじめ決められたタイミングやキュー アイテムの条件によってオートメーションを開始できます。

B. 監視機能を使用して、管理者によってワークスペースに割り当てられたマシンやマシン ランタイムの状態を確認できます。すぐにマシンの状態を確認できるよう、ワークスペースの [ホーム]

C. 新しく追加された [監視] ページから、ワークスペースのすべてのリソース (マシン、プロセス、キュー、および SLA 予測) の状態を確認できます。

モダン フォルダーと個人用ワークスペースの違い

個人用ワークスペースのコンテキストでは、ジョブはワークスペースを所有するユーザーのアカウント下で開始されます。このため、モダン フォルダーの機能と比較すると次のような違いがあります。

1. 個人用ワークスペースのコンテキストでは、マシン オブジェクトやユーザーを設定できません。
2. 個人用ワークスペースでは、RPA 開発者のユーザー アカウント下でプロセスが実行されるため、トリガーの実行ターゲットでユーザーを設定することはできません。
3. テスト機能とアクションは利用できません。このため、個人用ワークスペースのコンテキストではジョブの「中断」および「再開」ステートは存在しません。

今回の変更にスムーズに対応できるように、事前定義された Personal Workspace Administrator ロールに次の変更を加えました。詳しくは、ドキュメントをご覧ください。

マシン オブジェクトをすべてのサブフォルダーに一度に反映

無人オートメーションを社内でさらに運用しやすくするため、管理者は親フォルダーに割り当てられたマシン テンプレートや標準マシンを、同じ実行インフラストラクチャを必要とするすべてのサブフォルダーに数クリックで反映できるようにしました。このため、1 つ 1 つのサブフォルダーに同じマシンを手動で割り当てる必要がなくなりました。

マシンをフォルダーに割り当てる方法について詳しくは、こちらをご覧ください。

無人プロセスのデバッグ

Orchestrator のテナント設定で [ユーザー認証を強制し、ロボット キー認証を無効化] オプション (対話型サインイン) が有効化されている状態でも、スムーズにデバッグを行えるようにしました。

このオプションには、セキュリティが向上する、有人オートメーションを実行するユーザーが Orchestrator に簡単に接続できる、ユーザー ライセンス管理機能を利用してライセンス管理を効率化できる、といった複数のメリットがあります。その一方で、無人プロセスのデバッグが煩雑になるというデメリットがありました。

具体的には、対話型認証が強制されている状態で、マシン キーで Orchestrator に接続されたマシンにデバッグ目的でログインすると、一度 Assistant にサインインしなければデバッグ対象のプロセスが表示されませんでした。

今回のリリースでは、[ロボット] ページの [無人セッション] タブでマシンの [トラブルシューティング セッション] を有効化できるようにしました。

トラブルシューティング セッションを有効化すると、デバッグ目的で UiPath Assistant から無人プロセスを表示・実行できます。開発者がこの操作を実行する際には、ユーザー ライセンスは不要です。

トラブルシューティング セッションは一時的なセッションであり、上記の操作が行えるのはセッションがアクティブな間のみです。

詳しくは、「無人プロセスをデバッグする」をご覧ください。

有人オートメーション

Orchestrator を使用して有人ジョブを終了する

Orchestrator から有人ジョブを終了できる機能を追加したことで、企業の管理者が有人オートメーションを管理しやすくなりました。[オートメーション] > [ジョブ] に移動し、[その他のアクション] > [停止] または [強制終了]を選択することで、わずか数クリックで正常に動かなくなったオートメーションを終了させることができます。

注: 有人ジョブを Orchestrator で終了するには、v2021.10 以降の Robot を使用する必要があります。Orchestrator から有人ジョブを終了するには、SignalR を有効化し、Robot が WebSocket を使用して Orchestrator の SignalR チャネルに接続できるようにする必要があります。[設定] > [スケーラビリティ] で SignalR が有効化されていると共に、[WebSocket] が選択されていることを確認してください。

保留中のジョブの自動的な停止/強制終了

今回のリリースでは、未完了のジョブを終了させる機能を改良しました。これまでのように最初のアクションとして停止または強制終了を選択できるだけでなく、停止を試みた後にさらに強制終了を行うよう設定できるようにしました。具体的には、トリガーを作成する際に、特定の時間が経過したらジョブを停止させたり強制終了させたりするように設定できます。こうすることで、ジョブの処理フローを最適化し、あらかじめ決められた方法で未完了のジョブをすっきりと片づけることができます。

たとえば以下の画像の設定では、10 分以上保留状態が続いているジョブに対して、Orchestrator では停止が試行されます。それでもジョブが終了しない場合、20 分以上停止中の状態が続いているジョブに対して強制終了が試行されます。

トリガーの設定方法について詳しくは、こちらをご覧ください。

キューの改良

既存のキューを更新できるようにしました。具体的には以下のとおりです。

• 既存のキューの情報を維持したまま、キューの名前を変更できます。スペル ミスを修正したり、最初につけた名前を変更したりする際に、わざわざキュー (およびキュー アイテム) を削除して作成し直す必要がなくなりました。
• [自動リトライ] オプションを [いいえ] から [はい] に、またはその逆に変更できます。失敗したトランザクションを自動的にリトライさせるかどうかを、キューを作成した後でも検討・変更できるようになりました。
• [最大リトライ回数] に新しい値を設定できます。[自動リトライ] オプションを有効化した場合に、トランザクションが [成功] ステータスに変わるまでリトライされるよう、リトライの回数を設定できるようになりました。

上記の変更はキューの作成後に行うことができますが、変更が反映されるのは次回以降のトランザクションに対してのみですので、ご注意ください。

キューの編集方法について詳しくは、こちらをご覧ください。

Assistant ウィジェット

v2021.4.3 のリリースより、Automation Ops と Orchestrator のライブラリを使用して、UiPath Assistant にウィジェットを追加できる機能が利用できるようになりました。

これまでの Orchestrator では、ウィジェットが他のライブラリ パッケージと同じように表示されており不便でした。このため、今回はウィジェット専用の新しいライブラリの種類として、「Assistant ウィジェット」を追加しました。Orchestrator に今後アップロードされるウィジェットはすべて [Assistant ウィジェット] として表示されるため、ウィジェットとプロセスを区別しやすくなります。

注: この変更より前に Orchestrator にアップロードされたウィジェットは、これまでどおり [プロセス ライブラリ] として表示されます。

ウィジェットについて詳しくは、こちらをご覧ください。

長期実行のワークフロー

長期実行のワークフローでの Attended ロボットの使用

これまで、長期実行のワークフローを実行できるのは Unattended ロボットのみでした。これからは、UiPath Assistant からオーケストレーション プロセスを起動し、生成されたアクションが Action Center で完了されるまで待機した後、プロセスの残りの実行を Unattended ロボットに任せることができます。

ユーザーがジョブを開始する際に使用されるライセンスと、Unattended ロボットがジョブを再開する際に消費されるライセンスの相関関係は、下表のとおりです。

Attended ロボットでジョブを開始する際に使用されるライセンス	ジョブの再開時に消費されるライセンス
Attended User ライセンス	Unattended ロボット ライセンス
開発者ユーザー ライセンス Citizen Developer RPA 開発者 (RPA Developer) RPA Developer Pro	NonProduction ロボット ライセンス

Unattended ロボットでジョブを再開する際は、ジョブが最初に開始されたサーバーと異なるサーバーを使用することもできます。

ジョブ再開時におけるアカウントとマシンの設定の保持

リソースを最大限に活用するため、中断していたジョブを再開する際は、既定の設定を適用して利用可能な任意のロボットとマシンを使用することをお勧めします。しかし、次のような場合もあります。

• 再開されるジョブの実行に特定のアプリケーション (SAP など) が必要であり、そのアプリケーションは特定のマシンにインストールされている。
• ジョブの開始時と再開時で、同じユーザー コンテキストを使用する必要がある。

上記のような、ジョブの再開時に使用するリソースやライセンスの要件に対応するため、ジョブの開始時に指定したアカウントとマシンの設定を、ジョブの再開時にも使用できるオプションを追加しました。詳しくは、「ジョブを管理する」をご覧ください。

アカウントとアクセス権

インターフェイスの変更

管理ポータルの [アカウントとグループ] ページで行うアカウントを追加する操作と、Orchestrator で行うアカウントにアクセス権を付与する操作を区別しやすくするため、Orchestrator のインターフェイスを改良し、ページやタブの用語を一部変更しました。

今回の変更点は以下のとおりです。

• テナント レベルの [ユーザー] ページと [ロール] ページを、[アクセス権を管理] ページにまとめました。

• これまで [ユーザー] ページからアクセスできていた機能は、[アクセス権を管理] ページの [ロールを割り当て] タブから利用できるようになりました。

  [ユーザー] ページではアカウントの作成自体は行えず、既存のアカウントを Orchestrator に追加してロールを割り当てることしかできなかったため、今回タブの名前を上記のように変更しました。

• 同様に、以前の [ロール] ページからアクセスできていた機能は、[アクセス権を管理] ページの [ロール] タブからそのまま利用できます。

• また、アカウントとグループにロールを割り当てる方法を分けました。以前はどちらも同じ手順で行っていましたが、今回からはユーザーまたはロボット アカウント用とグループ用のそれぞれの操作に対応した異なるウィザードが表示されます。
• [ロールを割り当て] タブ (テナント コンテキスト > [アクセス権を管理] > [ロールを割り当て]) に、[アカウントおよびグループを管理] ボタンを追加しました。このボタンをクリックすると、管理ポータルの [アカウントとグループ] ページが開き、アカウントやグループを新しく追加できます。
• [アクセス権を管理] > [ロールを割り当て] タブにある [権限を確認] ボタンの名称を、[ロールを確認] に変更しました。実際にユーザーやグループに割り当てるのは「ロール」であり、ロールを構築する要素である「権限」を個別に割り当てることはないためです。

ドキュメント

• ユーザー アクセスの管理について
• ロールを割り当てる
• ロールを管理する

ディレクトリ アカウントを使用したシステム管理者の追加

ユーザーがディレクトリにリンクしている場合は、ローカル アカウントを作成する方法以外にディレクトリ アカウントを追加する方法によってもシステム管理者を追加できるようにしました。詳しい手順については、「 システム管理者を追加する」をご覧ください。

Elasticsearch の OAuth2 認証

Elasticsearch のロボット ログの読み込みに対して OAuth2 認証がサポートされるようになりました。このため、認証方法としてユーザー名とパスワードの代わりにトークンを使用できるようになりました。

OAuth 認証を使用してログを読み込むため、このメカニズムを有効化する Logs.Elasticsearch.OAuthEnabled パラメーターと、トークンの有効期限を制御する Logs.Elasticsearch.OAuthExpireInSeconds パラメーターを Orchestrator の UiPath.Orchestrator.dll.config ファイルに追加しました。

また、NLog に対しても OAuth2 認証を利用できます。OAuth2 認証を有効化するには、ターゲットの構成に属性 OAuthEnabled = “true” を設定します。

利用可能な認証方法について詳しくは、「X-Pack 認証」をご覧ください。

パッケージとオートメーション

パッケージ要件の表示

これまでは、プロセスを開始するために必要なリソースを確認するには、Studio や、Orchestrator のパッケージ エクスプローラーでオートメーション プロジェクトを確認する必要がありました。今回、プロセスの開始に必要なリソースが表示される機能を追加し、初めて利用するプロセスを簡単に実行できるようにしました。

プロセスに必要なキュー、アセット、アクション カタログ、およびストレージ バケットをあらかじめ確認できるため、プロセスをすばやく準備して開始できます。

注: この機能を利用するには、v2021.10 以降の Studio と v2021.10 以降のアクティビティ パッケージが必要です。

プロセスを追加または編集する際に、すべてのプロセスの依存関係が Orchestrator 内のページに一覧で表示されます。また、必要な各オブジェクトに関する便利な情報も確認できます。

さらに、プロセスのコンテキストを離れることなく、必要なリソースをすばやく作成したりリンクしたりできます。アセットが見つからない場合はその場で作成でき、必用なキューが別のフォルダーにある場合はボタンをクリックするだけでそのキューをリンクできます。

ホスト ライブラリ フィードへのロボットのアクセスを制限

ライブラリ パッケージを取得する際に、ロボットが既定のホスト フィード (現在 MyGet 上に存在する) にアクセスできることが、セキュリティ上の問題になることがありました。このため、[設定] ページに新しいオプションを追加し、ロボットの接続先をテナント フィードに限定できるようにしました。

以前は、ライブラリ パッケージの取得先オプションとして [ホスト フィードのみ] と [ホスト フィードとテナント フィードの両方] が用意されていましたが、今回さらに [テナント フィードのみ] のオプションを追加しました。

ライブラリ フィードの設定方法について詳しくは、こちらをご覧ください。

プロセスのデバッグ

実行中のジョブがプロセスに対して許可された最大数に到達したことを知らせるアラートの重要度を、Error から Info に変更しました。このため、プロセスをデバッグしやすくなりました。このアラートでは、次のようなポップアップ メッセージが表示されます。「フォルダー (フォルダー名): # プロセス (プロセス名) の # トリガー (トリガー名) はジョブを作成できませんでした。このプロセスに対するジョブの最大数に既に達しています。トリガーの設定、ロボットの利用状況、および実行中のジョブを確認してください。(#1693)」

このようなアラート メッセージを [アラート] ページで確認できるようにするには、[ステート] フィルターを [すべて] に変更してください。

Orchestrator でデプロイされたすべてのプロセスの記録

Orchestrator でデプロイされるすべてのプロセスに対してメディア レコーディング機能を既定で有効化し、この機能の設定トグルをインターフェイスから削除しました。アプリの設定パラメーター MediaRecording.Enabled を使用すればレコーディング機能を無効化できます。

ただし、機能を有効化する際はプロセスごとにオンに切り替える必要があります。プロセスごとにメディア レコーディング機能を有効化する方法について詳しくは、こちらをご覧ください。

動的型付け

新しく追加した動的型付けオプションは、キュー アイテムのアップロードに使用する CSV ファイル内の String 型の値を Orchestrator がどのように解釈するかを制御できる機能です。キューに設定されたスキーマの定義に一致するように、Orchestrator が数値を Integer 型または Boolean 型の値として解釈する必要がある場合に特に便利です。

以前は、数値を含む CSV ファイルをアップロードしようとしても Orchestrator がその数値を String 型の値として読み込んでいたため、Integer/Boolean 型を要求する JSON スキーマに対する検証に失敗していました。そのため、「キュー アイテムが固有データ JSON スキーマに違反しています」というエラーが表示されていました。

Orchestrator へのキュー アイテムのアップロードについて詳しくは、こちらをご覧ください。

パフォーマンスのベスト プラクティス

ログのテーブルに 100 万件を超えるロボット ログが保存されている際のパフォーマンスの低下を防ぐため、インデックスの作成をお勧めします。詳しくは、「Orchestrator のログ」をご覧ください。

インストールとアップグレードのユーザー エクスペリエンス

クライアント コンポーネントの自動更新

UiPath Robot、Studio、Assistant のクライアントのバージョンを Orchestrator から更新できるようになりました。一元化された場所から多数のマシンのバージョンを簡単に更新できるため、ユーザーの負担を軽減し、バージョンの更新プロセスを効率化できます。

UiPathOrchestrator.msi インストーラーには、この機能の更新サーバー専用の設定オプションとして UI に [更新サーバーのデータベース設定] 画面を、CLI に専用のパラメーターを追加しました。詳しくは、「Windows インストーラー」と「Orchestrator のコマンド ライン パラメーター」をご覧ください。

アップグレード

• Publish-Orchestrator.ps1 スクリプトから、-hostAdminPassword、-isHostPassOneTime、-defaultTenantAdminPassword、-isDefaultTenantPassOneTime パラメーターを削除し、MigrateTo-IdentityServer.ps1 スクリプトの専用キーとしました。MigrateTo-IdentityServer.ps1 パラメーターについて詳しくは、こちらをご覧ください。
• Orchestrator v2021.10 にアップグレードする際は、パフォーマンスの低下を防ぐため queueItemEvents と jobEvents をあらかじめクリーンアップしておくことをお勧めします。
• 以前のバージョンの Az モジュールが使用されている状態で Az v6.0.0 にアップグレードしようとすると、WARNING: The version 'x.x.x' of module 'Az.<Name>' is currently in use. Retry the operation after closing the applications. (警告: バージョン 'x.x.x' のモジュール 'Az.<Name>' が現在使用されています。アプリケーションを閉じてから操作をもう一度お試しください。) というメッセージが表示されます。この問題を解決するには、新しい PowerShell セッションで Publish-Orchestrator.ps1 を実行してください。
• テナントの暗号化に Microsoft Azure Key Vault を使用する場合は、Orchestrator インスタンスの UiPath.Orchestrator.dll.config ファイルで追加のパラメーター Azure.KeyVault.DirectoryId を設定する必要があります。詳しい手順については、「テナントごとに暗号化キーを設定する」をご覧ください。
• これまで UiPath.Orchestrator.dll.config ファイルの設定パラメーター WindowsAuth.ConvertUsersAtLogin で制御されていた Active Directory アカウントの変換処理が、インストールまたはアップグレード中に自動で行われるようになりました。そのため、この設定パラメーターを dll.config ファイルから削除しました。この変更による、既存のロボットへの影響はありません。
  注: v2018.4 を使用しており、Active Directory のローカル ユーザーをディレクトリ ユーザーに変換する作業を完了していない場合 (またはインポートしたユーザー全員を変換していない場合)、変換を完了するためには、未変換のディレクトリ アカウントを使用して少なくとも 1 回は Orchestrator に対話型サインインする必要があります。ID 管理ポータルへのサインイン、または UiPath Studio や UiPath Assistant からのサインインでは、アカウントの変換は完了できません。

構成

• 新しい UiPath.Orchestrator.dll.config パラメーターとして ProxyIntegration.Enabled を追加しました。このパラメーターを使用すると、プロキシ連携を無効化できます。既定ではこのパラメーターは表示されておらず、値は true に設定されています。つまり、特に指定しない限りはプロキシ連携が有効化されます。
• Identity Server のパブリック アドレスを指定する必須パラメーター -identityServerUrl を、Publish-IdentityServer.ps1 スクリプトに新たに追加しました。詳しくは、「Publish-IdentityServer.ps1 のパラメーター」をご確認ください。

API

• メンテナンス モードのテナントに API 呼び出しを行った際に返されるステータス コードを、503 から 423 に変更しました。
• FolderNavigation API の GetFolderNavigationContextForCurrentUser エンドポイントに、ブール値のプロパティ IsPersonal を追加しました。このプロパティはエンドポイントの応答本文に表示され、返されたフォルダーが個人用ワークスペースかどうかを確認します。詳しくは、ユーザー ガイドの API リファレンスをご覧ください。
• API 経由で監査ログを取得する際のパフォーマンスを向上させるため、エントリが最大 3,000 件までのバッチ単位で返されるようにしました。最初の 3,000 件より後のエントリを取得するには、クエリ パラメーターである skip と top を使用します。たとえば監査ログのエントリの 2 つ目のバッチ (3,001 件目から 6,000 件目まで) を取得する場合、API 呼び出しは次のようになります。 GET https://{base_url}/{organization}/{tenant}/api/auditLog?top=3000&skip=3000

• 監査データに必要なプロパティをいくつかのリソースの DTO に追加しました。したがって、エンドポイントの応答本文が以下のように変更されます。

  • /odata/Users

    "LastModificationTime": "2021-10-12T07:29:25.914Z", "LastModifierUserId": 0, "CreatorUserId": 0

  • odata/Robots

    "LastModificationTime": "2021-10-12T07:32:24.940Z", "LastModifierUserId": 0, "CreationTime": "2021-10-12T07:32:24.940Z", "CreatorUserId": 0

  • odata/Releases

    "LastModificationTime": "2021-10-12T07:29:25.914Z", "LastModifierUserId": 0, "CreatorUserId": 0

  • odata/Assets

    "LastModificationTime": "2021-10-12T07:57:15.145Z", "LastModifierUserId": 0, "CreationTime": "2021-10-12T07:57:15.145Z", "CreatorUserId": 0

  • odata/Libraries

    "Created": "2021-10-12T07:59:04.182Z", "LastUpdated": "2021-10-12T07:59:04.182Z", "Owners": "string", "IconUrl": "string", "Summary": "string", "PackageSize": 0, "IsPrerelease": true, "LicenseUrl": "string", "ProjectUrl": "string"

重要:

リリース ノートの誤記について (2021 年 12 月 9 日)

このリリース ノートに記載されている DTO プロパティは、UiPath 側の都合により 2021.10 のリリースでは提供が開始されませんでした。

更新: 2022 年 5 月 9 日

DTO プロパティが Orchestrator 2022.4 の以下のリソースに追加されました。

• /odata/Users

• /odata/Robots

• /odata/Releases

• /odata/Assets

• /odata/Libraries

テスト

今回のリリースから、Tenant Administrator ロールにバックグラウンド タスクの表示権限が含まれるようになりました。この変更は、既存の Tenant Administrator ロールには適用されません。既定のロールとその権限について詳しくは、こちらをご覧ください。

Orchestrator から分離した機能

アクション タブと管理機能の廃止

2021.4 のリリース ノートでお知らせしたとおり、[アクション]タブとアクションに関わる管理機能を Orchestrator で廃止しました。これをもって、アクションに関する機能は Action Center に完全に移行しました。Action Center ではすべてのアクションを表示・管理でき、アクションの割り当て、転送、完了、ならびにアクション カタログの管理ができます。Action Center を使用する際は、ユーザーが Orchestrator 上で適切なフォルダーに追加されていることを確認してください。なお、Orchestrator で管理していた既存のアクションのリンクは、インストーラーによって Action Center のインターフェイスにすべてリダイレクトされますのでご安心ください。ユーザー側で必要な作業はオンプレミス版 Action Center のインストールまたはアップグレードのみですが、Action Center を 1 つの Orchestrator インスタンスに接続する必要がありますのでご注意ください。Action Center は、Orchestrator と同じサーバーまたは別のサーバーにインストールされます。

Action Center のエクスペリエンスについて詳しくは、こちらをご覧ください。

Orchestrator と Insights の分離

Insights の機能を Orchestrator から切り離しました。これに伴い廃止された機能はありませんのでご安心ください。これまで Orchestrator を介して実行していたすべてのタスクは、Insights で実行できます。詳しくは、『Insights ガイド』をご覧ください。

使用性の改良

• [同時接続実行を無効化] オプションの名前を、実際の機能に即して [一度に 1 つのジョブのみを実行] に変更しました。
• パッケージ バージョン ウィンドウの [その他のアクション] メニューに、個々のパッケージ バージョンを削除できるオプションを追加しました。
• ロボットの設定の [コンソールへログイン] の既定値を [はい] に変更しました。
• Automation User ロールにログの作成権限が既定で含まれるようになりました。Orchestrator でジョブを実行するたびにログを作成できます。

  既存のテナントでこの設定を有効化するには、[テナント] > [設定] > [標準ロール] に移動し、Automation User ロールに不足している既定の権限を追加します。

非推奨化のタイムライン

注:

v2021.10 以降の Orchestrator では、以下の機能が削除されています。

• 標準マシンを使用したロボットの自動登録。マシン テンプレートを使用し、コマンド ラインでマシンを接続することをお勧めします。
• NTLM 認証。代わりに OAuth フローの使用をお勧めします。

Orchestrator の一部の機能が、2022 年に非推奨となる予定です。このため、上位の代替機能に切り替えることを強くお勧めします。

• 2022 年 4 月には標準マシンの非推奨化が予定されています。マシン テンプレートを使用することをお勧めします。
• 2022 年 10 月にはクラシック フォルダーの非推奨化が予定されています。モダン フォルダーへの移行をお勧めします。

詳しくは、「非推奨化のタイムライン」をご覧ください。

重大な変更

実行メディアの権限

/odata/ExecutionMedia/UiPath.Server.Configuration.OData.DeleteMediaByJobId エンドポイントに POST 要求を送信して実行メディアを削除する際に、実行メディアの削除権限が求められるようにしました。以前は表示権限が必要でした。

既知の問題

• フォルダー レベルからテナント レベルに移動する直前にクラシック フォルダーを選択していた場合、ロボット アカウントをフォルダーに割り当てることができません。具体的には、割り当てるロボット アカウントを検索しても、存在するはずのアカウントが表示されません。回避策として、サイドバーから一度モダン フォルダーを選択してから [テナント] > [フォルダー] に移動して割り当てを行ってください。
• Azure Active Directory 経由でユーザーを認証しようとすると、応答として 500 エラーが発生することがあります。これは、get_DNSDomainName() メソッドが、認証中のユーザーのドメインを解決できずに未処理の例外をスローすることが原因です。

  この例外を防ぐには、お使いの Azure Active Directory の DNS レコードを修正してください。

• Orchestrator の言語を日本語、中国語、または韓国語に設定すると、複数のページで時刻の表示形式が崩れます。
• UI からは削除できない Administrator ロールのユーザーを、Orchestrator API から削除できてしまいます。
• アイテムをキューにアップロードする際に、トランザクション .csv ファイルを使用できません。代わりに、こちらでダウンロードできる CSV テンプレートを使用してください。
• Orchestrator マシンを起動/再起動する際に、ノードの 1 つにエラーが表示され、使用不可能として表示される場合があります。回避策として、IIS から Orchestrator を再起動してください。
• Orchestrator の言語を日本語、中国語、または韓国語に設定すると、[ログ] ページの時刻が正しくレンダリングされません。具体的には、0 にスラッシュが入って表示され、その 0 の直後の単位 (時/分/秒) が表示されません。たとえば、11時20分03秒 と表示されるべき箇所で 11時2Ø03秒 と表示されます。
• 資格情報が設定されていないアカウントで実行したジョブを [ジョブ] ページおよび [ログ] ページの一覧で確認する際に、ホスト ID で正しくフィルター処理できません。Windows マシンでジョブを実行した場合、[ホスト ID] 列にはロボットの実際の ID (ドメイン\ユーザー名) が表示されますが、この ID でジョブを絞り込むとジョブが表示されません。Linux マシンでジョブを実行した場合、ジョブは「Root」のホスト ID 下で実行されますが、この値をジョブのフィルター処理に使用できません。

バグ修正

自動化

• 長期実行のワークフローが一時停止された際に、対応するジョブが Robot サービスのキューで [実行中] ステート等の状態で留まらなくなりました。
• 現在のジョブを取得する際に、Jobs テーブルのIX_Executing インデックスがハートビートによって適切に使用されるようになりました。
• ジョブを停止または強制終了すると、そのジョブのマシンの値が表示されなくなっていました。この問題は、[ジョブ] ページを更新すると修正されていました。
• ユーザー モードでインストールされた Robot が、Orchestrator からのジョブの停止/強制終了のコマンドを受信せず、[終了中] のステートに留まっていました。
• Webhook イベント queueItem.transactionStarted に、キューを定義するプロパティが含まれていなかった問題を修正しました。
• Assistant を更新すると、ジョブを実行中の Attended ロボットが [利用可能] と表示されていました。
• 同じ Multiuser ライセンスが割り当てられている 2 人の Active Directory ユーザーが同一の VDI を使用するシナリオで、ユーザーのロボットの実行設定が保持されず、既定値に戻っていました。具体的には、ユーザー B を Orchestrator に接続した状態でユーザー A のロボットに指定した実行設定が、ユーザー A が Orchestrator に接続するとクリアされていました。この問題は現在は修正されました。
• Insights を有効化すると Orchestrator でトリガーが起動しない問題が、ごくまれに発生していました。この問題は Insights を無効化すると解決していました。
• サブフォルダーのプロセスの監視の詳細ウィンドウ ([監視] > [プロセス] > [サブフォルダーを含む] チェックボックスをオン > [プロセスの概要]) を更新すると、「Release does not exist (リリースが存在しません)」というエラーが表示されていました。
• [ジョブ] ページの列の表示設定が、ページから離れて再び戻ると保持されていませんでした。
• クラシック フォルダーの [プロセス] ページでトリガーを作成しようとすると、ロボットのリストが表示されませんでした。
• ユーザーとマシンのペアごとのアセットを、Studio からデバッグできませんでした。このため、特定のユーザーとマシンのペアがアセットを受け取ったかどうかを確認するには、Assistant または Orchestrator からジョブを開始する必要がありました。この問題は、現在は修正されました。

セットアップ

• 今回のバージョンから、Publish-Orchestrator.ps1 スクリプトの -useQuartzClustered パラメーターを非推奨としました。
• ベアラー トークンの有効期限を UiPath.Orchestrator.dll.config から更新できなくなりました。このため、Orchestrator の構成ファイルで Auth.Bearer.Basic.Expire パラメーターが使用できなくなりました。トークンの有効期限を変更するには、Identity Server の Clients データベースで、Orchestrator.Ropc クライアントの AccessTokenLifetime プロパティを設定する必要があります。設定方法の例については、トラブルシューティングに関するこちらのセクションをご覧ください。
• Web.Config ファイルの <httpErrors> 要素が定義されていない状態で Orchestrator を v2018.4 から v2021.4 にアップグレードしようとすると、問題が発生していました。この問題によりアップグレードが失敗し、<httpErrors> の各エントリが複製されていました。この問題は現在は修正され、回避策を行う必要なくスムーズにアップグレードを実行できるようになりました。
• インストール時に Orchestrator がイベント ビューアーのソースに追加されず、NLog の標準の eventLog ターゲットを使用するアプリケーション ログがイベント ビューアーに記録されていませんでした。この問題は修正されました。
• Dynatrace OneAgent をアプリケーション パフォーマンス監視 (APM) に使用できるよう、Identity Server の起動時に発生していた問題を修正しました。
• Identity Server の appSettings.onprem.json ファイルで UseEmailAsIdentityName の設定が false に設定されていても、ユーザーを作成する際に [ユーザーのメール アドレス] フィールドが必須となっていました。この問題を修正し、メール アドレスを使用せずにユーザーを作成できるようにしました。
• アップグレードに関する問題を修正しました。以前は、インストール パラメーターを含む .json ファイルの生成時に、Insights データベースの詳細情報が適切にキャプチャされていませんでした。

API

• 多数のロボットを対象にしたアセットに対して [アセットを設定] アクティビティや [資格情報を設定] アクティビティを使用すると、タイムアウトが発生していました。このため、ロボットの値の設定方法を改良し、新しい API エンドポイント /odata /Assets /UiPath.Server.Configuration.OData.SetRobotAssetByRobotKey を追加しました。
• /odata/ProcessSchedules/UiPath.Server.Configuration.OData.SetEnabled エンドポイントのメタデータが正しくありませんでした。このため、生成された OData クライアントがエンドポイントの呼び出しに失敗していました。
• /odata/Alerts/UiPath.Server.Configuration.OData.MarkAsRead エンドポイントを呼び出しても、指定した ID のアラートが既読としてマークされませんでした。この挙動は、アラートの Id ではなく UserNotificationId を入力することで防げます。詳しくは、こちらの API リファレンス ドキュメントをご覧ください。

資格情報ストア

• 資格情報ストア プラグインのアセンブリが参照されている場合、アセンブリのクラスで ISecureStore を実装していないと、参照ファイルが Orchestrator で読み込まれませんでした。現在、Orchestrator では Plugins フォルダー内のアセンブリが常に読み込み可能になりました。
• CyberArk AAM 資格情報ストアでパスによる認証を使用すると (Plugins.SecureStores.CyberArk.UsePowershellCLI を true に設定)、次のエラー メッセージが表示され失敗していました。「Failed to retrieve robot password from UiPath.Orchestrator.SecureStore.CyberArk.CyberArkAimSecureStore storeUiPath.Orchestrator.Extensibility.SecureStores.SecureStoreException: Could not find password! Reason: '.\GetCredential.bat : The term '.\GetCredential.bat' is not recognized as the name of a cmdlet, function, script file, or operable program. (UiPath.Orchestrator.SecureStore.CyberArk.CyberArkAimSecureStore からロボットのパスワードを取得できませんでした。storeUiPath.Orchestrator.Extensibility.SecureStores.SecureStoreException: パスワードが見つかりませんでした。理由: '.\GetCredential.bat: 用語 '.\GetCredential.bat' はコマンドレット、関数、スクリプト ファイル、または操作可能なプログラムとして認識されていません。)」

この問題は、GetCredentials.bat ファイルが Plugins フォルダーではなく Orchestrator のインストール フォルダーにパブリッシュされていたことが原因で発生していました。現在、ファイルは Plugins フォルダーにパブリッシュされるようになりました。

その他

• Orchestrator の [アプリケーション設定] におけるボルゴグラードのタイムゾーンの表示名を、[(UTC+04:00) ボルゴグラード] から [(UTC+03:00) ボルゴグラード] に変更しました。これは表記上の誤りで、タイムゾーン自体は正常でした (UTC+03:00)。
• メールの設定をテストする際に、SMTP ポートが指定されていない場合でも成功メッセージが表示されていました。この挙動は現在は修正され、このシナリオではメールの検証が失敗するようになりました。
• 数百万を超える多数のジョブが存在する環境でパフォーマンスが低下し、ジョブのステータスを取得しようとするとタイムアウトが発生していました。この問題は、現在は解決しました。
• 非稼働日カレンダーを追加すると、ごくまれに「#199 - Cannot read property 'unshift' of undefined」というエラー メッセージが表示されていました。現在は、カレンダーを追加してもこのエラーは表示されなくなりました。
• 約 80,000 人のユーザーが個人用ワークスペースを持つ環境で、SQL による CPU 使用率が高くなりパフォーマンスが低下していました。
• 編集権限のない状態でカレンダーを作成しようとすると、「You are not authorized! (権限がありません。)」ではなく「Calendar with the same name exists (同じ名前のカレンダーが存在します。)」というエラーが表示されていました。この挙動は修正され、現在は適切なエラー メッセージが表示されます。
• [ストレージ ファイルをアップロード] アクティビティを使用して 0 バイトのファイルを MinIO ストレージ バケットにアップロードすると、「Response status code does not indicate success: 500 (応答ステータス コードが成功を示していません。)」というエラーが発生していました。現在は、MinIO バケットに 0 バイトのファイルをアップロードしてもエラーが発生しません。
• ライセンス数が 0 の場合に Orchestrator の [ライセンス] ページにライセンス カードが表示されないことが原因で、残数のないライセンスを過剰使用していても、それを画面上で確認できませんでした。この挙動は修正され、現在は残数のないライセンスが過剰使用されている場合にライセンス カードが表示されるようになりました。
• Studio から Orchestrator へパブリッシュしようとしたプロジェクトのパッケージ サイズが許可された最大値を超えていた場合に、不適切なエラー メッセージが表示されていました。現在は、ファイルが大きすぎる旨を示すメッセージが表示されるようになりました。