これらの推奨プラクティスを確認して従い、あなたの WLM 実装が安定していて、効率的で、スケーラブルであることを確保してください。

推奨プラクティス

冗長キューの所有権を確保する
  • 推奨事項: 1人の所有者が削除または無効になった場合でもキューにデッドロックが発生しないように、少なくとも 2人の所有者がいることを確認してください。
  • 理由: これは重要なビジネス継続性および管理のベストプラクティスです。 キューの所有者が組織を離れるかアカウントが無効になる場合でも、二次所有者は管理者のボトルネックなしでキューを管理（例えば、一時停止、再構成、または作業項目の管理）することができ、その結果、デッドロックを防ぐことができます。
Control Room における作業項目の可視性を最大化する
  • 推奨事項: Control Room で最大10個の作業項目の列を表示できます。 この機能を使って、作業項目データを最大限に可視化することができます。
  • 理由: 作業キューの構造を定義する際に、列を指定します。 Control Room の作業アイテムビューに関連する列を表示することで、オペレーターやビジネスユーザーは各作業アイテムのコンテキストを迅速に理解し、特定のアイテムを識別し、データをダウンロードする必要なくトラブルシューティングを行うことができます。 他の作業項目と区別する最も重要なフィールドを選択してください。
作業項目データと結果値を最適化する
  • 推奨事項: 特に作業項目の結果値には、1000文字まで受け入れ可能な作業項目値を最適に使用してください。
  • 理由: 作業項目の 結果 フィールドは、処理結果に関する詳細なフィードバックを提供するために重要です（例：請求書が正常に投稿されました、ID: INV12345、顧客記録が作成されました、アカウント: CUST987、または失敗 - 無効なメール形式)。 1000文字の制限を使用して、包括的で実行可能なメッセージを確保し、単純な結果のために外部ログを確認する必要を減らします。
作業項目を効果的に優先順位付けする
  • 推奨事項: 特定の作業項目を優先させるには、キューを作成するときに作業項目データをソートするようにします。
  • 理由: キュー全体および個々の作業項目にデフォルトの優先度を設定できますが、アイテムを挿入する 順序 も同じ優先度のアイテムの初期処理に影響を与えることがあります。 キュー内でソート基準を使用することで（キュー作成時に実施）、特定のビジネス価値や緊急性を満たすアイテムが常にデバイスが選択するためのキューの最上位に配置されることが保証されます。
API を使用して一括作業項目を挿入
  • 推奨事項: 作業項目を一括で挿入するには、作業項目 API を使用します。この API は、JSON 形式の作業項目のリストを受け入れるためです。
  • 理由: ループ内で 各単一の作業項目 を挿入するために API リクエストを送信すると、数千のアイテムに対して重要なネットワークおよび API のオーバーヘッドが発生します。 パフォーマンスを最適化するために、作業アイテムAPIを使用してください。これにより、複数の作業アイテムオブジェクト（バッチ）を含む JSON 配列を構築し、それを単一のAPIコールで送信できます。 これにより、呼び出しの数が大幅に減少し、大きなキューをポピュレートする際にデバイスがより速く、より効率的になります。
クラスターの時計が同期されていることを確認する
  • 推奨事項: クラスター内のすべてのノード（デバイス）の時刻（クロック）が同期されていることを確認します。 これは、Apache Ignite キャッシュ サーバーが正常に機能するために重要です。
  • 理由: Control Room は分散キャッシングのために Apache Ignite を使用しています。 クラスター内の異なるノードのシステムクロックが同期していない場合、データの不整合、キャッシュミス、その他の予測不可能なエラーが発生し、これが WLM のパフォーマンスや信頼性に影響を与える可能性があります。 ネットワーク時間プロトコル (NTP) サービスを構成する必要があります。
データベースの継続的な接続を確保する
  • 推奨事項: データベース接続が持続的かつ継続的であることを確認してください。これはワークロード自動化にとって重要です。 定期的にネットワーク スキャンを実施するか、ネットワークの問題を検出または回避できるツールを使用してください。
  • 理由: 連続的なデータベース接続は、途切れのないワークロード自動化に不可欠です。 接続の中断は、タスクの失敗、処理の遅延、データの不整合、または SLA の未達を引き起こす可能性があります。 安定した接続を維持することは、信頼性、スムーズな実行、および最適なシステムパフォーマンスを確保します。
API を通じて効率的な作業項目を取得します
  • 推奨事項: API にページネーション フィルターを適用して、作業項目を管理しやすいチャンクで取得します。
  • 理由: アイテムが ワークロードの管理 API を通じてキューからプログラム的に取得されるとき、デフォルトの制限（通常は 200）が適用されます。 これはシステムが大きな応答で過負荷にならないようにします。 キューから大量のアイテムを取得する必要があるシナリオでは、ページネーション（オフセットや長さのパラメータなど）を使用して、管理しやすいチャンクで取得します。

避けるべき実践

バルク挿入のためにループ内で個別の API 呼び出しを使用しないでください
  • 推奨事項: WLM 機能が効率的に動作するように、作業項目 API をループで使用して作業項目を一括挿入するのは避けてください。
  • 理由: 大量のバッチ内の各作業項目ごとに個別の API 呼び出しを設定することは非効率的であり、ネットワークやサーバーに大きな負荷を生じさせる可能性があります。 代わりに、リストを受け入れる workitems API を使用して作業項目をバッチ挿入します。
デバイスプール内のデバイスでローカルスケジュールを作成しないでください
  • 推奨事項: デバイスがデバイスプールに属している場合、そのデバイス上でローカルスケジュールを作成しないでください。 これはデバイスが作業項目を実行するためだけに使用されることを保証します。
  • 理由: プール内のデバイスは、WLM のためにControl Roomによって管理されます。 ローカルスケジュールはこの管理を上書きすることができ、デバイスが WLM タスクの代わりにスケジュールされたタスクを実行する原因となります。 これはリソースの競合、予測できない動作、および SLA の未達成を引き起こす可能性があります。 プール内のデバイスは、Control Room の分散作業アイテムに対して完全に利用可能であるべきです。
アクティブキューのユーザーから Bot 実行の権限を削除しないでください
  • 推奨事項: ユーザーに使用中のキューがある場合は、そのユーザー (ロール) から Bot を実行 権限を削除しないでください。
  • 理由: ユーザーの役割（または実行中のプロセスやスケジュールに関連付けられた特定のユーザーアカウント）がキューの処理に関連している場合、そのユーザーのBot 実行権限を削除すると、関連する自動化が失敗します。 これは結果的に WLM プロセスを妨げます。 変更を加える前に、特に自動化実行に積極的に関与しているアカウントについては、常に権限を確認してください。
処理中にデバイスの電源を切らないでください
  • 推奨事項: 作業項目が進行中の場合は、デバイスをシャットダウンしないでください。 デバイスをメンテナンスのためにオフラインにする必要がある場合は、キューを一時停止し、そのデバイスで作業項目が進行中でないことを確認してください。
  • 理由: デバイスが作業項目を処理中に突然シャットダウンすると、作業項目がスタックする（例えば、無期限に PUSHED 状態になる）か、進行状況が失われる可能性があります。 まず、関連するキューが一時停止されていることを確認し、現在処理中のアイテムが完了するのを許可し、その後、デバイスがオフラインにされる前にデバイスがアイドル状態であることを確認してください。 これにより、優雅な処理が保証され、データの損失や孤立した作業項目を防ぎます。
処理中に Control Room サービスを停止しないでください
  • 推奨事項: 作業項目キューが処理されている場合は、Automation Anywhere Control Room サービスを停止または再起動しないでください。 代わりに、キューのオートメーションを一時停止し、サービスを再起動します。
  • 理由: Control RoomサービスはControl Roomの重要な部分であり、WLMを含みます。 キューがアクティブな状態で停止すると、すべての処理が停止し、作業項目が不整合な状態に残る可能性があるか、ステータスを更新しようとする自動化でエラーが発生する可能性があります。 メンテナンスを行う前に Control Room サービスのキューを必ず一時停止してください（これにより自動化が新しいアイテムを選択しなくなります）、その後サービスを再起動します。

自動化の優先度を理解する

優先度により、オートメーションの処理順序が決定されます。 さまざまなレベルで自動化の優先度を設定できます。
  • Bot: Bot をスケジュールするとき (高、中、または低)。 詳しくは、Bot の自動化優先度の設定をご覧ください。
  • (デバイス プール レベルでの) キュー: キュー内のオートメーションの実行順序 (ラウンド ロビン または テーブルに表示する優先度) を定義します。 詳細については、「オートメーション キューの順序」をご覧ください。
  • (キュー レベルでの) 作業項目: 作業項目 列値の優先度を設定します。 たとえば、名 列の昇順、E メール 列の降順などです。

自動化の優先度がどのように機能するかを理解するために、次のシナリオを見てみましょう。

デバイス プール レベルで Q1 が第 1 優先、Q2 が第 2 優先だとします。 Q1 には、請求書金額や合計 などの作業項目があり、作業項目レベルの優先度は以下のようになっています。
  • Q1 作業項目レベルの優先順位 -> 請求書金額 列の昇順
  • Q2 作業項目レベルの優先度 -> 合計 列の昇順
Q1 と Q2 に同時に複数の作業項目を追加した場合、InvoiceAmount が最も低い Q1 の作業項目が最初に実行されます。

このようなシナリオでは、デバイス プール レベルのキュー優先度が、作業項目の優先度よりも優先されます。

次の表に示すように WLM が設定されている別のシナリオを考えてみましょう。
Bot とキュー名 デバイス プール ユーザー
プロセス1 1 1 ボット1
プロセス2 ボット2
プロセス3 ボット3
プロセス4 ボット4
上記の WLM 設定では、4 つのオートメーションをすべて並行してデプロイした場合、最初にデプロイされたオートメーション プロセスからの作業項目が最初に完了します。 その後、2番目にデプロイしたものが開始され、この順序で続行されます。 ただし、4 つのオートメーションはすべて並行して実行されるわけではありません。 したがって、複数のオートメーションを実行する場合は、次の表に示す設定を作成します。
Bot とキュー名 デバイス デバイス プール ユーザー
プロセス1 デバイス1 プール1 ボット1
ボット2
ボット3
ボット4
プロセス2 デバイス2 プール2 ボット5
ボット6
ボット7
ボット8
プロセス3 デバイス3 プール3 ボット9
Bot10
Bot11
Bot12
プロセス4 デバイス4 プール4 Bot13
Bot14
Bot15
Bot16