I think it will process one by one. In case if the input message has arrived even before the receive is activated, the message will be enqueued and when the receive activity gets activated it will check for any messages that has already arrived and process it otherwise it will wait for the input message to arrive.
Which ODE version are you on? Are you using OpenJPA or Hibernate? I would suggest to model the process and try it. On Thu, Nov 3, 2016 at 10:19 AM, Jit K <jkf...@gmail.com> wrote: > 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 > > >
