AWA (エージェントチャット) アサインの問題のトラブルシューティング方法Summary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 「高度なワークアサインメント」アプリケーション (エージェントチャットでも使用) を使用すると、エージェントへの誤ったアサイン、つまり過剰なアサインやアサイン不足が発生することがあります。たとえば、エージェントの最大キャパシティが 5 の場合、エージェントが最大キャパシティ 5 に達した後、AWA はエージェントに作業アイテムを提供すべきではありませんが、AWA が 5 を超えてアサインし続けた場合、これは過剰アサインです。また、エージェントの最大キャパシティに達するまで AWA がアイテムをアサインしないこともあります。エージェントに帯域幅がある場合、これを「アサイン不足」と呼びます。 この記事は、この種の割り当ての問題のトラブルシューティングに役立ちます。 Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #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: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #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 に移動します。エージェントとサービスチャネルでフィルターします。[キャパシティ] 列には、サービスチャネルごとのエージェントの最大キャパシティが表示されます。このキャパシティ列は、エージェントのキャパシティ上書きがサービスチャネルで定義されている場合にのみ入力されます。エージェントにキャパシティの上書きが定義されていない場合、このキャパシティ列は空になります。その場合は、次のスクリーンショットに示すように、サービスチャネルに移動して、チャネルレベルで定義されたデフォルトの最大キャパシティを確認する必要があります。 ステップ 2:エージェントの現在のキャパシティを確認する。 エージェントの現在の「使用中のキャパシティ」は、現在エージェントに提供されている作業アイテムの数と、現在エージェントにアサインされている対応中ステータスのドキュメントの数に基づいて計算されます。 エージェントの現在のキャパシティは、以下の手順で確認できます。 awa_work_item.list に移動し、キューごとに state="Pending Accept" のエージェントをフィルタリングします。ドキュメントテーブルに移動します。エージェントチャットの場合はインタラクションテーブル、ケース管理の場合はケーステーブル、インシデント管理の場合はインシデントテーブルになります。ドキュメントテーブルで、エージェントをフィルタリングし、チャネル条件と使用率条件と同様にフィルターも追加します。(チャネル条件と利用条件は OR ではなく AND になります)AWA システムは、ステップ 1 とステップ 2 の上でこれら 2 つのカウントを合計して、エージェントの現在の使用中キャパシティを計算します。 この段階では、エージェントの最大キャパシティとエージェントの現在の使用中のキャパシティがわかります。次に、手動でアサインされたドキュメントがあるかどうか、およびアサインの問題をさらにトラブルシューティングするためにスキル制限があるかどうかを確認する必要があります。 ステップ 3:手動でアサインされたドキュメントがあるかどうかを確認する。 システムで AWA がアクティブな場合でも、インタラクション/ケース/インシデントフォームまたはリストに移動し、[担当者] フィールドを任意のエージェントに変更するなど、リストまたはフォームを使用してドキュメントを手動でアサインできます。 ここで重要なのは、AWA によってエージェントの最大キャパシティ内で手動アサインが制限されないことです。したがって、その場合、手動アサインは過剰アサイン、つまりエージェントの最大キャパシティ制限を超える可能性があります。 ただし、エージェントがキャパシティを超えて手動でアサインされた場合、エージェントには帯域幅がなくなるため、AWA は作業アイテムのアサインを停止します。AWA は、エージェントの「使用中のキャパシティ」が最大キャパシティのレベルを下回った場合にのみ、エージェントのアサインを検討します。 たとえば、エージェントの最大キャパシティが 4 であるが、AWA によって 4 つ、マネージャーによって手動で 4 がアサインされた場合、そのエージェントの「使用中のキャパシティ」は 8 となり、これはキャパシティに応じたオーバーアサインとなります。エージェントが 5 つのアイテムをクローズすると、「使用中のキャパシティ」が 3 になり、AWA は彼をアサインとして検討できます。 これらは、過剰なアサインの問題を検証する手順です。次は、エージェントに十分なキャパシティがあるが、AWA が彼をアサイン先として考慮していないという、アサイン不足の問題です。 ステップ 4:スキル制限があるかどうかを確認する。 十分な帯域幅があるにもかかわらず、AWA がエージェントにアサインしない場合は、アサインに適用される必須スキルに問題がある可能性がありますが、エージェントが必要なスキルを所有していません。 スキル制限を確認する手順は次のとおりです。 作業アイテムドキュメントレコードで、必要なスキルを確認します。ドキュメントレコードは、インシデント/ケースまたはインタラクション (チャットの場合) にすることができます。影響を受ける作業アイテムについて、ドキュメントレコード番号 (CS36559811 など) をコピーし、task_m2m_skillテーブルに移動してフィルタリングします。これにより、エージェントがタスクを選択するために必要なスキルがわかります。ドキュメントに必要なスキルがわかったので、対応可能なエージェントがそれらのスキルを持っているかどうかを確認しましょう。これは、エージェントのテーブルsys_user_has_skillとフィルターに移動すると見つけることができます。エージェントが必要なスキルを持っている場合、システムはそのエージェントのアサインを検討する必要があります。 このプロセスの詳細については、 でも説明されていますKB0951909 セクション C - 必須スキル Related Links<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } アサインの問題のトラブルシューティングを行う際は、次の点に注意する必要があります。 1) 容量の計算は非常にコストがかかり、リソースを消費するプロセスであるため、特定の頻度で計算され、「awa_agent_capacity」キャッシュテーブルに保存されます。したがって、このテーブルの値に問題がある場合は、アサインの問題にもつながりかねません。したがって、上記の手順に従って、このテーブルの値を確認する必要があります。 2)既知のPRB 、 「PRB1417652 - awa_agent_capacity テーブルへの同時読み取りと更新により、誤った作業負荷値が発生する」 「PRB1376053 - システムプロパティ別のすべての AWA GlideRecord クエリで作業フローを false に設定」 ここでは、PRB1417652は Paris パッチ 7 以降で修正されており、Paris パッチ 7 より前のリリースで実行されているインスタンスでは、5 分ごとに実行されるスケジュール済みジョブ修正によってワークアラウンドが適用される可能性があります。つまり、キャパシティは 5 分ごとに固定されますが、このジョブによってキャパシティが修正される前の 5 分以内に AWA アサイン担当者スレッドが実行された場合は、アサインが過剰/不足する可能性があります。その場合、この PRB の影響を最小限に抑えるために、ジョブの間隔を 5 分から 2 分に増やす必要があります。 ここでは、PRB1376053は Paris リリース以降で修正されています。この問題は、AWA レコード監視レスポンダー (適格性/作業負荷) が Java クラスを呼び出したときに、その Java クラスがドキュメントテーブルを照会すると、プラットフォームの他の場所と同様に、それらのテーブルで BR を照会する前に起動されるという事実に対処します。ただし、これらの BR が遅い場合や再帰呼び出しを引き起こしている場合は、Record Watcher レスポンダープロセスが遅れる可能性があります。これにより、キャパシティの更新が遅延し、アサインの問題が発生する可能性があります。 例： エージェント A の最大キャパシティは 5 です彼はすでに AWA から提供された 5 つの作業項目を持っており、それを受け入れたので、彼の使用キャパシティは 5 です彼は 3 つのドキュメントをクローズしましたが、現在、彼の使用キャパシティは 2 (5-3=2) です。彼のマネージャーが彼にさらに 5 つのドキュメントを手動で割り当てたため、使用中のキャパシティは 5+2=7 になります (手動割り当てだったため、最大キャパシティ 5 を超えています)次に、マネージャーが手動でアサインされたドキュメントのうち 4 つの割り当てを解除すると、AWA のレコード監視レスポンダーのキャパシティが 4 減少しますこの Record Watcher の更新はすぐに実行されますが、ドキュメントテーブルでクエリ BR が遅い場合は、遅延が発生する可能性がありますしたがって、その間に、AWAは彼の能力が間違っていると考えるかもしれませんさらに、修正ジョブの合間に、キャパシティを適切な値に修正することができますその上、Record Watcher の更新が遅れてキャパシティがさらに減少するため、過剰割り当てが発生する可能性があります これは非常に稀なシナリオになるでしょう。 これを回避するには、Record Watcher レスポンダー更新イベントが迅速に処理されるように、ドキュメントテーブルのクエリ BR が遅くならないようにする必要があります。 または、システムプロパティ「glide.awa.query_br_disable=false」を設定することで、Record Watcher レスポンダースレッドからのクエリ BR の実行を回避する (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