Home

The VanillaBP Business Cockpit

The Business Cockpit is the application business people work in. It lists the user tasks somebody may work on and the business cases those tasks belong to, and it shows each case's own forms and pages inside its own screens. Like VanillaBP itself it is BPMS-agnostic, so tasks from Camunda 7, from Camunda 8 and from any other engine end up in one list. A system which runs no workflow at all can report tasks as well. Such a task points at a page of the application it came from, and opening it takes the user straight there.

It is a microservice of its own. It runs no workflow and processes no business data. The applications which do are called workflow modules, and each of them reports its user tasks and its business cases to the cockpit, serves the forms for them, and answers the questions the cockpit asks about them. The cockpit holds what they report, as a copy it can search and sort.

So a workflow module needs no web application of its own for its user tasks. And nobody has to walk through one application after the other to find out what is to be done. Every application offers work, and without one place to collect it, each user has to gather it and then sort out for themselves what is urgent and what can wait.

If you only want to see it running, read Running the Business Cockpit and start the jar. If you are about to connect an application to it, Connecting a workflow module is where that starts. Everything else on this page is the reading order.

What it does

The cockpit shows two lists, and both of them are filled by what the workflow modules report.

The list of user tasks holds what the logged-in user may work on: the tasks assigned to them, the tasks their groups are candidates for, and the tasks nobody said anything about. Opening a task loads the form from the workflow module which owns it. A task which points at another application carries the whole address of a page in that application instead, and opening it takes the user there, in a window of its own. Saving and completing the form is the workflow module's own business, and the cockpit hears about the result the same way it hears about everything else, as a report.

The list of business cases holds the workflows a user may see. Opening one loads a status site from the workflow module, which may tell about the details of the case and where it stands, and may offer actions on it, cancelling it for instance. Both lists take their columns from the business data the workflow module reported, so a column can hold a customer name or an amount, and a user can search, sort and filter by it.

Around the two lists the cockpit adds what a single workflow module cannot do on its own. It holds one login for everything a user sees. It passes the user on to every workflow module it reaches, so a form can adapt to who is looking at it. It sends notifications about new work. And it updates a list while somebody is looking at it, without a reload.

What it is not

It does not run workflows. A case appears in the cockpit because a workflow module reported it, and it disappears the same way.

It does not own business data. What a list column shows is a copy of what a workflow module sent, kept so the list can be searched and sorted. The truth stays in the application.

It does not start a workflow either. A button which starts one belongs to a workflow module, and the cockpit is only the place it is shown in.

Where to read on

Getting started

1. Architecture
   The cockpit next to the workflow modules, the proxy, the path a report takes, and why the store is a document database.

Operating it

1. Running the Business Cockpit
   The jar, the MongoDB behind it, the profile local with its demo users, and how a first start tells you what is still missing.
2. Security
   Logging in, how a user reaches a workflow module, which cases and tasks that user gets to see, and how to put an identity provider in front of it.
3. Configuration
   Every key the cockpit server reads and every key a workflow module reads, and the four levels a value may be written at.

Building a cockpit of your own

1. Building a custom Business Cockpit
   The library next to the container, what an application of your own has to write, and the configuration it brings itself.
2. Customizing the user interface
   The delivered React application as an example, how far a copy of it gets you, and what a user interface of your own has to answer.

Connecting a workflow module

1. Connecting a workflow module
   The one dependency, how a module registers itself, and the two ways its reports travel.
2. Reporting workflows and user tasks
   The provider methods your business code writes, the business data a list column is filled from, and reporting a change from your own code.
3. Templates
   Rendering titles and search texts from templates, per language, and what a template is handed.
4. User task forms and status sites
   Serving a form through module federation, the components of bc-shared, and the columns of the two lists.
5. Developing UI components locally
   The dev shell for React and for Angular, and the dev shell simulator which stands in for the cockpit.

Versions

1. Migrating from version 1
   What an application on the version 1 cockpit adapters has to change.
2. Releases
   Which cockpit version goes with which VanillaBP version, and what each release asks of you.

Each page assumes the pages above it and nothing below it, so reading in this order never leaves a term unexplained.

Three more wikis sit next to this one, one per BPMS. They describe what the cockpit's own half for that engine does, and they assume you have read the pages here: Camunda 7, Camunda 8 and the Process-Engine-API.