Web Services with Finesse 10.5 and UCCE Packaged

[Luis Enrique Perez Trujillo]

Hi, We installed a new Packaged UCCE 10.5 for 20 agents, We need communicate the UCCE with third party through Web Services, it's our first installation and I don't know very well the solution when integrate Web Services.

In the implementation I have Finesse 10.5 for both sides.

Can you help me with any experience or documentation?

I hope your comments.

[ptindall]

Mario,

The only way you can do this at the moment it to use the shadow queue approach behind CVP.  There's a doc attached describing the approach.

Paul

[mario.covarrubias]

Hi Paul,

Thanks for your help. Reviewing the doc you attached it seems that it might help us to achieve the goal that is needed.

I explain the situation a little bit more. We need to obtain the list of calls in queue when the following events occur:

• A call is added to the queue.
• The call is removed from the queue.

Basically what we need is to have an updated list of the calls in the queue every time one of the events listed occur. As I said, it seem your proposal might be helpful. The data that we need for each call in queue is the callerID and the uniqueID of the call (which in Finesse is the dialogID).

Checking the database table structure specified in the doc, I have some questions in which we need help:

• The field callid would be equivalent to the dialogID from Finesse, is this assumption correct?
• Is there a way to get the callerID from the data that ICM sends to CVP, so it can be stored in the database table also?

Also, to know a little more about this... what kind of data can we obtain from the GetSessionData in CallStartAPI and CallEndAPI classes? Where can we se the estructure of these classes (CallStartAPI and CallEndAPI)?

Your help is greatly appreciated.

Thanks,

Mario

[ptindall]

Mario,

Provided you use a CVP Call Studio application to provide your call queuing treatment, the custom call start and call end classes can be used to insert and remove call entries from a named virtual queue.  So, this will give you the list of calls in queue, updated on the enqueue/dequeue events, provided you invoke the Studio app once you've queued the call and provided you leave it there until the agent is selected or the caller abandons.    The virtual/shadow queue can reside in any data repository you wish; in this example, a simple SQL database was used as that's what most people are familiar with and it's quick to implement for a quick proof of concept.

The callid variable available in CVP comes from the Cisco-Guid SIP header on the incoming call to CVP and is also the same as the CallGUID and media_id ECC variables available to ICM scripts.   If you need to do any joins and correlation between the call at the desktop and the CVP data, just use that ID.   The Finesse DialogID is derived differently and won't match the CVP callid but I don't see why that would pose any problems.

The caller's number is already available to the CVP application by default as one of the standard call data variables so you don't need to pass that explicitly from the ICM script.  If you want to also include the original called DNIS in your calls in queue list you can access that in CVP via the _dnis session variable.  Once you've created the shadow queue entry in the start call class you can use the CVP application and database element to add/modify data in the queue database record to make visible absolutely anything you wish regarding the call and what has happened while the caller is in queue.   You don't have to do everything in Java; the custom classes are only necessary to provide start and exit handlers and can be coded to do the minimum necessary just to make the mechanism work.

CVP session data contains a number of fixed variables by default plus anything you choose to store for your own purposes in the CVP application.  You can read and write session data using the standard application elements and don't normally have to do it from Java.   Essentially, session data is just held in a Java HashTable with the data item name as the key.

To get more info on the start and end classes you should look at the CVP Javadocs which you can pick up from the doc folder on the CVP server down the C:\Cisco\CVP\... path.   Also, the DevNet CVP developer area includes getting started info.

Hope that satisfies your immediate questions.

Paul

[mario.covarrubias]

Hi Paul,

Thanks again for your support. We have been considering your advices although to be honest, there are some blank spaces in what we can understand because we are new in developing with ICM or CVP Studio. Even after we have reviewed developer guides and other Cisco documents, it hasn’t been easy to understand how to implement the Shadow Queue, maybe we lack experience…

There are a few more questions that have emerged:

• In the CVP-Shadow-Queue.pdf file, it is mentioned that, to insert and delete entries from the shadow queue in the database, we can modify the On Start Call and On End Call Java classes in order to add the necessary code for connection and the corresponding action in the repository configured as a JNDI datasource. The question here is: If we perform these changes in the java classes, are we in some kind of risk of losing Cisco PCCE’s support for changing this code?  We don’t know if Cisco might take it as a change in the elements of PCCE…
• The shadow-queue works as a parallel (copy) queue? I mean, even if there is queue data in the external repository, does the ICM still has its own queue data or the full queueing control need to be passed to the CVP application?
• How do we need to configure the Run External Script in order to pass the control to CVP Studio application?
• In the CVP application, is it enough to have the On Start Call and On End Call actions needed to insert and delete data into the external repository or do we need to configure more intermediate steps for queueing management?
• We understand that the On Start Call in CVP will execute the moment this application is invoked by ICM’s Run External Script, which we believe we need to configure to execute when the call is successfully queued to a skillgroup. The question is: the On End Call will be executed automatically when caller hangup or transfer to an agent, which means the call leaves the queue? The CVP application will detect this without us needing to explicitly call the On End Call?
• I think that our implementation considers 3 skillgroups (which should be identified by the dialed number configured for each in PCCE), and we might need to have calls queues for each of them. On ICM, when a call enters, and there are more than 1 skillgroup for queueing, is the call queued to the corresponding skillgroup depending on the dialed number associated to that skillgroup?
• Can we obtain the skillgroup name in which the call was queued, so we can send it as the qname for the repository?

I know it is too much to ask… but do you have an illustrative implemented example for the Shadow-Queue with ICM and CVP application? It can be a basic example and it doesn’t need to have real data, but it will really help us to understand better if we could see examples of the control flows that should be developed in both ICM and CVP Call Studio…

Again, thank you very much for all your help.

Mario.

[ptindall]

Mario,

Working down your questions list ...

• Nothing naughty or unsupported using the custom start and end call classes.   The hooks to invoke these custom classes exist to allow you to do any application specific processing you wish at the beginning and end of calls outside of the normal application flow.  CVP Call Studio/VoiceXML is very powerful and flexible because of the way it supports customisation and extensibility.  Of course, you're responsible for what you do in custom classes but using custom classes is normal use of CVP API's.
• ICM is still in full control of the call queuing and routing.  The shadow queue is simply a cosmetic data representation of the items in queue.  The join between the two is achieved via the CVP data actions you perform; there's nothing else that couples the virtual/shadow queue and the real queue.
• This is exactly the same as using Run Ext Scripts to invoke any other CVP Studio app and is done as documented in the CVP guides.  Use the GS,Server,V microapp and pass application name, queue name and any other data via the ToExtVXML variables in the normal way.
• You can do everything required in the Start and End Call classes.  However, if you wanted to add/update other information so it's visible in the shadow queue entries such as options the customer selected within the app you could do that simply using the normal database element from within the Studio app.   If you were using the shadow queue to track and play back queue position, you would have to make intermittent DB queries to get the latest position.  So, any other access is down to your particular use case.
• You don't explicitly invoke either Start or End Call classes; these are configured in the application properties to be executed on the call events as appropriate.  In fact, what makes this whole approach possible is the End Call class because it is invoked however the call ends and is the only way to intercept that event and add your own processing.   Without that, we'd not be able to remove an entry from the shadow queue as there is no way to intercept a call leaving queue and take control in the ICM or CVP scripts.
• In ICM, dialed numbers are not explicitly associated with skillgroups.  The mapping is DN --> Call Type --> Script.  The script Queue or Precision Queue nodes are what determine the skillgroups or attributes of the agent to which the call is routed.
• How you map the ICM queuing to the shadow queue representation is dependent on your particular use case and what makes sense to the operational people in terms of queue visibility but typically it would be done on call types or groups of call types which have the same ultimate routing treatment.  The virtual queue makes most sense if it contains entries that can all be satisfied by the same group or groups of agents.  Essentially, think of it as a bus queue; if you're observing it, it makes the most sense if all the passengers queuing are waiting to get to the same destination regardless of whether there is one or several different buses that can get them there.  So, I would start off using a queue name that is either the call type itself or a user defined name that maps to it.  If you have multiple call types all being handled the same then a common queue name across them all would make sense.

I hope this helps clarify things a bit more.   I will have a dig around but I don't think I have an example I can just export and send to you as the last time I did this myself was many lab systems/years ago.   Let me know if you have any more questions.

Paul