Debugging a subscribe flow service without disrupting the existing pub-sub flow for other testing.
Dec 14, 2020 13:25 0 Comments Other components SWEETY

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.
Prev Next
About the Author
Topic Replies (0)
Leave a Reply
Guest User

You might also like

Not sure what course is right for you?

Choose the right course for you.
Get the help of our experts and find a course that best suits your needs.

Let`s Connect