Camunda 7: Remote Process Engine Setup with External Service Tasks

The diagram above illustrates a remote process engine setup in Camunda 7. In this architecture:

• Camunda Process Engine is hosted as a separate application, handling BPMN workflow orchestration.
• Remote Applications implement the business logic for specific tasks within workflows. These applications are typically built using Spring Boot and integrate with the process engine through the Camunda External Task Client library.

How External Task Processing Works

• When a process instance reaches a service task with the implementation type “External”, the process engine creates a job.
• These jobs are assigned to a virtual queue, identified by the topic name configured during service task creation in the workflow.
• Remote applications register themselves to listen to specific topics and process the jobs using the External Task Client.
• Once processing is complete, the applications send a status update back to the process engine.

Illustration

Consider the setup where the process engine application has a BPMN deployed. The diagram above highlights:

• A virtual queue named dummyTopic, configured as the topic name for an external service task.

• A Spring Boot application equipped with the External Task Client dependency for job processing.

<dependency>
      <groupId>org.camunda.bpm.springboot</groupId>
      <artifactId>camunda-bpm-spring-boot-starter-external-task-client</artifactId>
      <version>${camunda.platform.runtime.version}</version>
    </dependency>

The application.properties file in the remote application configures the connection to the remote process engine. Essential configurations include endpoint URLs, authentication, and retry mechanisms. For instance:

camunda.bpm.client:
  base-url: http://localhost:8080/engine-rest # the URL pointing to the Camunda Platform Runtime REST API
  lock-duration: 10000 # defines how many milliseconds the External Tasks are locked until they can be fetched again
  subscriptions:  
    eligibilityCheck:
      variable-names: name,age,loanAmount,purpose,email,monthlyIncome # only fetch these variables
      process-definition-key: loanproces

The remote application’s job-handling logic includes fetching jobs from the queue, processing them, and updating the job status back to the process engine using the complete() method.

@Component
@ExternalTaskSubscription("dummyTopic")
public class TaskHandler implements ExternalTaskHandler {

 @Override
 public void execute(ExternalTask extTask, ExternalTaskService extTaskService) {

  String name = extTask.getVariable("name");
  long age = extTask.getVariable("age");
  long loanAmount = extTask.getVariable("loanAmount");
  String purpose = extTask.getVariable("purpose");
  String email = extTask.getVariable("email");
  String status = "";
  String rejectReason = "";

  System.out.println("name*** " + name);
  System.out.println("age*** " + age);
  System.out.println("loanAmount*** " + loanAmount);
  System.out.println("purpose*** " + purpose);
  System.out.println("email*** " + email);
  System.out.println("status*** " + status);
  System.out.println("rejectReason*** " + rejectReason);

  if (loanAmount < 100000) {
   status = "Rejected";
   rejectReason = "We are not approving loans less than 100000";

  } else {
   status = "Approved";
  }

  VariableMap variables = Variables.createVariables();
  variables.put("status", status);
  variables.put("rejectReason", rejectReason);

  extTaskService.complete(extTask, variables);

 }

}

Correlating Camunda 7 and Camunda 8 Architectures

Camunda 8 introduces the Zeebe Cluster, which serves as a scalable and distributed workflow engine. The Zeebe Cluster can be compared to the remote process engine setup in Camunda 7. Let’s examine key similarities:

Zeebe Cluster vs. Remote Process Engine:
In Camunda 8, the Zeebe Cluster handles workflow orchestration, akin to the process engine in Camunda 7.

JobWorkers vs. External Task Client:

• In Camunda 8, JobWorkers use the Zeebe Client library to subscribe to topics and process jobs.
• Similarly, in Camunda 7, External Task Subscriptions via the External Task Client library are used to process jobs assigned to specific topics.

Key Comparison:

Workflow Engine: Camunda7 -Process , Camunda8-EngineZeebe ClusterCommunication Library: Camunda7 — External Task Client , Camunda8 — Zeebe Client

Task Handling: Camunda7- External Task Subscription ,Camuna8 JobWorkers

Topic Subscription: Camunda7 — Virtual Queue in Service Tasks , Camunda8 — Zeebe Topics

Conclusion

The external service task model in Camunda 7 provides the flexibility to implement distributed and decoupled architectures, where task-specific logic resides in separate remote applications. Similarly, Camunda 8, with its JobWorkers and Zeebe Cluster, builds upon this concept by offering a cloud-native, scalable workflow engine.

Understanding these parallels allows developers to transition seamlessly from Camunda 7 to Camunda 8, leveraging the best practices from both architectures to meet modern workflow automation needs.

DMN defines the decision logic in a visual way working along side BPMN

Similar to BPM generates XML in the backend which is understood by Camunda Engine, DMN also generates XML in the backend which is understood by engine and executes the decision models.

Basic execution flow of DMN is as below.

Input → Decision(DMN) → Result(output)

here Input can be simple one or can be an output from another DMN. Those inputs are executed and evaluated again the decision models and output will be generated.

Why DMN?

• Understood by everyone
• Easy transition from decision to the implementation
• DMN usable along with BPMN
• Transparency

What is Decision Management?

Decision management is designing , building , and managing automated decision making systems.

Define goals → Create Decisions → Develop rules → Decisions are made compliant by rules → Automate Decision making

Decision Management Goals:

Transparency: Make decision logic explicit

Efficiency: Automate decisions if possible

Agility: Implement new or changed decision logic easily

Components of DMN:

Decision Requirement Diagram(DRD):

• It is a visual representation of the structure of the decision logic
• No exact logic here
• Shows the needed input and supporting decisions

Decision Tables:

Basically rules are expressed as decision table. Once you have an input(s) , think about rules and business logic which will go into decision tables.

Below is sample Decision Table which have set of business rules which evaluates cost of azure services selected by user.

eg: When AzureService = “AzureSql” and Version = “Standard”…… then Cost of the selected service is 100.

User can select AzureService and Version using input1 and input2 variable which will be passed to decision table and executes the decison model based on the hit policy , which is defined as unique in below table. If the rule is matched then that corresponding output value will be sent in the result here it is Cost of the service selected.

We will disucss on different types of hit policy in next blog.

Here Azure Cost is the Name of the Decision Table

In the above Image AzureService is first input which is passed to Decision table using input1(you can name as you like) variable which is of type String(different types are available).

In the above Image Version is second input variable which can be passed using variable input2 which is also of type String.

In the above Image Cost is the output of the decision table which is stored in result variable ‘price’ which is of type number.

Annotations are place where we can give some description above that rule or condition etc. Which is just an information purpose only and will not impact your rule execution.

Below is the DRD for the above Decision Table.Decision ID highlighted below is important and which will be used to integrated this DRD with BPM or Invoke this Decision Table using restAPI.

Using DMN in BPM:

Now we will see how to use above DMN in BPM , for which I have created a simple BPM with one task as DMN as shown below

And below highlighted screen shows how to refer DMN and output variable from DMN in BPM. here Decision reference is the Decision ID of DRD diagram and price is the output variable and Map decision result is selected as singleEntry(TypedValue) since our output from DMN is single value. we can discuss on other types in the other blog when we discuss about diffent hit policies.

This simple work flow will take 2 inputs(input1 & input2) from the user using user task , those input variables will be used as input to DMN to execute against decision model and provide an output(Cost of azure service). The resulted output will be printed to console using script task.

In below diagram i am completing user task by providing two input values.

here input1 and input2 variables should match the values defined in DMN to get evaluated.

You can go to Decisions to see the evaluated rules.

Click on the latest Decision Instance to see how the rule was evaluated. The evaluated rule will be highlighted as below.

And the final script task will be executed and print the output in the console.

This concludes how to work with DMN and integrate it with BPM. In the next blog we will discuss about different hit policies and how to handle the different outputs form DMN.

Camunda 7 is backed by Activiti engine(Camunda was originally a fork of the Activiti project) where as Camunda 8 is on Zeebe engine(scalable both horizontally and linearly) developed by Camunda which makes it suitable for Cloud operations and automation processes.

Process solutions using Spring Boot:

Camunda 7:

To build a process solution using Camunda 7 and Spring Boot we need :

1. Java
2. Spring Boot
3. Camunda Spring Boot Starter with embedded engine
4. Java Delegates

Camunda 8:

To build a process solution using Camunda 8 and Spring Boot we need :

1. Java
2. Spring Boot
3. Spring Zeebe Starter (Zeebe Client)
4. Job Workers

Typical Deployment Difference:

Data Storage:

In Camunda 7 data was stored in a relational database which was a bottle neck for scaling to cater huge loads.

Camunda 8 uses elasticsearch which is specialized on search efficinecy , not storage. The data can be exported into a datasource of your choice. Exporter simply takes the data from zeebe engine and puts it into elasticsearch.

Communication:

In Camunda 7 communication with engine was either through RestAPI or Java SDK in case of embedded engine.

In Camunda 8 communication with engine is via Zeebe Gateway which uses gRPC Api which will be used to start , fetch or complete a task.

Web Modeler:

Integrating Modeler with the engine in Camunda 7 was technically challenging and user-unfriendly. Camunda 8’s cloud-based Web Modeler is a lot more user-friendly.The new modeler greatly supports collaboration, since it doesn’t require Cawemo, but instead, offers separate tabs for the different roles It also offers play and design modes, as well as an AI generator for user task forms.

Connectors:

Camunda 8 introduces pre-built connectors to simplify communication with external systems in workflows. These reusable connectors will save developers time and effort. While Camunda provides some connectors, users can also build their own for internal systems. Importantly, this doesn’t restrict developer flexibility — Camunda 8 isn’t aiming to be a low-code platform. There’s an extensive connector marketplace that also includes partner-built connectors. Where as Camunda 7 does not have such in built connectors .

Operations :

The functionalities provided by Operate in Camunda 8, the equivalent of Cockpit in Camunda 7, is more limited. It’s currently impossible to suspend the execution of specific process steps, although the version is continuously being developed to include new features like retriggering task executions and manipulating stuck instances.Process instance migration is also significantly limited in Camunda 8.

Embedded Engine:

In Camunda 7, the workflow engine operates in a tightly coupled manner with your application. It achieves this by being embedded as a library within the same Java Virtual Machine (JVM). This co-location allows for shared resources, including thread pools and even the data source and transaction manager.

Camunda 8 workflow engine, Zeebe, functions as a separate, remote resource for your application. The key implication is the inability to directly share ACID transactions between your application code and the workflow engine, which means you’ll have to handle data consistency differently when planning the migration.

Scripting:

Camunda 7 allows the implementation of scripting tasks in Groovy, JavaScript and several other programming languages, which allows developers to write custom logic and perform complex operations directly within the workflow.

With Camunda 8, only FEEL script is allowed in script task activities. It aims to provide a more standardized, simplified, and optimized approach to workflow automation. However, this limitation may require developers to adapt their existing scripts and may not be suitable for all use cases. In situations where more complex or custom logic is required, developers may need to explore alternative approaches, such as implementing external services or using other extension points provided by Camunda.

Above are some of the differences between Camunda 7 and Camunda 8 .

Here we will work on embedded process engine setup using spring boot like below:

How to create Camunda spring boot project:

1. https://start.camunda.com/ its similar to spring initializer , its a quick start process to help create sample application with required dependencies

2. Or you can use Spring Initializer to create normal spring boot project and add Camunda related dependencies manually and add BPMN file in resources folder.

Using start.camunda.com select the modules which you are interested in and select the Camunda version and spring boot version. You can also set admin username and password here.

Once project is generated you can import to your IDE like STS or VSCode etc.

Open your bpmn file using Camunda modeler and start to create your work flow.

Here I have created multiple script tasks and service tasks.

Script Task: Inline JavaScript

Above highlighted is the script task with script format as JavaScript and type as inline. And script is just to print text in console.

Script Task: Inline Script to print JSON object

Above highlighted is the other script task with script format as javascript and type as inline script and in the script we have created a JSON object and printing it to console and this result is stored in result variable as UserObject, which can be used in rest of the flow and process business logic using this object.

Script Task: External JavaScript Resource

Above is the script task with type as external resource. Resource represents a js file which is present in resources folder of spring boot project.

var studentObj = {
     name: 'John',
     age: 25,
     subject: 'English'
     };
     
     var studentJson = JSON.stringify(studentObj);
     
     print(studentJson);
     print("Printing User Object from previous script task:::"+JSON.stringify(UserObject));
     print("Printing Global User Object from previous script task:::"+JSON.stringify(globalUserObj1));

Here in the js file we are priniting studentJson object , as well as printing UserObject which was created as result object in previous script task.

Service Task: Java Delegate

Above is the service task with implementation as Java class , here we have give reference to java class with complete package name and implementation details as follows.

package com.example.workflow.delegate;

import org.camunda.bpm.engine.delegate.JavaDelegate;

public class TestDelegateWithJava implements JavaDelegate{
 
 @Override
 public void execute(org.camunda.bpm.engine.delegate.DelegateExecution execution) throws Exception {
  System.out.println("TestDelegateWithJava executed");
 }

}

This is the java delegate class where we have to implement JavaDelegate and override execute method. DelegateExection object will hold all the key elements about runtime and process variables and global parameters which can be used and can be passed on to next elements in the flow.

Service Task: Delegate Expression

Above is another way of implementing serivce task using Delegate expression, advantage of this way of implementation compared to java class is that in case if there is any change in package structure and you move the class it will not break the service task implementation as it uses expression to find the class.

package com.example.workflow.delegate;

import org.camunda.bpm.engine.delegate.DelegateExecution;
import org.camunda.bpm.engine.delegate.JavaDelegate;
import org.springframework.stereotype.Component;

@Component
public class TestDelegateExecution implements JavaDelegate {

 @Override
 public void execute(DelegateExecution execution) throws Exception {
  System.out.println("TestDelegateExecution executed");
 }

}

Serivce Task: Expression

Above is the another way of implementing service task using expression , here we can refer any of the existing java class method like service class or util class etc.

package com.example.workflow.service;

import org.springframework.stereotype.Service;

@Service
public class SimpleService {
 
 public String generateMessage() {
  System.out.println("SimpleService executed");
  return "Hello World";
 }

}

Service Task: HttpConnector — Get Implementation

Here were are using Camunda http-connector to make GET API call, you can use input parameters and output parameters under connector section.

Input parameters is to set URL , request body etc. and output parameters is used to receive response and process it.

ServiceTask: Http-Connector- POST method

Starting the process instance:

@GetMapping("/getTest2")
 public String test2() {
  ProcessEngine processEngine = ProcessEngines.getDefaultProcessEngine();
  ProcessInstantiationBuilder instantiationBuilder =  processEngine.getRuntimeService().createProcessInstanceByKey("FirstProcess");
  
  instantiationBuilder.setVariable("name", "ALEX");
  instantiationBuilder.executeWithVariablesInReturn();
  
  return "Started Process Instance!!";
 }

you can start the process instance using Java SDK by using Camunda runtime services like above.

Rest API method:

POST: http://localhost:8080/engine-rest/process-definition/key/FirstProcess/start

Body: {}

you can use Camunda provided rest api support like above where FirstProcess is the proces instance key of our workflow. Here i gave body as empty but based on the requirement we can pass the process variables as well.

In this article we will learn about BPMN and its benefits, recognize most commonly used BPMN elements and model a simple BPMN diagram.

BPMN in Context: Business Process Management(BPM) is a systematic approach for designing, executing, documenting , monitoring and controlling both automated and non automated processes.

What is BPMN? Business Process Model and Notation(BPMN), is an open standard notation for business process modeling and process automation. BPMN specifies an agreed set of symbols for process modeling simple or complex business processes.

Why you should use BPMN? The most important benefit is that it provides a common language for all stakeholders in an organization. It provides a graphical representation of a business process that anyone, from business analyst to developers to stakeholders can easily understand, aiding in business process analysis and business process improvement.

BPMN diagrams are represented in xml, which allows them to be executed by process engine allowing developers to easily implement and deploy the process. Where as business analyst can easily create and improve process diagrams using visual elements that anyone can understand. Developers are responsible for the technical implementation of process , Managers can monitor and control the processes.

BPMN Elements:

Any BPMN process consists of number of steps or activities which can be performed in sequential or in parallel according to business rules. In BPMN processes are described using diagrams containing series of graphical elements such visual representation makes it easier for users to understand the logic of the process. BPMN classifies the elements by categories so users can easily recognize them.

1. BPMN Flow elements:

Events: They describe things that happened before ,during or end of the process. They can happen regardless of the process or as a result of the process , you can react to events or trigger events.

Tasks: This is a step in the process an activity that needs to be done.

Gateways: These are elements helping us present multiple paths in a process

2. BPMN Connecting Elements:

Sequence Flows: This shows the order of elements in process

Simple BPMN Flow:

Start Event:

A start event shows which event causes the process to start and it happens regardless of the process. It is labeled “Order Received”. As a best practice, when you label an event use the past tense because the action already happened when the event triggers.

Intermediate Event:

This stands for a status reached in the process and that is modeled explicitly. As a use case, if you regard reaching a certain status as a milestone and you want to measure the time until the milestone is reached.

End Event:

This represents the end of the process. It is possible to have one or more end events in a process. A use case multiple end events would be conditional process which can take different routes based upon business rules.(e.g Order Accepted or Order rejected)

Task :

This is a step in the process , an activity that has to be done. In this example after receiving the order you have to send a confirmation. This task is labeled “Send Order Confirmation”. As a best practice, when you label a task in a diagram always use a verb+ object.

Gateways:

We will discuss on most used Gateways which are Exclusive Gateway (XOR) and Parallel Gateway.

1. Exclusive Gateway(XOR):

This is a Data-Based decision gateway , which means the decision does not happen in the gateway but it only evaluates available data. We have to choose exactly one outgoing sequence flow. It is not possible to continue in both directions.And exclusive gateway can be used in cases to split or merge the flow as show in process model below.

2. Parallel Gateway:

This is not based on a decision but only defined through the incoming and outgoing sequence flows. It is used to parallelization of flow or as well of synchronization of flow which is shown as below.

This concludes this article on what is BPMN and commonly used elements of BPMN. In next article we will some advance elements of BPMN. If you want to Camunda and its Ecosystem here is the link for my previous article here.

Camunda BPM is a Java based framework which is implementer of BPMN 2.0 specifications.
It is a light weight open source platform for business process management.
It is used for modeling and executing BPMN(Business processes workflows) , CMMN (Case Management)and DMN (Decision Management).
It provides a native API and also supports the standard BPMN 2.0 API. It is highly scalable and can handle high volumes of process instances and tasks.
Camunda BPM is a flexible framework for workflow and process automation. It’s open-source and written in Java, allowing it to be embedded into Java applications or used as a standalone process engine server.

Here are some key features of Camunda:

1. BPMN 2.0, CMMN 1.1 and DMN 1.3: Camunda supports these standards for defining and executing business processes, case management models, and decision tables, respectively. This means you can model your processes using these widely accepted standards and execute them directly on Camunda.
2. Java API and REST API: Camunda provides a native Java API that allows you to start, stop, and interact with business processes from within your Java applications. It also provides a REST API that allows you to interact with the process engine from any programming language.
3. Scalability: Camunda is designed to be highly scalable. It can handle a large number of process instances and tasks, making it suitable for high-load scenarios.
4. Embeddability: Camunda is designed to be embedded into Java applications. This means you can include the Camunda libraries in your application and use the Camunda engine as part of your application.
5. Web applications: Camunda comes with web applications for monitoring and managing business processes. These include the Camunda Cockpit (for process monitoring and operations), the Camunda Admin (for user and group management), and the Camunda Tasklist (for task management).
6. Extensibility: Camunda is designed to be extensible. You can add custom logic to your business processes by writing Java code that interacts with the Camunda engine.
7. Spring and Spring Boot integration: Camunda provides integration with Spring and Spring Boot, making it easy to use Camunda in Spring applications.
8. Microservices orchestration: Camunda can be used to orchestrate microservices. You can model your microservices interactions as BPMN processes and execute them on Camunda.
9. Business-IT alignment: Camunda allows for a strong alignment between business analysts and developers as both can work on the same models. Business analysts can create models using the Camunda Modeler, and developers can take those models and easily execute them with the process engine.

We can divide Camunda Ecosystem into two parts

1. Model
2. Execute

Model: This is were we can use Camunda Modeler or Eclipse BPMN2 Modeler or bpmn.io to model our workflows there are also latest collaborative modeling tool like Cawemo that facilitates the design and specification of BPMN diagrams in a collaborative manner, bridging the gap between business analysts and developers.

Execute: This is the main part of camunda which has components like TaskList, Cockpit, Admin, Camunda Engine, Database etc..

Tasklist is a web application provided by Camunda for managing and working on user tasks. It’s part of the Camunda BPM platform and is designed to be used by end users who are responsible for completing tasks in business processes. Key features include Task Management, Task Filtering, Forms, Process Interaction, Identity Management etc..

Cockpit is a web-based administration tool that allows you to monitor and manage business processes and decisions in a Camunda BPM platform. It’s primarily designed for technical users such as system administrators and developers. Key features include Process Instance monitoring and modification , Job Management, Decisions, Batch operations etc..

Admin is primarily designed for system administrators and provides features for managing users, groups, authorizations, system settings, integration with LDAP & Active directory etc..

Engine is the core component of the Camunda BPM platform. It’s a lightweight, open-source workflow and decision automation engine written in Java. The engine can execute BPMN 2.0, DMN 1.3, and CMMN 1.1 models, The engine provides a Java API and a REST API for interacting with the engine. You can start and stop process instances, complete tasks, query for tasks and process instances, and more.The engine supports both local and JTA transactions. It can participate in existing transactions or create new transactions as needed.The engine provides integration with Spring and Spring Boot, making it easy to use Camunda in Spring applications.

Database — Camunda BPM platform uses a relational database to persist process instances, history data, and other runtime data. It supports a variety of relational databases like MySQL , PostgreSQL, MariaDB, Oracle, DB2, MSSQL, H2, CockroachDB etc..

It’s important to note that the choice of database can have an impact on the performance and scalability of your Camunda installation, so it’s worth considering your database choice carefully. Also its important what level of history we need and what are the task variables we are saving will also have an impact on performance. You can reach out to Camunda Community or enterprise to get indexes that helps improve the performance.

Hope you like this article on high level overview of Camunda and its Ecosystem. See you in next article….

Steps to Install and Setup Camunda on a Wildfly Server:

We’ll be using Camunda version:7.8 and Wildfly server:10.1.0 in this tutorial.

• Install Java and set environment variables.
• Connect to your VM using putty and run the below commands.

#JDK installation - - - - - - - - - - - 
sudo apt-get install -y openjdk-8-jdk
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/
export PATH=$PATH:/usr/lib/jvm/java-8-openjdk-amd64/bin

• Download camunda-bpm-wildfly10-7.8.0.zip/camunda-bpm-wildfly10-7.8.0.tar file.
• Navigate to /opt/camunda/server/wildfly-10.1.0.Final/standalone/deployments and add the war file.
• Run start-camunda.sh in/opt/camunda directory.
• To run Camunda as a background process: ./start-camunda.sh
• By default, Camunda will use in-memory H2 DB for storing the process details.

Steps to Connect to MySQL DB:

• Run the scripts present in below directory by selecting the files related to MySQL.
• Once the tables are created, navigate to the /opt/camunda/server/wildfly-10.1.0.Final/standalone/configuration/standalone.xml file.
• Add the Ccamunda subsystem as an extension:

<server xmlns="urn:jboss:domain:1.1">

  <extensions>

    ...

          <extension module="org.camunda.bpm.wildfly.camunda-wildfly-subsystem"/>

• Create a data source to connect to MySQL under the data sources section

<datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
    <connection-url>jdbc:mysql://*hostname*/*dbname*</connection-url>
    <driver>mysql</driver>
    <security>
        <user-name>*username*</user-name>
        <password>*password*</password>
    </security>
</datasource>
<datasource jta="true" jndi-name="java:jboss/datasources/ProcessEngine" pool-name="ProcessEngine" enabled="true" use-java-context="true" use-ccm="true">
    <connection-url> jdbc:mysql://*hostname*/*dbname*</connection-url>
    <driver>mysql</driver>
    <security>
        <user-name>*username*</user-name>
      <password>*password*</password>
    </security>
    <validation>
        <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker" />
        <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter" />
    </validation>
</datasource>

• Under drivers add a MySQL driver.

<driver name="mysql" module="com.sql.mysql">
    <driver-class>com.mysql.jdbc.Driver</driver-class>
</driver>

• Navigate to /opt/camunda/server/wildfly-10.1.0.Final/modules/com/mysql/driver/main and add mysql-connector-java-5.1.45-bin.jar and module.xml
• In module.xml, add the below content.

<?xml version="1.0" encoding="UTF-8"?>

<module xmlns="urn:jboss:module:1.1" name="com.sql.mysql">
    <resources>
        <resource-root path="mysql-connector-java-5.1.45-bin.jar" />
    </resources>
    <dependencies>
        <module name="javax.api" />
        <module name="javax.transaction.api" />
    </dependencies>
</module>

• Change the subsystem IP to point to the VM’s internal IP.

<wsdl-host>${jboss.bind.address:*IP*}</wsdl-host>

• And also change the management interface’s IP to point to the internal IP.

<interfaces>   
  <interface name="management">        
    <inet-address value="${jboss.bind.address.management:*IP*}" />    
  </interface>    
  <interface name="public">     
    <inet-address value="${jboss.bind.address:*IP*}" />   
  </interface>
</interfaces>

That’s it you are done with running your Camunda Bpm connecting to MySql as Database.