status of merge, non persisted script on fork, and n-out-of-

[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.

[tom.baeyens]

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.

[kukeltje]

I'll comment on the patterns things later, and (to my ashame) I have to admit that I forgot to mention my jBPM version (happens when you drink to much Jupiler). It is 3.2 from cvs-head. The logging says it is not persisted. I'll check if it is or not.

[tom.baeyens]

everything that is not documented is not persisted.

if you see a violation against that statement, then that should not be the case.

[kukeltje]

The script on the fork is not persisted, but it is not mentioned anywhere that it should be. What I did find out is that there is a lot of difference between the docs, schema (which in itself is very inconsistent) and behaviour/api of the core. I would like to make a suggestion to get this in line before 4.0 or even better 3.3. Shall I file a jira issue for this?

[kukeltje]

would it be to difficult to persist the script on a fork. Since http://jira.jboss.com/jira/browse/JBPM-308 is deferred to 3.2 (according to the log there) can we decide now? What is the alternative? imo it is a nice pattern that can be easily configurable with either a script or an action that calls a JBoss Rules file...

Ronald

[kukeltje]

Persisting it seems as simple as implementing Fork::read() as

 public void read(Element forkElement, JpdlXmlReader jpdlReader) {
 action = jpdlReader.readSingleAction(forkElement);
 script = (Script) action;
 log.debug("read()" + script.getName());
 }

If the fork is loaded the action is read back but as an action, not as a script, so casting it fails. This probably needs a small change in the fork.hbm.xml but I have no expertise in that. HEEEEEEEELLLLLPPPPPP ;-)

[tom.baeyens]

i think you need to add something like

<many-to-one name="script"
 column="SCRIPT_"
 foreign-key="FK_NODE_SCRIPT" />

to the Fork.hbm.xml

this will only be part of 3.2 because we don't want to change the db schema in micro release updates (e.g. from 3.1.2 to 3.1.3)

let me know if this doesn't help. don't forget to regenerate the DDL from the mappings

[tom.baeyens]

that many to one needs a cascade="all", but i don't know by heart if that is also the default.

[kukeltje]

will be part of 3.2 but isn't yet... correct? I do not intend to fix this for 3.1 or so. I'll give it a try.

Thanks

[kukeltje]

Great Tom, this works perfectly. Sounds stupid but this 'small' enhancement and the little time it took helped me convince one of my colleagues to start investigating jBPM for a serious project.

Probably the same is needed for making the join configurable as well... correct? With a little beanshell an n-out-of-m join can be created in jdpl for the moment (until it becomes an attribute...., same is true for the 'descriminator')

Next step would be to be able to use drools for this also, at least on the fork..... I'm looking into this now I understand more of the internals of jBPM.

btw, I already expected the fork.hbm.xml should be changed this way, just didn't try since I did not expect it to be this simple.

[tom.baeyens]

"kukeltje" wrote:
will be part of 3.2 but isn't yet... correct? I do not intend to fix this for 3.1 or so. I'll give it a try.

that's right. it was not yet fixed in 3.2 (although i thought i already fixed it).

thanks for reminding me :-) it's now fixed on my machine and i will check it in one of the next days

[tom.baeyens]

"kukeltje" wrote:
Probably the same is needed for making the join configurable as well... correct? With a little beanshell an n-out-of-m join can be created in jdpl for the moment (until it becomes an attribute...., same is true for the 'descriminator')

Next step would be to be able to use drools for this also, at least on the fork..... I'm looking into this now I understand more of the internals of jBPM.

making the join configurable is not really my priority. if you want, you can add and maintain it. but i would like to keep the jpdl language stable till 4.0. that's where i want to do a revision of the language constructs. and have all things like n-out-of-m and things like that.

improved drools integration is on the todo list for 3.x. don't know yet how that will look like. feel free to prorotype some ideas. if it is additions without changes to the current jpdl language, i won't have much objections.

[brittm]

Ronald,

I put a solution into the contributions section that addresses pattern 6 and 14. http://wiki.jboss.org/wiki/Wiki.jsp?page=MultiChoiceForkAH While it may be overkill for what your doing, you might be able to get some use out of it. Now that I think about it, I really need to update that--I've added some functionality since I posted it.

-Britt