BizTalk Internals: Publishers and Subscribers

Here I am going to show details of the BizTalk Server Publishers and Subscribers. We will investigate all of them step by step.


There are two main publishers: receive locations and orchestrations. The real number of publishers is bigger but let's talk about it later.

Receive Location

I have created a receive port with a File receive location and the PassThruReceive pipeline. Let’s drop a file into this location. There is no subscribers  for it, so we get a suspended message with these promoted properties:


Note the PassThruReceive pipeline does not promote any additional properties. 

All properties are from the …/system-properties namespace:

  • Receive Port properties: ReceivePortID, ReceivePortName.
  • Receive Location properties: InboundTransportType, InboundTransportLocation
  • Message property: LastInterchangeMessage.

We can use these properties for subscriptions.


  • We'll see several ID properties, like ReceivePortID, which are used internally for the binding subscriptions. Not sure it is a good idea to use them explicitly.

Now we change the PassThruReceive pipeline to the XMLReceive pipeline. One more property is promoted, the MessageType:



I have created an orchestration with one send port shape that publishes messages of XmlDocument type. It is officially called "untyped" type in BizTalk, because of special meaning of the message type. For .NET developers it could be confusing, because messages have a type of XmlDocument class. Anyway...     

Let’s send a message to this shape and check the properties promoted on this port shape.


There are two promoted properties: Operation and SPTransportID. The SPTransportID is the ID of this send shape in orchestration, which is a constant in the current deployment.

Note inconsistency: the ReceivePortName is promoted for the receive port but an orchestration send shape name is not promoted, neither an orchestration name. So we can set up the filter expression for the receive port for the port name, but cannot set up it for the orchestration name. This promotion makes sense as a part of the binding design, but this inconsistency is worth to mention.

Let's publish a typed message now. That means the Message Type is set up to the schema not to the XmlDocument class. Let’s check the context of the sent message:


A new MessageType property is promoted now. Note, the orchestration send port shape under hood uses the same mechanism as the XMLReceive pipeline which also promotes MessageType. All we have to do to get a MessageType property is to assign a schema to the Message Type parameter of the port type request:

Subscribers and Binding

There are three main subscribers: send ports, send port groups, and orchestrations.

We use this query to reveal subscriptions:



Send Port


Note: If we unenlist a send port, its subscription is removed from a subscription list.


Important! If a send port doesn’t have any filter expression and if it is not bound, it still has a subscription:


Any messages addressed to its ID will be routed properly. Technically it means this property should be promoted in a published message and this message will be routed to the port.

If we add a Filter expression as image
the subscription adds OR predicate. In our case we added a predicate, which subscribes to the messages from a specific receive port:


Send Port Group

If we unenlist the send port group or all of its send ports, its subscription is removed from the subscription list.

If the send port group doesn't have any filter expression and if it is not bound, it still has the subscription:


Send port group behaves as a single send port. it creates a separate subscription. The messages will be delivered to the ports included in this group for the group subscription. Also messages will be delivered to the individual ports for the port subscriptions. If you have the same filters on the group and on a send port included in this group, the messages will be delivered twice.

Rule of thumb: create filter on the individual send ports OR on the send port group, and never on both.


If the orchestration is unenlisted, its subscription is still here under Disabled status, it is not removed as it happens for the send port. image

If the receive shape of the orchestration is untyped and has the Specify later binding, the subscription includes the ReceivePortID. It is an ID of the orchestration receive shape.


If the receive shape of the orchestration is typed and has the Specify later binding, the subscription includes the ReceivePortID and the MessageType.  

Note: the AND predicate is used.


If the receive shape of the orchestration is typed and has the Direct binding, the subscription includes the MessageType. The ReceivePortID in not in subscription anymore.


Note: The send port and the send port group get the default subscriptions on IDs, which we cannot remove. These subscriptions is to the SPTransportID and to the SPGroupID respectively. The orchestration has the default subscription to the ReceivePortID  but not for the Direct binding. 

[to be continued...]

Print | posted on Monday, February 10, 2014 7:20 PM


# re: BizTalk Internals: Publishers and Subscribers

left by Rahul Saini at 8/19/2015 1:12 AM Gravatar
Brilliant Post!!
Publishers and Subscribers explained in detail
Post A Comment