Business Process Management Notation (BPMN) is a process modeling standard owned by the Object Management Group (OMG), a standards development organization. BPMN has become the de facto standard for understanding business process diagrams. The stakeholders of BPMN are people who design, manage, and realize business processes. BPMN diagrams are then translated to software process components. It provides businesses with the capability to understand their internal business procedures using a graphical notation and it uses an XML schema-based specification.
Camunda is an open-source, Java-based BPMN engine, compliant with the BPMN 2.0 specification, that provides intelligent workflows. Aarna Networks uses a Camunda modeler, which is a UI to design the workflows.
There are different Camunda components:
● Open source BPMN engine compliant with BPMN 2.0 specifications
● A Java-based framework providing intelligent workflows
● A camunda Modeling UI to design workflows
● A Java-based process engine library responsible for executing BPMN 2.0 processes:
● Uses relational database for persistence - This stores all state related information.
Camunda Modeler is a UI for designing workflows with drag and drop notations.
Fig 1 - Camunda Modeler
Camunda Process Engine Architecture has multiple components:
Fig 2 - Camunda Process Engine Architecture
Engine interfaces connect to the database which stores all the process states.
CDS (Controller Design Studio) is a framework which is used to automate the resolution of the resources for instantiation and any configuration provisioning operation. There are different concepts in CDS:
In this synchronous process, the actor calls the workflow, using REST API or through the UI. This will call CBA workflow1, which is deployed in the CDS. Thus in runtime we trigger the CBA. CBA returns some value back to the Camunda workflow. Again wecall the CBA workflow2., which returns the response. In the Camunda workflow we can consolidate all the responses we received from the CBA and then return it to the consumer in a particular format as required. Each process will have a unique ID. In each response we will find the response ID and relevant response data.
Fig 3 - Camunda and CDS Interaction Synchronous
The consumer will call a workflow, which would be defined as asynchronous. It immediately returns the response to the user with the Process UUID and in the background it will call the CBA configured here in the workflow and store the responses in the Camunda workflow cache. At the end it will be stored in the relational database. If we want this user to send back this response through some REST API, which the user has exposed, we can send the response.Users can use either standard Camunda REST API to get the status of this workflow and get the response data using standard REST API exposed by Camunda. If we have CBAs which are long running, we will use asynchronous interaction.
Fig 4 - Camunda and CDS Interaction Asynchronous
For more information -
https://docs.camunda.org/manual/latest/
https://camunda.com/best-practices/invoking-services-from-the-process/
https://docs.camunda.org/manual/latest/reference/bpmn20/
Below is the link to our webinar on the same topic, it includes the demo as well -
https://www.youtube.com/watch?v=tSMan-0ENy0&t=1099s