- This topic has 4 replies, 1 voice, and was last updated 8 years, 3 months ago by
.
-
Posts
-
-
If performance is a problem then using direct ports between orchestrations will be faster than writing to MSMQ.
Writing to MSMQ will leave behind the message context. i.e. all conext properties will need to be demoted into the message on send and promoted again on receive..
When using direct ports the messagebox acts as the queue and the message context is maintained.The only advantage of writing to MSMQ would be if you wished to execute pipeline components between your silos.
-
Yes direct ports do need to be defined at design time.
But you can route using promoted properties and the pub/sub mechanism of the messagebox – this is basically what binding the orchestration to a receive port does.When you bind a port it creates a subscription filter like:
[code:1:add554a995]BTS.ReceivePortId = <bound port id> AND BTS.MessageType = <receive shape message type>[/code:1:add554a995]With a direct port you set your own subscription filter on the receive shape. You can create your own routing properties. e.g. MyNamespace.PartnerId and create your own subscription filter:
[code:1:add554a995]MyNamespace.PartnerId = 27 AND BTS.MessageType = <receive shape message type>[/code:1:add554a995]Care needs to be taken with direct ports, it is easy to create an infinte loop.
And you will need to learn the trick of promoting properties inside an orchestration using a correlationset.-
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 serviceIt 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.
-
After thinking about it, I’m really leaning towards msmq queues between each biztalk stack of functionality. This will allow us to dynamicly route messages through stacks of functionality, and keep our assemblies only tied through schema assemblies.
Has anyone attempted something like this? I’m afraid that it looks deceptively simple right now.
Thanks for any input.
-
I will read up more on direct ports, but I thought that direct ports need to be defined at development time. So the next time a new partner needed to be implemented, I would be adding a series of decision shapes to route their messages, but could obviously be way off base. Thanks for the input, and I’ll read up on them as soon as I get to work.
Thanks
-
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.