This article identifies the main affected areas you should be aware of in a new Orchestrator deployment. Some of the items addressed in this article must be taken care of prior to an upgrade/installation. Several of them are validated by the installer or by the Platform Configuration Tool if you choose to use it. We highly recommend that you download and use the Platform Configuration Tool to validate your environment prior to an upgrade.
.NET Core 6.0.x
ターゲット ワークフレーム
資格情報ストア プラグインおよび NLog 拡張機能を維持するには、TargetFramework
を以前の .NET Framework 4.7.2 からサポート対象のターゲット フレームワークにアップグレードする必要があります。資格情報ストアと NLog 拡張機能のターゲット フレームワークは、どちらも UiPathOrchestrator.msi
インストーラーによってチェックされます。
この制限は、プラグインまたは NLog 拡張機能が持つ可能性があるすべての参照にも適用されます。
Supported Target Frameworks | |||||||
---|---|---|---|---|---|---|---|
.NET Standard | 1.0 | 1.1 | 1.2 | 1.3 | 1.4 | 1.5 | 1.6 |
.NET Standard | 2.0 (recommended) | 2.1 | |||||
.NET Core | 6.0 | 6.0.10 |
社内で開発した資格情報ストア プラグインや NLog 拡張機能については、再コンパイルが必要な場合があります。
指定されたターゲット フレームワークをターゲットとするその他の
.dll
ファイルを特定し、Orchestrator のディレクトリにコピーしなければならない場合があります。ほとんどの NLog ターゲットは指定されたターゲット フレームワークに対応していますが、正しい.dll
をコピーしたことを確認する必要があります。たとえば、NLog.Targets.Splunk
を使用する場合、.nupkg
ファイルをダウンロードして.zip
として開き、lib\netstandard2.0
フォルダーに移動して、そこから.dll
ファイルを使用する必要があります。
CyberArk の資格情報ストア プラグイン
Orchestrator の古いバージョンでは、CyberArk の資格情報ストア プラグインが .NET Core に非対応のライブラリを使用していました。現在の Orchestrator は、CyberArk AIM に付属する CLIPasswordSDK64.exe
ツールを使用します。
プラグインは、
CLIPasswordSDK64.exe
を、CyberArk AIM の既定のインストール パスC:\Program Files (x86)\CyberArk\ApplicationPasswordSdk\CLIPasswordSDK64.exe
で検索します。CyberArk AIM を既定のパス以外にインストールした場合は、UiPath.Orchestrator.dll.config
に正しいパスを指定する設定エントリを追加する必要があります。このパスは、インストール前にweb.config
のappSettings
セクションで指定するか、インストール後にUiPath.Orchestrator.dll.config
で指定できます。
例:
<add key="Plugins.SecureStores.CyberArk.CLIPasswordSDKExePath" value="D:\CustomFolder\CLIPasswordSDK64.exe" />
プロキシ構成
プロキシ構成は、タグ <defaultProxy>
を使用して web.config
内で設定できなくなりました。サポートされなくなった構成の例は次のとおりです。
<system.net>
<defaultProxy>
<proxy usesystemdefault="True" proxyaddress="http://<ip>:<port>" bypassonlocal="True" />
</defaultProxy>
</system.net>
.NET Core でプロキシを指定する方法は、次の 2 つです。
環境変数を使用する
環境変数は、web.config
で次の構文を使用して設定できます。<environmentVariable name="[insert_variable_here]" value="[insert_address_here]" />
(例: <environmentVariable name="HTTP_PROXY" value="http://127.0.0.1:8080" />
)
Variable | Description |
---|---|
HTTP_PROXY | The proxy server used on HTTP requests. |
HTTPS_PROXY | The proxy server used on HTTPS requests. |
ALL_PROXY | The proxy server used on HTTP and/or HTTPS requests in case HTTP_PROXY or HTTPS_PROXY are not defined. |
NO_PROXY | A comma-separated list of host-names that should be excluded from proxying. |
例:
- 認証なしの場合:
ALL_PROXY=http://localhost:8888
- 認証ありの場合:
ALL_PROXY=http://user:password@localhost:8888
環境変数を設定せず、既定のプロキシ システム (IE の設定または Windows のプロキシ設定) を使用する
詳細は、こちらの Microsoft 公式ドキュメントをご覧ください。
設定ファイル
Web.Config
Orchestrator の設定のほとんどが、web.config
から UiPath.Orchestrator.dll.config
に移されました。新しいファイルは、旧 web.config
ファイルと同じ構造で、保存先も以前と同じディレクトリです。UiPath.Orchestrator.dll.config
ファイルを変更しても IIS は再起動されないことに注意してください。次のセクションが移動されました。
- 接続文字列
- アプリの設定
- NLog の設定
- Quartz の設定
- 暗号化キー
web.config
は、IIS が使用する設定のみを記述するファイルとして再利用されます。アップグレード時に、インストーラーが自動的に上記のセクションを新しい設定ファイルに移動します。さらに、web.config
に残される設定を変換して Orchestrator の最新バージョンで必要な設定に一致させます。無効化された動詞、有効化/無効化されたモジュール、カスタムの再書き込みルールなど、お客様によるカスタマイズは保存されます。
Check web.config
docs.
Check UiPath.Orchestrator.dll.config
docs.
IIS マネージャー
接続文字列とアプリケーション設定は IIS マネージャーでは表示できなくなりました。IIS マネージャーを使用した Orchestrator の接続文字列やアプリケーション設定の編集はサポートしていません。
設定ファイルを直接編集する必要があります。
NLog ターゲット
種類が「Database」の NLog ターゲットについては、connectionStringName
プロパティが connectionString
に変更されました。その値は、次の構文に従う必要があります: connectionString="${ui-connection-strings:item=Default}"
。Default
は、<connectionStrings>
セクション内の、使用したい接続文字列の名前です。
See docs on Targets of the Orchestrator Execution Logs.
種類が
Database
のカスタム NLog ターゲットを使用する場合、アップグレード中に、プロパティconnectionStringName
が自動的にconnectionString
に変更されます。インストール/アップグレード後に設定ファイルに手動でターゲットを挿入する場合は、正しい値の新しいプロパティを使用してください。
SignalR プロトコル
SignalR と WebSocket
SignalR ライブラリが、古い Robot クライアントに非対応の新しいバージョンに更新されました。ジョブが利用可能になったときの Unattended ロボットへの通知を引き続き使用できるように、ロング ポーリングを使用する旧 SignalR プロトコルを模した、対応性維持のためのメカニズムが実装されました。2020.10 より古い Robot は、ロング ポーリングでしか Orchestrator に接続できません。
WebSocket を使用するために、ロボットを 2020.10 にアップグレードすることを推奨します。特にロボットを大規模にデプロイしている場合にコスト効果が得られます。
SignalR スケールアウトの固定セッション
SignalR のスケールアウトには、WebSocket 以外のすべてのプロトコル (すなわち SSE とロング ポーリング) で固定セッションが必要です。
Orchestrator は、お客様のロード バランサーで固定セッションが有効化されていないものと想定し、既定では WebSocket トランスポートのみが有効化されます。

固定セッションを有効化するには、
UiPath.Orchestrator.dll.config
に<add key="Scalability.SignalR.RequireStickySessions" value="true" />
キーを追加します。true
に設定すると、すべてのトランスポートが有効化され、Orchestrator はロード バランサーで固定セッションが有効化されているものと見なします。固定セッションをロード バランサーで有効化せずに、UiPath.Orchestrator.dll.config
で有効化すると、SignalR 接続が失敗します。
SignalR の SQL Server によるスケールアウト
スケールアウトのメカニズムは、インストール中に SQL Server から Redis に切り替えられます。ロボット/アクティビティの SignalR 認証の無効化はサポートされなくなりました。このため、Scalability.SignalR.AuthenticationEnabled
パラメーターは非推奨となりました。
[キュー アイテムを待機] アクティビティ
2020.10 よりも古い [キュー アイテムを待機] アクティビティを使用すると、最大 30 秒の遅延が発生する場合があります。
このような問題を避けるには、最新のアクティビティ バージョンにアップグレードしてください。
NuGet インフラストラクチャ
内部 NuGet フィードのプロトコルを v2 から v3 に更新しました。
Legacy リポジトリ
NuGet のリポジトリの種類として、Legacy
はサポート対象外になりました。アップグレード時に、種類が Legacy
のリポジトリは、すべて Composite
に移行されます。
新しいパッケージの保存場所は、以前のバージョンの Orchestrator で web.config
で、パラメーター NuGet.Packages.Path
および NuGet.Activities.Path
がどのように設定されていたかによって異なります。
- パッケージを既定の場所 (
~/NuGetPackages
と~/NuGetPackages/Activities
) に保存していた場合、新しいパッケージの保存場所はRootPath=.\Storage
になります。 - パッケージをカスタムの場所に保存していた場合は、インストール中に新しい保存場所を尋ねられます。サイレント インストールの場合は、アップグレード前に
web.config
で指定していないかぎり、STORAGE_TYPE
とSTORAGE_LOCATION
のパラメーターが必須になります。
v2020.10 以降では、パッケージの保存場所を UiPath.Orchestrator.dll.config
の Storage.Type
および Storage.Location
パラメーターで設定します。アップグレード後、Legacy
関連のアプリ設定はすべて非推奨となり、無効になります。
NuGet.Packages.Path
NuGet.Activities.Path
Nuget.EnableRedisNodeCoordination
Nuget.EnableNugetServerLogging
NuGet.EnableFileSystemMonitoring
NuGet.Repository.Type
Composite
リポジトリの場合、パッケージ専用のフォルダー内では、コピー/貼り付けコマンドを使用できません。
Swagger ライブラリ
Orchestrator API を記述する swagger.json
ファイルの生成方法を大幅に変更しました。Swagger ファイル内の API 記述を使用するクライアント ライブラリ ジェネレーター (AutoRest、Swagger Codegen など) に依存している場合、生成されるコードが以前と大幅に異なります。
自動生成のクライアントを使用するその他のカスタム ツールがあれば、それらも更新が必要になる可能性があります。
API の変更
フォーム POST パラメーターを持つ API
フォームデータ オブジェクト内でのパラメーターを伴う POST
要求は機能しなくなりました。
Orchestrator に
POST
要求を行うメカニズムとしては、要求の本文に JSON の要求パラメーターを含める方法だけがサポートされています。
約 1 か月前に更新