Re: Execution/Dehydration Scheduling

Tech-Archive recommends: Fix windows errors by optimizing your registry

Thanks, Scott... No problem.

In step 2 the started orch sends messages using direct binding to a partner
port created in the main orch (the one that starts) and passed as parameter
the started.

The called orch in step 3 gets this partner port as parameter and listens
for the messages produced by the "started" orch.

Is this messy? Hope it got a bit more clear...



"Scott Colestock" wrote:

> My reply below was predicated on using direct binding, rather than
> call/start shapes - sorry.
>
> When step 2 happens below, you could very well start producing messages for
> which there are no subscribers (yet). How is the started orchestration (in
> #2) "producing" messages - is it using direct binding to just push them back
> to the message box?
> If the "called" orchestration is expected to receive those messages, you
> could end up with routing failures.
>
> Scott Colestock
> www.traceofthought.net
>
>
>
> "Samuel L" <SamuelL@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:EC633972-3D65-4050-8570-52DD8F0CA833@xxxxxxxxxxxxxxxx
> > Maybe I haven't exactly understood what you meant Scott...
> >
> > But does your explanation really apply to the given flow:
> >
> > 1) (Receive shape) Receive activating message
> > 2) (Start shape) Start a worker orchestration A which starts producing
> > messages
> > 3) (Call shape) Call another worker orchestration B which starts
> > receiveing
> > the messages produced by A.
> >
> > Thanks for your comments!
> >
> >
> >
> > "Scott Colestock" wrote:
> >
> >> I'm assuming you are using direct binding between the orchestrations?
> >>
> >> Remember that the message box always represents an intermediate hop. If
> >> orch b is enlisted but not running, messages will accumulate in the
> >> message
> >> box until b begins running. If it is not enlisted, you will get a
> >> routing
> >> failure (since there are no subscribers.)
> >> You can think of the message box as providing store and forward in this
> >> sense (just as it does for send adapters that may not be able to deliver
> >> messages immediately.)
> >>
> >> Scott Colestock
> >> www.traceofthought.net
> >>
> >>
> >>
> >> "Samuel L" <SamuelL@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> >> news:C843DF39-EBD7-4F96-B360-906816E7BF9F@xxxxxxxxxxxxxxxx
> >> > Hi!
> >> >
> >> > I have implemented the following flow as an orchestration:
> >> >
> >> > 1) Receive activating message
> >> > 2) Start a worker orchestration A which starts producing messages
> >> > 3) Call another worker orchestration B which starts receiveing the
> >> > messages
> >> > produced by A.
> >> >
> >> > This process works as intended when I run it.
> >> >
> >> > But my question is if it could the case that between step 2 and 3 the
> >> > main
> >> > orchestration is dehydrated (or delayed in some other way) so that
> >> > worker
> >> > A
> >> > starts producing messages before worker B is up and running?
> >> >
> >> > Are there some rules for execution/dehydration scheduling that the
> >> > BizTalk
> >> > engine follows which prevents this scenario?
> >> >
> >> > Thanks for all comments!
> >> >
> >>
> >>
> >>
>
>
>
.

Relevant Pages