|
Home > Archive > BizTalk Server General > July 2005 > different message types handled by the same orchestration ?
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 |
different message types handled by the same orchestration ?
|
|
| Ravi Shankar 2005-07-21, 5:52 pm |
| Hello,
How would one handle the scenario I'm about to define below in an
orchestration.
The business process is
1. Application A send a message say 100
2. This message is passed on to application B
3. B response with a response 110
4. This response is passed back to application A
(so far so good... simple orchestartion)... now for the twist
In the above scenario, if application A does not get a response back within
say 180 seconds it send a repeat request which is message type 101. 100 & 101
would have similar reference numbers to be able to build a correlation...
So if the application A has time out waiting for 110 the same orchestration
instance should accept the 101 also and send back two 110 in response.
What would the orchestration look like ?
--
Ravi Shankar
| |
| Stephen W. Thomas 2005-07-21, 5:52 pm |
| Hello.
What type of messages are you sending out of the Orchestration? Are the one
way messages (like a file) or request-response (web service calls)?
So if you send out two messages you need to wait for both responses or just
one?
Stephen W. Thomas
http://www.biztalkgurus.com
"Ravi Shankar" wrote:
> Hello,
>
> How would one handle the scenario I'm about to define below in an
> orchestration.
>
> The business process is
>
> 1. Application A send a message say 100
> 2. This message is passed on to application B
> 3. B response with a response 110
> 4. This response is passed back to application A
>
> (so far so good... simple orchestartion)... now for the twist
>
> In the above scenario, if application A does not get a response back within
> say 180 seconds it send a repeat request which is message type 101. 100 & 101
> would have similar reference numbers to be able to build a correlation...
>
> So if the application A has time out waiting for 110 the same orchestration
> instance should accept the 101 also and send back two 110 in response.
>
> What would the orchestration look like ?
>
> --
> Ravi Shankar
| |
| Ravi Shankar 2005-07-21, 5:52 pm |
| Hello Stephen,
The messages are all one-way (flat file type)
In the example before I can respond to the 100, if I get the 101, then I
need to respond to 100 anyway, but also need to respond to the 101.. only the
110 I send the second time will contain a reference to the first one sent.
--
Ravi Shankar
"Stephen W. Thomas" wrote:
[vbcol=seagreen]
> Hello.
>
> What type of messages are you sending out of the Orchestration? Are the one
> way messages (like a file) or request-response (web service calls)?
>
> So if you send out two messages you need to wait for both responses or just
> one?
>
> Stephen W. Thomas
> http://www.biztalkgurus.com
>
>
> "Ravi Shankar" wrote:
>
| |
| WenJun Zhang[msft] 2005-07-22, 7:52 am |
| Hi Ravi,
My thought is Application A must be able to determine and drop the
first time 110(if exists) after it sends 101, or it always accepts
only 1 110 and ignore the other?
Thanks.
Best regards,
WenJun Zhang
Microsoft Online Partner Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
| |
| Ravi Shankar 2005-07-22, 5:50 pm |
| Hi WenJun,
In case the application A sends a 101 it will discard the first 110 and only
act on the second 110 but the first 100 still needs to be responsed to...
Can a scenario be addressed using a sequential covoy pattern something like
this..
1. Receive Shape (attached to a port with filter for 100 & 101) triggers
orchestration
2. Move into a parallel shape
3a. One part of the parallel share is a another receive shape listening for
101 on the same receive location.
3b. The other part of the arm does the processing (ie: sending the message
to another application and waiting for a message from 110 (asynchronous send
& receive) and creation of a 110 to send to A
....
later both these arms condense into ajoin (OR)
after that we take a call if we did get A 110...
If we did not then EXIT else get the 110 sent previously, create another 110
with appropriate reference to the 101 & 110 sent previously and send it to A
and end orchestration.
--
Ravi Shankar
""WenJun Zhang[msft]"" wrote:
> Hi Ravi,
>
> My thought is Application A must be able to determine and drop the
> first time 110(if exists) after it sends 101, or it always accepts
> only 1 110 and ignore the other?
>
> Thanks.
>
> Best regards,
>
> WenJun Zhang
> Microsoft Online Partner Support
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
| |
| WenJun Zhang[msft] 2005-07-26, 7:56 am |
| Hi Ravi,
Looks like you've got the approach. However I still didn't catch the
full scenario. For a general issue, what about B doesn't respond to
the 101 too?
Anyway I think a most solid and simplest solution may be that B
responds something else like 111 to 101. Then you needn't run into
such kind of convoy design. Is this possible?
Thanks.
Best regards,
WenJun Zhang
Microsoft Online Partner Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
| |
| Ravi Shankar 2005-07-26, 5:53 pm |
| Hi WenJun,
To answer your questions, if B does not respond to the 101 within the time
out period, then A would display a message saying "host not contactable,
retry" or something to that effect. If the operation is retried then it comes
in as a fresh 100 
B can only repond with another 110 to the 101. This is the message protocol
and cannot be changed.
If it does not work. I'm in DEEP soup simple.
--
Ravi Shankar
""WenJun Zhang[msft]"" wrote:
> Hi Ravi,
>
> Looks like you've got the approach. However I still didn't catch the
> full scenario. For a general issue, what about B doesn't respond to
> the 101 too?
>
> Anyway I think a most solid and simplest solution may be that B
> responds something else like 111 to 101. Then you needn't run into
> such kind of convoy design. Is this possible?
>
> Thanks.
>
> Best regards,
>
> WenJun Zhang
> Microsoft Online Partner Support
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
|
|
|
|
|