|
Home > Archive > BizTalk Server Orchestration > May 2005 > receiving an abort request
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 |
receiving an abort request
|
|
| ChuckD_Duncan 2005-05-18, 5:59 pm |
| Situation: sub-orchestration has been called to Send a request at some
later date/time (followed by a correlated receive).
Easy enough so far, just put a Delay in for the Timespan and then hang out
til time to do the Send.
BUT during that delay, the end user may want to ABORT. Thus I have the
Delay and a RECEIVE in parallel - whichever completes first wins. If the
abort is received, obviously we get out of the sub-orchestration and
everyone is happy.
BUT since the SEND has not occurred I cannot Correlate the incoming Abort
request with anything. I cannot mark it as Activating because then I
can't call this orchestration from a higher-level one.
What's a poor boy to do?
Thanks in advance.
Chuck Duncan
| |
| Tomas Restrepo \(MVP\) 2005-05-19, 2:47 am |
| Chuck,
> Situation: sub-orchestration has been called to Send a request at some
> later date/time (followed by a correlated receive).
> Easy enough so far, just put a Delay in for the Timespan and then hang out
> til time to do the Send.
> BUT during that delay, the end user may want to ABORT. Thus I have the
> Delay and a RECEIVE in parallel - whichever completes first wins. If the
> abort is received, obviously we get out of the sub-orchestration and
> everyone is happy.
> BUT since the SEND has not occurred I cannot Correlate the incoming Abort
> request with anything. I cannot mark it as Activating because then I
> can't call this orchestration from a higher-level one.
I haven't tried this, but: couldn't you a) use a Listen shape instead of a
Parallel actions shape? As for the correlation, you could simply use a
separate correleation, started from the parent orchestration (it certainly
should have something to indicate what could be aborted) and then pass that
correlation as an argument to the suborchestration?
What I'm meaning is that the parent orchestration certainly knows what
you're to send from the suborchestration, possibly initializing the
correlation when the parent orchestration received its starting message, for
example.
Consider this example:
- Parent orchestration is started, with request with ID 500. Orchestration
initialized a correlation based on ID 500 on activating receive
- Parent orchestration calls suborchestration to send reply to request ID
500 and passes the correlation to the suborchestration as an argument
- Suborchestration listens to abort message for request 500 based on the
correlation.
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
| |
| ChuckD_Duncan 2005-05-23, 5:53 pm |
| I agree Tomas, I think that sounds great. I am working on setting that up
and I will let you know how it works out. It almost seems obvious once
you described it.
Thanks again.
|
|
|
|
|