[Design of JBoss jBPM] - Re: status of merge, non persisted script on fork, and n-out
by tom.baeyens＠jboss.com
it is indeed true that some efforts for patterns are only supported in xml parsing. up until now, this didn't give any problems because the patterns-only node constructs were not documented and hence nobody knew about the existence.
i didn't yet remove them completely because i aimed at showing that with jbpm, we can handle any pattern. if it doesn't yet exist, we can simply implement it. the only thing that we have to take care of is that the runtime data structures support all the patterns.
looking at the future, i think that we want to show that the process virtual machine (rebranding of graph oriented programming) is a runtime data structure that can support all patterns. we can develop a separate language for showing this. which isolates our patterns efforts from the jPDL language.
wether we should rip out the patterns nodes from the xml parsing, i don't know. i am not against it, as long as this isn't interpreted as: we give up on patterns.
script in fork is not persisted in the 3.1.x because this breaks db compatibility. you can make it work in your installation by adding the many-to-one in the fork for the script field. this is what has been fixed in HEAD of cvs for 3.2.x releases.
generic mechanism of conditions on transitions is certainly something that i anticipate for 4.0. as at would result in a big effort of explaining these changes in the 3.x releases.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979982#3979982
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979982
19 years, 5 months
[Design of JBoss jBPM] - status of merge, non persisted script on fork, and n-out-of-
by kukeltje
Hi,
There is a scenario within our company where we need the multiple choice (WFP06) and multi merge (WFP08) patterns.
When I deploy a process with a merge node in it, I get the following exception:
org.hibernate.HibernateException: instance not of expected entity type: org.jbpm.graph.node.Merge is not a: org.jbpm.graph.def.Node
When looking at the code, I see that it does extend org.jbpm.graph.def.Node, it is in node.types.xml, but is not referenced in comments in Node.hbm.xml nor does it have its own hibernate mapping file. The code also states that an explicit merge is not needed since in jBPM multiple transitions can go into a node. This would do for a non-synchronizing merge, correct? A synchronizing merge would be a normal join then, correct? Shouldn't we either remove the merge node completely (it is not visible in the gpd either) or fully support it?
Regarding the accompanying multi choice, In the pattern testcases this is done by a script on a fork (which is sufficient for us). However, this script is not persisted as is shown in the logging, and therefor the multi-choice will not work in real life without a custom fork (to bad since it is a common pattern in our branche). Is there a reason for the script not to be persisted? Is it easily changed? Again, I'd say fully support it or drop support. Or should we introduce conditions on transitions as an alternative (or support both)?
A generic mechanism of conditions on transitions would also make guarded transitions possible or better prevent certain transitions from showing up in the ui, the only difference is the moment of evaluation.
The last item regarding nodes is the n-out-of-m join. It is possible to do this programatically, but wouldn't it be better to have support for this in the schema as well? Just like with the previous node issues, I'd say we should support it or drop support and show an alternative.
I won't file jira issues for this yet, since I want to discuss it first.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979960#3979960
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979960
19 years, 5 months