ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sathwik B P <sathwik...@gmail.com>
Subject Re: Dynamically invoke a child process
Date Wed, 02 Nov 2016 13:16:04 GMT
Response Inline

On Wed, Nov 2, 2016 at 4:50 PM, Jit K <jkfrm8@gmail.com> wrote:

> Hi Sathwik,
> Thank you for taking time to suggest these ideas.
> I was thinking on the same line but did not implement because I was not
> sure about calling <receive /> in a loop.
> Since <receive /> is a blocking activity, I thought the loop will stop
> during the first iteration when it executes the first <receive /> activity
> and will not not complete.
> I have few queries.
> 1) Iterative forEach parallel='yes'
> In my case I would like to collate the result of all sub-processes in the
> main process. So in the first approach (forEach) do you think I can add a
> <receive /> after <invoke /> as shown below
> <bpel:forEach parallel='yes' ...>
>         initialize the counter here
>         <scope>
>                <partnerlink .. /> access the EPR array using the index
> counter and assign it to the partnerlink.
>                <invoke .../>
>                <receive .../> to receive the response from above invoke
>          </scope>
> </bpel:forEach>
In BPEL a sub-process is implemented by using a <SCOPE /> within the
<PROCESS />. Just to clarify your sub process definition is actually a full
blown process. Am I right?
Yes, you can add a <RECEIVE /> after <INVOKE />, make sure you use
correlations. Also, any variables defined within the <SCOPE /> is a local
variable and cannot be accessed outside of it.

Example forEach Parallel:

> 2) While loop with async communication and explicit correlation
> ‚ÄčIn case of while loop, the execution is sequential. This is ok for <invoke
> /> activities. But may not work for <receive /> activities because there is
> no guarantee that the responses will be received in the same order of
> invoke.
> Or putting <receive /> in <while> will create an implicit <flow> like
> <forEach> loop?
> Thank you once again.
> JK

There is no guarantee of order of message processing. But, if you can make
a unique correlated value relate for every invoke-receive then you can know
which receive relates to the invoke. So, it doesn't matter in which order
the receive has arrived.

<FOREACH> creates an implicit <FLOW> as per the bpel specification:
<WHILE> does not create any implicit <FLOW>.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message