UCCX 10.6(1)SU2 SQL POC

[joeharb]

We have a need to do Database dips as we are replacing a product (non UCCX) that would offer specific information to an agent for the respective call.  I have read the compatibility matrix and noticed that SQL 2016 is not listed, does that mean it won't work or is not supported from TAC?  I am willing to do the upgrade of our UCCX but it will be a month or 2 as we have other 3rd party integrations that need to sign off on the upgrade.  I actually started the PUT tool upgrade process and reached out the other players to get the upgrade process rolling, but I need to have an answer if we will be able to provide the same functionality for the agents/reps.

Thanks,

Joe 

[Gregory Brunn]

2016 is listed as supported as of 11.62

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_compatibility/matrix/uccxcompat12_0_1.html

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_compatibility/matrix/uccxcompat11_6_2.html

[joeharb]

Thanks for the response...as I said I am willing to do an upgrade but that will most likely be a few months out, just trying to determine if we could perform a POC for 10.6.(1)SU2.

[david.macias]

I am sure that you will be able to get CCX 10.x to connect to a SQL 2016 DB. The reason why it's not in the compatibility matrix is that 2016 wasn't available when 10.x was released. That's my guess.

david

[Gregory Brunn]

a proof of concept on a unsupported version sounds like your just heading for trouble why not upgrade and then prove the integration or spin up a demo on 11.6 to prove the dip.

[Anthony Holloway]

Yeah I agree. @joeharb, If you've got the compute space available, the ISO from software.cisco.com is bootable and will provide you with like a 60 day demo license. Then you can POC the DB connection like my man Gregory over here is saying.

[joeharb]

I assume I would need to spin up both a cucm and uccx server?  

[Gregory Brunn]

No you can have multiple CCX per 1 CUCM. 

[joeharb]

I have installed a 11.6 version of UCCX and we are in the process of testing. I have a successful connection to the SQL server. Our main goal is to retrieve the customer name from the number called. The issue now is the use of a translation pattern to get the call to the script. I assume the only way to get the original dialed number is to create multiple triggers ( we are going to have a need for over 270 distinct dialed numbers) for the same application. I have not tried using a CTI route point at this time, but will tomorrow. Does anyone have a suggestion on the best way to implement this, I would prefer to do any “translations” via cucm.

Thanks

Joe

[Anthony Holloway]

I can't picture what challenge you face, and can elaborate or give examples?

[joeharb]

Our goal is to allow end customer to dial a specific number and our agents be able to answer accordingly to the number dialed. We hoped to have one application/script that could identify the DNIS and query sql to give us the proper name of the business that number is associated with. We provide the numbers to our customers which they display for support either in print or digital form, to their customers. We need to be able to see the dialed number in our script to correlate the dialed number to the respective customer so the agent answers appropriately.

[Gregory Brunn]

HYeah you so you can easily use different trigger numbers for each business unit to hit a switch statement that would set a different CSQ. If so translations are not needed but different triggers would be.

a get enterprise call info step can get dnis  and assign to variable you define. Same with ANI. No sql needed for that one.

Is your goal look up the customer ANI and provide the agent with information about them or

just to give different business units separate numbers to call into to route to different agents with different skills?

[Anthony Holloway]

So, if you give out 100 numbers, and you need to know which of the 100 was dialed, there's really only two ways to do this:

1) Create 100 different triggers

2) If their all contiguous, create 1 wild card trigger, like 32XX

I guess there's a third option, but it's really a hybrid of the two. You would create 100 Translations in CUCM, then have the potentially non-contiguous numbers translate to a contiguous range like 32XX, then in the DB have this extra number in there as a lookup value.

I guess there's one more twist on that last one, which is to instead of have the 32XX number in the DB, have the UCCX Script convert it back to the original number dialed just for the DB lookup. That sounds like a pain, because then you're maintaining the translation twice. I wouldn't recommend this option.

In fact, I would have asked during planning if we needed contiguous numbers for this project and then used summarizations to limit the patterns needed. Sometimes you get that chance, and sometimes not though.