Tuesday, May 28, 2013

Debugging a subscribe flow service without disrupting the existing pub-sub flow for other testing.

So I'm working on a pub-sub model and encountering errors.  To debug I had to disable the trigger to prevent new traffic while I'm debugging, change the pipeline from save to restore and then hold off any other testing from co-workers while I stepped through and made my changes.

It was far from ideal.

So I set out to make it better.  Instead of using the built-in save pipeline and restore pipeline (added in WM8) I went back to the old-school flow services.   I added a debug variable (parallel to my published document variable) and then added a Branch statement on that variable.  If not set (or really anything but "true") then I would save the pipeline, but I added the key data to the file name from my published document, so I could keep them all separate.  So for my interface I added the form number and data.  So my file was handlePOSLog-1000789-2013-05-23.xml.

Now to debug, I just set debug to true and fill in those 2 bits of information in my published document.  When debug was true, the branch statement would do a restore pipeline and load the file that had been run before.

This ended up working out great.  As we were running a test cycle and a bug would come up, I could start my debugger and trace through it while the others were still running test cases.  Many times I could fix the bug right away and we could retest that one and move on.  I also then had a history of all the runs and could reprocess them if needed to check the behavior was still the same.

So it looked like this:

Branch on /debug:
  • true: pub.flow.restorePipelineFromFile
  • $default: pub.flow.savePipelineToFile
I'll remove it before pushing it up to production but it has been a great help in developing the pub-sub interface.