All-in-one-container plus custom spring boot application

Flowable Engine
1

Hello,

I have a custom Spring Boot application, using the process engine. For persistence, I use a PostgreSQL database. Everything is deployed and wired using Docker compose. The custom exposes its’ features via an API. It does not provide a user interface.

Yet sometimes, I need a user interface. It would be neat, if I could add the All-in-One-Container to my Docker compose file.

  • Can I link the container to the same PostgreSQL database as the custom app?
  • Can multiple engines in different processes use the same database without interfering?

Thanks a lot,
Timo

2

Timo,

The answer is “it depends”. The process engine works in a very mircoservice-y way. You can add additional instances hooked to the same database and scale horizontally. If you hook the process engine from flowable-task up to the same database as your custom Spring Boot app, it will be considered just another instance and could be used to execute jobs. If those jobs don’t require custom Java code, you should be fine. If they do require custom code, you might get some class not found exceptions.

Will

3

Hello Will,

thanks a lot! Just so I got it right:

  • As soon as the process engine steps forward to some point where custom code is required, there will be class not found exceptions, because the custom classes are not available to the docker container.
  • When I use the docker container for debugging purposes (see current state and history of processes) and to resolve due human tasks, then I should be fine—as long as no custom-code service tasks follow these human tasks.

Are there another ways of integration to lift the caveat?

  • What would happen, if I deploy my custom application as a war-file with tomcat, next to the task app, also deployed as a war file?
  • If this would still lead to class not found exceptions: Can I somehow integrate the task app in my custom application?

Thanks a lot,
Timo

4

@timostolz
Any asynchronous jobs might get executed on Flowable-Task’s instance of the process engine as well. I’m not sure I would trust it with any code that wasn’t available to Flowable-Task.

Which brings me to another point. There is a method to deploy your custom code to Flowable-Task [https://flowable.org/docs/userguide/index.html#custom-bean-deployment]. It boils down to this:

  1. Let Tomcat run the WAR once so that it gets exploded
  2. Copy any custom code to tomcat/webapps/flowable-task/WEB-INF/lib/
  3. Restart Tomcat

On docker that means:

  • Running the container (called ‘flowable’ here)
  • copying out your code, docker cp demo-0.0.1-SNAPSHOT.jar flowable:/opt/tomcat/webapps/flowable-task/WEB-INF/lib/
  • then running docker exec -u 0 -it flowable chown -R tomcat:tomcat /opt/tomcat/webapps to fix ther permissions
  • Finally, restarting the container

Will

5

WIll has summarized everything quite well. I have more more thing to add.

Use Flowable Admin

If the all-in-one docker is needed only for debugging purposes maybe it is worth checking whether you can use Flowable Admin instead. Flowable Admin is not a Flowable Engine and uses the Flowable REST API to get the displayed data. If you expose the Flowable REST API in your application this would be seemless

Disable the Async executor in Flowable Task

If you disable the async executor it won’t pickup any jobs and you won’t get any class not found exceptions. The property for that is

flowable.process.async.executor.enabled=false
flowable.cmmn.async.executor.enabled=false

Really important is to not set this in the lib/application.properties of the tomcat. If you do that then the async executor of your own application will not be activated. I would advise that you set this property in the tomcat/webapps/flowable-task/WEB-INF/flowable-default.properties

Hope this helps