Integrations and APIs for Service

Get Involved. Join the Conversation.

Topic

    Jared
    3PQ Chat does not pop into agent workspace, but server says...Answered
    Topic posted July 20, 2013 by Jared Gold Medal: 3,500+ Points 
    406 Views, 4 Comments
    Title:
    3PQ Chat does not pop into agent workspace, but server says it did
    Content:

    We're seeing an intermittent issue with the 3PQ Chat Routed method. We are very definitely using only a single client to the 3PQ API server. We send all chat pop requests from the clients to this single server, yet are seeing the same issue which was happening with multiple endpoints connected to the server.

    We make the ChatRouted call, receive SUCCESS, relay that message to the agent desktop. Consistently, we can do this dozens and dozens of times, with SUCCESS every time. However, every now and then, with nothing different happening with the agent or server side, the chat simply doesn't pop into the agent workspace.

    We made a non-trivial architecture change to meet the requirement of using a single client to the API, and continue to see the same issue. There are no logs for this because the logs show successful screenpops, but if needed we can reproduce it and provide ChatIds for items which did not populate. Are there any logs we have access to which will give more information on this?

    Please advise,

    -Jared

    Best Comment

    Sridhar Chodavarapu

    Hi Jared,

    Few questions for you:

    • How are you managing the max chat sessions that the agent can handle? Is it set to the default 3 on the profile?
    • Are you using any 3PQ api's for managing either the sessions or the agent state?
    • When the issue occurs, can you take a look at the Chat supervisor real time report and see if the agent can take any more chats?

    I am suspecting that the agent is at full capacity but the ChatRouted returns success.

    You can also turn on Add-in logging to check add-in behavior. Please follow the steps below:

    1. From the console, click the system menu (the red icon at the top left)
    2. Select 'Add-in Logging->View Current File'
    3. In the screen that pops up, set Component Logger to Verbose

    At this point you should see any Add-in log messages, most important when a chat has been routed to the agent, there should be a log message like you see below:

    OnEngagementAssignmentEvent - ChatEngagementAssignmentEventArgs
       Contract: RightNow.AddIns.HostSideAdapters.ChatEngagementAssignmentEventArgsViewToContractAdapter
       EngagementId: 11
       MustAccept: False
       Type: LEAD
       EngagementCreateTime: 8/5/2013 4:18:45 PM
       EngagementFirstEngagedTime: 8/5/2013 4:27:01 PM
       QueueId: 1
       SecondsEngaged: 423
       ContactInfo: RightNow.AddIns.AddInSideAdapters.ChatContactInfoContractToViewAdapter
       AgentInfo: 
       ResponseAction: NONE
     
    If you do not see that, then probably something went wrong and you should first verify if the agent is at full capacity.
     
    Hope this helps and please let us know what you find out.
     
    Thanks,
    Sridhar

    Comment

     

    • Jared

      This is a serious issue for the following reasons:

      1. The same agent can receive chats properly before and after this occurs with no change to configuration or login/available state.

      2. 3PQ Chat Server reports that the chat successfully popped, but it doesn't actually appear in the workspace. This is clearly out of scope for us to be able to resolve.

      3. The issue is intermittent, so it is not something we can reproduce in an isolated test environment.

      4. There is no way for our code to detect the failed pop, because RightNow reports that it was already successful.

      Any update to this issue will be greatly appreciated!

      Thanks,

      -Jared

    • Brian Haskins

      Hi Jared,

      I have engaged the Chat Dev team on this issue and we will respond back asap.

      thanks,

      tudley

    • Sridhar Chodavarapu

      Hi Jared,

      Few questions for you:

      • How are you managing the max chat sessions that the agent can handle? Is it set to the default 3 on the profile?
      • Are you using any 3PQ api's for managing either the sessions or the agent state?
      • When the issue occurs, can you take a look at the Chat supervisor real time report and see if the agent can take any more chats?

      I am suspecting that the agent is at full capacity but the ChatRouted returns success.

      You can also turn on Add-in logging to check add-in behavior. Please follow the steps below:

      1. From the console, click the system menu (the red icon at the top left)
      2. Select 'Add-in Logging->View Current File'
      3. In the screen that pops up, set Component Logger to Verbose

      At this point you should see any Add-in log messages, most important when a chat has been routed to the agent, there should be a log message like you see below:

      OnEngagementAssignmentEvent - ChatEngagementAssignmentEventArgs
         Contract: RightNow.AddIns.HostSideAdapters.ChatEngagementAssignmentEventArgsViewToContractAdapter
         EngagementId: 11
         MustAccept: False
         Type: LEAD
         EngagementCreateTime: 8/5/2013 4:18:45 PM
         EngagementFirstEngagedTime: 8/5/2013 4:27:01 PM
         QueueId: 1
         SecondsEngaged: 423
         ContactInfo: RightNow.AddIns.AddInSideAdapters.ChatContactInfoContractToViewAdapter
         AgentInfo: 
         ResponseAction: NONE
       
      If you do not see that, then probably something went wrong and you should first verify if the agent is at full capacity.
       
      Hope this helps and please let us know what you find out.
       
      Thanks,
      Sridhar
    • Jared

      Sridhar,

      This is all very good information. Thanks for the lead on Max Sessions for Chat, as it was not something we suspected. This might explain why the issue doesn't occur in our dev lab, but does in a production environment.

      We're using UQ routing to send 2 chats at a time, and had Max Sessions set for 3 on at least one of the profiles involved, but it may have been set lower on one of the other profiles. There was another issue involving some chats which would not close out of the workspace (I'll open another post for that), although they had been closed out in the UQ system by then. It's likely in this circumstance that the agent could have received too many chats and Max Sessions was involved.

      I will enable logging as you recommended, and make sure the Max Sessions is 3 for all profiles even though we're only sending 2 at a time, and keep an eye out. I will post to this thread again when we have more data.

      Thanks again for the very detailed information!

      -Jared