06-20-2016 08:28 AM - edited 01-10-2019 01:55 PM
Sometimes it's nice to see which steps, a call executed, very quickly, without needing to recreate the call flow and performing a risky Reactive Debug session. Here are the steps to do so:
In order for this feature to work, you will need to enable ENG debugging under trace configuration within CCX Serviceability.
You are free to use any SSH client you like. Keep in mind that this is the platform administrator account, and not the same one you use for RTMT or CCX Administration. Although, in many environments the username and password pair are the same for all of these accounts. It's common for this username to be one of: Administrator, administrator, osadministrator, or osadmin. Note the case on the first two.
Start by running the following command to get the Implementation ID for the call, which we will use in the next step to find the Task ID. Replace the example phone number with your calling party number.
Command
file search activelog uccx/log/MIVR "call.received.*6125551000" ignorecase
Output
Output truncated...implId=4654465/3...truncated
Alternatively, you can search for your call by any of the following additional call attributes:
Trigger (Technically the same syntax as Calling Number, just give it the Trigger instead)
Alternate Command Using Trigger Number
file search activelog uccx/log/MIVR "call.received.*6125552000" ignorecase
Alternative Command Using Application Name
file search activelog uccx/log/MIVR "call.received.*YourApp" ignorecase
Alternative Command Limiting to a Date/Time match (December 27, 2016 in last 10 minutes of the 9 o'clock hour)
file search activelog uccx/log/MIVR "dec 27 09:5.*call.received" ignorecase
Find when the implId gets associated to the Task ID. Use the implId from the previous step, within this command, to find your Task ID. We'll then use the Task ID from this step, in the next step, to find all of the executed steps for this call.
Command
file search activelog uccx/log/MIVR "4654465.*associated" ignorecase
Output
trunc...MediaId:4654465/3 Task:42000000286 associated with Task ID: 42000000286...
Find all of the script steps your call executed by supplying your Task ID, from the previous step, in this command.
Note that Call Subflow borrows the same implId and Task ID, so you'll see Sub Flow step executing, an advantage over Reactive Debugging. (Hence the max executed step counter does not reset upon call subflow)
Also note that, a call which transfers from script to script will begin a new call, keep the same implId, but get a new Task ID, and therefore its own set of executed script steps. (Hence the max executed step counter resets upon transfer)
Command
file search activelog uccx/log/MIVR "execute step.*42000000286" ignorecase
Output
...Execute step of Task 42000000286 : Start
...Execute step of Task 42000000286 : Accept (--Triggering Contact--)
...Execute step of Task 42000000286 : Play Prompt (--Triggering Contact, P[hello])
...output truncated...
Find all of the received digit key presses from the caller. This can be useful for understanding what a caller selected, but also if you have a double digit DTMF issue.
Command
file search activelog uccx/log/MIVR "42000000286.*digit received" ignorecase
Output
...Digit Received: 1
Say the script was holding a transfer extension in a variable. While you'll see the variable name in the above steps, you will not see the String value. So, to get the extension you actually transferred the caller to, use this step in addition to the above.
Command
file search activelog uccx/log/MIVR "call.transferring.*implId=4654465" ignorecase
Output
...Call.transferring(2001) JTAPICallContact[id=5977,implId=4654465...
This is how you get the Agent User ID, name and extension who answered the call. So, tieing back into the above bonus step, there is a value in there that you'll need, which is the "session=" number. Let's pretend the number was 53000095261.
Command
file search activelog uccx/log/MIVR "contactconnectedevent.*rsrc name.*53000095261" ignorecase
Output
...ContactConnectedEvent Resource Rsrc Name:Anthony Holloway ID:aholloway IAQ Extn:+16125551212...
Thanks for reading. I hope this helps you.
EDIT [12/27/2016]: Took out a snarky comment, added more useful content.
EDIT [1/12/2018]: Added second bonus item for finding which number you might have transferred the caller to.
EDIT [4/4/2018]: Added third bonus item for finding which Agent you might have transferred the caller to.
EDIT [1/9/2019]: Fixed some incorrect language referring to the wrong steps, since I have since added more steps.
Anthony ,
this looks great , thanks !!! I am trying to find why step is not occurring and thought I would be able to use this.
The steps show fiel search activelog,,, is there a way to do this and get a log from 2 days ago?
Hi Anthony, I entered the command as stated above and got the following results:
admin:file search activelog uccx/log/mivr "Call.received.*62843" ignorecase
Unable to find any file(s) in path: /var/log/active/uccx/log/mivr
So does this mean I do not have turned on the correct debugging in UCCX Serviceability ?
The logs on your server are circular, and if you have a very busy system, then your history will not be very great. You'll need to increase the number of log files retained on the system, if you want to go back further OR decrease the amount of stuff being logged. E.g., Turn off certain logging levels you might have enabled once, way back when you worked a TAC case, OR simplify your scripting so you're not executing hundreds and hundreds of steps for every call.
You can adjust the amount of logs files kept on circular rotation from CCX Serviceability.
Looks like you lower cased the folder name MIVR. It's case sensetive, so keep it upper case.
Also, keep in mind that if you have two UCCX servers, then the logs are only being generated on the Master node.
Try this command on your Master node, to list all files ordered by date, minding case:
file list activelog uccx/log/MIVR detail date
Anthony,
Thanks !! that was it , I did not use the upper case, did not realize it would be case sensitive.
Ran it and got several days of mivr logs.
Appreciate your time and assistance !
Legend as always. Thanks Anthony.
Great stuff Anthony [+5]
Regards
Deepak
This is an excellent document I am trying to follow....so Thank you for writing this
just have quick question to ask you.....Does MIVR logs or any logs have info on variables during each steps of script execution?
I am trying to work on a problem where script steps select an agent based on calling number. My calls are going to wrong agents.
I am not too sure how to explain but if you have questions let me know. Thanks a lot
Great document I have a quick question hopefully, when running the following:
:file search activelog uccx/log/MIVR "call.received.*4258680331" ignorecase
or
file search activelog uccx/log/MIVR "oct 08 09:0.*call.received" ignorecase
I receive back:
Searching path: /var/log/active/uccx/log/MIVR
Search completed
Am I entering something incorrectly?
When entering:
file list activelog uccx/log/MIVR detail date
08 Oct,2019 08:38:45 192,193 Cisco002MIVR149.log.gz
08 Oct,2019 09:14:08 196,936 Cisco002MIVR150.log.gz
I get a long list of files, it appears the records are there?
Thank you,
@laubryYes, you don't have a file with a date of "09:0*". It should work with following:
file search activelog uccx/log/MIVR "oct 08 09:1.*call.received" ignorecase
You see that here:
08 Oct,2019 08:38:45 192,193 Cisco002MIVR149.log.gz 08 Oct,2019 09:14:08 196,936 Cisco002MIVR150.log.gz
So, a wildcard with 09:0* can't match.
Huge help! Do you know if there is a way to see the variables of a call in a script? E.g. when i have a database attached and the script selects a random entry from a table and stores it in a variable - how could i check afterwards what it selected?
Thanks for the reply - can you tell me what is the best way to download these log files? as they dont show up on tftp, is the only solution to host an sftp server and use "file get"?
Ah, i was able to download the log file via CoreFTP, but i couldnt find the "after execution" part containing variable names - i searched for the right log files as above, opened them, searched for a variable name but i found nothing. i enabled the debug log level of the service in the post above, i dont know of anything more i need to do - when you tested it, was the "After execution" part with the variables directly below the last executed step in the log?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: