Hi,   Within the UCCE Database there is a Agent_Real_Time table that has a series of columns holding various times which I am querying.  E.g. DateTime,  DateTimeLastStateChange, DateTimeLastModeChange etc all of time DBDATETIME.     Are these timestamp values always guaranteed to be in GMT/UTC?  Or if I connected to another setup could these in fact be in any local timezone? (e.g. CET, EST etc).   I am looking at the Database Schema Handbook for Cisco Unified ICM/Contact Center Enterprise & Hosted but don't see any guidance around this specifically.     I would like to know so that I understand if I need to add logic to do a conversion or not if I script against another database not in GMT.   Thanks, Mark ... View more

Hi, To capture the values that a caller has input into IVR  (e.g. Caller gets a prompt to enter their customer ID)  previously on the Cisco Express API we were using a field on events CallerEnteredDigits that appeared to have caputured this data. On CTIOS I believe this was also a field that was exposed via the Call object. Is this field exposed on Finesse? If not would we just need to set the CallerEnteredDigits into one of the standard call variables (or set up a new ECC variable?) and get it from there via a Finesse dialog? Cheers, Mark ... View more

Hi, We are now looking at ensuring our 3rd party Finesse application handles HA fail-over scenarios correctly.  As I understand Finesse works similarly to CTIOS where there is a primary server and a secondary server.  The secondary server is there to kick in should the primary fail. On login currently we perform a SystemInfo call to ensure the primary server is IN_SERVICE and we then attempt to make the XMPP connection (using Smack API) to the primary server. Question - at the initial login stage should we also be logging the agent into the secondary server as well as the primary so they are already connected to both servers so that if one goes down we can seamlessly just switch to the other? I notice in the Cisco Finesse Web Developer guide there are a number of potential failover scenarios and notifications you may receive: Scenario Notification Cisco Finesse Notification Service goes down Client loses BOSH connection Cisco Finesse Tomcat goes down Finesse user presence is 'unavailable' Finesse loses connection to the CTI server Finesse sends SystemInfo notification of OUT_OF_SERVICE E.g. We are currently connected to primary finesse server... If our XMPP connection loses connection e.g. (Finesse Notification Service goes down) is the onus on our application at that stage to then switch the Rest API connection & notification service connection over to use the secondary server instead of the primary? If our we receive a presence unavailable for the Finesse user on the XMPP notification service connection e.g. (Finesse Tomcat goes down) is the onus on our application at that stage to then switch the Rest API connection & notification service connection over to use the secondary server instead of the primary? If Finesse loses connection to the CTI server and we get an OUT_OF_SERVICE event do we try to connect to the secondary at that stage? Or do we wait for some time and retry? Presumably there will be failover of the CTI server component behind the scenes. I might have more questions once I get into the deeper detail  but I'm just at the early stages of trying to work out what we need to implement in our code to allow our desktop to handle HA failover scenarios. Thanks, Mark ... View more

Hi, We are currently developing Finesse integration using SCCP-based Cisco IP communicator endpoints.  Does this have any bearing on the integration with Cisco Finesse?  I would assume not as the Finesse API/notifications would be agnostic to the protocol used for the endpoints. For example, if someone using our application were to set up SIP Cisco IP communicator endpoints instead of SCCP - then in theory our integration should continue to work seamlessly as there should be no difference in the notifications received from Finesse given the end point protocol has changed. Has anyone had any experience of using both of these protocol types for endpoints on Finesse?  Back when we were using CTIOS then I believe it was the case that this change led to events coming through in a slightly different order/ with different data on them that led to some issues with our integration code.  Just trying to get a feel for the risk level involved here if someone were to switch the phone setup. Thanks, Mark ... View more

Hi, I f an agent is on a call and the call data is updated by another agent then t he CTI server will issue a CALL_DATA_ UPDATE_EVENT to everyone involved in that call.  P reviously in CTIOS we would have have captured this event when it arrived at our agent and we would then notifiy our 3rd party desktop the call data had been updated.  Our application was then capable of going and getting the updated call data from CTIOS if it needed too. In Finesse things seem to work slightly differently - all the call data is sent on every Dialog notification that comes back.  In the above scenario the agent appears to simply receive a new Dialog notification object with the updated call variables but the same state, participant states etc in relation to the call.  This makes it difficult to identify the cause of receiving the Dialog notification to be due to the call data being updated.  Is this intended?  There looks like no easy way (a flag, or similar) on the Dialog notification to indicate that it is simply the call data that has been updated. Only option would be if we added logic on our side to continually check the call variables on each Dialog to determine if they have changed.  We could also try and update the call data on every dialog notification but that would be costly and wasteful if nothing has changed (which it hasn't in most cases). Just wondered if anyone else has encountered this or has an understanding of this.  How does the Finesse desktop deal with this scenario? Thanks, Mark ... View more