During some development, I had to use Request-Response Pattern between two orchestrations, so I’ve decided to understand the work of this pattern inside BizTalk and particularly about the principle of the Publish/Subscribe. Maybe you know that BizTalk create automatically new subscription for this pattern but do you really know where and when?
Using the following sample:
we use two orchestrations, on one hand we have an orchestration which doing a request :
on the other hand, we have an orchestrations that receive the request (This orchestrations subscribe to message Type : Request and one promoted property Action for the routing)
But my question was : How the 2nd orchestration send the response message to the calling orchestration? If I call the 2nd orchestration from different point, how does it know the requestor and how is realized the routing?
We’re going to explain this.
The routing properties and publish/subscribe properties can be observed in the subscription details at different step of the processing. So we are going to place breakpoint on this following steps :
- First we stop the orchestration RequestResponse to observe the context of the published message
- Then we put a breakpoint on the receive shape to see what the oprtRequestResponse has changed on the message
- we put a breakpoint in the Snd Response shape to see the context of the response message
- Finally we put a breakpoint on the rcv response shape of the first orchestration
Here is the result of this analysis :
- This following screenshot shows us, the context of the published message, where we can see that a CorrelationToken is write
In the same time, a instance Subscription was created.
As we can see, the orcConsume subscribe to the message with the system property CorrelationToken equal to “9bfc8bbc-9251-453c-8303-8eac8b761673”
- In the context property of the Request message, we retrieve the Correlation Token
In the context property of the response message, the CorrelationToken is … NULL, strange no?
- In the context property of the response message in the breakpoint of the receive shape, we have the CorrelationToken with the good value AND this property is promoted (if not, the routing will have failed)
So we can conclude that :
- The RequestResponse port in the first orchestration write a GUID in the CorrelationToken property context of the message
- The RequestResponse port in the second orchestration write the SAME GUID in the CorrelationToken and promote the property to enable the routing just before sending the message in the message Box
I’ve did a last test where I set the correlationToken is the second orchestration with a message assignment in the Construct Message shape. Before sending the message, the CorrelationToken is set with the new guid. After the port, in the message box, the CorrelationToken is replaced by the good GUID use for the routing. So I think the conclusion is good.
In a second part, we will see how to replace the RequestResponse of the Second orchestration by two simple way-port