Demystifying Direct Bound Ports – Part 4

Self-Correlating Direct Bound Ports

Self-Correlating direct bound ports are self referential (i.e. the address property includes the service instance identifier of the orchestration) providing the capability of getting messages back to a particular orchestration instance without using a correlation set.

To configure a self-correlating direct bound port select ‘Self Correlating’ as the ‘Partner Orchestration Port’.

The way to use it is to create a receive self-correlating direct bound port in orchestration A.  In Orchestration B declare a port as a Send Port Orchestration Parameter of the same port-type as defined in orchestration A.  This declaration will create a logical port on your orchestration designer surface with the direction flipped.  When orchestration B is called with the ‘Start Orchestration’ shape, pass the port as a parameter to orchestration B.  Orchestration B then does whatever business logic it needs to and then can send a message on the port passed in as a parameter.  The message will be sent to the self-correlating port of the instance of orchestration A that originally started orchestration B.

Although this can be done with a Call Orchestration this would only make sense with a Start Orchestration as it generates an asynchronous instantiation of an orchestration that cannot have out or reference parameters so the self-correlating port can be used as a means of responding back to the orchestration which instantiated it.[1]

Under the covers what happens is that at run time when orchestration A starts a subscription will be created for each self-correlated direct bound port.  The subscription will look like the following:

BTS.Operation == Operation_1 And

BTS.PartnerPort == selfCorrelated And

BTS.PartnerService == aabbccdd-0011223344-eeff-5566778899aa

Where Operation_1 is the name of the operation on the port, selfCorrelated is a literal string used as the PartnerPort, and a GUID for the Partner Service that uniquely identifies this port for this instance of the orchestration.

When orchestration A starts orchestration B the orchestration engine will pass the self-correlated port instance information to orchestration B, along with the other orchestration parameter values.  When orchestration B then sends a message on the self-correlating port that was passed in as a parameter the orchestration engine will set and promote the properties listed above allowing the message to be routed back to the instance of orchestration A that originally instantiated the current instance of orchestration B.


Figure 10 self-correlating port communication


In the next posting I will explain another way of using self-correlating direct bound ports with dynamic direct bound ports.

[1] Note that you can pass an initialized correlation set as a parameter to a called orchestration and follow the correlation set within the called orchestration.  This means that subscriptions and convoys work across call orchestration boundaries.  This does not work with started orchestrations.

Comments (2)
  1. A nice explanation of the direct port binding flavors in BizTalk. Part 1:

  2. TheCloud says:

    Calling child orchestration strategies

Comments are closed.

Skip to main content