- This topic has 7 replies, 1 voice, and was last updated 8 years, 4 months ago by
.
-
Posts
-
-
I have an request/response scenario which uses the following flow:
-
A request is sent to a two-way receive-port using WCF BasicHttp (Build using Publishing Wizard)
-
The request-message is stored in the messagebox (no orchestration used)
-
A solicit/response send port subscribes to this message type and transforms the message to an format that a legacy system behind understand (Sends to a webservice)
-
A response from the legacy system comes back to the send port, which transforms the legacy-message into the format that the origin receive-port expects/returns
-
The receive port gets the message a returns it to the sender
Which element in the message-context is used to guarantee that to original request gets the correct response? Lets say that we have 50 callers at the same time, an some operations in the legacy system take longer than others.
I have looked at the MessageID through the HAT, but this changes in every step. Is this magic? 🙂
/A
-
-
Hello mcgyver,
It’s not magic, because what happens is that BizTalk construct a totally new message and use it, so by nature, it will have a new message id.
What you may do is “co-relating” this set of messages.
Hope this rings any bells.
Mike
-
Hei Michael.
But does BizTalk correlate this messages automatically? I’m using basic message-based routing.
I have made some tests, an each time the correct response gets back to the “requester” and I haven’t set up any correlation mechanisms.
-
Hi Mcgyver,
Maybe I didn’t get you right the first time,
Step 5 in your original post, how does the receive port get the response from the send port? I need to know more details about the subscriptions.
Mike
-
The received port (Request-Response) is build by using WCF Service Publish Wizard where I chose to publish a service using two schemas. The one used for the request is named “GetStatusRequest.xsd” and the one used for response is named “GetStatusResponse.xsd”. So when I call the WCF-service a “GetStausRequest” message is stored in the messagebox.
My send port (Static Solicit-Response) then subscribes to “GetStatusRequest”, and transforms this message into another message which my legacy-system understands. This message is called “LegacyStatusRequest” and is submitted to the legacy-system. It then returns a new response message called “LegacyStatusResponse”, which the send port receives as response. The send port then transforms this message into the “GetStatusResponse” message and stores it in the messagebox.
So far so good. 🙂
But the magic then appears when the receive port, which looks into the messagebox for “GetStatusResponse”-messages, knows which of the response messages to correlate with the orgin request. If 50 requests is made in a few seconds, it needs some context-data to correlate the 50 responses back to the correct request.As I wrote I have made some tests, and every time the right response has came back to the requester.
-
[quote user="mcgyver"]I have made some tests[/quote]
well, it may work properly if you’re testing with a few messages specially if your legacy system is responding fast enough to request messages. What I’m suggesting is to load test the application
let me know if I can help with anything.
Mike
-
I took a deep-dive into this, to figure out whats happens behind the scenes, and found out that it’s based on instances to share messages. based on InstanceID’s and MessageID’s.
See this image for a better understanding
-
The intial request/response promotes am internal CorrelationID to incoming message (5AB20) when it is published to the MessageBox and thens creates a subscription a based on this CorrelationID and waits.
The Solict/Respomse port to the Legacy system will copy this CorrelationID into its response message (ED5D2). This is a standard function of two way ports,
The original port will receive this response based on its subscription. When this instance terminates it deletes the subscription.
If you are fast and the legacy system is really slow, you should be able to view this transitory subscription in the Biztalk Admin Console.
This “magic” is performed by the Endpoint Manager (EPM)
Check out this blog post by Richard Seroter
-
-
-
-
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.