|
Home > Archive > BizTalk Server Orchestration > August 2005 > What happens in the message box for HTTP messages
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
What happens in the message box for HTTP messages
|
|
|
| I have an orchestration previously created by someone else which sends a
message to a HTTP send port, the message and the send shape have had
correlation set for them.
The next shape in the orchestration is the receive shape which receives the
same message back from a HTTP receive port which is routed through a custom
pipeline.
I understand what is happening but I am not sure why. The following sentence
found on the msdn website confuses me:
"After the adapter sends the message to a destination URL and the BizTalk
Messaging Engine receives the HTTP success status code, the HTTP send adapter
deletes the message from the MessageBox database."
I am getting confused as to whether this is what my orchestration is doing
and how come my message is returned to the orchestration from the BizTalk
database. Is it because correlation was used?
Cheers,
Gary
| |
| Yossi Dahan 2005-08-05, 7:48 am |
| Gary wrote:
> I have an orchestration previously created by someone else which sends a
> message to a HTTP send port, the message and the send shape have had
> correlation set for them.
>
> The next shape in the orchestration is the receive shape which receives the
> same message back from a HTTP receive port which is routed through a custom
> pipeline.
>
> I understand what is happening but I am not sure why. The following sentence
> found on the msdn website confuses me:
>
> "After the adapter sends the message to a destination URL and the BizTalk
> Messaging Engine receives the HTTP success status code, the HTTP send adapter
> deletes the message from the MessageBox database."
>
> I am getting confused as to whether this is what my orchestration is doing
> and how come my message is returned to the orchestration from the BizTalk
> database. Is it because correlation was used?
>
> Cheers,
> Gary
Gary
What you've quoted from the documentation refers to the message sent.
basically when you send a message from an orchestration it is published
to the message box and the send port subscribed to it picks it up and
delivers it.
obviously once the outgoing message has been delivered successfully it
is no longer needed in the message box and will be deleted (at some
point, not necessarily immediately)
As for getting the response back into the orchestration this depends if
its a synchronous or asynchronous operation, but then again, not really,
and I will try to explain -
from the orchestration's point of view it doesn't matter which send port
delivers the message, it just published a message to the message box
(send shape).
then you have a receive shape. normally (without changing anything) this
means you orchestration is not waiting for a message of a specific type
and the first message of this type that will be published by anything
into the message box (by a receive port, receive part of a 2 way end
port or an orchestration) will be picked up by the orchestration.
of course this is not exactly what you need, as you're looking for a
message of a certain type, but to a specific instance of it - the one
that answers the message sent from that instance of your orchestration
(remember - you can have more then one at any given time)
this is where the correlation comes into play - it adds to the
subscription certain properties of the message so it says something like
- all messages of type x with value y in element z
this can then be used to check the value of a known element that will
relate the response to the original request.
so - in asynchronous communication patters we rely on correlations we
define in the orchestration
in synchronous communication (when you use 2way send port) you don't
explicitly specify correlation but in fact this is exactly what happens
behind the scenes. biztalk creates a guid, assigns it to the request and
correlates on it for the response. the 2-way adapters such as the http
adapter know to copy this guid from the request to the response when it
arrives. you can see now that it can only happen in synchronous patterns
where the adapter is capable of doing the correlation.
I hope this is not to confusing.
Yossi Dahan
| |
|
| Thanks Yossi that makes part of it more clear. I think I have one more thing
that I am unsure of. My Orchestration works like this:
1. Orchestration sends a message to the message box
2. Send port picks up the message and delivers it
3. Receive Port receives the message
4. Message is passed to orchestration
The bit I am struggling to understand is how does step 2 and 3 communicate.
My send port is a one way HTTP type port sending to the BTSHTTPReceive.dll.
My receive location is of one way HTTP type again with the address specified
as BTSHTTPReceive.dll.
Does this mean that my send port will send the message to any receive
locations of type HTTP with the specified address of the BTSHTTPReceive.dll
and that the correlation is what filters it? If so does the message go back
in to the message box from the send port and then the receive location pick
it up via the subscription which has the relevant added correlation
properties?
"Yossi Dahan" wrote:
> Gary wrote:
>
> Gary
>
> What you've quoted from the documentation refers to the message sent.
> basically when you send a message from an orchestration it is published
> to the message box and the send port subscribed to it picks it up and
> delivers it.
> obviously once the outgoing message has been delivered successfully it
> is no longer needed in the message box and will be deleted (at some
> point, not necessarily immediately)
>
> As for getting the response back into the orchestration this depends if
> its a synchronous or asynchronous operation, but then again, not really,
> and I will try to explain -
>
> from the orchestration's point of view it doesn't matter which send port
> delivers the message, it just published a message to the message box
> (send shape).
>
> then you have a receive shape. normally (without changing anything) this
> means you orchestration is not waiting for a message of a specific type
> and the first message of this type that will be published by anything
> into the message box (by a receive port, receive part of a 2 way end
> port or an orchestration) will be picked up by the orchestration.
>
> of course this is not exactly what you need, as you're looking for a
> message of a certain type, but to a specific instance of it - the one
> that answers the message sent from that instance of your orchestration
> (remember - you can have more then one at any given time)
>
> this is where the correlation comes into play - it adds to the
> subscription certain properties of the message so it says something like
> - all messages of type x with value y in element z
>
> this can then be used to check the value of a known element that will
> relate the response to the original request.
>
> so - in asynchronous communication patters we rely on correlations we
> define in the orchestration
>
> in synchronous communication (when you use 2way send port) you don't
> explicitly specify correlation but in fact this is exactly what happens
> behind the scenes. biztalk creates a guid, assigns it to the request and
> correlates on it for the response. the 2-way adapters such as the http
> adapter know to copy this guid from the request to the response when it
> arrives. you can see now that it can only happen in synchronous patterns
> where the adapter is capable of doing the correlation.
>
> I hope this is not to confusing.
>
> Yossi Dahan
>
>
| |
| Yossi Dahan 2005-08-05, 5:52 pm |
| Gary wrote:[vbcol=seagreen]
> Thanks Yossi that makes part of it more clear. I think I have one more thing
> that I am unsure of. My Orchestration works like this:
>
> 1. Orchestration sends a message to the message box
> 2. Send port picks up the message and delivers it
>
> 3. Receive Port receives the message
> 4. Message is passed to orchestration
>
> The bit I am struggling to understand is how does step 2 and 3 communicate.
> My send port is a one way HTTP type port sending to the BTSHTTPReceive.dll.
> My receive location is of one way HTTP type again with the address specified
> as BTSHTTPReceive.dll.
>
> Does this mean that my send port will send the message to any receive
> locations of type HTTP with the specified address of the BTSHTTPReceive.dll
> and that the correlation is what filters it? If so does the message go back
> in to the message box from the send port and then the receive location pick
> it up via the subscription which has the relevant added correlation
> properties?
>
> "Yossi Dahan" wrote:
>
>
Gary
I think to clarify this a bit further I need to explain a couple more
things -
1. the send operation (by the send port) and the receive operation (by
the receive port/location) have nothing to do with each other (unlike
the logical ports in the orchestration, as I will explain in the next point.
you send the message using port A and receive it using port B.
in your case both using the same adapter, but this is not required. you
can have the same logic by sending using the http adapter and receiving
using the msmq adapter or any other combination.
this highlights the fact that the adapter has nothing to do with the
correlation in asynchronous pattern.
so how does it happen? this bring us to point number 2 -
in the orchestration the send shape and the receive shape do have a
certain relationship through the correlation set.
in the orchestration you define a correlation type, which basically list
the properties that are used to identify a message exchange (for
instance - employee name and date of birth) - these properties will be
used to match the response to the request so their values must uniquely
iidentify the exchange and exist in both the request and the response,
although not necessarily in the same schema)
then you create a correlation set which is an instance of your type and
in the send shape you initialize your correlation set (through the send
shape's properties) this tells BizTalk - I'm sending this message, and
I'm expecting a response. the response must have these values in these
fields (based on the correlation set).
later in the orchestration (not necessarily the immediate next step) you
have a receive shape and configure it to follow that correlation set.
this means it will create a subscription for a message of the type you
select but will only accept messages with the same values in the
properties defined in the correlation set as they were in the sent message.
this is a bit confusing, so a quick sample:
say we have request message
<holidayRequest>
<employeeName>Gary</EmployeeName>
<dateOfBirth>01/08/2005</dateOfBirt>
<holidayStartDate>10/08/2005</holidayStartDate>
<length>10</length>
<holidayRequest>
and then a response message
<holidayResponse>
<employeeName>Gary</EmployeeName>
<dateOfBirth>01/08/2005</dateOfBirth>
<status>Approved</status>
</holidayResponse>
in this example when you send the request you will initialize a
correlation set with the values of employeeName and dateOfBirth
so when the response arrives, because it has the same values in these
fields it will be routed to the same instance
if you get
<holidayResponse>
<employeeName>Yossi</EmployeeName>
<dateOfBirth>02/08/2005</dateOfBirth>
<status>Approved</status>
</holidayResponse>
as a response it will fail routing as the values don't match.
it is, of course, quite possible to send two request, for two employees
and then the correlation mechanism makes sure each response is delivered
to the correct instance.
I hope this is a bit clearer now
Yossi Dahan
| |
|
| Hi Yossi,
Thanks for clarifying the fact that the send port and receive port have
nothing to do with each other. This was the part that was getting me confused
the most, as everything I have read up to now on BizTalk suggests this too.
From your explanation I am assuming that a message sent via HTTP to the
BTSHTTPRecevie.dll must go into the message box database from
BTSHHTPReceive.dll in order to allow my receive location to pick it up based
on the subscription.
So the message will follow this path:
1 Orchestration
2 MessageBox
3 SendPort
4 MessageBox (I think - from the BTSHHTPReceive.dll)
5 ReceivePort (picked up via the subscription)
Thanks for your help Yossi, and for taking the time to reply.
Gary
"Yossi Dahan" wrote:
> Gary wrote:
> Gary
>
> I think to clarify this a bit further I need to explain a couple more
> things -
>
> 1. the send operation (by the send port) and the receive operation (by
> the receive port/location) have nothing to do with each other (unlike
> the logical ports in the orchestration, as I will explain in the next point.
> you send the message using port A and receive it using port B.
> in your case both using the same adapter, but this is not required. you
> can have the same logic by sending using the http adapter and receiving
> using the msmq adapter or any other combination.
> this highlights the fact that the adapter has nothing to do with the
> correlation in asynchronous pattern.
>
> so how does it happen? this bring us to point number 2 -
>
> in the orchestration the send shape and the receive shape do have a
> certain relationship through the correlation set.
> in the orchestration you define a correlation type, which basically list
> the properties that are used to identify a message exchange (for
> instance - employee name and date of birth) - these properties will be
> used to match the response to the request so their values must uniquely
> iidentify the exchange and exist in both the request and the response,
> although not necessarily in the same schema)
> then you create a correlation set which is an instance of your type and
> in the send shape you initialize your correlation set (through the send
> shape's properties) this tells BizTalk - I'm sending this message, and
> I'm expecting a response. the response must have these values in these
> fields (based on the correlation set).
> later in the orchestration (not necessarily the immediate next step) you
> have a receive shape and configure it to follow that correlation set.
> this means it will create a subscription for a message of the type you
> select but will only accept messages with the same values in the
> properties defined in the correlation set as they were in the sent message.
>
> this is a bit confusing, so a quick sample:
>
> say we have request message
>
> <holidayRequest>
> <employeeName>Gary</EmployeeName>
> <dateOfBirth>01/08/2005</dateOfBirt>
> <holidayStartDate>10/08/2005</holidayStartDate>
> <length>10</length>
> <holidayRequest>
>
> and then a response message
>
> <holidayResponse>
> <employeeName>Gary</EmployeeName>
> <dateOfBirth>01/08/2005</dateOfBirth>
> <status>Approved</status>
> </holidayResponse>
>
> in this example when you send the request you will initialize a
> correlation set with the values of employeeName and dateOfBirth
> so when the response arrives, because it has the same values in these
> fields it will be routed to the same instance
>
> if you get
>
> <holidayResponse>
> <employeeName>Yossi</EmployeeName>
> <dateOfBirth>02/08/2005</dateOfBirth>
> <status>Approved</status>
> </holidayResponse>
>
> as a response it will fail routing as the values don't match.
>
> it is, of course, quite possible to send two request, for two employees
> and then the correlation mechanism makes sure each response is delivered
> to the correct instance.
>
> I hope this is a bit clearer now
>
> Yossi Dahan
>
>
| |
| Tomas Restrepo \(MVP\) 2005-08-05, 5:52 pm |
| Hi Gary,
> Thanks for clarifying the fact that the send port and receive port have
> nothing to do with each other.
That is correct. In BizTalk, an adapter can have either a transmitter (send)
or receive side (or both), but the two are, in essence, completely unrelated
to one another. They usually run in separate contexts, with different
configuration, etc. The relationshipt between the receive and send side for
an adapter is fairly tenous, at best, at least from my point of view...
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
|
|
|
|
|