Biztalk Architecture Question

Home Page Forums BizTalk 2004 – BizTalk 2010 Biztalk Architecture Question Biztalk Architecture Question

#13953

I’m hoping someone might be able to help me through an architecture hurdle I’m facing.

We currently have a process that consists of :

Bulk load a file
Select the rows back out
Iterate the rows, calling a web service for each row
Hand off the results to another orchestration
Iterate the rows again calling a different web service

It has worked, but is suffering from timing issues (currently it is taking 5 hours or so for 1 customer), and it is not very flexible.

My thought was to break this down in a number of different biztalk \”things\”. Each of these things would do 1 small part of the process above, and send the message to the next biztalk thing in the chain, much like a convoy. I was hoping that I could use the pub/sub model to route messages through these functionality silos in a flexible way, basicly each silo would modify the message ever so slightly, and a subscription would hand it off to the next thing.

In my mind this architecture worked great. I could inject \”silos\” at runtime, and use the sub model to route messages as I needed, even adding very specific customer functionality to only one of the paths through the convoy.

I sat down with a couple of developers here, and we started to talk about how to implement it, and hit a brick wall. Unfortunatley, we are all pretty new with biztalk, although we have a lot of experiance in .net. What I’m picturing in my mind is a MessageBox send port, and MessageBox receive port, the receive port having the same filter drop down that is in the send port. Maybe there is a way to implement this that I am unaware of, but I don’t know a way.

My next thought bloated out complexity, but it would work I think. Add an MSMQ queue between each silo, where send ports could route to queues based on context properties, and recv locations would just listen to their \”holder\” queue. This would work, but it seems overly complicated, and we would have the need to maintain N (being the number of functionality silos) – 1 queues.

My last though was just to load the whole file, and write custom code that does it, and trigger the custom code through a SOAP call. This is probably the easiest to implement in the short term, but difficult to maintain and will require coding that, at least in my mind, has already been done in the pub/sub model of BizTalk.

Does anyone have any suggestions on this? I feel like I’m trying to fit a square peg in a round hole, but it seems like I should be able to dynamicly route messages back to biztalk, and I’m missing something easy here.

Thank you in advance for any help.