Camunda-cockpit: deploy rest layer independently from user-interface

[ia.sre...@gmail.com]

Hi,

we have planned to deploy the camunda-cockpit user-interface independently from the camunda backend. The backend should run in the application where the embedded process engine runs.
The cockpit user-interface should be deployed with a separate war package.

Bernd Rücker told us (in the course of a training session) this is possible by excluding the rest module from the camunda webapp.

The camunda-bpm-webapp project contains the backend code for all web applications (like the cockpit). The core module has a dependency to the camunda-engine-rest.
The webapp module has a dependency to the camunda-cockpit-ui project. The webapp module also starts the cockpit rest layer (web.xml). It also uses the org.camunda.bpm.webapp.impl.engine.ProcessEnginesFilter to replace the $APP_ROOT placeholder in the index.html (which is in the camunda-cockpit-ui project).

How exactly can we deploy the cockpit backend independently from the user interface? Which components do we need in our backend to run the cockpit? Which components, beside the camunda-cockpit-ui, are required for the user interface?

Kind regards,
Stefan

[Daniel Meyer]

Hi Stefan,

Interesting ... :)

I don't think this easily possible, At least I have not yet seen users doing this. But that does not mean that we should not try it out :)

These are the top-level challenges I see: 

1. We assume that there is a single servlet session for all resources accessed by the application. If we split this over multiple war files we get different sessions (?) The authentication mechanism may need work in that case.
   
2. Cockpit has plugins which execute custom SQL queries against the process enigne database (as custom commands). We would have to think about where to put all that.

A different approach would be to use a standalone distribution of the webapplication (which starts it's own embedded process engine) and point that to the same database used by the "actual" process engine. You would have to turn off the job executor in that case.

Cheers,

Daniel

[ia.sre...@gmail.com]

Hi Daniel,

thanks for the quick response!

We also considered the approach with the second process engine, which shares the database with the first one (the different approach you described). It would have a some drawbacks:
* Starting a new process instance in the webapp: The webapp does not have the classes (Java delegates) which are referenced by the ServiceTasks.
* Listeners: If we re-assign a UserTask in camunda-cockpit, the (cdi-)listener for e.g. BusinessProcessEventType.ASSIGN_TASK will not be triggered in the application with the 'original' process engine.
* New cockpit plugins could not use (CDI) services provided by our application.

The approach we initially considered was to split frontend and backend and integrate the backend into the backend of our application. The frontend will be deployed independently. But if this is not possible without a significant amount of gluecode, it is not really a good alternative ;) At the latest we will get a problem when we want to upgrade to a newer version of cockpit.

Alternatively we could integrate cockpit as dependency to our application (ear). So the cockpit could find the running process engine.

Best regards,
Stefan