-
1. Re: Process Instance end method
roccolocko Jun 13, 2007 1:20 PM (in response to jstuck)You'll never see a process state in the END node.
Do you have another tasks on your process or just START -> END? -
2. Re: Process Instance end method
jstuck Jun 13, 2007 2:58 PM (in response to jstuck)I do have other nodes besides the end node. Ideally though, when I end the process, I would like to signal the process into an end state.
Jeff -
3. Re: Process Instance end method
cristian_e Jun 13, 2007 4:41 PM (in response to jstuck)I believe when you end the process instance it's node isn't actually changed by design. It will just show you this "ended" state, but it will stay at it's current node. This is specially helpful in a situation where you have more than just one end state ("to which one should the token go?").
In case you have a complex process design between the start and end state (or at least a series of Task nodes and others) you can send the token to the end state directly changing it's node using the API (Token.setNode). This way you avoid creating all the task instances and stuff that could appear in the way, you just directly point the root token to the desired end node.
Cristian
www.miro.cl -
4. Re: Process Instance end method
roccolocko Jun 14, 2007 5:57 PM (in response to jstuck)First of all, you need then to have a transition to the END node, which I guess you do have, anyways, like I said before your process is probably working but simply you are never going to see it on the END node. Once a task goes to the END node it simply "ENDS", and the process is finish, meaning is not longer at any state (node).
-
5. Re: Process Instance end method
cristian_e Jun 15, 2007 11:44 AM (in response to jstuck)One interesting thing to consider here is the fact that you probably won't have a transition to the end state from every node in the process design. If you want to send the token to the end state at once, you have to take into consideration the whole path needed to get there, or you can "fly" there changing the state.
Nevertheless, I think that the "flying" option must be adopted carefully cause strange things can start happening. For example (at least in jbpm 3.1.2) there is no restriction for a subtoken to escape from a fork-join segment to the parent process.