views:

282

answers:

2

I am not sure if I ask the right question, but this is the scenario I am trying to run:

Multiple files (XML and a few related files, "attachments") have to get into BizTalk as a single message. I have looked into existing adapters, and don't see that done with existing once. To be more accurate, files are taken from file system. Files are not found at the same time, but arrive one at a time, when order is not insured. XML (content) file is the one that knows what attachments it has to have (what other files).

We are looking into BizTalk 2009 and I was wondering would be that responsibility of a custom Adaptor, or something else. And were I could look for samples.

Thanks.

+4  A: 

It is probably possible to do what you want using a custom adapter, though I'd recommend against it. You can achieve what you require using orchestration.

What you are looking for is likey a convoy, or at the least some use of correlation.

In BizTalk a convoy is a messaging pattern (as opposed a BizTalk feature) that allows groups of messages to be processed by a single orchestration.

You essentially use correlation on a receive port to group messages together in either a parallel (what you probably want) or sequential fashion.

There is an article here by Stephen W. Thomas about convoys (it is for BT 2004 but the concepts still hold) and there is a lot of additional information on the web and in books (Professional BizTalk server 2006 has a subsection on them)

Without more details on your scenario it is hard to know exactly how the convoy would be built but below are two approaches to look at (also, I've not had a chance to properly use BT2009 so there may be extended support for correlation scenarios that help you out).

Flexible Correlation

If you don't know anything about the files listed in the context XML you will probably need a pattern like the one described by Charles Young in this post.

Non-uniform sequential convoy

If you do have a little bit of info before hand one way might be as follows (basically a Non-uniform sequential convoy):

This makes the assumption that there is some way of linking all the files together so you can correlate them.

Create a single orchestration that subscribes to you inbound receive port (which contains the file receive location).

This orchestration will have a single activation receive shape that is set up for your content file.

Once the orchestration is started by a content file a second correlated receive shape starts picking up the messages that match that content file. (this second receive could possible be in a loop to allow for variable numbers of files)

You then pack them all together into a single outbound file of your design and send them out once the full number of files has been received.

David Hall
David,Thank you for this information. Convoy looks interesting, yet I am not sure how it would work in this case. You see, the attachments are binary files, and know nothing about the content XML file. There's nothing to promote from those attachments. Maybe I am missing something, feel free to point that out. 10xSean
Sean
+1  A: 

Seems to me a better approach would be to implement the above requirements with a combination of a custom pipeline component and/or a custom adapter. I assume you do not really need to manipulate the incoming files - except for the content XML file - or that you couldn't since they are in binary format. This calls for a custom pipeline component.

What you can do is develop a custom BizTalk adapter to interact with the file system and to implement the listening and looping logic. Next you can develop a custom pipeline component to create a single BizTalk message perhaps with base64 data type in it for binary data. Additionally you could also promote messages right in this component to enable orchestration subscriptions.

Orchestrations are more suited for implementing business work-flow scenarios where the messages are already in XML format. This do not appear to be the case. In any case I think at the very least a custom pipeline component would be needed.

Bikal Gurung
Thank you. It sounds like what we will have to do. We will need to operate on the message/attachments involving orchestration/external services.
Sean