In the previous blog, How the IT Guys Can Help or a Brief Guide to Process Analysis, we used the BPMN standard to document the current State of the process and also to design a new method in which we solved the customer’s problems and requirements.

One advantage of using BPMN is the direct transition from analysis through design to solution implementation.

This is made possible by the so-called BPMN engines. A BPMN engine is a software component that can interpret a drawn BPMN model. It provides tools for engaging systems responsible for solving a process’s technical tasks and support for the specification and processing of user tasks by user-defined roles. If a customer needs to automate and streamline business processes and does not have a more extensive information system to cover them, deploying a BPMN engine is the optimal solution.

Several BPMN implementations, built on different technologies and of varying quality, are available on the market. See, for example, the comparison at https://www.itcentralstation.com/categories/business-process-management. In the past, we used jBPM, but in the last few years, we switched to the Camunda solution and are thrilled with it.

Camunda is a package of tools called the Camunda platform, which covers activities ranging from process analysis (DESIGN) through the deployment of modelled processes as part of information systems (AUTOMATE) to the optimisation of their performance (IMPROVE):

As usual, the Camunda platform is available in free Community and paid Enterprise versions. I have marked the different tools in the previous figure with colour:

1.  The red ones are only in the Enterprise version
2.  Orange is also in the Community version but with limited functionality
3.  Green is also fully functional in the Community version

The great thing is that the Community version is so broad, functional, and documented that we have successfully implemented several projects with it.

This blog is about using the Community version of the Camunda platform. I will introduce you to:

1.  Camunda Modeler – a process drawing tool
2.  Camunda Engine is a component for deploying drawn processes. We will take a closer look at this one:
   1.  Recommended technology stack – what can we mix it with
   2.  Database transactions – how it got down there
   3. Deployment options – what different situations can it handle
   4. Hardware requirements – how much iron it will eat
3.  Camunda Cockpit – a tool for monitoring deployed processes

I won’t introduce the tasklist, as this one is too austere for commercial use, but we’ll implement our nicer tasklist using Angular.

Camunda Modeler

Camunda Modeler is a very nice, fully functional BPMN editor. It provides all the elements of the BPMN 2.0 standard:

The different parts of the Camunda Modeler:

• A – On the top left is a panel with BPMN’s main elements (events, gates, tasks, subprocesses, data objects, pools, etc.).
• B – To the right of the selected element, icons are displayed through which we can:

• •  Continue by selecting the next element – top 2 rows of icons – see displayed context menu – C
  •  Specify the type of drawn element – key icon
  •  Cancel element – trash icon

• D – In the right part, it is possible to fill in the parameters of the selected element

In Camunda Modeler, it is possible to edit BPMN models drawn using other analysis tools as long as they meet the BPMN 2.0 standard. For example, we have successfully tested it with the widely used Enterprise Architect tool. In addition to saving to BPMN files, drawn models can be exported as images, a handy functionality when creating documentation.

Camunda Engine – recommended technology stack.

Vendor-recommended components working with the BPMN engine (the so-called technology stack) are sufficient for most medium-demanding projects:

The different layers of the architecture:

Camunda Engine – database transactions

The State of a given process instance persisted in the relational database and was changed in database transactions bound by the executing process’s wait states. For example:

In this process, the persistent State of the process is altered if the operations from the completed user task (Provide shipping address) are successfully executed

To the timer (wait until the next business day). If an exception occurs within these operations, the process run continues processing this exception or remains in an error state = incident.

Wait states that separate transactions of the process they are waiting for:

1.  a specific message (addressed to this process instance)
   • Modelled by BPM elements: Receive Task, Message Event, Event-based Gateway,
2.  a specific signal (intended for a defined group of instances)
   • Modelled by BPM elements Signal Events, Event-based Gateway,
3.  user task completion by the user
   • Modelled by the BPM element User Task,
4.  expiry of the specified time
   • Modelled by the BPM element Timer Event,
5.  performing a published task
   • Modelled by the BPM element: External tasks

Transactions can also be controlled by BPMNelement parameters, but that is beyond the scope of this blog.

Camunda Engine – deployment options

Depending on the size, architecture and requirements of the system on which the Camunda Engine is deployed, three deployment options are supported:

Type	Architecture	Description
Embedded		The Process Engine is deployed as a library within the Java application. The Java application utilizes its services through the provided Java API.
Standalone Process Engine server		The Process Engine is deployed on a separate server. Applications from other servers use the Process Engine’s services as a network service. In such a deployment, the provided REST API interface can be utilized. A different communication layer can be built on top of it (e.g., SOAP WS, JMS, etc.) if necessary.
Shared within the container		The Process Engine is deployed as an application to an application server. Applications deployed on the server use the Process Engine’s services as application server services. Supported application servers: Apache Tomcat 7.0 / 8.0 / 9.0 JBoss EAP 6.4 / 7.0 / 7.1 / 7.2 Wildfly Application Server 10.1 / 11.0 / 12.0 / 13.0 / 14.0 / 15.0 / 16.0 / 17.0 / 18.0 IBM WebSphere Application Server 8.5 / 9.0 (iba Enterprise Edition) Oracle WebLogic Server 12c (12R1,12R2) (iba Enterprise Edition)

Camunda Engine – hardware requirements

Factors that define Camunda Engine hardware requirements:

Recommended hardware configurations as required:

Camunda Cockpit

Camunda Cockpit is an administration interface implemented in the form of a web client, through which it is possible to monitor running process instances and resolve their incidents. After logging in to Camunda Cockpit, a general overview of the Camunda Engine status is displayed:

Displays the number of deployed processes, running instances, the current number of incidents, instances of processes stuck in an error state, and the number of user jobs entered. Selecting Running Process Instances (highlighted in red) will take you to a breakdown of the deployed processes:

Meaning of table columns:

1. State = State of the instances of the process. Options:
   1. some cases are in an error state
   2. there are no incidents in the instances of this process
2. Incidents = Number of instances of the process/subprocess in error state = incident
3. Running Instances = Number of all instances of the process. Instances in an error state are also included.
4. Name = Name of the deployed process or subprocess

When you click on (Name) of the selected process, the process model is displayed:

Elements that are defined as pending (see the Database Transactions chapter) are showing as

1.  the number in the blue circle = the number of instances of this process that are waiting in the given element,
2.  number in the red circle = number of instances of this process that have reached an error state in this element = incidents

If the element is a subprocess, these numbers are the sum of its wait elements. We can nest into it and see the distribution of its instances and incidents in detail:

The table below lists these instances. By clicking on the ID of the selected instance, we can view the current values of the process variables, change their values, and resolve incidents in this way.

Roman IT guy