Hi all
I did a follow
up to my old
post about how to loop around the elements of a message a couple of days ago.
As you can se from the comments to my followup, Thiago mentions that there isn’t any
performance hit because everything is done inside an atomic scope. Now, Thiago is
naturally correct when he states, that no persistence occurs inside an atomic scope.
But as you can also see from the comments, I wondered about what to do about using
a request-response port – so I just had to test it.
For BizTalk 2009, just as the previous versions, you CAN’T have both the send shape
and corresponding receive shape used for a request-response port in the same atomic
scope. At compile time you will get this error: “an atomic scope may not contain or
call a service or scope that contains both the send and the corresponding receive
of a requestresponse operation on a ‘uses’ port or servicelink”.
This may seem odd at first glance, but it is due to the fact, that in order to make
sure the ACID properties
are respected at runtime the orchestration engine submits messages that are sent out
to the messagebox, but it doesn’t release them for the messagebox to route until the
atomic scope has finished. This way, if an error occurs inside the atomic scope, no
messages have actually been sent, and therefore, BizTalk can guarantee a consistent
state.
So basically, if the message isn’t released until AFTER the atomic scope, then there
is no way you can receive the reply inside the same atomic scope. Makes sense.
SO, if you want to loop around elements in a message by calling a receive pipeline
inside your orchestration, you can’t use request-response ports, as you can with other
patterns. Sorry, but that is the way it is.
Conclusion:
If you want to loop around elements inside an orhestration, use a receive pipeline
if possible since this is done in an atomic scope and therefore no persistence points
occur. If not possible, use the pattern described here.
Thanks, Thiago for pointing out that my post needed some more details
—
eliasen