Yesterday, I had a non-descriptive NullPointerException occur within a visual snippet sub-map in WebSphere Integration Developer. The only message written to the log was something that identified which transformation in the sub-map failed. There was nothing about what line was bad. Rather than filling my code full of “Got Here” and “Did this Runs”, I thought I would use the debugging capabilities of the tool.
I thought I would get the ability to move from one snippet to the next to identify the issue. It would have been even sweeter to get hot-code replace, but I don’t mind rerunning my testcase.
What I got was an exercise in bugs, pain and non-intuitiveness. I set my breakpoint at the first point in my visual snippet. The breakpoint popped. I then tried to step into the next line of the snippet and the debugger interpreted that as ‘Run to completion’ so I missed the point of failure.
I realized that I had to just keep manually setting breakpoints for any point where I wanted to stop. My snippet is quite large and finding a NPE is hard. It also took about 6-10 seconds to hit the next breakpoint in the chain. The editors would go crazy resizing and flipping between editors while this was happening.
I decided that the best approach was to use my breakpoints to divide my visual snippet in halfs, identifying which half was failing and then breaking it down even more. Of course, each re-iteration was a completely new invocation which took time.
I also experienced a few times where the breakpoint graphic was created (hello little dot) but it never popped anyway. Another invocation please.
Everything was just so painful and slow to run, that it took about an hour of running tests to figure out that the visual snippet editor didn’t initialize a value.
Next time? I’ll just put in the extraneous system.out’s and forget about even running the debugger again. For all my defenses of the tool and runtime, even I can’t defend how crummy the debugger is.
I also work with WID, WPS, WTX etc. in Healthcare domain. Your blog is really useful to me and I thank you for taking time in sharing your knowledge. Keep up the good work.
Hi Akram,
Thanks for the kind words. I’m glad you are able to find value in what I have to offer.
Hi,
it was one of the first things I noticed when I started to develop in WID – the debugger is absolutely useless…
For debugging purposes we have to use many debug logs in our processes, sometimes it’s the only way to know what is really happening 🙂
Yeah, what I do is leverage WebSphere Tracing for my debugging. That way the code can go into production and get reused should a issue occur there.
Yeah, we also use higher levels of WebSphere tracing – just few days ago it helped us very much in identifying problem with built in staff verb “Group” – it seemed that it’s not working but thanks to trace we saw that although LDAP itself is case insensitive, the way WPS handles group names when using this verb leads to case-sensitive operation – trace was displaying sql queries that are used for access rights recognition and we immediately saw whats going on.
I also forgot to mention Audit Trail and Failed Event Manager which both can be used for gathering debug information
Debugging with WID’s debugger is a nightmare. If IBM is entertaining fantasies that building an application with WID is a faster and easier method compared to writing code, they are mistaken. One of the first things they need to realize is that the abiltiy to debug is essential to writing and testing complex applications.