Hi. We have multiple applications which should use bpm. I want to know what is a good approach:
Hi,
We’ve seen people take different approaches depending on a range of considerations about how the applications are managed and maintained, so there’s no easy answer.
It comes down to how many applications; how many customizations or service calls (REST or otherwise); whether you need constant uptime; whether there are shared processes / forms / decision tables; how much QA or UAT is needed etc. And, of course, it’s a mix of all these considerations.
It is definitely popular to have a central BPM service that orchestrates application services.
It’d be interesting to hear other peoples’ ideas and experiences.
Cheers
Paul.
A connected question/clarification - suppose I am to embed flowable into multiple apps (say A and B, both with flowable UI and Rest components), am I right to assume -
These instances can share the database (and will by default).
If I am to start process1 from A and B both, first one that pick it will lock it, so second one just fail.
If App-B has all external resources in its engine’s classpath to execute process1, it will succeed, and same process execution through App-A should fail. (will it fail at process instance start or at the execution step where external resource is needed?)
If App-A is deployed by just placing all flowable(.com) built war files into tomcat webapp folder,
a) is there another way to change default port(8080) for flowable pieces (without messing with tomcat server.xml etc.)
b) configure for (db credentials, user and password) for all pieces.
It is also possible to let App-A point to App-B Rest End points through modifying rest.[process,dmn,form,content].app.port=8080 in the flowable-ui.app.properties. if so, does it mean that if then I submit a job from App-A, all external resources in path of App-B’s engine will now be available?
sorry, many questions here. may be some dumb but needed to clarify. Thanks.
Hi Andy,
A lot of questions, but it’s not really clear to me what you’re trying to achieve. When you say App-A and App-B, do you mean they are different applications (in the sense of different code and logic), or do you mean the same webapp deployed in 2 different tomcat instances?
Cheers
Paul.
Hi Paul,
Primarily, I meant two different applications (code and logic), both embedding flowable core engines and flowable others embeddable components (including rest part to submit jobs etc).
Here is another (bonus) question 
does it matter if say, I accompany each of these applications with a its own flowable webapps deployed in 2 different tomcat instances?
Hi Andy,
Again, yes, all is possible. There are a number of different options available to you, and it really depends on your situation and needs as to which might be best.
Basically, you can have as many different embedded engines in multiple containers working from the same DB and single schema, but you need to make sure that the apps isolate processes etc from each other. Alternatively, you can obviously have multiple applications working with the same DB instance but different schema, or even more simply, multiple DB instances. Unless there’s a compelling reason to keep everything in a single schema, having separate schema for each app is the most flexible and easily managed.
If you really want to use a single schema, then there’s a few options for how to manage separation. The cleanest is using multitenancy, so each app operates against its own tenant. That way, processes etc are completely isolated (but java customizations, service tasks, etc can be shared). Otherwise, using the App or Process categories are ways to be able to filter processes easily.
Hopefully, one of these options gives you what you need for your specific use case!
Best regards
Paul.