cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

UCCX: Viewing Executed Script Steps via CLI

7398
Views
75
Helpful
10
Comments

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:

 

Step 1: Enable Engine Debugging

In order for this feature to work, you will need to enable ENG debugging under trace configuration within CCX Serviceability.

 

 

Step 2: SSH in to Master Node

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.

 

Step 3: Find the implId

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

 

Step 4: Find Application Task ID

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...

 

Step 5: Find All Script Steps

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...

 

Bonus Step: Find Key Presses

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

 

Bonus Step: Find Where You Transferred The Caller

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...

 

Bonus Step: Find the Agent Who Answered the Call

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.

Comments
Participant

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?

Participant

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 ?

VIP Mentor

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.

VIP Mentor

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
Participant

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 !

Enthusiast

Legend as always. Thanks Anthony.

Cisco Employee

Great stuff Anthony [+5]

Regards

Deepak

Participant

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

Beginner

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,

 

Beginner
Beginner

@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.

CreatePlease to create content
Content for Community-Ad

Cisco COVID-19 Survey