What I've seen done with jbpm 3 (which jBPM 4 resembles), is that a webservice was built over the jBPM engine api. You can use the jBPM engine api to figure out what the status is of different process instances (your suggestsion touch on some of them).
If you need help with the engine API, let me know. I'm pretty sure I know which methods you could use.
thanks for your answer ,but the problem is a little bit different.
The API works fine as long as the jbpm engine can treat the exception/error during crash and reflect this situation by updating the process instance status.
The problem is all about process recovery in case of server crash, e.g. the classical power outage.
If such an error happens, a process instance will recover in the last saved state. This means that you do not know, whether a transition to another node has been triggered already and you do not know which transition has been taken, if at all.
In this situation the API does not help, I think.
So potentially I have to implement a history of transistions in a transaction external to the hibernate session. That's the only workaround I can come up with.
Ah, indeed, I guess I missed that.
I guess the other things I might suggest in this case are the following:
- try to make all code in the actual jbpm 4 node/transition classes idempotent, and have any real operations be external to that code -- by placing the actual operations/actions in external webservices.
- In general, you want to limit code to nodes and not put it in transitions. Among a number of other reasons, these kind of situations are one reason why it's not a good idea.
If you're able to do the above, then you can use the jBPM api to detect which processes are not running/active and restart them or otherwise discard the original process and restart a new process with the same initial information as the original process.