-
1. Re: Evaluating jBPM for these cases
Hi,
1)Yes via custom work items (http://docs.jboss.org/jbpm/v5.1/userguide/ch13.html), there is no out of the box implementation for that. Although it is pretty straightforward to implement jax-rs and jax-ws with work items, there will also be available some interesting implementations in the public repository (http://kverlaen.blogspot.com/2011/10/introducing-service-repository.html , http://kverlaen.blogspot.com/2011/12/jbpm-52-released.html ) .
2)The state of work items is always stored before and after execution. The only thing that you may need is to have some kind of logic executed in case the system breaks down while executing a work item in order to specify how you want to react for the stored work items that may not have completed execution i.e. restart work item execution or complete work item automatically etc.
3,4)I think this mainly depends on the app server you'll be using i.e. Jboss provides ha clustering solutions , as far as jbpm5 is concerned you'll be fine. Basically treat jbpm5 as you would with any other jee application.
5)Yes, there is a console and repository already for jbpm. However you can also implement your own or simply use the available api to do actions like that, it all depends on how you plan to use jbpm i.e. in the core of your app, as a service etc
- no problem with oracle many people have been using it
- quartz is not required by jbpm5 to function
-
2. Re: Evaluating jBPM for these cases
Thank you for your replies. Little more clarification needed on (3). What does jBPM use behind the scenes to identify that a process has been abandoned by another server (that crashed), and therefore another server in the cluster should pick up from the saved state?
Is there a built-in scheduler that keeps track of all servers and built-in background jobs that keep monitoring database tables for any processes that are abandoned by crashed servers?
-
3. Re: Evaluating jBPM for these cases
Hello,
Well in a clustered environment when a request is received one of the nodes will serve that request. If that node fails then it's up to the cluster to maintain the running session having it available to the other nodes and also redirect the next request to an available node. So then comes jbpm running on the other node that will try to handle that request. Since the data regarding the processes is persisted at a common datastore and the app server's session is maintained then the instance of jbpm within that session should be able to carry on.
-
4. Re: Evaluating jBPM for these cases
Ok, so as long as the workflow still has some input pending from the client, there is a possibility of recovering the workflow. If the workflow is past the stage where it needs any more input and the server crashes after that and before the end of workflow, then it appears there is no way of recovering it. Am I understanding it right?
-
5. Re: Evaluating jBPM for these cases
In a clustered environment if a node fails everything should continue working as if nothing happened.
In a non clustered environment when jbpm fails, since the state is persisted it will continue from where it left off unless the failure occured while executing a work item i.e. while calling a web service, while executing a piece of code, as you mentioned between after the start of the work item and before the end of it. In those cases one will have to specify to the engine what to do with the persisted work items i.e. re-run them, complete them, do something based on some logic related to the work item etc.