I think the best solution is to use the variable tag in your subprocess definition to insert a variable in the sub process.
<process-state name="SubProcess State"> <sub-process name="SubProcess" /> <variable name="variable1" access="read" /> <transition to="A SuperProcess Node" /> </process-state>
In the code above you take the variable named variable1 from the processInstance (ContextInstance.getVariable) and insert it to the subprocess instance.
I hope it helps...
In that case you take an existing process instance and pass it to the sub process.
My question is about a process variable specific to that sub process. So, a variable that should not be assigned in the main process (eg. because it is not used there and has no relevance there) but is needed in the sub process.
Eg. if you have a 'handle invoice' sub process (triggered from a mail, passing that invoice) in a main process that could be eg. a 'development service'.
You don't want the invoice on the main process, but you want to set the invoice on the sub process...
(the example might not be 100% realistic, but I hope you understand the idea)
I don't fully understand your idea.. but lets try with this approach:
1) Main process have a process-state (subprocess) in one of the nodes
2) When the process-state is reached a new processInstance is created (that represent the subprocess)
3) At this moment you need to introduce a new variable that is only needed in the subprocess
4) I think if you create a Task in the start-state of the subprocess definition, an user can put the variable value for the subprocess instance or if you don't need the user interaction you can put an event listener here.. (for this I think in an event in the first transition)
Is this your case?
1,2, 3 is what I mean
The first task in the sub process is a task with an action that is called automatically (no user interaction)
So, do you mean that I should put the listener in the process instead of having an 'external' message listener ?
Actually this sounds quite good ..
But then I have another problem ... there can be multiple invoices ... In that case the sub process is called stand alone ... (main process could be closed already, eg. after first invoice is handled). So can you have a listener inside a process from which you don't know it will have to be created / started a second time...
I agree that if you could have a listener as the first node (task) in a process, it would do the trick further on... but then I would always have a process started because there could be other incoming messages.
ummm , i am understanding your situation....
This make me think that you need something like a CustomFork with a process-state.
1) the main process have a MultichoiceFork node
http://www.jboss.org/community/docs/DOC-11442 Look there
2) this Multichoise fork create on demand an X number of subprocesses and insert the correct variable value to the created subprocess (a diferent invoice in every subprocess)
Thats make sense to you?
I think that in the multi fork case, you know how many parallel processes you need on node entry (based on the process variable).
But I think that is not applicable for the case I am facing ;)
I mean : I am dealing with the insurance business... In theory, it is possible to close a claim (main process closed) but afterwards, there is new data available... so some parts (sub processes) could be started again.
I think the same happens when you are dealing with legal files, ...
So that is why I have A. the subprocess (there is always at least one invoice, which I have to wait for a certain time in the flow and afterwards some automatic handling can be started) and B. that sub process can be started seperately (in the case there are n invoices)
On the one hand I think that this might be again some weird situation I am facing (I don't have years of work flow experience). But otherwise, I think there must be quite some situations where this can actually happen (so I might not be designing processes from Mars ;) )
That's ok.. I think if you have the situation when the Main process finished, you don't have to use process-state nodes. Because process-states are designed to run "inside" a node when your main process is still running.
So I think you have 2 diferent process here:
1) The main process could call another process
2) The second process that handle the new data available when the main process is finished.
I think we are going to the right solution