UCCX 11.X Enterprise variables on abandon

[glenn.martindell]

Hello All,

I have a script in UCCX and am using enterprise variables to track what options callers press throughout the script so this can be reported on using CUIC.   I am writing my enterprise variables as part of the disconnect steps in the script.   I also have a contact inactive exception that send to the disconnect steps when a caller hangs up.  The script writes my enterprise variables fine as long as the caller stays on the line until all script steps execute correctly.   The problem I have is when the caller hangs up, none of my enterprise variables get written.   Is there a way to set enterprise variables on an abandon?

Thanks,

Glenn

[Sean Lynch]

I haven't tried this...  but try and switch the order of your steps.  After your GoTo label, first clear the exception then try the Set Enterprise step to get the variable data updated.   Just a shot in the dark...

Let me know what you find.  I may try this in my lab tomorrow...

Sincerely,

Sean

[glenn.martindell]

Hi Sean,

Thanks for the reply.  I made the switch and it is definitely better now but I still have gaps in what is and is not writing.   I'll keep investigating and see if I can determine what causes the writes to fail.

Thanks,

Glenn

[Sean Lynch]

Check the MIVR logs for indication of what is going on in the instances where data isn't written. Perhaps a delay step could be added prior to the terminate.

-Sean

[Anthony Holloway]

A quick side topic: Your use of the Terminate step in that particular case, where a caller has already hung up, causes an exception to be thrown, and your script aborts abnormally. I would recommend you have two different labels down there: One for when you want to disconnect the caller, and one for when the caller disconnects themselves. The former should have the terminate step, the latter should not.

Back to the main topic: I don't believe what you are trying to do is actually supported: writing to the contact record after it's been committed to the db_cra. You might be successful some of the time due to a race condition, but you'll likely never get it to be 100%.

See this similar defect: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvd37201

What you might want to do is, write the Enterprise Data sooner, if possible, predicting the outcome if a disconnect were to happen, and then when it doesn't, re-write it to the correct value.

Example:

/* Assumes Successful will be the outcome, and if it is, I needed to write this value ahead of time */
Set Enterprise Call Info (result = "transfer successful")
Call Redirect ("4000")
  Successful
    Set Contact Info (Handled)
    Goto End
  Busy
    Set Enterprise Call Info (result = "busy")
  Invalid
    Set Enterprise Call Info (result = "invalid")
  Unsuccessful
    Set Enterprise Call Info (result = "unsuccessful")

[Gregory Brunn]

Good advice as always Anthony. Me and Glen pinged each other on teams and this was my first question for him as well was why not write it sooner if he can.

[glenn.martindell]

Sorry for the delay responding and thanks to all that did respond.   I finally got around to making the changes in the script (putting a delay before the end step and separating with abandoned call treatment from my normal call disconnect) and the writes to the CPVs seem better.  I'll know better when there's a little more traffic tomorrow.

I never knew not to have a terminate step for abandoned calls so regardless of the outcome of my data writes, I learned something new.

Thanks again to all that responded

Thanks,

Glenn