Direct bound ports are logical one-way or two-way ports that you can use inside your orchestration; such ports are not explicitly bound to physical ports. This allows 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:
Today we are going to talk about the Self-correlating direct bound ports.
Self-correlating direct bound ports assist you in designing asynchronous inter-orchestration communication. Messages sent to a self-correlating direct bound port are routed to the instance of the orchestration that created the receiving end of the self-correlated direct bound port.
Self-correlating direct bound ports are self-referential (i.e., the address property includes the service instance identifier of the orchestration). This means that a self-correlating direct bound port supplies the information that an orchestration can use to send messages back to its enclosing orchestration. When using the self-correlating direct binding, the orchestration engine generates a correlation token on a particular message to the orchestration instance. This provides the capability of getting messages back to a specific instance of orchestration without using a correlation set.
To configure a self-correlating direct bound port, select the Self-Correlating option on the Port Binding window of the Port Configuration wizard.
The way to use it is to create a receive self-correlating direct bound port in Orchestration A.
And set the Port direction to I’ll always be receiving messages on this port.
And in Orchestration B:
And set the Port direction to I’ll always be sending messages on this port.
This declaration will create a logical port on your orchestration designer surface with the direction flipped.
Now, back to Orchestration A:
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.
Note: Although this same exercise can be done with a Call Orchestration shape, this self-correlating proof-of-concept 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.
How does this work behind the scenes?
Under the covers, what happens is that at run time, when orchestration A starts:
BTS.Operation == Operation_1 And
BTS.PartnerPort == selfCorrelated And
BTS.PartnerService == aabbccdd-0011223344-eeff-5566778899aa
You can find a sample solution of Self-correlating direct bound ports on my GitHub here:BizTalk360! To know more about the BizTalk360 features, try out free trial or book a demo.