You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ode.apache.org by Raghvendra Srivastava <ra...@gmail.com> on 2016/10/24 00:45:43 UTC
Re: Dynamically invoke a child process
Hi Sathwik,
How are you doing?
I am also very interested in this use case. Please suggest a way to
accomplish this using ode.
Thanks,
Rag
On Thursday, September 15, 2016, Jit K <jk...@gmail.com> wrote:
> It worked too. Thanks.
>
> H
> owever, this was just a part the solution I am trying to develop.
>
> I have a main process and bunch of sub processes. Each sub process is
> registered in a central repository with a unique name. Sub processes may be
> added or removed as required (with appropriate addition or removal from
> central repository).
> The request message to the main process has a list of sub processes to be
> invoked for that particular request. For example, request-1 may need to
> invoke sub-process-1 and sub-process-3 whereas request-2 may need to invoke
> sub-process-2 and sub-process-3.
> Thus I want to invoke the specified sub processes. Sub processes should
> execute in parallel. At the end there should be a join to collate the
> results of all sub processes.
>
> Please suggest how can I achieve this?
> Do I need all sub processes to have same interface (namespace, operations
> and messages)? Till now I was trying with the SAME Sub process (same name,
> same interface) deployed at 2 different locations. Now I am trying with
> DIFFERENT sub processes (different names, same interface).
>
> Any kind of help is appreciated.
>
> Regards,
> JK
>
>
Re: Dynamically invoke a child process
Posted by Sathwik B P <sa...@gmail.com>.
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 <jk...@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 <sa...@gmail.com> wrote:
>
> > Response Inline
> >
> > On Wed, Nov 2, 2016 at 4:50 PM, Jit K <jk...@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
> >
>
Re: Dynamically invoke a child process
Posted by Jit K <jk...@gmail.com>.
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 <sa...@gmail.com> wrote:
> Response Inline
>
> On Wed, Nov 2, 2016 at 4:50 PM, Jit K <jk...@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
>
Re: Dynamically invoke a child process
Posted by Sathwik B P <sa...@gmail.com>.
Response Inline
On Wed, Nov 2, 2016 at 4:50 PM, Jit K <jk...@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
Re: Dynamically invoke a child process
Posted by Jit K <jk...@gmail.com>.
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>
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
Re: Dynamically invoke a child process
Posted by Sathwik B P <sa...@gmail.com>.
Hi Jit,
Hope these couple of approaches might address your requirement. This is
just a high level idea.
1) Iterative forEach parallel='yes'
<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 .../>
</scope>
</bpel:forEach>
The forEach parallel loop runs an implicit <flow> for the embedded <scope
/> and that's how it runs parallel. You might have to use an array to hold
the EPR and use the counter value within the loop to access the specific
EPR during each iteration and assign it to the partnerlink. In order to
hold EPR values in an array you might have to use an XSLT transformation.
Instead of using a global partnerlink you might define and use a local
partner link within the forEach scope.
2) While loop with async communication and explicit correlation
<while ...>
<invoke /> This is a one way invoke with explicit correlation
</while>
<while ...>
<receive /> This receive should be with explicit correlation
</while>
Here, the first while loop does an sequential invoke, but since its a
one way invocation it doesn't wait for any response and it completes almost
immediately. The second while loop will wait for as many responses as the
invokes were made. Correlation values have to be unique across the
iterations.
Hope this helps.
regards,
sathwik
On Mon, Oct 24, 2016 at 12:04 PM, Sathwik B P <sa...@gmail.com> wrote:
> Hi,
>
> We will be happy to answer questions if there is any specific problems in
> executing the process model on ODE or question on the behaviour of ODE.
>
> We cannot answer questions about complete process solution models.
>
>
>
> *To answer this question,Do I need all sub processes to have same
> interface (namespace, operations and messages)? *
> Ans: Bpel activity definition is static in nature (Bpel Specification) and
> one cannot change it at runtime. Henceforth, invoking multiple sub process
> using the same Invoke activity definition would enforce you to have your
> sub process adhere to same interface. Only the endpoints of the partnerlink
> can be changed.
>
> regards,
> sathwik
>
>
> On Mon, Oct 24, 2016 at 6:15 AM, Raghvendra Srivastava <
> raghvendrasrivastava@gmail.com> wrote:
>
>> Hi Sathwik,
>> How are you doing?
>> I am also very interested in this use case. Please suggest a way to
>> accomplish this using ode.
>> Thanks,
>> Rag
>>
>> On Thursday, September 15, 2016, Jit K <jk...@gmail.com> wrote:
>>
>> > It worked too. Thanks.
>> >
>> > H
>> > owever, this was just a part the solution I am trying to develop.
>> >
>> > I have a main process and bunch of sub processes. Each sub process is
>> > registered in a central repository with a unique name. Sub processes
>> may be
>> > added or removed as required (with appropriate addition or removal from
>> > central repository).
>> > The request message to the main process has a list of sub processes to
>> be
>> > invoked for that particular request. For example, request-1 may need to
>> > invoke sub-process-1 and sub-process-3 whereas request-2 may need to
>> invoke
>> > sub-process-2 and sub-process-3.
>> > Thus I want to invoke the specified sub processes. Sub processes should
>> > execute in parallel. At the end there should be a join to collate the
>> > results of all sub processes.
>> >
>> > Please suggest how can I achieve this?
>> > Do I need all sub processes to have same interface (namespace,
>> operations
>> > and messages)? Till now I was trying with the SAME Sub process (same
>> name,
>> > same interface) deployed at 2 different locations. Now I am trying with
>> > DIFFERENT sub processes (different names, same interface).
>> >
>> > Any kind of help is appreciated.
>> >
>> > Regards,
>> > JK
>> >
>> >
>>
>
>
Re: Dynamically invoke a child process
Posted by Sathwik B P <sa...@gmail.com>.
Hi,
We will be happy to answer questions if there is any specific problems in
executing the process model on ODE or question on the behaviour of ODE.
We cannot answer questions about complete process solution models.
*To answer this question,Do I need all sub processes to have same interface
(namespace, operations and messages)? *
Ans: Bpel activity definition is static in nature (Bpel Specification) and
one cannot change it at runtime. Henceforth, invoking multiple sub process
using the same Invoke activity definition would enforce you to have your
sub process adhere to same interface. Only the endpoints of the partnerlink
can be changed.
regards,
sathwik
On Mon, Oct 24, 2016 at 6:15 AM, Raghvendra Srivastava <
raghvendrasrivastava@gmail.com> wrote:
> Hi Sathwik,
> How are you doing?
> I am also very interested in this use case. Please suggest a way to
> accomplish this using ode.
> Thanks,
> Rag
>
> On Thursday, September 15, 2016, Jit K <jk...@gmail.com> wrote:
>
> > It worked too. Thanks.
> >
> > H
> > owever, this was just a part the solution I am trying to develop.
> >
> > I have a main process and bunch of sub processes. Each sub process is
> > registered in a central repository with a unique name. Sub processes may
> be
> > added or removed as required (with appropriate addition or removal from
> > central repository).
> > The request message to the main process has a list of sub processes to be
> > invoked for that particular request. For example, request-1 may need to
> > invoke sub-process-1 and sub-process-3 whereas request-2 may need to
> invoke
> > sub-process-2 and sub-process-3.
> > Thus I want to invoke the specified sub processes. Sub processes should
> > execute in parallel. At the end there should be a join to collate the
> > results of all sub processes.
> >
> > Please suggest how can I achieve this?
> > Do I need all sub processes to have same interface (namespace, operations
> > and messages)? Till now I was trying with the SAME Sub process (same
> name,
> > same interface) deployed at 2 different locations. Now I am trying with
> > DIFFERENT sub processes (different names, same interface).
> >
> > Any kind of help is appreciated.
> >
> > Regards,
> > JK
> >
> >
>