Central jBPM (enterprise) with remote access from managing apps

[zecas]

Hi,

I'm new to jBPM, and I'm reading a manual plus many guides on the web, and there are some questions that come to my mind.

I know I can incorporate jBPM in a web application, standalone application. That is quite awesome and feels good to have such wide options available.

But let's look into this specific scenario, and the best practices to implement it:

I want to implement severam processes in a company. I want to be able to execute them, and to have a web frontend. Let's imagine that I'll have 1 specific webapp for each process, to make it hard .

So I can develop each webapp, with included jBPM, and each one will have a database with webapp specific tables, and jBPM specific tables. That is the way I can develop them all.

But I'm interested in another approach ... I want ONE instance of jBPM running, with a dedicated database, hibernate config, etc ... I'll deploy ALL enterprise processes in there. Central jBPM processing. Period.

Then, I'll develop each webapp, let's say in isolated EARs, and each one will connect to the central jBPM repository and list their processes, start them, signal them, etc ...

That central jBPM EAR would be responsible to display the console that,  for admin purposes, would allow us (admins) to deploy the process xml  and manage process "versions", or check their status, or even display  some statistical info.

Is there something already available for the job? I mean, an EAR that allows to work with jBPM via Webservice invocations, or remote EJB invocations, to mimic the service api I can use "locally"?

Thanks

[sebastian.s]

jBPM does not offer webservices to invoke API operations itself but the console ships with a RESTful webservice used as abstraction layer for 2 reasons. Firstly the console is a generic application and is used for other projects, too and secondly it should be deployable on an application server different from the one jBPM is deployed on. So you could go and try to use the RESTful webservices. Search the forums. There are a couple of posts about it. You could also build your own abstraction layer in form of a webservice. If you search the forums you will also find the effort of somebody trying to create a REST interface for jBPM. Be aware that the RESTful webservice for the console does not implement all the operations offered by the jBPM-API.

[zecas]

Sebastian Schneider wrote:

jBPM does not offer webservices to invoke API operations itself but the console ships with a RESTful webservice used as abstraction layer for 2 reasons. Firstly the console is a generic application and is used for other projects, too and secondly it should be deployable on an application server different from the one jBPM is deployed on. So you could go and try to use the RESTful webservices. Search the forums. There are a couple of posts about it. You could also build your own abstraction layer in form of a webservice. If you search the forums you will also find the effort of somebody trying to create a REST interface for jBPM. Be aware that the RESTful webservice for the console does not implement all the operations offered by the jBPM-API.

Thanks for the info. I've found some info about the RESTful webservice, still I have no detailed info if it implements all the operations of the jbpm api or not, but I'll sure give it a try.

So in the situation I described, with several webapps each with at least one process, what practices you recommend?

1# Each webapp is responsible for deployment of it's own processes, and has it's own hibernate config with jbpm db definition PLUS webapp specific database definitions?

2# Same as point 1# but 2 different hibernate configs (is this possible?), one for jbpm to a common enterprise jbmp db, PLUS the second hibernate config for specific definitions in a different db? (this would bring added complexity for transaction management between the 2 databases, ie, starting a process in jbpm AND create records in webapp specific tables)?

3# Install a central console, and use RESTful webservice if fullfills the needs, if not, just use console for process deployment and managing, and create a EAR project that would implement jbpm api services as required?

Just to feel safe, is there any special precaution if I use several applications with jbpm hibernate configs that point to the same jbpm database? I assume database wouldn't be of any issue, as transactions are correctly maintained amongst different connections, from different applications. My question resides more on any precaution on the jbpm api side, any special one?

Thanks

[zecas]

Any opinion counts for me ...

Thanks

[rebody]

Hi zecas,

  When I saw webservice, I think you may have a try to BPEL. It is totally based webservice invoking.

[zecas]

Huisheng Xu wrote:

Hi zecas,

  When I saw webservice, I think you may have a try to BPEL. It is totally based webservice invoking.

I'm interested in interacting with the engine using webservices. I believe BPEL usage is more related with webservice orchestration as part of the processes themselves, right?

I'm interested in developing business processes that may and may not have human interaction, an approach like jBPM, as far as I can tell, is a good aproach for what I intend. Just wanna think about an enterprise level engine implementation

Keep ideas flowing ...

Thanks

[swiderski.maciej]

Hi,

First of all, RESTfull service does not cover entire api exposed by jBPM. It does cover the most frequently used operations (starting, signaling, task management, job execution, deployments, etc).

I would say that it depends on the load for that processes and obviously quantity of process instances. If you have millions of executions per day and process a good idea would be to separate them.

Otherwise I think a good option is to have centralized process repository with administration capabilities.

Next I would build the application business logic as set of services/api accessible from jBPM processes. It is something like your point 3 but I would secure that both jBPM and application login is executed within same transaction boundaries by using JTA to keep atomic operations for both parties.

Just to feel safe, is there any special precaution if I use several applications with jbpm hibernate configs that point to the same jbpm database? I assume database wouldn't be of any issue, as transactions are correctly maintained amongst different connections, from different applications. My question resides more on any precaution on the jbpm api side, any special one?

Here I would say that problems can occour when working with job executors. Besides it is hibernate so it could bring regular problems as with any other application accessing the same data base from different places.

That's just me personal opinion. I am open for discussion.

HTH

Maciej