Multiple applications, Central BPMn instance

Flowable Engine
1

Hi all :slight_smile:

I’d like to ask some questions regarding a multiple applications / central BPMn engine scenario.

What would be the best practice for you considering these two options:

  • Install flowable in a dedicated Tomcat or other application server.
  • Each of my applications will use this central BPMN engine REST API to upload its workflow (let’s say a BAR since they will have some custom ServiceTasks?), start some tasks and so on.
  • Some workflows will have to call another application (micro-service, SOA, …) through JMS/REST to get some data needed to continue (so applications will have some custom JavaDelegate to do that).
  • In such a case should I write some kind of utilities based on Spring, bundle them into a JAR and put it next to the BPMN engine (web-inf or something), so that these custom JavaDelegate can find these utilities, or is this something that should be bundled within each application’s BAR?

or

  • Creating a Spring boot app bundling the various spring boot starters for the bpmn engine, the modeler, the auth server and so on.
  • This application would expose the BPMN REST API so it would be in a way a central BPM engine like said above in the first solution.
  • It would have the utilities to call services through JMS/REST bundled (custom package)
  • Each application would deploy a BAR via the REST API, and the JavaDelegate would have access to the utilities to call services through JMS/REST because they would share the same classpath and process engines.

I’d appreciate the fact that we would have only one BPMn engine instead of each application running the engine itself, for monitoring purposes and so on.

Besides I would also prefer the first solution because I won’t have to create a custom app that would serve as a delegate around what you all have already written, but how to bundle my utilities to write and read through JMS/REST is not really clear to me with that first solution.

Thank you all for your inputs :slight_smile:
Foo’

2

As always when it comes to software, it depends.

First of all, note that in both scenarios you’d need to have the custom logic on the classpath. Whether it’s spring boot / default rest application. when calling custom logic in your processes, you always need the custom logic on the classpath (you can’t add it to a bar, it doesn’t take java classes).

If the default REST API’s are adequate for you, then there is no problem going with the default install, deploy your process definitions and add your custom jars.

If you want to have dedicated REST api’s (say you want to have an ‘order REST API’ instead of starting a process instance through the default api’s), then you’d need the Spring boot app approach.

To make things a bit more complex: it’s trivial to add the spring boot rest starters to your spring boot application and have a mix: the default api’s and your custom ones.

If you want to have like JMS listener kicking off a process instance, then going with a Spring Boot application is way easier than the first option.