Debugging IP IVR script
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-11-2014 08:28 AM - edited 03-15-2019 06:03 AM
I have a script that we use to automate activating gift cards. The caller calls in presses 1 to activate the gift card, collects the digits, makes a SOAP call out to activate the card, a balance is returned and the call ends. This process works for our test gift card but does not work for any other gift cards. My initial thought was that the card umber was hard coded, but its not.
I do not get a response at all when trying to activate a newer gift card. My test gift card starts with 6074 and the new ones start with 6097. The soapResonseString stays "null"
My developer would like me to debug the service call and see what the full http response is, but I do not know how to o this.
- Labels:
-
Other Contact Center
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-11-2014 11:30 AM
Hi.
Er... this is a bit vague. Can you tell me the way you are contacting the SOAP server? Could you please post your SOAP client code?
G.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-11-2014 12:39 PM
Kind of new to some of this...
Is this what you are looking for?
{
java.io.ByteArrayOutputStream baos = new java.io.ByteArrayOutputStream();
String content = soapRequest;
int readTimeout = 12000;
try {
java.net.URL url = new java.net.URL(soapServiceEndpoint);
java.net.HttpURLConnection urlCon = (java.net.HttpURLConnection) url.openConnection();
urlCon.setFixedLengthStreamingMode(content.length() );
urlCon.setReadTimeout (readTimeout);
urlCon.setDoInput (true);
urlCon.setDoOutput (true);
urlCon.setUseCaches (false);
urlCon.setRequestMethod("POST");
urlCon.setRequestProperty("Content-Type","text/xml;charset=UTF-8");
urlCon.setRequestProperty("SOAPAction","http://nsm.searssiding.com/giftcard/IGCActivate/Activate");
java.io.DataOutputStream output = new java.io.DataOutputStream(urlCon.getOutputStream() );
output.writeBytes(content);
output.flush();
output.close();
java.io.DataInputStream input = new java.io.DataInputStream(urlCon.getInputStream() );
int bufSize = 4096;
byte[] bytesRead = new byte[bufSize];
int bytesReadLength = 0;
while(( bytesReadLength = input.read( bytesRead )) > 0 ) {
baos.write(bytesRead,0,bytesReadLength);
}
input.close();
baos.close();
} catch (Exception e) {
e.printStackTrace();
return null;
}
return baos.toString();
}
I was able to resolve my issue with the script, but I would like to know how to better debug in the future.
For this instance where it says " e.printStackTrace();" I walk told to change it to "return e.getMessage();" ran a reactive debug and was returned a time out error instead of just null.
From there I was able to change "int readTimeout =" to 12000 instead of the 5000 it was set to.
My question from here is moving forward what traces and log levels would I need to get this information from within RTMT? I had no way to know what that null result was. It says e.printStackTrace but I do not know where it would have written to.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-12-2014 03:09 AM
Hi,
actually, the author of the above code block is me and I believe returning null when an exception happens is better than returning the error message (the return value of e.getMessage()). the printStackTrace method gives you all the details, not just the top line.
It's very important to notice that printStackTrace sends the error message including the stack trace to stderr, which is in case of UCCX directed to MIVR/stdout.log (I guess via log4j). In Plain English, the only file you need to watch here is MIVR/stdout.log for the messages printed by printStackTrace().
Let me demonstrate:
I simply created a new script with one Do step, containing the following code block:
{
try {
throw new RuntimeException("Boooo!");
} catch (Exception e) {
e.printStackTrace();
}
}
This basically throws and catches an exception.
I also ssh'd to the UCCX and issued the following command:
file tail activelog uccx/log/MIVR/stdout.log
I don't even need to call in, debugging the script from the CCX Editor is sufficient.
Now, what I can see is a bit chatty but I can see all the details:
Nov 12 11:57:01.597 CET: *** keepalive is called...
java.lang.RuntimeException: Boooo!
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.cisco.expression.impl.ConstructorImpl.evaluate(ConstructorImpl.java:714)
at com.cisco.expression.Expression.valueOf(Expression.java:275)
at com.cisco.expression.impl.Throw.evaluateStatement(Throw.java:263)
at com.cisco.expression.impl.Try.evaluateStatement(Try.java:494)
at com.cisco.expression.impl.StatementImpl.evaluate(StatementImpl.java:170)
at com.cisco.expression.Expression.valueOf(Expression.java:275)
at com.cisco.expression.Expression.evaluate(Expression.java:1859)
at com.cisco.wfframework.steps.core.StepDo.execute(StepDo.java:75)
at com.cisco.wfframework.obj.WFBeanStep.executeImpl(WFBeanStep.java:141)
at com.cisco.wfframework.obj.WFStep.execute(WFStep.java:174)
at com.cisco.wfframework.obj.WFWorkflowTask.executeStep(WFWorkflowTask.java:494)
at com.cisco.wfframework.engine.core.WFEngineWorkflowTask.executeStep(WFEngineWorkflowTask.java:122)
at com.cisco.app.impl.WFWorkflowAppDebugTaskWrapper.executeStep(WFWorkflowAppDebugTaskWrapper.java:416)
at com.cisco.wfframework.engine.core.WFEngineWorkflowDebugTask.step(WFEngineWorkflowDebugTask.java:125)
at com.cisco.wfframework.engine.rmi.RemoteWorkflowTaskImpl.stepAndReturnConnection(RemoteWorkflowTaskImpl.java:121)
at com.cisco.app.impl.ApplicationManagerImpl$2$2.stepAndReturnConnection(ApplicationManagerImpl.java:833)
at sun.reflect.GeneratedMethodAccessor219.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
I see the type (class) of the Exception - RuntimeException (the exception I threw).
I see that very professional message (Boooo!)
I see that the exception happened within a Do step (c.c.wfframework.steps.core.StepDo.execute) evaluating the value of an expression.
Okay, now let's take a look what e.getMessage() gives me. I changed the code block to this:
{ try { throw new RuntimeException("Boooo!"); } catch (Exception e) { s = e.getMessage(); } }
s being a simple String variable, of course.
Now when debugging the script, the value of s became "Boooo!". That's it. I don't know anything about the exception itself. I can see only the error message the programmer decided to give to me. Which is, between us, not helpful at all.
G.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-12-2014 04:59 AM
Gergely,
Thank you for taking the time to explain this to me. I did happen to change the code back to it's original state and now that I know which log to watch I should have no issues in the future.
