cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
772
Views
0
Helpful
3
Replies

Setting Call Variables for Consult Calls

limingq2010
Level 1
Level 1

In Finesse JavaScript API, dialog.makeConsultCall does not allow you to assign call variables (user.makeCall does not let you do that either, but at least the web service API counterpart lets you do that if it is a UCCE setup). The only way to set call variables seems to be waiting for the dialog for the consult call to get created, and the call variables can be updated once the handleNewDialog callback is hit with that new consult call dialog entity.

 

Since the process is asynchronous, when you have to deal with multiple call legs at the same time, it's hard to reliably correlate the context of dialog.makeConsultCall at the time and the future new dialog object. What is the best practice of setting call variables for consult calls? I would appreciate it if someone can provide us some guidance on this.

1 Accepted Solution

Accepted Solutions

dekwan
Cisco Employee
Cisco Employee

Hi,

 

Unfortunately, there isn't a good way to do it. You pretty much have to wait until after the call is established and when the UPDATE_CALL_DATA action is listed as an allowable action. You are correct that if you have multiple calls, it is hard to correlate. You can always check the callType of the call and see if it is CONSULT.

 

Thanx,

Denis

View solution in original post

3 Replies 3

dekwan
Cisco Employee
Cisco Employee

Hi,

 

Unfortunately, there isn't a good way to do it. You pretty much have to wait until after the call is established and when the UPDATE_CALL_DATA action is listed as an allowable action. You are correct that if you have multiple calls, it is hard to correlate. You can always check the callType of the call and see if it is CONSULT.

 

Thanx,

Denis

Thanks for the reply Denise. Some programming APIs would let you pass a customized reference value to the calls that are asynchronous in nature, and when the response is ready, it passes that same reference value back in the response body. It makes it much easier to pair up the requests and responses when they take place asynchronously and in parallel.

 

Hope Cisco would consider mechanisms like this in future versions.


@limingq2010 wrote:

Thanks for the reply Denise. Some programming APIs would let you pass a customized reference value to the calls that are asynchronous in nature, and when the response is ready, it passes that same reference value back in the response body. It makes it much easier to pair up the requests and responses when they take place asynchronously and in parallel.

 

Hope Cisco would consider mechanisms like this in future versions.


Finesse actually has that with the <requestId> in the REST API request. But when you use the Finesse JS API, this requestId is automatically populated for you. I tried to see if there was a way to override it and provide your own, but wasn't able to find anything.

 

While writing the above response, I just remembered that the Finesse JS library doesn't have the update call variable built in and you need to use the REST API to do it. In this case, you can probably send it yourself. Take a look at this sample gadget: https://github.com/CiscoDevNet/finesse-sample-code/tree/master/UpdateCallVariableDataSampleGadget It doesn't send the requestId, but you can modify it to do so.

 

Thanx,

Denise

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: