BizTalk port/orchestration filtering performance overhead

Question

Please consider the following scenario in BizTalk 2006:

Received message should be routed to orchestration or send port according to the following constraints

(Message.Type = "SomeType" AND Message.Sender = "SomeSender")
OR
(Message.Type = "SomeOtherType" AND Message.Sender = "SomeOtherSender" AND Message.IsSigned = true)
OR
(Message.Sender = "AnotherSender" AND Message.IsSigned = true)
etc...

One way to do this is by applying filters on orchestration receive shapes or send ports.

On the other hand, I can promote a routing data field to the message context in custom receive pipeline component based on the message fields and then applying only one constraint to the filter:

Message.Route = "Route A"

Which of these alternatives is a less performance costly solution here (lower latency)?

Thanks in advance.

Answer 1

The main thing that will impact your latency is the number of persistence points (saves of state to the database).

If alternative 2 (promoting "Route" in a pipeline) allows you to totally cut out the orchestration (or do you need it for something else?) and let you have a pure messaging solution (port to port), that'll be faster that when having an orchestration in there.

Answer 2

Between the two options I would generally pick the orchestration filter. The implementation of the subscriptions is pretty fast, so having a few segments to filter on is not a huge overhead.

Having a pipeline component and promoting a property off that is not guarenteed to be faster, and is an overhead in terms of development and maintenance.

There's one bit down side, in my view, to orchestration filters (but - from your question it does not appear you necessarily going to make it any better) and that is the fact that the rule is compiled (unlike send port filters, for example)

If you need this to be more dynamic, and you can write your pipeline component so that it is configurable that would give you some benefit.

Answer 3

If you have a class of senders (as it appears you do) you might also consider a party / role link implementation which would give you additional flexibility.