It is quite difficult to address the actual design patterns you've
mentioned
without knowing more details. generally - as you know by now- asynchronous
interfaces are better from a scalability point of view, and I tend to
suggest
at least considering async interfaces whenever possible have you
considered
splitting up the request currently going into process A to separate, async
requests as well?)
Anyway - one thing I think I can comment on is your following observation
-
"but I'm concerned that the n orchestrations
processing n requests will not be able to distinguish the different
messages
coming from System B during the processing because the messages are
correlated on order number and all of the threads are processing requests
for the same order. System B, which is outside of my control, doesn't
provide data in the response message to uniquely tie it to the request I
sent.
"
This might be relatively easy to resolve - in fact - you have quite a few
options -
one option, if you're going down the start orchestration route, is to pass
a
receive ****t as a parameter to the started orchestration; when that
orchestration is ready to return a response it would use the ****t paramter
to
send the response, which would deliver the message to the correct instance
of
the initial orchestration.
Have a look at the following article by Mauricio Ritter
http://www.codeproject.com/KB/biztalk/bts_async_call.aspx.
haven't read it
in detail, but it seems to be using the same principle.
Another approach you can use is to simply utilise BizTalk's
publish-subscribe mechanism combined with the correlation option -
this statement you seem assume you have to use a value from the message
(such as order ID), but that is incorrect.
You can introduce your own context property to correlation on (or use the
system correlation token property) and assign a [guid?] value to it in the
initial process (when creating the request going to the internal process).
you can then publish that message using a send shape linked to a direct
****t
configured to initialise a correlation set that uses the property with the
guid.
the second process will also use a direct ****t, this time with an
activating
receive shape and a filter configured to pick up the right message.
it would extract the guid from the message's context and use it when
publi****ng the response (again - setting it in a context proprety and
initialised a correlation set in the send shape - to make sure the
property
gets promoted)
back in your initial process you will have a receive shape, yes - using a
direct bound post - following on the correlation set.
This sound quite extensive, but really is not that a big deal (and there's
lots of posts around using correlation-sets) and it will ensure that
messages
get routed back to the correct process.
As you've suggested you may need to spawn multiple internal processes you
may want to look at implementing a scatter-gatherer pattern (here's one
example -
http://www.richardhallgren.com/a-loosely-coupled-scatter-and-gather-implementation-in-biztalk-2006/)
I hope this helps
--
Yossi Dahan
MVP BizTalk Server
http://www.sabratech.co.uk/blogs/yossidahan
"Zoe Hart" wrote:
> My BizTalk orchestration receives a series of requests from System A via
a
> BizTalk generated web service. The workflow to process an individual
request
> is basically: receive the request, send a request-received
acknowledgement
> message, process the request (which involves a series of messages back
and
> forth with System B and can take anywhere from a few seconds to three
days.
> The receipt and acknowledgement of the request is handled in my main
> orchestration. The processing of the request is handled in a
> sub-orchestration which I call synchronously from my main orchestration.
So
> when n requests come in they get processed one at a time - receive,
> acknowledge, process, receive, acknowledge, process, etc. The problem is
> that when the first request takes longer than a few seconds to process,
the
> latter requests timeout in the web service.
>
> So an obvious alternative is to start the processing sub-orchestration
> asynchronously rather than calling it synchronously. That way I could
> receive and acknowlege the first message, start an orchestration on
another
> thread to process it, and receive and acknowledge the second request
while
> the first is still processing and spawn an orchestration on yet another
> thread to process the second request. And on and on until I've received
> acknowledged all requests and spawned off orchestrations to process
them.
> I'm looking into that approach, but I'm concerned that the n
orchestrations
> processing n requests will not be able to distinguish the different
messages
> coming from System B during the processing because the messages are
> correlated on order number and all of the threads are processing
requests
> for the same order. System B, which is outside of my control, doesn't
> provide data in the response message to uniquely tie it to the request I
> sent.
>
> So the behavior I'd like to have is for my main orchestration to receive
and
> acknowledge the first request and submit it to a queue for processing
with
> System B. Then it would receive and acknowledge the second request and
> submit it to the same queue. Effectively I want the processing on a
separate
> asynchronous thread (so I can quickly acknowledge all incoming requests)
but
> I want the separate requests processed in order on one thread as opposed
to
> in parallel on many threads. Can anyone suggest how I might get that
> behavior in a BizTalk orchestration?
>
> Thanks,
> Zoe
>
>
>
|
