How work Request-Response Pattern (Part 1)

 

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 :

Orchestration 1 : Consumer

 

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)

Orchestration 2 : RequestResponse

 

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 :

  1. First we stop the orchestration RequestResponse to observe the context of the published message
  2. Then we put a breakpoint on the receive shape to see what the oprtRequestResponse has changed on the message
  3. we put a breakpoint in the Snd Response shape to see the context of the response message
  4. Finally we put a breakpoint on the rcv response shape of the first orchestration

Here is the result of this analysis :

  1. This following screenshot shows us, the context of the published message, where we can see that a CorrelationToken is write

Context property

 

In the same time, a instance Subscription was created.

Dynamic Subscription

As we can see, the orcConsume subscribe to the message with the system property CorrelationToken equal to  “9bfc8bbc-9251-453c-8303-8eac8b761673”

Subscription Detail

  1. In the context property of the Request message, we retrieve the Correlation Token

Context Property of the input message

 

In the context property of the response message, the CorrelationToken is … NULL, strange no?

Context Property of the Output Message

  1. 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)

image

 

So we can conclude that :

  1. The  RequestResponse port in the first orchestration write a GUID in the CorrelationToken property context of the message
  2. 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

This entry was posted in BizTalk. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s