UCCX: Issue Updating Custom Variables (Update Dialog, UPDATE_CALL_DATA)

[jdiegmueller]

I am attempting to update a custom variable field (specifically, callVariable1) from an external CRM system.

This works if I authenticate as the Agent's username/password, but fails if I attempt to use a service/Administrator account -- the failure scenario is slightly different depending on the UCCX version:

* UCCX 10.6(1): Finesse Tomcat returns HTTP 202 Accepted, but no change is made.  I traced this to CSCut86977, and was advised by TAC to upgrade to 11.0(1) as it contains the fix.  However,

* UCCX 11.0(1): Finesse Tomcat returns HTTP 401 Unauthorized, and does not make the change.

Obviously it won't be possible for the external CRM system to authenticate as the Agent as it doesn't know the Agent usernames/passwords (nor do we want it to). 

Is there another way to have an external system update the custom variable fields that I am overlooking?

-jd

[dekwan · Accepted solution]

Hi,

Unfortunately the only user that who is authorized to use this REST API is the agent's who are on the call per spec: https://developer.cisco.com/docs/finesse/#!dialogupdate-call-variable-data 

Per spec the security constraints for that API:

Agents can use this API.

Agents can only act on a participant of a dialog when they are that participant.

Is it possible to have the call variable update happen on the agent's desktop itself? Or is the new value to be updated grabbed from the CRM?

Thanx,

Denise

[jdiegmueller]

Denise--

Thank you for weighing in on this.

Unfortunately the only user that who is authorized to use this REST API is the agent's who are on the call per spec: https://developer.cisco.com/media/finesseDevGuide2/CFIN_RF_D91DEB3D_00_dialog-update-call-variable-data.html

Per spec the security constraints for that API:

Agents can use this API.

Agents can only act on a participant of a dialog when they are that participant.

Is there a reason for this restriction?  Perusing old forum posts, I see quite a few other folks have run in to this same limitation over the years and have expressed desire for an Administrator user to be able to update a Dialog.

Is it possible to have the call variable update happen on the agent's desktop itself? Or is the new value to be updated grabbed from the CRM?

Maybe?  I'm certainly open to your suggestions:

The application is that there are ~300 (and growing) different "programs" that a call might be for, and after much discussion it has been determined that there is no way to identify this information upfront -- ie, the Agent has to work that out by working with the caller.

My thought was to scribble the program in to the custom variable 1 field for the call, and then extend the CUIC CSQ reports to allow us to also filter on the custom variable 1 field (the "program"). 

My initial solution mock-up for this used a Gadget which presented a drop-down list of programs which was generated by querying the CRM system (to allow us to maintain correct id:program mappings, and to populate new programs without any administration on the UCCX/Finesse side of things) and to simply scribble the selected program's id in to the custom variable 1 field.  I then used CUIC Premium to extend a handful of CSQ reports to allow the user to filter on program (or programs), and imported those in to the co-resident/onbox CUIC.  So far, so good as all of this pieced together quite well.

However, after demonstrating this setup to the contact center staff, they expressed concerns with this approach since it was a separate "bag on the side" that the Agent would have to switch back to and execute on once they sorted out which program the caller was calling about.  In short, they were concerned about the human factor associated with this manual approach. 

The CRM developers suggested that if I would make a REST call to them informing them when a new call started (ie, tell them which Agent was on a new call, and providing them with the Dialog id) that they could make a REST call back to us once the Agent selected a program within their normal application/workflow.  We got very excited about this approach since it gave them all of the benefits of the granular reporting, but without needing to change the Agent workflow at all ... but as we're finding out here, this approach won't work due to the restriction outlined above.

As for your suggestion of having the client make that request, that's certainly possible -- but how will the CRM system alert the client that a program has been selected, and that it is now free to make a REST call to determine the program?  The only alternative I could think of was to continuously poll every few seconds -- and in an environment that peaks at around 150 active calls, I have a hunch the CRM developers will not be receptive to that approach.

Any suggestions on how to solve this?

-jd

[jdiegmueller]

My initial solution mock-up for this used a Gadget which presented a drop-down list of programs which was generated by querying the CRM system (to allow us to maintain correct id:program mappings, and to populate new programs without any administration on the UCCX/Finesse side of things) and to simply scribble the selected program's id in to the custom variable 1 field.  I then used CUIC Premium to extend a handful of CSQ reports to allow the user to filter on program (or programs), and imported those in to the co-resident/onbox CUIC.  So far, so good as all of this pieced together quite well.

I wanted to keep this separate from my initial response, but did want to add:

In addition to the restriction associated with updating the custom variables associated with an inbound ACD (voice) calls, I was hoping to do something similar with SocialMiner Chat and Email queues as well.  Although there are references in the Finesse Web Services Developers Guide to Dialogs being of mediaType Voice, Email, or Chat, it appears that in UCCX that Email and Chat are not actually Dialogs (ie, if I GET /finesse/api/User/agent1/Dialogs when the Agent is on an active chat, I get nothing back). 

I presume this is expected, as well?

Is there any other means to interact with chat and emails in UCCX 11.0(1)?  I was hoping to do something similar to what I described in my previous note (scribbling a program id in to the custom variable 1 field) but that idea appears to be a non-starter.  Are there any other ways to associate metadata with a chat/email that we could use for more granular reporting?

-jd

[dekwan]

In addition to the restriction associated with updating the custom variables associated with an inbound ACD (voice) calls, I was hoping to do something similar with SocialMiner Chat and Email queues as well.  Although there are references in the Finesse Web Services Developers Guide to Dialogs being of mediaType Voice, Email, or Chat, it appears that in UCCX that Email and Chat are not actually Dialogs (ie, if I GET /finesse/api/User/agent1/Dialogs when the Agent is on an active chat, I get nothing back). 

I presume this is expected, as well?

Yes. This is expected. In Finesse 11.0 and below, it only handled dialogs of voice media type. I am not 100% sure if there has been a change for Finesse 11.5 for UCCX.

Is there any other means to interact with chat and emails in UCCX 11.0(1)?  I was hoping to do something similar to what I described in my previous note (scribbling a program id in to the custom variable 1 field) but that idea appears to be a non-starter.  Are there any other ways to associate metadata with a chat/email that we could use for more granular reporting?

Not through Finesse. This is very heavy, but you would have to listen to all of the CTI Server messages from CCX to get the information about the email and chats and then use the CTI Server request to update the call variable data. This isn't a simple thing to do though.

Thanx,

Denise

[jdiegmueller]

Not through Finesse. This is very heavy, but you would have to listen to all of the CTI Server messages from CCX to get the information about the email and chats and then use the CTI Server request to update the call variable data. This isn't a simple thing to do though.

To be clear, you're referring to the API documented here?:

* https://developer.cisco.com/docs/contact-center-express/#!cti-protocol-dev-guide 

Indeed this appears it would bit more of an undertaking, but I might try kicking the tires on such an approach in Java.

I'll start skimming through the Developer's Guide (https://developer.cisco.com/docs/contact-center-express/#!cti-protocol-dev-guide ).

Thanks for your thoughts on this.

-jd

[dekwan]

To be clear, you're referring to the API documented here?:

* https://developer.cisco.com/docs/contact-center-express/#!cti-protocol-dev-guide 

Indeed this appears it would bit more of an undertaking, but I might try kicking the tires on such an approach in Java.

I'll start skimming through the Developer's Guide (https://developer.cisco.com/docs/contact-center-express/#!cti-protocol-dev-guide ).

Correct. Thats it, except it seems like they don't have the docs for 10.6 and 11.0. I will hopefully get that updated soon. The protocol didn't really make too many changes between 10.5 and the latest so I think using the 10.5 one is fine.

Thanx,

Denise

[dekwan]

Hi,

I don't know why I didn't think of this the other day when I said email and chat needs to be done via CTI server messages, but updating the call variables can actually be done through the CTI server messages too (and does not need agent credentials). So although it is very heavy, it would accomplish everything you want to do.

So if this route was taken, the CRM (server) would have to establish the CTI server connection and would essentially be listening on the CTI Server messages(events). You can actually figure out when a new call is started for an agent using these events so you would need the REST call from the desktop to CRM to inform them of the new call. Then when the CRM gets the program update, it can call the SET_CALL_DATA_REQ to update the call variable to the program.

I think this is a heavier (and more difficult) but cleaner design.

Thanx,

Denise

[jdiegmueller]

I don't know why I didn't think of this the other day when I said email and chat needs to be done via CTI server messages, but updating the call variables can actually be done through the CTI server messages too (and does not need agent credentials). So although it is very heavy, it would accomplish everything you want to do.

So if this route was taken, the CRM (server) would have to establish the CTI server connection and would essentially be listening on the CTI Server messages(events). You can actually figure out when a new call is started for an agent using these events so you would need the REST call from the desktop to CRM to inform them of the new call. Then when the CRM gets the program update, it can call the SET_CALL_DATA_REQ to update the call variable to the program.

I think this is a heavier (and more difficult) but cleaner design.

Denise--

Thanks again for weighing in on this.  I particularly appreciate this add-on comment because -- depending on how challenging I found implementing the UCCX CTI protocol in Java -- I was going to consider having a server handle both the voice and chat/email cases since it would provide a single interface to the CRM application.

I'll likely start trying to dig in to this tomorrow; thanks again for the pointers.

-jd

[dekwan]

Hi,

Is there a reason for this restriction?  Perusing old forum posts, I see quite a few other folks have run in to this same limitation over the years and have expressed desire for an Administrator user to be able to update a Dialog.

I don't think that there is a reason for the restriction, but more of a design choice at the time it was built.

Thank you for that detailed information about your setup and what you are trying to accomplish. It helps me give you specific suggestions.

The CRM developers suggested that if I would make a REST call to them informing them when a new call started (ie, tell them which Agent was on a new call, and providing them with the Dialog id) that they could make a REST call back to us once the Agent selected a program within their normal application/workflow.

Can you get (or give) clarification on what it means for "that they could make a REST call back to us once the Agent selected a program"? This usually means that there is some sort of notification service (similar to the Finesse notification service) where the CRM will push notifications to whoever is subscribed/listening. Is this the case? If so, would the selected program text be in the notification too? If not, then polling would be the only solution and I agree that is too clunky and a performance drain.

If there is indeed a notification service, you can build a gadget for the Finesse desktop where it subscribes/listens to the CRM notification. Assuming that the selected program is in the notification, the gadget can take that value and call the Call Variable Update API.

On a side note (unrelated to your question), is this CRM a thick client or a web-based one? One of the beauties of Finesse is that you can integrate the CRM into the Finesse desktop so that agents don't have to flip between applications.

Thanx,

Denise

[jdiegmueller]

The CRM developers suggested that if I would make a REST call to them informing them when a new call started (ie, tell them which Agent was on a new call, and providing them with the Dialog id) that they could make a REST call back to us once the Agent selected a program within their normal application/workflow.

Can you get (or give) clarification on what it means for "that they could make a REST call back to us once the Agent selected a program"? This usually means that there is some sort of notification service (similar to the Finesse notification service) where the CRM will push notifications to whoever is subscribed/listening. Is this the case? If so, would the selected program text be in the notification too? If not, then polling would be the only solution and I agree that is too clunky and a performance drain.

If there is indeed a notification service, you can build a gadget for the Finesse desktop where it subscribes/listens to the CRM notification. Assuming that the selected program is in the notification, the gadget can take that value and call the Call Variable Update API.

There is not currently a notification service -- these were just some conceptual ideas that we were kicking around.  "Make a REST call back to us", in the context I used it, was meant to signify that the CRM would simple make a call against the Finesse REST API.  So there would be a few different code paths in the CRM that could lead to a program being selected, and once that happened they would come along and update the Dialog (which won't work for the reasons we've already covered). 

Having said that, I do believe there is willingness on both sides to invest some development time in order to make this successful.  As you probably ascertained I am not a developer by trade but have been slowly taking on more custom development-oriented tasks and projects, so I do not yet have a handle on what all of the various options that are available to me entail nor am I always using the right lingo.  Is there a sample gadget that demonstrates what subscribing/listening to a notification would look like?  I understand how to make a client-initiated call to a web service (such as in the "WebService Sample Gadget 2.0"), but I am not following how I would have the Finesse client subscribe to a notification on the CRM server such that it would alert the client to a change in real-time.  Are you suggesting that the Finesse client would subscribe to the notification service, and the notification service could perform an HTTP PUT to the client once a program is selected?  If yes, I was unaware that the Finesse clients could be directly acted upon from a third-party application and it sounds like that would be the way to go.

Again, thanks for any/all input.

-jd

[dekwan]

As you probably ascertained I am not a developer by trade but have been slowly taking on more custom development-oriented tasks and projects, so I do not yet have a handle on what all of the various options that are available to me entail nor am I always using the right lingo.

Then this is the right place to be! DevNet is all about helping existing developers as well as teaching non-developers how to code.

Is there a sample gadget that demonstrates what subscribing/listening to a notification would look like?  I understand how to make a client-initiated call to a web service (such as in the "WebService Sample Gadget 2.0"), but I am not following how I would have the Finesse client subscribe to a notification on the CRM server such that it would alert the client to a change in real-time.

Unfortunately there isn't a sample gadget to do this. I will put it in the backlog of potential sample gadgets. What I am suggesting is to have the Finesse gadget subscribe (or listen depending on what CRM would expose) to get notifications/events. It is the same idea as the Finesse notifications where you would get an event when the agent changes their state. When the CRM detects that the agent made a change to the program, it would publish an event to whoever is subscribed (which would be the agent). The gadget code will receive the event and handle it in whichever way, in this case call the update call data API.

Are you suggesting that the Finesse client would subscribe to the notification service, and the notification service could perform an HTTP PUT to the client once a program is selected?  If yes, I was unaware that the Finesse clients could be directly acted upon from a third-party application and it sounds like that would be the way to go.

It isn't the notification service that will perform the HTTP PUT. It will send an event/message back to the gadget and the gadget itself will take the event that contains the program and perform the HTTP PUT.

The CRM application would basically be similar to the Finesse notification service on a way smaller scale.

I hope that clarifies it.

Thanx,

Denise