Listen Shape Branch Order: It Seems to Matter
On some days, odd or unpredictable behavior seems to be the norm more than the exception when working with BizTalk Orchestration.
Recently, I’ve been building out an orchestration using a convoy pattern to aggregate messages before sending them on (See Richard Seroter’s excellent article on this pattern). An often-used part of this pattern (not used in Seroter’s article) is to place a Listen shape in the orchestration to set a time-out for how long you’ll wait for a new message before packing things up and moving on. Here is how we first implemented the Listen:
However, we found that in our loop that contained the Listen, the orchestration would execute the Receive portion first, even though a message had not come through. This caused other code in the loop to execute that should not have, or at least not yet. In our case, the orchestration placed every message in the aggregation twice.
Not so good…
Anyway, weird problems often have simple solutions. We just reversed the branch-order for the shape, causing (I think) the Delay to be accounted for first. So our new Listen looked like this:
And, for whatever reason, this seemed to work. If I find out more detail on the “why” of this, I’ll post a comment here. If anyone else knows, I’d welcome a comment or email.