Cockpit Tasklist and Admin - camunda-community-hub/vanillabp-camunda7-adapter GitHub Wiki

Camunda ships web applications which let you look into a running engine. Cockpit shows instances and incidents, Tasklist shows the user tasks, and Admin shows users and authorizations. An extra module serves them for the engines VanillaBP built:

<dependency>
  <groupId>org.camunda.community.vanillabp</groupId>
  <artifactId>camunda7-adapter-spring-boot-webapps</artifactId>
  <version>2.0.0</version>
</dependency>

That is the entire setup. The applications are served at /camunda, and every engine VanillaBP built for a camunda7 adapter id is offered there. Spring Boot only, see Deviations.

This module switches off Camunda's own engine auto-configuration, because VanillaBP owns the engines. So camunda.bpm.enabled is false by default here. If you set the property to true, the start fails with a message which says so.

1. The engine name is part of the URL
   Which engine a URL addresses when several adapter ids are configured.
2. Logging in
   What the module does about users and authorizations, and what it leaves to you.
3. Configuration keys
   The keys this module reads.

VanillaBP names an engine after its adapter id. So in an application with the id camunda7, Cockpit is at

http://localhost:8080/camunda/app/cockpit/vanillabp-camunda7-camunda7/

Nobody has to type that. /camunda redirects to the right application of the right engine. With several adapter ids, all of them appear in the engine switcher of the web applications. This is what a BPMS migration with two engines looks like from the outside.

The web applications need a user. If no user is a member of the group camunda-admin, they open their setup wizard instead of a login. If your application has no identity provider yet, the module can create an administrator from the configuration:

vanillabp:
  adapters:
    camunda7:
      webapps:
        admin-user:
          id: demo
          password: demo
          first-name: Demo
          last-name: User

On the first start, the module creates the user if it does not exist yet and makes it a member of camunda-admin. That group gets every permission on everything the engine knows. A line in the startup log says so, because a user with full permissions should not be a surprise later.

If you leave admin-user out, this module creates nobody. Use that for an application which manages its own users, through Camunda's identity service, an LDAP plugin or a custom identity provider.

All of them sit under the adapter id, like every other setting of an adapter instance: