Working with Direct Bound Ports in Orchestrations: Message Box direct bound

Direct bound ports are logical one-way or two-way ports that you can use inside your orchestration that are not explicitly bound to physical ports. This will allow you to have different communication patterns among your services.  

There are three types of direct bound ports that you can choose as the Partner Orchestration Port:

• Message Box direct bound ports.
• Partner direct bound ports.
• Self-correlating direct bound ports.

Today we are going to talk about Message Box direct bound ports.

Message Box direct bound ports

Message Box direct bound ports allow you to implement publish-subscribe design patterns.  Messages sent by an Orchestration to a Message Box direct bound port are published to the BizTalk Server Message Box database without any explicit intent of the message recipients.  

Recipients of the message can be any service that can subscribe to messages which include:

• Orchestrations with Logical Receive Ports configured as Message Box direct bound ports, whose subscriptions are based only on message type and filter expression (for activating receive shapes) or correlation set (for non-activating receive shapes), get messages directly from the Message Box.

  • If you don’t add any filter criteria to the activating receive shape connected to a Message Box direct bound port, then the subscription will be:

    • http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == <SchemaMessageType>

  • Every Receive shape inside our Orchestrations always includes the message type as part of its subscription. 
• Physical Send Ports filling the subscription requirements, like message type, also get a copy of that message directly from the Message Box.
  • A send port doesn’t have any default subscription, which means if you want to subscribe to those types of messages, you need to have a filter condition like  MessageType == <SchemaMessageType>
  • If you don’t provide it with a filter, it will only handle messages sent directly to it via a bound (specify-now or specify-later) logical orchestration port.

For any published message, there can be any number of subscribers for that message.  If no subscribers are interested in the message when you publish it, a persistence exception is thrown with an inner exception of Subscription not found.

Another thing you need to be aware of is that, inside an orchestration, you can create a Message box direct bound receive port that does not have a filter explicitly, and in this case, it will receive any message types. How do you accomplish that?

If inside the Orchestration you specify that the Message Type associated with that Message Box direct bound receive port to be  XmlDocument then this will be a type-agnostic port. Type-agnostic ports will accept any message type.

If using Message Box direct bound ports has its advantages, like creating loose-coupling solutions. But it also has its disadvantages that you need to be aware especially:

• Infinite message loop processing.
  • This is a typical mistake developers commonly make: we create an Orchestration with a Logical Receive Port configured as Message Box direct bound without any other additional filter specified. Later we send the same message to a send port physically bound to an endpoint.  In this case, the developer assumes that since the logical Send Port is bound to a physical Send Port, only that physical Send Port will get the message.  This is not the case!  What will happen is that after the first message is published to the Message Box, an infinite number of orchestrations will be activated.  This will happen because:
    • The message being sent to the Send Port endpoint will always be published to the Message Box.
    • Then what happens is that every time a message is sent to the Message Box, all subscriptions are checked for a match.
    • In this case, the activation filter of the orchestration will match the message, and a new orchestration instance will be started.
    • In the end, we will end up with recurse to infinity.  
• An undesired message is being processed.
  • This happens when developers don’t make or specify the filter inside Orchestrations with Logical Receive Ports configured as Message Box direct bound ports or Send Ports distinguishing enough.  The side effect of not having a distinguishing enough filter is that the Orchestrations or Send Ports can receive messages they didn’t intend to. 

For those reasons, use this functionality carefully!

To configure a Message Box direct bound port, select Routing between ports will be defined by filter expressions on incoming messages in the Message Box database in the Port Configuration Wizard.

You can find a sample solution of Message Box direct bound ports on my GitHub here:

• Working with Direct Bound Ports in Orchestrations: Message Box direct bound