Wednesday, 08 July 2009

Hi all

2 and a half year ago, I wrote a blog post about looping around elements, which can be found here: http://blog.eliasen.dk/2006/11/05/LoopingAroundElementsOfAMessage.aspx. In this post, I mention two ways to do something per element in a message. One is to use the XML (or flat file) disassembler to split the message into lots of messages and have them handled individually, and the other is to do it inside an orchestration.

Since then, BizTalk has been updated such that you can now call a receive pipeline from within your orchestration, which gives you the another way of looping through elements inside an orchestration.

Often times, in the forums, users are suggested to loop through elements of a message inside an orchestration. It is a fairly common approach if you want the subelements of a message handled in the correct order, for instance.

This post is to make sure people know that looping around a message inside an orchestration can have a serious performance impact.

Say you receive a large message – 100MB. You start looping around it inside an orchestration and split it up into, say, 1000 messages of 100k each. Then, for each message you call a web service or send out the message to some system. What will happen is, that the orchestration will persist its state after each send shape, meaning that the 100BM is written 1000 times to the messagebox. Persistence points are something you always need to be aware of when designing your orchestrations, and with messages of 100MB, even more so.

SO, don’t just loop around a message inside an orchestration because you can… do it when you absolutely have to.

Thanks

--
eliasen

Wednesday, 08 July 2009 22:07:07 (Romance Daylight Time, UTC+02:00)  #    Comments [2]  | 
Saturday, 11 July 2009 02:32:12 (Romance Daylight Time, UTC+02:00)
When calling a pipeline from an orchestration it happens inside an atomic scope so there are no persistance points. It does keep the debatched messages or references to them in memory until it is all disassembled though from what I can tell because it has to wait until it's finished debatching before committing. When having to choose between calling a pipeline from the orchestration or debatching with xpath the former seems like a better choice. With very large messages though nothing beats debatching in the receive port.
Saturday, 11 July 2009 20:21:31 (Romance Daylight Time, UTC+02:00)
Hi Thiago

Well, I must confess I have never tried calling a pipeline from within an orchestration myself, but since you can't have both the send- and receive shape from a request-response port in the same atomic scope, then how do you deal with having to call a web service or the SQL adapter or something else for each message?

I guess I'll have to look into this...
All comments require the approval of the site owner before being displayed.
OpenID
Please login with either your OpenID above, or your details below.
Name
E-mail
Home page

Comment (Some html is allowed: a@href@title, b, blockquote@cite, em, i, strike, strong, sub, sup, u) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Enter the code shown (prevents robots):

Live Comment Preview

Theme design by Jelle Druyts