cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
18426
Views
106
Helpful
18
Comments
Anthony Holloway
Cisco Employee
Cisco Employee

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
A_
Level 1
Level 1

Yeah, here is an anonymized example.

In the context variable/part you can see your script variables.

[time] %MIVR-ENG-7-UNK:[MIVR_ENG_TASKS-31-4-TASK:scriptfile.aef] WFTracingLogImpl: Execute step of Task [number] : End 
[time] %MIVR-ENG-7-UNK:[MIVR_ENG_TASKS-31-4-TASK:scriptfile.aef] WFTracingLogImpl: >>>>> After execution
An object of com.cisco.app.impl.WFWorkflowAppDebugTaskWrapper
State: STARTED
Application: [anonymized, information about uccx application]
Trigger: ContactApplicationTrigger[anonymized, more information about trigger]
   An object of com.cisco.wfframework.engine.core.WFEngineWorkflowDebugTask
   ID: [id]
   Start time (ms): [time]
   Source ID: 
   Destination ID: 
   Media Instance ID: null
   Session handled: false
   Context:
   An object of com.cisco.wfframework.obj.WFWorkflowContext
   {
     {variableA, java.lang.Boolean, false}
     {variableB, java.lang.String, myStringValue}
     {variableC, java.lang.String, 00000}
   }
   Private Context:
   An object of com.cisco.wfframework.obj.WFWorkflowContext
   {
     {anonymized, few internal variables}
   }
   Number of executed steps: [number]
   Current step: End
<<<<<

 

ericksinho
Level 1
Level 1

@Anthony Hollowayis there a command to debug an app triggered by a HTTP instead of Call?

 

I have an HTTP triggered application I am trying to debug to find out whether it's working or not.

I went to CUIC "Aborted/Rejected report" and found some "Reject: Setup Timeout, Reject: Resource Busy, Reject: Resource Not Acknowledging" but have no idea what causes this behavior

Wonxie
Level 1
Level 1

very useful indeed

Getting Started

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: