2020.10.4

公開日: 2020 年 12 月 15 日

更新内容

CyberArk CCP との連携

Orchestrator と CyberArk CCP を連携させました。このため、資格情報ストア機能が拡張・改良されました。

概要

Central Credential Provider (CCP) は、Orchestrator と CyberArk を連携させるために使用する、エージェントレスな AAM メソッドです。Central Credential Provider は資格情報コンテナーに保存されているパスワードを取得し、認証済みのリモート アプリケーションがそのデータにアクセスできるようにします。これにより、サーバーにエージェントをデプロイすることなく CyberArk からロボットの資格情報や資格情報アセットなどの機密情報を取得できます。資格情報を安全に取得するには、クライアント証明書が必要です。

CyberArk® CCP と正常に連携するには、CyberArk® の PVWA 内に環境を正しくセットアップするための次の手順を確認することをお勧めします。

1. Create an application for your Orchestrator instance and add client certificates.
2. セーフを作成しメンバーを追加することで、適切な権限を保証する。

v2020.10.4 にアップグレードする場合、アップグレード前にお使いのインスタンスで CyberArk を有効化していれば、CyberArk CCP が自動で有効化されます。CyberArk を有効化していない場合は、UiPath.Orchestrator.dll.config 内の Plugins.SecureStores パラメーターに UiPath.Orchestrator.SecureStore.CyberArkCCP.dll を追加して有効化します。

改良点

ジョブのカウント方法

今回のリリースでは、Triggers.JobsCountStrategy パラメーターを追加し、トリガーで開始されるジョブのカウント方法をユーザー側で完全に制御できるようにしました。これにより、ユーザーは自身のニーズに最適なカウント方法を以下のオプションから選択できます。

• PerProcess (プロセスごと) - 必要な数のジョブをトリガーが開始するにあたって、指定したプロセスで保留中のジョブの数が考慮されます。たとえば、同じプロセスに対して定義された 2 つのトリガーが、それぞれ 3 個のジョブと 5 個のジョブを開始するよう設定されているとします。ある時点で 1 つ目のトリガーが 3 個のジョブを開始している場合、2 つ目のトリガーが実行される際は、必要なジョブ数 (5 個) に達するように 2 個のジョブが開始されます。
• PerTrigger (トリガーごと) - 必要な数のジョブをトリガーが開始するにあたって、同じトリガーによってこれまでに開始された既存のジョブの数が考慮されます。たとえば、あるトリガーがある時点で 9 個のジョブを開始するよう定義されているとします。既に 2 個のジョブが正常に完了している状態でトリガーが再び実行されると、必要なジョブ数 (9 個) に達するようにさらに 2 個のジョブが開始されます。
• NoLimit (制限なし) - 必要な数のジョブをトリガーが開始するにあたって、既存のジョブや保留中のジョブは考慮されません。たとえば、あるトリガーがある時点で 5 個のジョブを開始するよう定義されているとします。同じトリガーが 2 度目に実行される際は、さらに 5 個のジョブが開始されます。

Learn about the Triggers.JobsCountStrategy parameter.

永続性アクティビティのサポート

今回のリリースでは、キュー アイテムベースのワークフローでの Persistence 系アクティビティに対するサポートを追加しました。これまでの Orchestrator では 24 時間以上実行中の状態にあるキュー アイテムは破棄されていたため、実行に 24 時間以上かかる長期実行のワークフローを使用できませんでした。今回この制限を取り除いたため、トランザクションへの人間による入力作業に対する時間の制約がなくなりました。

重要:

UiPath 側の都合により、上記の機能がリリース ノートの記載どおりにバージョン 2020.10.4 に追加されていませんでした。この機能は Orchestrator の次回のパッチで優先的に追加される予定です。進行中のキュー アイテムに対する 24 時間の制限は、次回のリリースで上記の機能が追加されるまでは引き続き適用されます。

セットアップ

• セカンダリ ノードのインストールにパッシブ モードが使用できるようになりました。インストール時にはこのモードを使用することをお勧めします。/passive パラメーターを指定すると、進行状況バーとエラー ポップアップが表示される制限付きのユーザー インターフェイスが有効化されます。これまではサイレント モードのインストールしか使用できませんでしたが、今後は /Q の使用は無人インストールに対してのみ行ってください。

その他

• You can now control whether or not login error codes are displayed in the UI, by using the HideErrorCodesInUi parameter in the Identity Server appsettings.Production.json file.
• web.config 内の <system.webServer> 要素にロックされたセクションが含まれていると、Orchestrator の機能が損なわれる可能性があります。このため、プラットフォーム構成ツールに追加の確認項目を加え、ロックされたセクションがないかどうか、<system.webServer> 要素全体を確認できるようにしました。ロックされたセクションが存在する場合、IIS 内で手動でロックを解除する必要があります。
• [常時実行プロセス] トグル ボタンの挙動をイメージしやすくするため、このトグルの名前を [プロセスは UiPath Assistant から停止できません。] に変更しました。つまり、この機能を [プロセスの設定] ページから有効化すると、該当するプロセスは UiPath Assistant から停止できなくなります。

バグ修正

• All logs generated prior to 2019.10 were displayed on the Logs page without being filtered by the containing folder (formerly organization unit). We added and enabled by default a new UiPath.Orchestrator.dll.config setting (Logs.Elasticsearch.EnableFolderIdFilter) which prevents logs that cannot be filtered from being displayed on the Logs page. You can still see such logs by navigating to Logs from the Robots (classic folders) and Jobs pages (More Actions > View Logs).
• アップグレードに失敗してロールバックが実行されるたびに、Administrator ロールからアクションの編集権限とアクションの割り当ての作成権限が削除されていました。現在は、アップグレードに失敗してもどちらの権限も保持されます。
• appSettings を Web.Config から UiPath.Orchestrator.dll.config に移動したことが原因で、Configure-PlatformNode.ps1 スクリプトによるシングル ノードからマルチノードへの移行が失敗していました。現在は、このスクリプトは例外をスローしなくなりました。
• パッケージの移行を伴うアップグレードに失敗した後に、インポート済みで未使用の Storage フォルダーがクリーンアップされませんでした。現在は、残されたコンテンツは削除されるようになりました。
• アップグレードの開始前に UiPathOrchestrator.msi インストーラーによって利用可能なディスク領域が確認されず、パッケージの移行に失敗する場合がありました。現在は、移行の開始前に警告が表示されるようになりました。
• UiPathPlatformInstaller.exe が特定のサブジェクト形式の SSL 証明書を検証せず、インストールに失敗するか、アップグレードの警告が表示されていました。
• アップグレード時に Windows 認証を使用すると、UiPathOrchestrator.msi インストーラーによって資格情報が検証されませんでした。このため、アップグレードのプロセスが失敗していました。
• 引数の型が Orchestrator で検証されず、プロセスに適合しないパラメーター値が設定できていました。現在は検証が正常に行われ、デザイン時に設定した引数の型と入力値の型が一致しない場合は、例外がスローされるようになりました。
• クラシック フォルダーを削除しても、それに関連付けられたユーザーが削除されませんでした。現在は、クラシック フォルダーを削除するとユーザーも削除されるようになりました。
• v2020.4 から v2020.10 に Orchestrator をアップグレードすると、「テナントから継承」権限モデルに基づき、Active Directory ユーザーがモダン フォルダーから割り当て解除されていました。この問題は、親の Active Directory グループをフォルダーに割り当てても発生していました。
• 読み取り/書き込みの資格情報プラグインに存在する資格情報アセットを削除しても、資格情報が Orchestrator からしか削除されませんでした。現在は Orchestrator で資格情報アセットを削除すると、資格情報ストアで参照されている関連付けられた資格情報オブジェクトも削除されるようになりました。削除対象の資格情報アセットがオートメーション プロジェクトなどの他の場所で使用されていないことを確認するようにしてください。
• 非アクティブ タイムアウト期間が終了してもユーザー セッションがタイムアウトせず、ユーザーが期待通りにセッションからログアウトできませんでした。