公開日: 2022 年 4 月 7 日
キュー トリガーを介したジョブ開始メカニズムの改良
キュー トリガーによるジョブの開始方法について、度重なる変更が生じておりましたが、再び検討を行った結果、挙動を改めて変更することとしました。なお、今回の変更が最終決定となる予定です。
以前の問題点: キューに追加された新しいアイテムの数が、処理中のアイテム数を下回っていると、ロボットがアイドル状態であっても追加のジョブが開始されませんでした。以前の算出方法では、実行中のジョブ (キュー アイテムをアクティブに処理しているジョブ) の数が、実行可能なジョブ (新しく追加されたアイテムを処理するのに必要なジョブ) の数より大きくなることが多く、その都度この問題が発生していました。
最初の修正: 実行可能なジョブの数を算出する際に、新しいアイテム数だけではなく、新しいアイテムと処理中のアイテムの合計数を考慮するようにしました。しかし、この方法には問題があることが分かりました。
最新の修正: Orchestrator では、実行可能なジョブの数を算出する際に新しいアイテムの数を考慮しますが、新しいジョブの開始可否を決定するために、保留中のジョブの数も確認します。以下の例をご確認ください。
- キューに新しいアイテムが 2 つ存在し、保留中のジョブが 2 つ存在する => 新しいジョブは開始されません。
- キューに新しいアイテムが 2 つ存在し、保留中のジョブが 1 つ存在する => 新しいジョブが 1 つ開始されます。
これにより、過度ではない適切な数のジョブを開始し、新しいアイテムをすべて処理できるようになりました。
バグ修正
-
攻撃者がロボットへの特権アクセスを持つ場合に、Orchestrator への API 呼び出しにブルートフォース攻撃を行うことによって、同一テナント内の他のロボットのライセンス キー (マシン キー) を取得できてしまう問題を修正しました。理論的には、この問題で攻撃者がアクセスできる対象は、アクセス権を持つロボットのリソースに限られていました。
Read the security advisory for UiPath - Robot Account Takeover.
-
Occasionally, job executions of long running workflows would get stuck in a Running status without being transitioned to a Suspended state. Upon killing those jobs, the jobs transitioned to and got stuck in a Terminating state. The underlying issue has been fixed and long running jobs are now transitioned to the different states as expected and are executed without issues.
-
Orchestrator の
UiPath.Orchestrator.dll.configファイルでPlugins.SecureStores.CyberArk.UsePowerShellCLIパラメーターをtrueに設定していると、CyberArk 資格情報ストアから資格情報アセットを取得できませんでした。 -
The Test Email Settings button could not be used when Use Default Credentials was selected if the SMTP Username and SMTP Password fields were blank.