Hi Sathwik, >> 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, my sub process is a full blown process (defined in a separate .bpel file).
I am restructuring my query about While loop. I am considering explicit correlations to implement this because we will have to relate invoke-receive activities. While loop executes its child activity in sequence, i.e. start new activity after first is complete. This is OK for one way <invoke>. However I do not understand how it will work for <receive>. Considering the sequential behavior of while loop, in the first iteration it will execute the first <receive> activity and wait till it is complete. Once the first <receive> is complete, it will execute the second <receive> and wait till is is complete and so on. However, while it is waiting for second <receive>, what if the process receives a response from 3rd <invoke>? It will fail because there is no corresponding <receive> on. Is my understanding correct or I am missing something here? Regards, JK On Wed, Nov 2, 2016 at 6:46 PM, Sathwik B P <sathwik...@gmail.com> wrote: > Response Inline > > On Wed, Nov 2, 2016 at 4:50 PM, Jit K <jkf...@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: > https://github.com/apache/ode/blob/master/bpel-scripts/src/ > main/resources/2.0/good/foreach/ForEach2-2.0.bpel > > > > 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: > http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html#_Toc164738521 > <WHILE> does not create any implicit <FLOW>. > > regards, > sathwik >
