BPMN

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

Camunda is an open-source, Java-based BPMN engine, compliant with the BPMN 2.0 specification, that provides intelligent workflows. Aarna.ml 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:

  • Case Management Model and Notation (CMMN 1.1) - this is a standard for modeling cases, while BPMN is a standard for modeling processes
  • Decision Model and Notation (DMN 1.1) decisions - this is used to configure any rules, which are required for the given use cases or for storing any configuration for a given use case.
  • Default support for Javascript & Groovy based tasks

●     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:

  1. Modeler - It is the Camunda UI or desktop application where we design the processes. This comes under the design phase.
  2. Task List -This is an out-of-the-box web application tightly integrated with Camunda. When we deploy any process as a user task, then it can be seen in the Task List.
  3. Cockpit - It is a web application used for process monitoring, e.g., if we have      deployed any process and it is still running, then through the cockpit, we can check the status of the process.
  4. REST API - It is used to interface with external components. Its goal is to provide      access to the engine interface.
  5. Custom  application - Using this we can have our own applications and through REST API, we can access all the engine interfaces.

                                          Fig 2 - Camunda Process Engine Architecture

Engine interfaces connect to the database which stores all the process states.

ONAP CDS Definitions and Concepts

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:

  1. Data Dictionary - A list of parameters that need to be resolved during runtime.
  2. Resolution - Provides value to a configuration parameter during runtime. The source of these values can be through input, set as default, fetched through REST,      SQL and many more.
  3. Configuration Provisioning - Used for complex interaction with south bound APIs. CDS provides us workflows (in ONAP directed graph format) and scripts (Kotlin, Python).
  4. Modeling - Used for defining data dictionaries, resolution mechanism, workflows, and scripts, which are part of provisioning. CDS uses TOSCA and JSON for      modeling and all the model information is stored as CBA (CDS Blueprint      Archive).

Camunda and CDS Interaction Diagram (Synchronous)

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

Camunda and CDS Interaction Diagram (Asynchronous)

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

‍