Wednesday, 15 July 2009

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

Wednesday, 15 July 2009 19:45:03 (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 

Theme design by Jelle Druyts