AWA（Agent Chat）の割り当て問題のトラブルシューティング方法Summary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 「Advanced Work Assignment」アプリケーション（Agent Chat でも使用される）は、エージェントへの誤った割り当て、つまり過剰割り当てまたは過少割り当てを引き起こすことがあります。たとえば、エージェントの最大キャパシティが 5 の場合、エージェントが最大キャパシティ 5 に到達した後は AWA は作業項目を提供すべきではありませんが、5 を超えて割り当て続ける場合があります。これは過剰割り当てです。また、エージェントに余力があるにもかかわらず、最大キャパシティに達するまで AWA が項目を割り当てない場合があります。これは過少割り当てと呼ばれます。 この記事は、この種の割り当て問題をトラブルシューティングするのに役立ちます。 Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } すべて Instructions<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 過剰割り当て / 過少割り当ての問題をトラブルシューティングするための重要な手順は次のとおりです。 エージェントの最大キャパシティを特定するエージェントの現在の「使用中キャパシティ」を確認する手動で割り当てられたドキュメントがないか確認するスキル制限がないか確認する ステップ 1: エージェントの最大キャパシティを特定する エージェントの最大キャパシティは次の手順で確認できます。 maint/admin/agent として対象インスタンスに接続します。awa_agent_capacity.list に移動します。エージェントと Service Channel でフィルターします。Capacity 列に Service Channel ごとのエージェントの最大キャパシティが表示されます。この Capacity 列には、Service Channel でエージェントのキャパシティオーバーライドが定義されている場合のみ値が表示されます。エージェントに対してキャパシティオーバーライドが定義されていない場合、この Capacity 列は空になります。その場合は、Service Channel に移動して、チャネルレベルで定義されたデフォルトの最大キャパシティを確認する必要があります。 ステップ 2: エージェントの現在のキャパシティを確認する エージェントの現在の「使用中キャパシティ」は、現在そのエージェントに提供されている作業項目数と、現在エージェントに割り当てられ、作業進行中状態にあるドキュメント数に基づいて計算されます。 エージェントの現在のキャパシティは次の手順で確認できます。 awa_work_item.list に移動し、Queue ごとに state="Pending Accept" のエージェントでフィルターします。ドキュメントテーブルに移動します。Agent Chat の場合は interaction テーブル、Case Management の場合は case テーブル、Incident Management の場合は incident テーブルです。ドキュメントテーブルで、エージェントでフィルターし、さらに Channel 条件と utilization 条件を追加します。（Channel 条件と utilization 条件は OR ではなく AND で結合されます。）AWA システムは、上記ステップ 1 とステップ 2 の 2 つの件数を合計して、エージェントの現在の使用中キャパシティを計算します。 この時点で、エージェントの最大キャパシティと、現在の使用中キャパシティが分かります。その後、割り当て問題をさらにトラブルシューティングするために、手動割り当てされたドキュメントやスキル制限がないかを確認する必要があります。 ステップ 3: 手動で割り当てられたドキュメントがないか確認する システムで AWA が有効になっていても、ユーザーはリストやフォームから手動でドキュメントを割り当てることができます。たとえば、interaction/case/incident のフォームまたはリストから Assigned to フィールドを任意のエージェントに変更できます。 重要な点は、AWA は手動割り当てをエージェントの最大キャパシティ内に制限しないということです。そのため、手動割り当てによってエージェントの最大キャパシティ制限を超える過剰割り当てが発生する可能性があります。 ただし、エージェントがキャパシティを超えて手動で割り当てられた場合、AWA はそのエージェントに作業項目を割り当てなくなります。利用可能な余力がないためです。AWA は、エージェントの使用中キャパシティが最大キャパシティを下回った場合のみ、そのエージェントを割り当て対象として考慮します。 たとえば、エージェントの最大キャパシティが 4 の場合に、AWA により 4 件割り当てられ、その後マネージャーによってさらに 4 件手動で割り当てられると、そのエージェントの使用中キャパシティは 8 になります。これはキャパシティに対する過剰割り当てです。その後エージェントが 5 件を完了すると、使用中キャパシティは 3 になり、AWA は再びそのエージェントを割り当て対象として考慮できるようになります。 ここまでが過剰割り当て問題を確認する手順です。次は、エージェントに十分なキャパシティがあるにもかかわらず AWA が割り当て対象として考慮しない、過少割り当て問題に関する内容です。 ステップ 4: スキル制限がないか確認する エージェントに十分な余力があるにもかかわらず AWA が割り当てを行わない場合、割り当てに必須スキルが設定されている一方で、エージェントが必要なスキルを保持していない可能性があります。 スキル制限を確認する手順は次のとおりです。 作業項目のドキュメントレコードについて、必要なスキルを確認します。ドキュメントレコードは incident、case、または interaction（チャットの場合）のいずれかです。対象の作業項目について、ドキュメントレコード番号（例: CS36559811）をコピーし、task_m2m_skill テーブルでフィルターします。これにより、そのタスクをエージェントが取得するために必要なスキルが分かります。ドキュメントに必要なスキルが分かったので、利用可能なエージェントがそのスキルを持っているか確認します。sys_user_has_skill テーブルに移動し、対象エージェントでフィルターすることで確認できます。エージェントが必要なスキルを持っている場合、システムはそのエージェントを割り当て対象として考慮するはずです。 このプロセスの詳細については、KB0951909 - Section C - Mandatory Skills も参照してください。 Related Links<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 割り当て問題をトラブルシューティングする際に知っておくべき追加事項および補足事項は次のとおりです。 キャパシティ計算は非常にコストが高くリソースを消費する処理であるため、一定間隔で計算され、「awa_agent_capacity」キャッシュテーブルに保存されます。そのため、このテーブルの値に問題がある場合、それも割り当て問題につながる可能性があります。したがって、上記手順に従ってこのテーブルの値を確認する必要があります。既知の PRB 「PRB1417652 - awa_agent_capacity テーブルに対する同時読み取りおよび更新によって誤ったワークロード値が発生する」「PRB1376053 - システムプロパティによってすべての AWA GlideRecord クエリで Work Flow を false に設定する」 PRB1417652 は Paris Patch 7 以降で修正されています。Paris Patch 7 より前のリリースを実行しているインスタンスでは、5 分ごとに実行されるスケジュールジョブによる回避策が適用されている可能性があります。この場合、誤ったキャパシティは 5 分ごとに修正されますが、AWA の assigner スレッドがこの 5 分間の間、つまりジョブによってキャパシティが修正される前に実行された場合、過剰割り当てまたは過少割り当てが発生する可能性があります。その場合、この PRB の影響を最小限に抑えるために、ジョブの間隔を 5 分から 2 分に短縮する必要があります。 PRB1376053 は Paris リリース以降で修正されています。この問題は、AWA Record Watcher Responder（Eligibility/Workload）が Java クラスを呼び出した際、その Java クラスがドキュメントテーブルをクエリすると、プラットフォームの他の場所と同様に、対象テーブルの Query Business Rule より先に実行されるという事実に関連しています。しかし、それらの Business Rule が遅い場合や再帰呼び出しを発生させる場合、Record Watcher Responder プロセスが遅延する可能性があります。その結果、キャパシティの更新が遅れ、割り当て問題を引き起こす可能性があります。 例: Agent A の最大キャパシティは 5すでに AWA から 5 件の作業項目が提供され、それらを受諾しているため、使用中キャパシティは 53 件のドキュメントをクローズしたため、使用中キャパシティは 2（5-3=2）マネージャーがさらに 5 件のドキュメントを手動で割り当てたため、使用中キャパシティは 7（5+2=7）になる（手動割り当てのため最大キャパシティ 5 を超過）その後マネージャーが、その手動割り当てされた 5 件のうち 4 件の割り当てを解除するこれにより、AWA の Record Watcher Responder はキャパシティを 4 減少させる必要があるこの Record Watcher 更新は即座に実行されるべきだが、ドキュメントテーブル上の Query Business Rule が遅い場合は遅延する可能性があるその間、AWA は誤ったキャパシティを基に判断する可能性があるさらに、その間に修正ジョブが実行されて正しいキャパシティへ補正される可能性があるその後で遅延していた Record Watcher 更新が実行され、さらにキャパシティが減算されるため、過剰割り当てを引き起こす可能性がある これは非常にまれなエッジケースです。 これを回避するには、Record Watcher Responder の更新イベントが迅速に処理されるように、ドキュメントテーブル上の Query Business Rule が遅くならないことを確認する必要があります。 または、システムプロパティ「glide.awa.query_br_disable=false」を設定することで、Record Watcher Responder スレッドから Query Business Rule が実行されることを回避できます（Paris リリース以降でのみ利用可能）。 3. 割り当て問題をトラブルシューティングする際に有用なログパターン スケジュールジョブ修正では次のログマーカーが出力されます。 "CSM Number of agents with incorrect capacity" キャパシティ更新時に glide.record_watcher.evaluator ワーカースレッドは次のログマーカーを出力します。 Update workload. Agent: <sys_id_of_agent>, channel: <sys_id_of_channel> また、Record Watcher スレッドは、Record Watcher イベントを遅延処理した後に次のログを出力します。 glide.record_watcher.evaluator.<thread_number> SYSTEM Processed record