If so, does anyone have a simple example?
Solved! Go to Solution.
Thanks for the reply. This makes sense and may also help explain why, when i do my after hours testing, i can place 200 calls w/out issue, but during business they are seeing the problem. Response times may be slower during day....
I'll give your suggestion a try.
I know this is a very old post but does anyone know if I replace the finesse10.0.1 with 11.5 will it work in 11.5? since now there is a difference in the versions?
Unless anyone has this gadget for version 11.5 that can share :D
I think you already have your answer, but I will post it here for others. You can follow this blog to convert the gadget: How to convert your existing 10.5.1 custom gadget to work with 10.6.1, 11.0.1, or 11.5.1
If you get it working after following the steps, it would be great for you to post it for others.
Is working now althought there are a lot of modifications from the first gadget. The only thing I needed it to do was to modify the Call Variable and it does that.
The reason we need this is because we need to be able to identify all calls that are initiated from our system. Updating the call after it's been initiated works ok if the call succeeds; however, that method doesn't work if the call is made to an invalid number.
Any ideas if this can be achieved? I suspect not... We're using UCCE 11.6(1).
You can create a custom gadget that calls the REST API directly. Note that this is only available with UCCE, which you said you are using.
Thanks for your advice. I've tried that, and it works in so far as the call is initiated and the call variable is successfully set on calls that result in no answer or conversation. However, the call variable does NOT get set (i.e. it doesn't appear in Termination_Call_Variable) for calls that result in busy or unavailable. So this solution is actually worse than the method we're already using, which is to initiate the call and then issue an UPDATE_CALL_DATA REST request once the call has been initiated: this actually successfully sets the variable for busy, and some (but not all) unavailable calls.
Are there any plans to change this functionality, so that the call variable will ALWAYS get set no matter what the call outcome is?
All we're trying to do is to come up with a definitive way of identifying calls that have been initiated via our application, regardless of whether it's successful or not.
I will reach out to the Finesse team to see if this is a bug or if it is by design, if there are any plans to change the functionality. My gut feel is that this is a CCE design or issue because Finesse is usually just a pass through. Either way, I will check.
When you say Termination_Call_Variable, I assume you mean Termination_Call_Detail. If you did mean TCD, the CCE team told me that this is only set for calls made through the CTI route point. Are your busy and unavailable calls made through the RP?
If you really did mean Termination_Call_Variable, can you explain to me what that is and where you see that?
Yes, the Termination_Call_Variable table holds the expanded call variables. Here's an extract from the UCCE database schema guide: "The system software generates a Termination_Call_Variable record for each enabled persistent expanded call variable for every call processed at a peripheral." You can find the schema guide here: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/icm_enterprise/icm_enterprise_11_6_1/Reference/Guide/ucce_b_database-schema-handbook-for-cisco.html
Ah. Yeah, the ECC variables are also only stored if the call is made via the CTI Route Point (according to the engineer). In your scenarios, did the calls go through the RP?
The types of call I'm referring to are outbound calls made directly from the agent's extension - so no, they wouldn't be hitting a CTI Route Point.
Thanks - I kind of guessed that because my testing already showed that to be the case! So, as per my original post:
"The reason we need this is because we need to be able to identify all calls that are initiated from our system."
I'm taking it the answer is that this is just not possible, then.