Antoine,
I don't think it would be too difficult to implement, most of the logic
/ state is already there (collecting and storing the "tokens" etc.), it
just needs a new type of Join that follows the logic as defined in the
BPMN2 spec. A first step could just put the logic to determine whether
to continue or not by traversing the graph in the JoinInstance. For
more complex cases, an approach where the graph is traversed for each
Join node during process compilation could be done if this is necessary
for performance reasons.
Kris
Antoine Toulme wrote:
Kris, how hard would it be to implement this ?
On Mon, Aug 15, 2011 at 5:53 PM, Kris Verlaenen <kverlaen(a)redhat.com
<mailto:kverlaen@redhat.com>> wrote:
Antoine,
While we would like to support all constructs as defined in the
BPMN2 specification, we currently do not support the OR gateway
yet. Since it is a rather advanced construct (especially if you
start using it in combination with (unstructured) cycles), we in
general recommend users to try and avoid this complexity by trying
to remodel the business problem using a combination of (the much
simpler) XOR and AND gateways. Therefore, the construct is not
yet on any specific release.
The best way if you want to track progress would be to create a
JIRA issue I would say, that we will then use to report progress
when implementing this feature. It would also allow other users
to vote for this issue to keep track of interest.
The implementation would be an extension of the generic Join node
(and JoinInstance), where the logic to decide when to continue
would not only keep track of the "tokens" that already arrived (as
is already done in the current implementation) but would also
check for incoming branches that don't have a "token" yet whether
there aren't any active node instances that could still reach this
incoming branch. In most cases this can be done by simply
traversing the process graph. But we could add support for
complex cases, where the graph reachability analysis is done
during process compilation (to avoid runtime overhead) and to
support more complex cases (where for example the join instance
would need to register as a listener to the process instance to
make sure it is re-evaluated whenever necessary).
Kris
Antoine Toulme wrote:
The BPMN spec contains the business requirements and the
description of the functionality of this construct.
Anurag also explained the functionality in this thread.
The questions we have for the jBPM team are:
-is this construct on the roadmap ? if yes, for which release ?
-if yes, is there a way to track its development ?
-Overall, what would the work consist and how hard is it to
implement ?
Please advise.
Antoine
On Fri, Aug 12, 2011 at 9:00 AM, Mauricio Salatino
<salaboy(a)gmail.com <mailto:salaboy@gmail.com>
<mailto:salaboy@gmail.com <mailto:salaboy@gmail.com>>> wrote:
That's what I mention. it can be easy to implement most of the
times but there are also some complex business use case
that can
complicate the generic approaches.
Looking at a concrete use case will help a lot to
understand what
do you want to achieve.
On Fri, Aug 12, 2011 at 12:53 PM, mardo <mardo(a)abicola.de
<mailto:mardo@abicola.de>
<mailto:mardo@abicola.de <mailto:mardo@abicola.de>>> wrote:
Hi there,
just some general remarks from my side:
the semantics and implementation of the inclusive
OR-join are
far from trivial. See e.g. references below.
http://domino.research.ibm.com/library/cyberdig.nsf/papers/331BE249A11C1B...
http://www.springerlink.com/content/97413825k6141332/
However, I’d be interested in the concrete business
requirement you have for modeling, since from my experience
you can cover a very large part of regular requirements
just
using the “simple” gateways.
Best
Markus
*From:* jbpm-dev-bounces(a)lists.jboss.org
<mailto:jbpm-dev-bounces@lists.jboss.org>
<mailto:jbpm-dev-bounces@lists.jboss.org
<mailto:jbpm-dev-bounces@lists.jboss.org>>
[mailto:jbpm-dev-bounces@lists.jboss.org
<mailto:jbpm-dev-bounces@lists.jboss.org>
<mailto:jbpm-dev-bounces@lists.jboss.org
<mailto:jbpm-dev-bounces@lists.jboss.org>>] *On Behalf Of
*Mauricio Salatino
*Sent:* Freitag, 12. August 2011 14:21
*To:* Anurag Aggarwal
*Cc:* jbpm-dev(a)lists.jboss.org
<mailto:jbpm-dev@lists.jboss.org>
<mailto:jbpm-dev@lists.jboss.org
<mailto:jbpm-dev@lists.jboss.org>>
*Subject:* Re: [jbpm-dev] Re- IOR gateway
Hi Anurag,
Based on your description I think that I'm
understanding what
do you want to do now.
Right now the behaviors implemented in jBPM5 are XOR
and AND.
I think what you want to implement is N of M converging
gateway, as it was in Drools Flow? Am I right?
You want to wait 2 of the 3 branches that you have to
propagate the execution?
Cheers
On Fri, Aug 12, 2011 at 5:47 AM, Anurag Aggarwal
<anurag(a)intalio.com <mailto:anurag@intalio.com>
<mailto:anurag@intalio.com <mailto:anurag@intalio.com>>> wrote:
Hi Mauricio,
If an an AND converging gateway has n incoming branches, it
expects that all incoming have been triggered and when
it is
so - it calls triggerCompleted (so that the rest of the
process can continue)
In case of OR converging, lets assume a process
branch1
/ \
OR (diverging) - branch 2 - OR (converging)
\ /
branch 3
now any of branches may be triggered, OR converging has to
wait for all branches that were actually triggered (say
branch1 and branch 3). But the problem is it does not know
which branches were triggered (for AND it was easier - just
wait for all branches to be triggered). here in case of
OR -
we don't know to continue to wait for branch 2 or not
Regards, Anurag
On Aug 12, 2011, at 1:18 AM, Mauricio Salatino wrote:
Hi Antoine,
So do you want to implement and OR or and AND converging
gateway, by the description it looks like and AND
converging
gateway. Is there any differences with the AND converging
gateway that is currently implemented in jBPM5?
Cheers
On Thu, Aug 11, 2011 at 4:46 PM, Antoine Toulme
<atoulme(a)intalio.com <mailto:atoulme@intalio.com>
<mailto:atoulme@intalio.com <mailto:atoulme@intalio.com>>> wrote:
Hi Mauricio, that's an OR converging gateway.
On Fri, Aug 12, 2011 at 12:42 AM, Mauricio Salatino
<salaboy(a)gmail.com <mailto:salaboy@gmail.com>
<mailto:salaboy@gmail.com <mailto:salaboy@gmail.com>>> wrote:
Hi guys.. that's the AND Converging gateway right?
The AND waits for all the branches that are converging
before
propagate.
If that's not what you are looking for it should be
very easy
to implement.. and probably you can model that with the
complex converge gateway.
Cheers.
On Thu, Aug 11, 2011 at 4:33 PM, Antoine Toulme
<atoulme(a)intalio.com <mailto:atoulme@intalio.com>
<mailto:atoulme@intalio.com <mailto:atoulme@intalio.com>>> wrote:
Broadcasting to list in case other committers have an
insight ?
Antoine
On Thu, Aug 11, 2011 at 12:39 PM, Anurag Aggarwal
<anurag(a)intalio.com <mailto:anurag@intalio.com>
<mailto:anurag@intalio.com <mailto:anurag@intalio.com>>> wrote:
Hi Kris,
How are you
Recently one of our requirements came up for converging
IOR gateway, this is the gateway which according to
bpmn
specification syncs up on all upstream tokens and
propagates token when no upstream token is left
Currently jbpm does not support this construct, I was
wondering if jbom has this in roadmap and if you
can give
some advice on difficulty and state of implementation
Regards,
Anurag
_______________________________________________
jbpm-dev mailing list
jbpm-dev(a)lists.jboss.org
<mailto:jbpm-dev@lists.jboss.org>
<mailto:jbpm-dev@lists.jboss.org
<mailto:jbpm-dev@lists.jboss.org>>
https://lists.jboss.org/mailman/listinfo/jbpm-dev
-- - CTO @
http://www.plugtree.com
<
http://www.plugtree.com/> - MyJourney @
http://salaboy.wordpress.com
<
http://salaboy.wordpress.com/>
- Co-Founder @
http://www.jbug.com.ar
<
http://www.jbug.com.ar/>
- Salatino "Salaboy" Mauricio -
-- - CTO @
http://www.plugtree.com
<
http://www.plugtree.com/> - MyJourney @
http://salaboy.wordpress.com
<
http://salaboy.wordpress.com/>
- Co-Founder @
http://www.jbug.com.ar
<
http://www.jbug.com.ar/>
- Salatino "Salaboy" Mauricio -
-- - CTO @
http://www.plugtree.com -
MyJourney @
http://salaboy.wordpress.com
- Co-Founder @
http://www.jugargentina.org
- Co-Founder @
http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
_______________________________________________
jbpm-dev mailing list
jbpm-dev(a)lists.jboss.org
<mailto:jbpm-dev@lists.jboss.org>
<mailto:jbpm-dev@lists.jboss.org
<mailto:jbpm-dev@lists.jboss.org>>
https://lists.jboss.org/mailman/listinfo/jbpm-dev
-- - CTO @
http://www.plugtree.com - MyJourney @
http://salaboy.wordpress.com
- Co-Founder @
http://www.jugargentina.org
- Co-Founder @
http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
_______________________________________________
jbpm-dev mailing list
jbpm-dev(a)lists.jboss.org <mailto:jbpm-dev@lists.jboss.org>
<mailto:jbpm-dev@lists.jboss.org
<mailto:jbpm-dev@lists.jboss.org>>
https://lists.jboss.org/mailman/listinfo/jbpm-dev
------------------------------------------------------------------------
_______________________________________________
jbpm-dev mailing list
jbpm-dev(a)lists.jboss.org <mailto:jbpm-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jbpm-dev