Today, my favorite debugging tip is to use the F8 or Step Into function to step through each step in a MAP statement. Just use Trace-To-Here to get to the MAP step then either press F8 or click on the StepInto button.
Once the MAP statement opens to display the pipeline, you can press F7 to step through each mapping step or transformation.
I think this was introduced in one of the 6.x releases, but when I go long periods without wading through complex maps, I tend to to forget how handy it is.
What are your favorite debugging / unit testing tricks or tips?
Also when debugging document / literal soap message processing (custom soap processors or “wrapper” services). Creating a test driver in Flow that builds a soap message and then invokes your soap processor or wrapper service directly instead of using pub.client:soapHTTP allows you to trace through and step into the services that expect a soapRequestData object. Comes in handing for tracking down pesky issues related to extracting soap headers or payload elements.
This is more of a gotcha-checker than a debugging tip:
To check for active save/restorePipelines calls left by mistake after debugging, I right click the pub.flow:savePipeline or restorePipeline service in the WmPublic and ‘Check Dependents’.
I use the “check dependents” tip for pub.flow:debugLog as well, but my most frequent “dead code” mistake is to leave MAP statements in my code that populate test data.
Of course, religiously writing JUnit-like tests for each Flow that would take care of that problem.
Maybe, though, I could create a “mapTestData” service that just populates a variable with test data and then use your “check dependents” tip to find any of those that got missed.
My most embarrassing bug story is tracking down a defect to one of my unit testing MAP statements with the comment “TEST DATA - DELETE ME”. .
I quite like being able to save/load/modify/drop values from the pipeline in developer without having to change code. Useful when you want to simulate something breaking or returning a bad value.
Useful is to use tracepipeline with scope if you want to print out some document structure but have too much other mess in the pipeline.
In terms of using find dependents:
bytesToString and StringToBytes for encoding issues (e.g. to/from japanese or something)
restorePipelineFromFile (sign of bad coding practice if it’s ever in “real” services)
-if a certain service is throwing an exception in the logs, using find dependents usually narrows it down.
Bit more hacky: If you’re working with services that have soemthing other than String/IData/Integer/Float/Doubles Objects on the pipeline that show up as nulls when they actually have data in them: try adding that class to the classpath for the developer. That way the Developer will be able to show the toString() result for the Object which is probably more useful than “null”.
Java services when doing a bit of quick debugging I sometimes put a throw new ServiceException(“debug stuff here”) in certain cases. Other times I create a String that I add a bunch of things to then output in the pipeline. Anything too complicated I use an IDE and rig up a simple test harness.
A good one to find the SQL for an adapter service is to add in an extra parameter that you don’t have a “?” for… This will throw an exception containing the SQL so you can have a look at it (more practical than digging through logs set to some ridiculously high debug level).
Runaway services I like being able to kill it by reloading the package.
Oh and of course: WmUnit (new release yesterday) automated tests for catching all the stupid things when changing code…
Mark:
DELETE-MEs have this disconcerting habit, don’t they?
A small addition to Nathan’s idea:
> Java services when doing a bit of quick debugging I sometimes put
> a throw new ServiceException(“debug stuff here”) in certain cases.
If a ‘throw exception …’ is put in the middle of a Java service, you get an ‘unreachable statement’ error from the compiler. This is because the code after the ‘throw’ statement is never executed. A workaround is to fool Java by making the throw appear conditional (actually it isn’t) : if (true) {throw new ServiceException(“Step 3: var = !” + var); }
and fill the output entries to 32 lines. that is nasty to look at directly, but I wrap this service in another flow, when needed, with interfaces to better suit a particular use.
One layer is a thin one that does a single repeat on an execution failure. For me, it can be helpful for single transient failures.
I tend to bundle this service with a custom document list to string table service to make what seem like in memory tables of data to work with. Good day.
}
.