Pass process instance key to sub process

[mimra]

Hi

I would like to be able to pass the key of a (parent) process instance to a child process instance created using:

 <process-state name="start-child-process">
 <sub-process name="child-process" binding="late"/>
 </process-state>

I have searched the docs and the net and asked a forum question:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=142969

It seems to me there is no easy way (if any) of doing this, so I might add this. I would like some input on my thought.

I am thinking about adding a attribute to the sub-process tag to specify if the child process should be given the parent key. Something like:

 <process-state name="start-child-process">
 <sub-process name="child-process" inheritParentKey="true" binding="late"/>
 </process-state>

Then I would make the change in the org.jbpm.graph.node.ProcessState.

Any comments on this?

/Michael

[camunda]

Good point! I think the functionality is quite a good idea...

Maybe we should do it somehow similar to the variables given to a sub-process? But makes things more complex, so maybe not...

(Would be somehow like this:

<process-state name="start-child-process">
 <sub-process name="child-process" binding="late"/>
 <variable access="read,write" name="variable1" mapped-name="dsadsad" />
 <key access="read,write"/>
</process-state>

)

And what crossed my mind, should we consider other use cases like "I want to pass the key to the sub-process, but not as key, but as variable x"? My feeling says, better not, just keep it simple...

But currently I don't have a concrete use case, so these are just thoughts....

[jbarrez]

I have had the same problem in the past and I use

<process-state name="subFlow" >
 <sub-process name="theSubFlow" binding="late" />
 <variable name="id" mapped-name="subflow.id" />
</process-state>

I don't see the benefit of having a specialized construct for it.

[mimra]

How will this set the key of the child process?
Is there a relation between id and key??

/Michael

[jbarrez]

Ah you are talking about the business key and not a normal variable.

I guess that that's not possible with the current implementation altough it would be nice to have.

Perhaps a workaround would be to have an ActionHandler after the start node which sets the business key automatically based on a set variable?

[mimra]

Yeah I thought about that solution as well and that can be done with the current implementation. I have implemented the solution above and it's a small change to a single class.

The big question is if this feature is something we think should be supported by the JPDL implementation or should be handled with custom code as outlined above??

/Michael

[jbarrez]

I think it is a 'nice to have' feature in JPDL.

However, I think there are some use cases:

- variable of superprocess mapped to subprocess: OK with current implementation
- inherit parent key
- define a variable that will become the business key of the subprocess (!= from the parent key)
- default: none of that

[camunda]

Agreed. Maybe we can agree, that inherit the parent key is easy to solve, a valuable use case and we have a volunteer :-)

So I would propse: Go ahead! If you don't have committer access post the code here and I can commit it.

One remaining problem is, that the XSD can not be changed in minor versions (or is that allowed? Koen? Is it possible in major versions?), so that XSD and designer support will still lack, but the implementation can be already done I think.

The only important choice is how the attribute is named, I would suggest "copyParentKey" (because it is in the SuperProcess, "inherit" is from the perspective of the SubProcess).

But please open a jira issue for it...

[mimra]

Yes that sounds great. I'll create a JIRA and post a patch.
Let's just agree on "copyParentKey" for attribute name.

Hmm - one more thing though; I've made the change to the 3.2.2 code because I use this in the JBoss ESB 4.4.GA which comes with jBPM 3.2.2.

If I make this change to jBPM 3.2.3 it won't be of much help if the ESB guys don't upgrade to 3.2.3 with the next ESB release...

I'll have a look at the 3.2.3 - if the class in question hasn't changed in 3.2.3 we can make the patch in both 3.2.2 and 3.2.3...

/Michael

[tom.baeyens]

this is a good addition. but keep in mind that just posting the code is not enough. also the XSD need to be updated, test cases need to be created for each feature and the documentation needs to be updated.

keep that in mind as we will not be able to do that work for this contribution. without those additional elements we cannot add it to the codebase.

i just saw that SEAM has a community branch. maybe we should do something similar. a branch where community people can commit all kinds of stuff. then if it is considered ready, it can be merged into trunk.

[jbarrez]

Tom, that is a very good idea!