Enterprise Chat and Email のエージェント ログインおよび可用性を解決して下さい 目次

はじめに前提条件要件使用するコンポーネント機能概要エージェント ログイン フローエージェント フロー 可用性の可用性はチャット エントリ ポイントで必要となりますログ 収集

概要

エンタープライズ チャットおよび Email（ECE）がステータス エージェント アベイラビリティのときクライアント開始チャット セッションどのように識別するかこの資料に記述されています。

前提条件

要件

次の項目に関する知識が推奨されます。

Enterprise Chat and Email●

Webブラウザ開発者ツール●

Unified Intelligent Contact Management Enterprise●

使用するコンポーネント

この資料に記載されている情報はソフトウェア バージョン ECE 11.6 に基づいています。

この資料に記載されている情報は特定のラボ環境のデバイスから作成されました。 このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。 

機能概要

エージェント アクティビティを管理し、きちんとタスクをルーティングする Cisco UnifiedIntelligent Contact Management Enterprise（ICM）のために ICM は ICM に記録 されるすべてのエージェントを監察する必要があります。 アプリケーション インスタンスは、ECE のような拡張 ICM CTI/ARM （エージェント レポートおよび管理）インターフェイスを通して、エージェン

ト アクティビティおよびエージェント ステータスを報告します。

ARM サービスは現在の CTI サーバ 機能性に構築され、アプリケーション エージェントを監視し、アクティビティに任せるクライアントアプリケーションを可能にします。 ARM インターフェイスはエージェント（ワークステーション モード）またはアプリケーションと関連付けられるすべてのエージェント（ブリッジモード）の指定されたセットを監視するクライアントアプリケーションを可能にします。

イメージは ARM インターフェイスのより多くの詳細を示します。  アプリケーション インスタンスは 1つ以上のエージェントをエージェント PG （メディア、等を出入りしてそれらを記録 して下さい）管理し、タスク アクティビティ（開始する タスク、終わりタスク、等）で報告するのに ARM インターフェイスを使用します。 

エージェント ログイン フロー

エージェント アベイラビリティは CTI サーバ側から識別されます。 エージェントがエージェント コンソールにログオンするとき、ECE リスナー プロセスは CTI サーバに要求を送信 します。要求はエージェントが利用可能ように彼自身ログオンされ、マークされることを示します。

これらは CTI サーバに ECE アプリケーションによって送られるインジケーターです:

エージェントがログオンされる時はいつでも、リスナーは MEDIA_LOGIN_REQ を送信 します。MEDIA_LOGIN_REQ はメディア ルート Domain（MRD） （ログ エージェントおよびその MRDのために設定されるすべてのスキルへのエージェント）に規定 された エージェントを記録 します。 エージェントが利用可能ように彼自身を示すとき、リスナーはエージェントはルーティング可能またはルーティング可能 READY またはない READY である示し、クライアントによって定義されした エージェント 情報を提供することを 2 つの More 要求を送信 します。 CTI クライアントが Open 要求 メッセージの関連 MRD 周辺装置ペアのためのアプリケーション パスを規定したにログインは拒否されます。 成功するログインに関してはエージェントはまた示されたMRD に属する少なくとも 1 つのスキル Group（SG）に属するために設定する必要があります。

イメージはメッセージが流れ図 Log In 要求のためのことを示します:

INFO トレース レベルとのリスナー ログ:

2019-07-20 18:27:31.749 GMT+0000 <@> INFO <@> [14285:listener-event-pool-priority-arm-request-

executor::-0] <@> ProcessId:4584

<@> PID:1 <@> UID:1005 <@> HttpSessionId:IrltMMd3T0prrkbhAwK8wkL5 <@>

com.ipcc.listener.arm.ARMLogger <@> 

<@> Sending MEDIA_LOGIN_REQ  -> 0 0 0 27 0 0 0 -105 0 2 8 1 0 0 19 -120 0 0 19 -87 0 0 0 0 0 0 0

1 107 5 49 48 48 53 0   <@>

2019-07-20 18:27:32.037 GMT+0000 <@> INFO <@> [71:Thread-9] <@> ProcessId:4584 <@> PID:1 <@>

UID:12 <@> HttpSessionId: 

<@> com.ipcc.listener.arm.ARMLogger <@>  <@> Received MEDIA_LOGIN_RESP  ->  0 0 0 8 0 0 0 -104 0

2 8 1 0 0 0 0   <@>

 既定のトレース レベルとの CTIsvr ログ:

20:27:32:466 cg1A-ctisvr Trace: ProcessMediaLoginReq - sessionID 4

20:27:32:466 cg1A-ctisvr Trace: SendARMMsg -- InvokeID = 591309094, MRDID = 5000, ICMAgentID =

5033, AgentMode = 0

IsAvailable = 0, MaxTaskLimit = 1, AgentInfo = 1005, ApplicationPathID = 5001, PeripheralID = 0,

AgentID =

20:27:32:607 cg1A-ctisvr Trace: ProcessARMMediaLoginRespMsg -- InvokeID = 591309094, Status = 0,

AgentSkillTargetID = 5033

No エラーが CTI サーバ側から発生したことをステータス 0 は意味します。

エージェント フロー 可用性の

エージェントがチャット SG に関連付けられる、およびこの SG がチャット入口点の ECE キューに関連付けられれば場合、エージェントが利用可能な彼自身を示すとき 2 要求、MAKE_AGENT_ROUTABLE_IND および MAKE_AGENT_READY_IND を見ます。

規定 された エージェントは規定 された MRD におけるルーティング可能 な モードに設定 されたことをルーティング可能 な示す値が ICM に告げるエージェントを作って下さい。

注: し、エージェント ルーティング可能 で はない応答を取り消す保留中を作るエージェント ルーティング可能 で はない 要求を待っている間、ルーティング可能 な示す値メッセージが送信 することができるエージェントを作って下さい。

作りなさいエージェント準備ができた示す値要求はアプリケ− ションサーバからリスナーによって届きます、リスナーは CTI サーバにおよびその時点に要求を ECE のための利用可能として考慮されるエージェント転送します。 そのケースでは、チャットが同時に始められれば、開始するべきシステム割り当てはそのチャットのためのチャット アクティビティを作成し。

リスナー ログは INFO トレースが有効に なる場合それらの要求を示します: 

2019-08-19 13:34:09.773 GMT+0000 <@> INFO <@> [8938:listener-event-pool-priority-arm-request-

executor::-441] <@> ProcessId:5436 <@> PID:1 <@> UID:12 <@> HttpSessionId: <@>

com.ipcc.listener.AgentAvailabilityStatusHandler <@> <@>

AgentAvailabilityStatusHandler:agentIsAvailable() MAKE_AGENT_ROUTABLE_IND to ARM

armLoginDataArraySize= ARMAgentData

==================================================================

2019-08-19 13:34:09.773 GMT+0000 <@> INFO <@> [8938:listener-event-pool-priority-arm-request-

executor::-441] <@> ProcessId:5436 <@> PID:1 <@> UID:12 <@> HttpSessionId: <@>

com.ipcc.listener.arm.ARMLogger <@> <@> Sending MAKE_AGENT_ROUTABLE_IND -> 0 0 0 16 0 0 0 -102 0

1 57 43 0 0 19 -120 0 0 25 20 0 0 0 2 <@>

2019-08-19 13:34:09.774 GMT+0000 <@> INFO <@> [8938:listener-event-pool-priority-arm-request-

executor::-441] <@> ProcessId:5436 <@> PID:1 <@> UID:12 <@> HttpSessionId: <@>

com.ipcc.listener.arm.ARMLogger <@> <@> Sending MAKE_AGENT_READY_IND -> 0 0 0 14 0 0 0 -99 0 1

57 44 0 0 19 -120 0 0 25 20 0 1 <@>

2019-08-19 13:34:09.774 GMT+0000 <@> INFO <@> [8938:listener-event-pool-priority-arm-request-

executor::-441] <@> ProcessId:5436 <@> PID:1 <@> UID:12 <@> HttpSessionId: <@>

com.ipcc.listener.AgentAvailabilityStatusHandler <@> <@> PRINT_STATE after sending

MAKE_AGENT_READY_IND to ARM:

CTI サーバおよび OPC プロセスからの出力は記録 します:

### CTI Server

15:34:09:841 cg1A-ctisvr Trace: ProcessMakeAgentRoutableInd - sessionID 6

15:34:09:841 cg1A-ctisvr Trace: SendARMMsg -- InvokeID = 80171, MRDID = 5000, ICMAgentID = 6420,

MaxTasks = 2, SessionID = 6

15:34:09:841 cg1A-ctisvr Trace: ProcessMakeAgentReadyInd - sessionID 6

15:34:09:841 cg1A-ctisvr Trace: SendARMMsg -- InvokeID = 80172, MRDID = 5000, ICMAgentID = 6420,

MakeRoutable = 1, SessionID = 6

### OPC

15:34:09:841 PG1A-opc Trace: MakeAgentRoutableInd - InvokeID = 80171, MRDID = 5000, ICMAgentID =

6420, MaxTasks = 2, SessionID = 6

15:34:09:841 PG1A-opc Trace: MakeAgentReadyInd - InvokeID = 80172, MRDID = 5000, ICMAgentID =

6420, MakeRoutable = 1, SessionID = 6

結果 OPC プロセスが AS_NOT_READY 状態からエージェントを取除き、AS_NOT_ACTIVE 状態に置くように。 NewState=AS_NOT_ACTIVE は実際にチャット/メールのための READY 状態です。

15:34:09:841 PG1A-opc Trace: SetAgentState: ASTID=6420 Periph#=15003 MRDomainID=5000 SGSTID=6928

SG#=70518(0x11376) OldState=AS_NOT_READY NewState=AS_NOT_ACTIVE Duration=0 CurLine=-1

ReasonCode=0 AgentObj=0x44535b8

現時点ではエージェントはルータ観点からルーティング可能、利用できます。 これをチェックする最もよい方法は rttestユーティリティを使用することです:

rttest: agent_status /agent 6420

### 6520 is ICMAgtID

Agent CUCM.Agent_test (6420, periph# 15003)

domain: Cisco_Voice (1), state = [nr-0:1,R], 411 secs

CL nr TEST_SG (6274, periph# 70520)

L nr CUCM_PIM1.Cisco_Voice.defa.88025 (5000, periph# 31858)

domain: ECE_Chat (5000), state = [na-0:2,RA], 383 secs

CL na TEST_Chat (6928, periph# 70518)

L na CUCM.ECE_Chat.default.11006 (6909, periph# 54839)

na - NotActive

0:2 – AciteTasks: ConcurentTaskLimit

RA - R はルータがエージェントをこのドメインで新しい作業のために使用可能と見なすことを（設定 された場合）ルーティング可能、A 示しましたです

注意： ICM 11.5、11.6 および 12.0 では問題 CSCvq11852 チャットを見つけることができ、メールは toagents を割り当てられることではないです利用可能の。 （アプリケーションパスによって報告される）そのようなシナリオでは D が利用できないドメインを意味するrttest 出力 [na-0:2,RD] で見ます。

それを越えて、ユーティリティ OPCtest およびエージェント PG procmon からのエージェントの状態をチェックできます。

例：

opctest /cust <inst> /node PG1A

opctest: dump_agent 5000 15003

C:\icm\pcc12\ra\logfiles>procmon <inst> PG1A pim1

11:38:40 Trace: EMT Creating Mutex Global\IMTConnect_DisconnectLock

>>>>dagent 15003

5000 がエージェントが作成される周辺装置 ID である一方、15003 はエージェントでありPeripheralNumber。

可用性はチャット エントリ ポイントで必要となります

チャット初期化では、クライアントはメッセージが「照会に感謝するのを見る場合があります。サービス時間は 9am-5pm PST、月曜日金曜日」。です。 チャットのための READY 状態にエージェントがある時でさえそのようなメッセージが現れることができます。 エージェント アベイラビリティを識別するためにシステムはクライアントがエントリ ポイント URL を実行するときAPI コールを発信します。 API 要求は ECE アプリケ− ションサーバに ECE Webサーバを通過します。 このアベイラビリティはアプリケ− ションサーバで作成されるセッションによって判別されます。

可用性が MRD アベイラビリティおよび MRD で利用可能なエージェントがあればチャットでに外観を必要とする ECE 11.6 利用可能があります。 ここの問題は SG の 1 つで利用可能なエージェントがあれば MRD がアクティブになり、チャットが提供されればチャット MRD で 2 SG がある場合、それ来ます。 この問題は ECE 12.0 および それ以降 バージョンで解決します。 機能拡張は設定の SG の使用によって行われました。 そのケースでは、システムはまた仕様 MRD のために利用可能な彼ら自身を示すエージェントのためのスキル グループを数えます。

API 要求:

http://<ECE_WEB_Server_IP>/system/egain/chat/entrypoint/initialize/1001

1001 がエントリ ポイント ID であるところ。

API 応答:

{"checkEligibility":{"responseType":0},"maskingPatterns":{"maskingPattern":[]},"isVideoChatLicen

sed":false,"isVideoChatEnabled":false,"videoChatMaxEscalation":5,"isDirectAudioChatEnabled":true

,"isChatAttachmentEnabled":false,"maxChatAttachmentSize":3,"isBlackListType":false,"isOffRecordE

nabled":false,"htmlTagMatcherRegEx":"((?:[\\r\\n|\\n]*(?:<[^>]*>)*[\\r\\n|\\n]*)*)","htmlTagMatc

herIncr":1,"isOneTagOff":true}

エージェントは利用できることシステムがどのようにのための定義するか 2 つのオプションがあります。 エージェントはチャットに利用できますまたはこれをする割り当てキュー深度があります。 キュー深度設定はすべてのエージェントが使用中のとき並べることができる顧客の数を可能にします。

API 応答で checkEligibility の注意して下さい: responseType 値。 その当時エージェント アベイ

ラビリティはであるもの示します。

0 として来る場合、エージェントがあるチャットを奪取 して利用可能があるか、またはキュー深度が達しないことを意味します。

●

1 時である場合、利用可能なエージェントがないことを示します。●

2 つは最大キュー深度が達したことを意味します。●

注: 何エージェントが特定時に利用できるかあることがわかるここにオプションがありません。

エージェントが利用可能ななら他の .js ファイルは Webブラウザによって受け取られます。 その結果、クライアントはエントリ ポイントについてはログイン名およびサブジェクト パラメータの最初のページを見ます。

ログ 収集

API 応答はクライアント側から（Webブラウザ ネットワーク トレースから）または消費される高い IO が理由で長い間保存するために推奨されないトレース レベルまたはデバッグが付いているECE アプリケ− ションサーバから利用できます。