Orchestrator
2020.10
  • リリース ノート
    • 2020.10.1
    • 2020.10.2
    • 2020.10.3
    • 2020.10.4
    • 2020.10.5
    • 2020.10.6
    • 2020.10.7
    • 2020.10.8
    • 2020.10.9
    • 2020.10.10
    • 2020.10.11
    • 2020.10.12
    • 2020.10.14
    • 2020.10.15
    • 2020.10.16
    • 2020.10.17
    • 2020.10.18
    • 2020.10.19
    • 2020.10.20
    • 2020.10.21
バナーの背景画像
サポート対象外
Orchestrator リリース ノート
最終更新日 2023年12月12日

2020.10.14

公開日: 2021 年 12 月 7 日

更新内容

キュー トリガーを介したジョブ開始メカニズムの改良

今回のパッチでは、キュー トリガーのロジックを変更しました。具体的には、到達する必要のあるジョブの数を算出する際に、新規および処理中のキュー アイテムの合計数が考慮されるようになりました。以前は新しいアイテムの数のみが考慮されていたため、処理中のアイテムよりも新しいアイテムの数が少ない場合は、ロボットがアイドル状態であってもジョブが開始されませんでした。この挙動は、実行中のジョブの数が、必要なジョブ (キュー アイテムをアクティブに処理するジョブ) の数を上回らないように設計されていたため発生していました。

変更前と変更後の挙動を分かりやすく示した例は、以下のとおりです。

次のように定義したキュー トリガーがあるとします。

フィールド

値 (Value)

最初のジョブをトリガーするアイテムの最小数

1

同時に許可される保留中および実行中のジョブの最大数

100

指定した数のアイテムが追加されるたびにジョブをトリガー

1

変更前の挙動の再現手順

  1. キューにキュー アイテムを 3 個追加します。Orchestrator は、新しいアイテムの数に基づいて必要なジョブの数を算出します。この場合はジョブが 3 つ必要です。Orchestrator は、キュー アイテムを 3 個処理するためにジョブを 3 つ開始します。3 個のアイテムのステータスが [処理中] に変わります。
  2. キューに新しいアイテムをさらに 2 個追加します。Orchestrator は、新しいアイテムの数に基づいて必要なジョブの数を算出します。この場合はジョブが 2 つ必要です。必要なジョブの数が実行中のジョブの数より少ないため、Orchestrator は新しいジョブを開始しません。
  3. キューに新しいアイテムをさらに 2 個追加します。Orchestrator は、新しいアイテムの数に基づいて必要なジョブの数を算出します。この場合はジョブが 4 つ (2+2) 必要です。Orchestrator は、必要なジョブの数 (4 つ) に到達するためにジョブを 1 つ開始します。

変更後の挙動の再現手順

  1. キューにキュー アイテムを 3 個追加します。Orchestrator は、新しいアイテムと処理中のアイテムの合計数に基づいて必要なジョブの数を算出します。この場合はジョブが 3 つ必要です。Orchestrator は、キュー アイテムを 3 個処理するためにジョブを 3 つ開始します。3 個のアイテムのステータスが [処理中] に変わります。
  2. キューに新しいアイテムをさらに 2 個追加します。Orchestrator は、新しいアイテムと進行中のアイテムの合計数に基づいて必要なジョブの数を算出します。この場合はジョブが 5 つ (3+2) 必要です。Orchestrator は、必要なジョブの数 (5 つ) に到達するためにジョブを 2 つ開始します。

    重要: 今回のリリースでは、Orchestrator がキュー トリガーを介してジョブを開始する場合の挙動を大幅に変更しました。この新しい挙動は既定で有効化されており、オフにすることができません。v2020.10.14 にアップグレードする前に、このリリース ノートをよくお読みください。不安がある場合は、この問題に対処した次回以降のパッチが公開されるまでお待ちください。

Elasticsearch へのランタイム例外のログ記録

権限の問題や接続の失敗といったランタイムの問題の可視性を向上させるため、ランタイム例外が Orchestrator によって Elasticsearch にログ記録されるようになりました。

AIM Web サービス名のカスタマイズ

CyberArk CCP 資格情報ストアの設定画面に [Web サービス名] フィールドを追加し、CCP の Web サービス名をカスタマイズできるようにしました。このフィールドを空のままにすると、既定の名前である「AIMWebService」が使用されます。



セットアップに関する改良点

コマンド ライン パラメーターを 4 つ追加し、Orchestrator データベースへの接続を柔軟に設定・カスタマイズできるようにしました。これらのパラメーターは、Orchestrator のサイレント インストールのコマンド (クリーン インストールまたはアップグレード) で利用できます。また、これらのパラメーターを parameters.JSON ファイルに追加することもできます。

新しいパラメーターの詳細と使用方法の例については、『UiPath 製品のインストールとアップグレード』ガイドの「コマンド ライン パラメーター」をご覧ください。

既知の問題

GenerateReportsJob ([キュー] ページの統計値を計算するバックグラウンド ジョブ) の背後のメカニズムを「増分」から「パーティション スワップ」に変更したことが原因で、次のようなエラーが発生します。「The 'LastQueueItemEventProcessed' property on 'UiQueueProcessingRecordBase' could not be set to a 'null' value ('UiQueueProcessingRecordBase' の 'LastQueueItemEventProcessed' プロパティに 'null' の値を設定できませんでした。)」この問題を回避するには、次のクエリを使用してデータベース内の QueueProcessingRecords.LastQueueItemEventProcessedd フィールドを 0 に設定してください。UPDATE [dbo].[QueueProcessingRecords] SET [LastQueueItemEventProcessed] = 0 WHERE [LastQueueItemEventProcessed] IS NULL

バグ修正

  • アプリの設定パラメーター Plugins.SecureStores.CyberArk.UsePowerShellCLI が有効化されていると、GetPassword コマンドが正しく動作せず、出力の形式が正しくありませんでした。この問題を修正し、GetPassword コマンドの出力フィールドの値が正しい形式で出力されるようにしました。
  • CyberArk AAM 資格情報ストアでパスによる認証を使用すると (Plugins.SecureStores.CyberArk.UsePowershellCLItrue に設定)、次のエラー メッセージが表示され失敗していました。「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 v2020.10.10 の環境でキュー アイテムあたりの処理時間が 1 秒未満の場合に、デッドロックが発生していました。このとき、プロセスは「An error has occurred. Error code: 0 (エラーが発生しました。エラー コード: 0)」という例外を複数回スローし、その後クラッシュしていました。この問題は修正され、キュー アイテムの処理時にデッドロックが発生しなくなりました。
  • /odata/ExecutionMedia/UiPath.Server.Configuration.OData.DeleteMediaByJobId エンドポイントに POST 要求を送信して実行メディアを削除する際に、実行メディアの削除権限が求められるようにしました。以前は表示権限が必要でした。
  • 多数のロボットを対象にしたアセットに対して [アセットを設定] アクティビティや [資格情報を設定] アクティビティを使用すると、タイムアウトが発生していました。このため、ロボットの値の設定方法を改良し、新しい API エンドポイント /odata /Assets /UiPath.Server.Configuration.OData.SetRobotAssetByRobotKey を追加しました。
  • Webhook クライアントが動作しない問題の影響により、Orchestrator の接続文字列を復号できませんでした。この問題は、現在は修正されました。
  • マルチノード環境では、すべてのノードの接続文字列が同一である必要があります。ノードの接続文字列が異なるとエラーが発生する可能性があるため、全く同じ文字列が使用されていることを確認してください。余分なスペースなどのわずかな違いがあるだけでも問題が発生しますのでご注意ください。

Was this page helpful?

サポートを受ける
RPA について学ぶ - オートメーション コース
UiPath コミュニティ フォーラム
UiPath ロゴ (白)
信頼とセキュリティ
© 2005-2024 UiPath. All rights reserved.