2021.10.4

公開日: 2022 年 4 月 7 日

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

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

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

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

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

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

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

改良点

Ledger データベースのテーブルにはデータが溜まりやすいため、クリーンアップを頻繁に行う必要があります。これに対処するため、新しいクリーンアップスクリプトを追加しました。Ledger データを 7 日ごとに削除でき、適用されるバッチのサイズは 1,000 エントリです。新しいスクリプトについて詳しくは、以下のドキュメントをご覧ください。
- スタンドアロン Orchestrator のインストール
- Automation Suite のインストール

既知の問題

ホストとして Swagger UI 経由でメンテナンスウィンドウを終了しようとすると、失敗する場合があります。これは、Swagger UI が認証に Cookie を使用しており、Cookie の情報はブラウザーを閉じると失われるためです。

API 経由でメンテナンスモードを終了するには、以下の回避策のいずれかをご利用ください。
- ブラウザーを閉じず、Swagger UI から /api/Maintenance/End に POST 要求を送信します。
- API テストアプリケーション (Postman など) を使用して、以下の操作を行います。
  - 資格情報を提供して /api.Account/Authenticate エンドポイントへのアクセストークンを取得します。
  - Authorization: Bearer {access_token} ヘッダーを使用して、/api/Maintenance/End エンドポイントに POST 要求を送信します。
- 以下の PowerShell スクリプトを実行します。

$orchestratorUrl="https://localhost:6234"
$hostTenant="host"
$hostUser="admin"
$hostPassword=""
$tenantId="" #number

# Authenticate
$body=@{
    "tenancyName"="$hostTenant";
    "usernameOrEmailAddress"="$hostUser";
    "password"="$hostPassword"
}

$response = Invoke-WebRequest -Uri "$orchestratorUrl/api/account/authenticate" -Method Post -Body ($body | ConvertTo-Json) -ContentType "application/json"
$token = "Bearer " + ($response | ConvertFrom-Json).result

# End maintenance mode

$headers=@{
    "Authorization"="$token"
}

$res = Invoke-WebRequest -Uri "$orchestratorUrl/api/maintenance/end?tenantId=$tenantId" -Headers $headers -Method Post -ContentType "application/json" -ErrorAction Stop

if ($res -and ($res.StatusCode -eq 200)) {
    Write-Host "Maintenance mode ended successfully for tenant $tenantId"
}$orchestratorUrl="https://localhost:6234"
$hostTenant="host"
$hostUser="admin"
$hostPassword=""
$tenantId="" #number

# Authenticate
$body=@{
    "tenancyName"="$hostTenant";
    "usernameOrEmailAddress"="$hostUser";
    "password"="$hostPassword"
}

$response = Invoke-WebRequest -Uri "$orchestratorUrl/api/account/authenticate" -Method Post -Body ($body | ConvertTo-Json) -ContentType "application/json"
$token = "Bearer " + ($response | ConvertFrom-Json).result

# End maintenance mode

$headers=@{
    "Authorization"="$token"
}

$res = Invoke-WebRequest -Uri "$orchestratorUrl/api/maintenance/end?tenantId=$tenantId" -Headers $headers -Method Post -ContentType "application/json" -ErrorAction Stop

if ($res -and ($res.StatusCode -eq 200)) {
    Write-Host "Maintenance mode ended successfully for tenant $tenantId"
}

バグ修正

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

セキュリティのサポート技術情報について詳しくは、「UiPath Orchestrator - Robot Account Takeover」をご覧ください。
長期実行のワークフローのジョブを実行すると、ジョブが「中断」ステートに移行されずに「実行中」ステートに留まることがありました。このようなジョブを強制終了すると、ステートは「終了中」に移行し、そのままそのステートに留まっていました。今回のリリースでは、この挙動の原因となった問題を修正しました。現在は、長期実行のジョブは期待どおり別のステートに移行し、問題なく実行されるようになりました。
[ロールをロボットアカウントに割り当て] ウィンドウの誤記 (英語 UI) を修正しました。具体的には、[Search for a robot account] フィールドが [Seach for a robot account] と表示されていました。現在、フィールド名のスペルは正しいものに修正されています。
手動でアップロードされたパッケージの名前が [監査] ページの詳細情報に表示されませんでした。この問題は、パッケージを個別または一括でアップロードした際に発生していました。現在は、アップロードされたすべてのパッケージの名前が [監査] ページの詳細情報に正しくログ記録されるようになりました。
Active Directory で姓が指定されていないユーザーが、Orchestrator にログインできませんでした。