2020.10.16

公開日: 2022 年 4 月 7 日

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

キュー トリガーによるジョブの開始方法について、度重なる変更が生じておりましたが、再び検討を行った結果、挙動を改めて変更することとしました。なお、今回の変更が最終決定となる予定です。

以前の問題点: キューに追加された新しいアイテムの数が、処理中のアイテム数を下回っていると、ロボットがアイドル状態であっても追加のジョブが開始されませんでした。以前の算出方法では、実行中のジョブ (キュー アイテムをアクティブに処理しているジョブ) の数が、実行可能なジョブ (新しく追加されたアイテムを処理するのに必要なジョブ) の数より大きくなることが多く、その都度この問題が発生していました。

最初の修正: 実行可能なジョブの数を算出する際に、新しいアイテム数だけではなく、新しいアイテムと処理中のアイテムの合計数を考慮するようにしました。しかし、この方法には問題があることが分かりました。

最新の修正: Orchestrator では、実行可能なジョブの数を算出する際に新しいアイテムの数を考慮しますが、新しいジョブの開始可否を決定するために、保留中のジョブの数も確認します。以下の例をご確認ください。

• キューに新しいアイテムが 2 つ存在し、保留中のジョブが 2 つ存在する => 新しいジョブは開始されません。

• キューに新しいアイテムが 2 つ存在し、保留中のジョブが 1 つ存在する => 新しいジョブが 1 つ開始されます。

これにより、過度ではない適切な数のジョブを開始し、新しいアイテムをすべて処理できるようになりました。

バグ修正

• 攻撃者がロボットへの特権アクセスを持つ場合に、Orchestrator への API 呼び出しにブルートフォース攻撃を行うことによって、同一テナント内の他のロボットのライセンス キー (マシン キー) を取得できてしまう問題を修正しました。理論的には、この問題で攻撃者がアクセスできる対象は、アクセス権を持つロボットのリソースに限られていました。

  セキュリティのサポート技術情報について詳しくは、「UiPath Orchestrator - Robot Account Takeover」をご覧ください。

• 長期実行のワークフローのジョブを実行すると、ジョブが「中断」ステートに移行されずに「実行中」ステートに留まることがありました。このようなジョブを強制終了すると、ステートは「終了中」に移行し、そのままそのステートに留まっていました。今回のリリースでは、この挙動の原因となった問題を修正しました。現在は、長期実行のジョブは期待どおり別のステートに移行し、問題なく実行されるようになりました。
• Orchestrator の UiPath.Orchestrator.dll.config ファイルで Plugins.SecureStores.CyberArk.UsePowerShellCLI パラメーターを true に設定していると、CyberArk 資格情報ストアから資格情報アセットを取得できませんでした。
• [既定の資格情報を使用] を選択すると、[SMTP ユーザー名] フィールドと [SMTP パスワード] フィールドが空白の場合、[テスト メールの設定] ボタンを使用できませんでした。