synBoogaloo - BizTalk/.Net 3.0

Why is it drug addicts and computer afficionados are both called users?

  Home  |   Contact  |   Syndication    |   Login
  28 Posts | 0 Stories | 29 Comments | 77 Trackbacks

News

Archives

Post Categories

Image Galleries

Blog Role

Organisations

Photo Album

BizTalk 2004 implementing a recieve pipeline component inside an orchestration

What I am about to describe will not be new to a lot of you, in fact BizTalk Bill suggested this technique a users group meeting. The fact is, that before Christmas I could find no documentation on it in my usual trawling of the blogosphere to see if there was a more elegant way with BizTalk 2004 to employ envelope splitting inside an Orchestration … I couldn’t find one. So I’m going to spell it out for you here.
Before Christmas I was looking into a way of receiving a large amount of data from a retail head office system applying some business process logic on that data as a whole before splitting that data up into individual messages i.e. one message per retail branch. I had quite good control over the validity of the xml from the head office so I was (with aggressive testing) quite sure there wouldn’t be individual records which would fail during validation or transformation. As we were dealing with quite high transaction volumes here I wanted to produce a message for each branch ~400 with as little overhead as possible = Envelope Splitting. The system was likely to be rolled out in BizTalk 2006 soon after go-live so I also wanted to allow for possible easy employment of BizTalk 2006’s really cool recoverable interchange processing and failed message routing functionality.
But hey I’m using BizTalk 2004 and I’m in an orchestration the answer is folks to either:

1.      Convince the powers that be to move to BizTalk 2006 (I tried)

2.      Write the HO message to disk and then read it off disk through a default xml receive pipeline or your own custom pipeline specifying the envelope schema in an xml disassembler component (better than the default xml receive pipeline for schema versioning) and there you have it individual branch messages.

3.     Same as 2 but instead of writing it to disk (you may not want to do this for security, scalability, async processing reasons) write it to an MSMQT queue and then read it off the queue through the receive pipeline which splits the message.

4. See correspondance with Tom Beerley below on how to achieve this using a loopback adapter, thanks Tom!

Hope this helps simple aye

R. Addis

posted on Sunday, January 15, 2006 11:40 PM

Feedback

# re: BizTalk 2004 implementing a recieve pipeline component inside an orchestration 1/17/2006 7:01 PM Tom Beerley
Option 4, which has worked well for me: Write a simple "Loopback adapter" for situations such as this. Similar to option 1 or 2 but without actually persisting anything to disk or queue, so it's probably faster.

# re: BizTalk 2004 implementing a recieve pipeline component inside an orchestration 1/17/2006 7:10 PM Rob A
Hey Tom,

Yes I tried to use a loopback adapter that was my first choice however I couldn't get to perform envelope splitting from an orchestration as the orchestration recieve shape expects only one response message not multiple (result of envelope splitting). I tried to place the recieve shape in a loop however this did not work. I would be really interested to know how you did it.

# re: BizTalk 2004 implementing a recieve pipeline component inside an orchestration 1/23/2006 5:32 PM Tom Beerley
Ah, I see. In my case they were two different orchestrations, which is why it worked for me. The first orchestration calls a Web Service that returns a large XML message that needs to be split into smaller messages. So I send that message to a send port that is bound to my loopback adapter. At that point the first orchestration is finished. The loopback adapter uses an envelope on the receive pipeline, which breaks up the message into smaller messages. Those smaller messages then get picked up by a second orchestration (a separate orchestration instance for each message).

# re: BizTalk 2004 implementing a recieve pipeline component inside an orchestration 2/20/2006 4:16 PM Rob A
Hey Tom,

Thanks for your reply, I finally got round to giving it another go and because the loopback adapter must be set on a Solicit Response External Port you can't bind it to an orchestrations Request-Response port and implement the response part of that (post envelope splitting) to your second orchestration...

In the end I got it to work by:

1) Use direct binding back to the message box on the send port of the first orchestration to send the envelope message back to the message box.

2) On the external send port which implements the loopback adapter put a filter on the BTS.MessageType property to filter on the envelope message. This is so you can get the envelope message for splitting from the message box.

3) Set your receive pipeline to XML receive on the external send port in 2 this will perform splitting of the message.

4) Create a send port or a second orchestration to receive the individual body messages from the message box via a BTS.MessageType filter equal to the body message namespace and root node.

OK, clear as mud ;) My question is am I missing something really simple here or is this the way you accomplished envelope splitting from an orchestration using the loopback adapter i.e. sending the message back to the message box and using filters on the BTS.MessageType to retrieve it??? I'd really appreciate knowing.

# re: BizTalk 2004 implementing a recieve pipeline component inside an orchestration 2/20/2006 4:17 PM Tom Beerley
Hi Rob,

Yes, that’s the same way I did it. I used direct binding from the first orchestration to publish the “batch” message to the message box, then I had a solicit-response send port set up with a filter to catch the message published by the first orchestration. The loopback adapter returns the message to BizTalk, and on the way back the message gets puts through the receive pipeline that does the splitting. The second orchestration also uses direct binding to pick up the individual messages after they’ve been split. In my case I didn’t have to explicitly set any filters for the orchestration because the subscription automatically includes the message type of the message being received by the orchestration.

Thanks,

--Tom


Post A Comment
Title:
Name:
Email:
Website:
Comment:
Verification: