Hello,

While using the Avaya DMCC sample application, I found that the aux work reason code does not propagate to the Avaya one-X Agent clientyet:

The reason code is properly reflected on CM

The reason code is seen in the Avaya one-X Agent log as delivered to one-X agent client

The Avaya one-X Agent client goes into aux work hence not allowed to take ACD queue calls

Is there a known issue with Avaya one-X Agent not displaying the reason code of the aux work state change? Note that the one-x agent client does change to aux work (just fails to show the reason code).

Some more details info below


One-X Agent build: 2.5.20020.0 (Spark version: 2.5.51.3) and latest GA build 2.5.60313.0 (Spark version: 2.5.13.0)


The reason codes are properly assigned within Avaya one-X Agent settings.


Changing to aux work and desired reason code on the Avaya one-x Agent itself displays the reason code correctly

Log excerpt at the exact time when auxwork 4 is requested:

2019-06-17 15:45:41,919 DEBUG 19984 Avaya.OneXAgent.ModelManager.WorkModelManager SessionImpl[S1:0a7ea272-08ce-4ba3-a0da-7625d6c80e0a].StateImpl=[duration=0,operations=[login=False,logout=True,shutdown=False,enterAux=True,enterReady=False,addWorkItem=True,addVoiceInteraction=True,loginAgent=False,loginIM=True,desktopSharing=True,video=True,tty=True,logoutAgent=True,enterFollowUp=False,observe=False,unobserve=False,remoteAgentLogout=False,quickAlert=False,],type=Ready,]

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.Dispatcher Dispatcher: Received Event - ASTFeaturesListEvent

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand IncomingCommandHandler: Received event - ASTFeaturesListEvent

2019-06-17 15:46:28,389 INFO 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand manual-in Button transitioned from on to off

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand Feature : Manual In

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand Attr Name = avaya-cm-action, Value = on

2019-06-17 15:46:28,389 INFO 16936 Avaya.OneXAgent.WorkService.WorkServiceImpl PhoneService_AgentStateChanged:oldState=Ready;newState=LoggedOut

2019-06-17 15:46:28,389 INFO 16936 Avaya.OneXAgent.WorkService.WorkServiceImpl UpdateSessionState: Agent State LoggedOut

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.Dispatcher Dispatcher: Received Event - ASTFeaturesListEvent

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand IncomingCommandHandler: Received event - ASTFeaturesListEvent

2019-06-17 15:46:28,389 INFO 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand aux-work Button transitioned from off to on

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand Feature : AuxWork 4

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand Attr Name = avaya-cm-action, Value = on

2019-06-17 15:46:28,390 DEBUG 19984 Avaya.OneXAgent.Work.SessionStateImpl Object is detached from model:SessionStateImpl[Ready]

2019-06-17 15:46:28,391 DEBUG 19984 Avaya.OneXAgent.ModelManager.WorkModelManager SessionImpl[S1:0a7ea272-08ce-4ba3-a0da-7625d6c80e0a].StateImpl=[duration=0,operations=[login=False,logout=True,shutdown=False,enterAux=False,enterReady=False,addWorkItem=True,addVoiceInteraction=True,loginAgent=True,loginIM=True,desktopSharing=True,video=True,tty=True,logoutAgent=False,enterFollowUp=False,observe=False,unobserve=False,remoteAgentLogout=False,quickAlert=False,],type=LoggedIn,]

2019-06-17 15:46:28,391 INFO 16936 Avaya.OneXAgent.WorkService.WorkServiceImpl PhoneService_AgentStateChanged:oldState=LoggedOut;newState=Aux

2019-06-17 15:46:28,391 INFO 16936 Avaya.OneXAgent.WorkService.WorkServiceImpl UpdateSessionState: Agent State Aux

2019-06-17 15:46:28,392 DEBUG 19984 Avaya.OneXAgent.Work.SessionStateImpl Object is detached from model:SessionStateImpl[LoggedIn]

2019-06-17 15:46:28,393 DEBUG 19984 Avaya.OneXAgent.ModelManager.WorkModelManager SessionImpl[S1:0a7ea272-08ce-4ba3-a0da-7625d6c80e0a].StateImpl=[duration=0,operations=[login=False,logout=True,shutdown=False,enterAux=True,enterReady=True,addWorkItem=True,addVoiceInteraction=True,loginAgent=False,loginIM=True,desktopSharing=True,video=True,tty=True,logoutAgent=True,enterFollowUp=False,observe=False,unobserve=False,remoteAgentLogout=False,quickAlert=False,],type=Aux,]

There is no mechanism for Communication Manager to indicate the current Reason Code to One-X Agent. This means that One-X Agent will only show the correct RC if it was used to set the RC.

If you use a deskphone or CTI to change the agent to Aux state, One-X Agent will not show the correct RC - it will show whatever RC was selected the last time One-X Agent was used to enter Aux state. This us just a limitation or One-X Agent.

Martin

Martin,

Thanks for your reply but something doesn't make sense to me.

In the logs of Avaya One-X Agent, I can clearly see that CM pushed the aux work mode state and reason code (4 in the log excert case I provided earlier). So, based on that, we can see CM letting one-x Agent know about both aux work plus reason code. Are you suggesting this is a limitation of the One-X Agent client itself only? And, if so - are you aware whether there any JIRA etc items open for that product team to look into this scenario?

Please note that I was asked to post on Devconnect after opening up an SR and being told that this is a devconnect item since SDK's are involved.

Many thanks,
Alex

Alex,

As Martin mentioned, there is not any mechanism for CM to send the reason code name to clients (one-X Agent in this case), CM only sends the reason code number to clients as you can see in the log. Even if you can set the reason code names from 1 to 9 on CM, CM cannot send the reason code name to clients...

Because CM does not send the name of reason code to clients, so one-X Agent uses the data which it has in its own DB... It means that you can can set the reason code name on one-X Agent side and it can display on one-X Agent after changing the Auxiliary state of the ACD Agent (System Settings > Reason Codes > Aux Reason Codes)

Regards,
Tuan Pham

Thanks for your reply PhamTuan,

i understand that CM only sends the reason code (integer value) to one-x agent. But, I would expect one-x Agent to properly identify the reason code as I have the proper mapping of reason codes to reason code names within one-x agent configuration (see below sample config)


Knowing the above, are you saying so long as the mapping is there and properly lines up, we should expect one-x Agent to properly show the reason code name? If so then I think this is a bug with One-x agent. Looking forward to your guys reply.

Alex

auxReasonCodes.xml for my one-x Agent setup (noting the mapping I have configured correctly)

<?xml version="1.0"?>

<ReasonCodes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Id="0" IsLeaf="false" ReadOnly="false" DefaultGuid="a47969b6-33b2-44c3-82d1-b972379568c3" Version="2.5.60313.0" xmlns="http://avaya.com/OneXAgent/ObjectModel/ReasonCode">

  <ReasonCodes Id="0" Label="default" IsLeaf="true" ReadOnly="false" Guid="a47969b6-33b2-44c3-82d1-b972379568c3" />

  <ReasonCodes Id="1" Label="Project Work" IsLeaf="true" ReadOnly="false" Guid="a233d786-8d59-4a69-85c4-ba91378a8c36" />

  <ReasonCodes Id="2" Label="Team Meeting" IsLeaf="true" ReadOnly="false" Guid="b4f832b8-82fc-462e-a776-1b2c49235a65" />

  <ReasonCodes Id="3" Label="Training" IsLeaf="true" ReadOnly="false" Guid="7476debe-7c40-4652-8610-a6934de9760a" />

  <ReasonCodes Id="4" Label="Break" IsLeaf="true" ReadOnly="false" Guid="e943dd05-d5aa-413a-995b-2a97c85940de" />

  <ReasonCodes Id="5" Label="Lunch" IsLeaf="true" ReadOnly="false" Guid="f86ffb2f-d739-407e-95ae-215fedfbd2fe" />

  <ReasonCodes Id="6" Label="Case Work" IsLeaf="true" ReadOnly="false" Guid="1656c3f0-d73b-4a33-9753-0696840167f4" />

  <ReasonCodes Id="7" Label="DM Activities" IsLeaf="true" ReadOnly="false" Guid="30e00be1-4ec9-4066-8dcf-c06743844621" />

  <ReasonCodes Id="8" Label="Expert Case Work" IsLeaf="true" ReadOnly="false" Guid="2a88302f-2a2c-4f6b-b1ea-89d402f0102c" />

  <ReasonCodes Id="9" Label="Email/Chat Case Work" IsLeaf="true" ReadOnly="false" Guid="2282b157-79d9-4c78-afc4-3ddc6ede5492" />

</ReasonCodes>

I have had the same issue from our third-party CRM for the last 10 years. The unavailability AUX reason codes are mirrored in the CRM, CM, CMS and Avaya One-X Agent settings. It is as they say, Avaya One-X Agent will only show the Aux reason if it is selected in the Avaya One-X Agent. However selecting it in the Avaya One-X Agent does not update the CRM and the CRM must be made available or unavailable before Avaya One-X Agent. The CRM can take the Avaya One-X Agent from Aux to Auto-In and show ACD-In in CMS but any Aux state for Break, Lunch, Meeting, etc only shows as AUX on the Avaya One-X Agent unless manually selected to match the CRM. If the Agent does not manually select the Aux reason code then CMS Supervisor real-time Agent Group Report will never show the agents status as anything but Aux until they change to work inbound calls. Then the agent will show as ACD-IN. Needless to say this puts the supervisors at an extreme disadvantage when they have no idea if the agents are in Aux for Outbound Calls, Break, Meeting, Training, Lunch, etc. The CRM provides no real time status on the agents.

Chris