orchestrator
2021.10
false
  • リリース ノート
    • 2021.10
    • 2021.10.1
    • 2021.10.2
    • 2021.10.3
    • 2021.10.4
    • 2021.10.5
    • 2021.10.6
    • 2021.10.7
    • 2021.10.8
    • 2021.10.9
    • 2021.10.10
    • 2021.10.11
    • 2021.10.12
    • 2021.10.14
    • 2021.10.15
    • 2021.10.16
重要 :
このコンテンツの一部は機械翻訳によって処理されており、完全な翻訳を保証するものではありません。 新しいコンテンツの翻訳は、およそ 1 ~ 2 週間で公開されます。
UiPath logo, featuring letters U and I in white
サポート対象外

Orchestrator リリース ノート

Automation CloudAutomation Cloud Public SectorAutomation SuiteStandalone
最終更新日時 2024年10月31日

2021.10.4

公開日: 2022 年 4 月 7 日

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

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

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

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

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

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

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

SQL Server の Azure AD 認証

注: 追記 (2022 年 4 月 20 日)

Azure Virtual Machines または Azure App Service にインストールした Orchestrator に対して、Azure AD のサポートを追加しました。このため、Azure AD 認証を使用して Orchestrator を SQL Server に接続できます。詳しくは、こちらをご覧ください。

改良点

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

  • v2020.4 より前のバージョンからアップグレードを行う際は、プラットフォーム構成ツールによる証明書のホスト名の検証が適用されません。このため、このようなシナリオではホスト名の検証が行われないようにしました。
  • Orchestrator をアップグレードする際に v2021.10 より古い Insights が有効化されている場合は警告メッセージが表示されるようになりました。このメッセージでは、Insights のハードウェア要件が v2021.10 以降大幅に変更されたことについて通知します。Orchestrator をアップグレードする前には、Insights の新しい要件を満たしている必要があります。

既知の問題

  • ホストとして 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 にログインできませんでした。
  • Orchestrator の UiPath.Orchestrator.dll.config ファイルで Plugins.SecureStores.CyberArk.UsePowerShellCLI パラメーターを true に設定していると、CyberArk 資格情報ストアから資格情報アセットを取得できませんでした。
  • Orchestrator と Identity のデータベースでトルコ語固有の照合方法が使用されている場合に、v2020.10 から v2021.10 へのアップグレードが失敗していました。また Latin1 ベースの SQL 照合方法を選択している場合は、アプリケーション サーバーでトルコ語 (tr-tr) のカルチャが使用されている際に同様の問題が発生していました。この問題を修正するには、en-us のカルチャに切り替えてからインストールを再度お試しください。

このページは役に立ちましたか?

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