Yossi Dahan [BizTalk]


Tuesday, September 08, 2009

Debugging Expression shape code

Sandro Pereira has posted a question, and answer, in the BizTalk newsgroup (he also described his answer, in detail, on his blog) about debugging expression code in Visual Studio

He wasn’t referring to debugging code in helper classes, but code in expression and assignment shapes.

My answer was that this was not possible, but Sandro quickly proved me wrong, as he demonstrates in his answer and blog post, and this got me thinking –firstly – despite knowing about the option to use the generated code (and actually using it on very rare cases to understand a certain BizTalk behaviour) I had never thought of using it for debugging, and that is an interesting thought.

However – I had to wonder – how come I never came across the need to? in all those years of BizTalk development, not even once can I remember thinking – oh! I could solve this if only I could debug the piece of code in this shape..

The reason, I think, is two fold -

1. I rarely have more than 2-3 lines of code in an expression shape of any kind; if it’s not straight assignments, its going into a helper method; it’s cleaner, it’s more reusable, and it’s easier to debug.

2. I use trace. a lot. and so every few shapes or so, and certainly in expression shapes, I will have a trace line that outputs to a log file important information about the state, and the flow of the process; this proves to be invaluable when troubleshooting issues on the live environments, but also really helpful in development.

Labels: ,


  • Yossi, I agree with you.

    Over the years I've been asked many times "why isn't there debgger support?". My answer has been "for the same reason you don't get color coded syntax highlighting and can't set breakpoints, it's not intended to be a code editor". The people asking those questions generally want to put 200 lines of c# in there :)

    The intent, and right way to do it, is as you say to have a couple of lines of "glue code" that call into your helper classes. Once people start thinking that way, then life gets simpler for them.

    However, it's interesting that this works, there may be some time (under very unsual circumstances) where it may come in handy.

    By Anonymous Brian Loesgen, at 09/09/2009, 19:58  

  • Hi Yossi,

    Interesting question, and yes you are absolute right what you describe in your reasons.

    Like you, I never put more than 2 or 3 lines in expression shape, I prefer to put the code in a helper method, for the same reasons that you describe.

    However, I don´t like to put XPATH expression in helper method and I prefer use inside orchestration, and in a previous project that I work, I have the need to get some elements of the message to elaborate a notification message and this approach help me to see why the elements that I try to get are passed without values.

    And another reason is, we not always develop all the projects, and in some cases we have the need migrate or update previous projects developed by other teams with lot of code inside expression shapes, you never know :(.

    By Anonymous Sandro Pereira, at 11/09/2009, 15:29  

  • Sandro

    Fair point about 3rd party development (replace them...!) :-)

    As for your first point - I actually prefer to put xpaths in assemblies mostly because it's easier to maintain in the long term when schemas change - I usually have them all in one place so I know where to look (as opposed to go through all expression shapes in all orchestrations), but that's down to style alone.

    Either way - debugging is really only useful on dev machines, whilst good tracing is useful on all environments, so I would have put enough trace to tell me what's going on, and turn it off; then - when facing an issue, I will turn tracing on, on either environment, and will hopefully have enough information to know what's going on (if the tracing is done well enough, that is)

    By Blogger Yossi Dahan, at 13/09/2009, 11:30  

  • Agree with your points yossi, we were discussing a similar topic at work the other day and one of the things mentioned was how much less the developers had used orchestration debugging on the back of our development/testing process. Thinking about it I couldnt remember the last time I needed to debug an orchestration with HAT which must mean our BizUnit testing is thourgh.

    Although im now expecting a nightmare problem to debug tomorrow, but at least i now know sandro's trick which is always something useful to know.

    By Anonymous mike stephenson, at 29/09/2009, 21:44  

  • Very good article but I would like to note it is also helpful if your situation requires debugging of pipeline execution in orchestrations.

    By Blogger Bon, at 21/05/2011, 05:41  

Post a Comment

<< Home