Process Instance end method

[jstuck]

Hello All:

I have a process instance which has been persisted via Hibernate. I want to end that process instance on a start node. When I call processInstance.end(), and then check processInstance.hasEnded() is true. However, the processInstance state is still on the start state. Is this expected behavior? Has anyone else seen this? How can I force the process instance to transition to the end state when using the end method?

Thanks,

Jeff

[roccolocko]

You'll never see a process state in the END node.

Do you have another tasks on your process or just START -> END?

[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

[cristian_e]

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

[roccolocko]

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

[cristian_e]

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.