Contents

Troubleshooting Tips

Use Log Event tool after Failure path

Add Log Event steps after most failure paths in order to log the error to the NT Event log. Errors logged this way are much easier to find than looking at trace logs. Use the "Error" log type sparingly. Use the "Warning" type instead unless the error is really bad. Identify the handler name in the text of every Log Event step by inserting a variable called HandlerName in the text. Also identify the previous step number that triggered the log event and a brief description of the possible problem. Please note that some telephony tools will follow the failure path even when no "real" failure occurred. The Extended Get Key, for instance, will take the failure path if the caller hangs up or is disconnected while the Get Key is playing prompts or waiting for input.

Use "Informational" log events to troubleshoot or verify handler functionality

"Informational" NT Event log messages can be created in a handler using the Log Event tool. Use them to verify important steps in a handler or track major changes or unique events in a handler. Can also be used to troubleshoot handlers by identifying failure paths or other unwanted behaviors. Use this method rather than debugging handlers or looking at trace logs. Create Assignment steps with HandlerName to find errors in Event logs more easily.

Use blank assignment steps at the end

For handler paths that end with multiple possible conditions or selections, insert a blank assignment step in order to facilitate troubleshooting. When debugging without these steps, it can be hard to determine which path is taken.

Set breakpoint in debug to skip over sections

You can turn any step into a breakpoint after a handler is already in debug mode. Your handler must already be in debug mode to set a breakpoint:

Right-click on the step you want to set as a breakpoint.
Choose Set Breakpoint from the menu that appears. The step’s color changes to red. When the debug handler runs, it will automatically stop at this step.

Use a condition step for cell phone ANI before debug step

To debug a handler on a live system that is receiving many calls, insert a Condition step before a Notify Debugger step that checks the ANI call information and matches it to your cell phone number. This will allow you to debug a live call without risking interrupting a customer call. Only your cell phone number will trigger the debug. Consider using a system parameter for the ANI string to avoid having to republish the handler when you want to change the debug trigger number.

Debug using custom notification

Trigger your subroutine handler for debugging using a Send Custom Notification command. Create a separate handler that has the Custom Notification initiator followed by your subroutine.

Use a Net Send to troubleshoot handlers

Insert an Execute Shell Command step with a Net Send command to quickly be notified of a troubleshooting event in a handler. Another option is to use email tools and send the event to yourself.

Learn how to read IP trace logs

Every handler developer should be familiar with how to read the information in the IP trace logs. This can often be the only way to troubleshoot handler problems. Often a handler will work when debugged, but fail when running in normal mode. An IP log will tell you exactly what was happening when a handler runs.

Write specific troubleshooting to trace logs

Use the Write Trace Message tool to indicate specific events such as conditions and selections you want to track in a problem handler. These steps are not shown in the trace log even at the highest "Notes" level of tracing.

Use a special viewer to read trace logs

Trace log files can often be quite large and take forever to open using regular word processors. PureConnect Customer Care uses Visual Slick Edit. It can quickly open large files and can do advanced searches.