DEV Community: Jeya

Optimistic lock exception in Camunda engine

Jeya — Tue, 22 Nov 2022 08:44:40 +0000

Hey there!

If you want to understand the Optimistic lock exception which occurs in Camunda engine most of the times and if you would like to debug it and tweak it according to your needs, you are in the right place.
At the end of this article, you will be able to understand the reason for Optimistic lock exception occurrence and way to avoid this in Camunda engine.

Let’s get started.

Why it occurs?

Optimistic lock exception occurs in the DB when there is concurrent transaction.

For ex. There is a row in table (say R1), which is getting updated via two different transactions. That is when one transaction successfully updates the Row R1, whereas the other gets the exception.

In Camunda tables, for each row, version will be maintained (column rev_). Whenever there is an update in the row, version gets increased. So, when there are concurrent transactions, both rows get a same version of row and tries to update. One transaction’s update will be successfully done, version will be increased, whereas the other transaction’s update will fail with Optimistic exception as it is trying to update lower version of row.

Where it occurs?

In the join gateway of parallel/inclusive gateway. When the parallel processes finish at same time and both the executions reaches the join gateway at the same time, both the executions will be trying to update the job information. One of them would get success and other would get the exception.

In the tasks which is present in between parallel/inclusive gateway fork and join. If the tasks are async before or after, the When we use same variable name in both the execution, when engine tries to persist the data into DB, there is a possibility of getting the exception, both executions may try to persist the variable at the same time.

How to resolve?

1.For resolving this issue, Camunda engine has a concept of job retry. Whenever engine gets job exception, it attempts to retry the task (whichever tasks exists after last save point). This would come handy in many places. By default, number of retries will be 3. We can reduce this or disable by explicitly configuring it.
If the process is transactional and retrying the task may impact the workflow progression and there is no data dependency on the Camunda tables (Camunda variables are not used outside the current process), then we can simply disable the Camunda engine retry configuration.

Retry configuration can be done in two places,

Task level
Engine level

For configuring in task level, in BPMN process, in the async task properties, there will be Retry Time Cycle, this can be set as R0/PT5S (Retry zero times for every 5 seconds). This will override the default configuration.

For configuration in engine level, we can use below.
engineConfiguration.setFailedJobRetryTimeCycle("R0/PT5S")

2.If we implement the first solution, job will not be retried, and whichever execution gets committed first will be present in DB. This holds good for join gateway exception.
But, in case the exception is in the task in-between the fork and join gateway due to the user defined variable, this needs to be sorted out in the code. If not, one of the parallel process would get stuck in the task where it got the Optimistic lock exception and engine will assume that job is finished as the retry value would be zero.

Try to use unique variable names in the execution wherever there is a parallel process.
Configure exclusive job in the parallel process.

Hope this gives some idea on how Camunda engine works internally.

Happy debugging! 😊

BPM notations

Jeya — Sun, 20 Feb 2022 15:00:04 +0000

In previous article, we have used basic notations to create BPMN and learned about how to integrate REST API with BPMN. If you have not gone through yet, follow this link:
https://dev.to/jeyaauthithan/integrating-rest-api-with-bpmn-4mph

At the end of this article, you will be able to get a better understanding on more BPM notations and how to start the process instance.

Let’s get started!

Notations:

Send Task:
Implementation of Send task is same as service task, only difference is the way we want to represent the symbols in our BPMN. For ex. If we are making external system calls, to make it precise that request is being send, Send Task can be used.

Receive Task:
In this task, BPMN is expected to receive the data from external system. Hence, whenever execution reaches this task, it waits till someone invokes it with the response. We can have more than one ‘receive’ task in the BPMN file. Each receive task will have its own unique message name to differentiate it from each other. External system can invoke the task by correlating to its message name.

User Task:
This task specifies that we need some user inputs before proceeding with the workflow. When execution reaches this task, it waits till user completes the task with necessary inputs. This task can be completed via cockpit or internal REST API of Camunda engine.

Call Activity:
Call activity can be used to invoke a BPMN within a BPMN process. It is
same as calling a method inside another method. If there are some BPMN process
which can be reused inside another BPMN, this call activity can be configured
with the called BPMN process id.

Parallel Gateway:
Using Parallel Gateway, we can have more than one sequence flows which
will be executed in parallel. This will split the flow into concurrent paths. The
paths are executed concurrently and independently.

Inclusive Gateway:
This is combination of both exclusive and parallel gateway. The Inclusive Gateway represents the need to decide where all conditions must be evaluated. Whilst the Inclusive Gateway can be used to show that all paths must be taken, it should be used in such a way that at least one of the paths is taken.

Pool/Participant and Lanes:
Pool/Participant can be used for orchestrating the process. We can write BPMNs without Pools and lanes as well. In cases where we want to have clear view and step by step segregation of activities/tasks, we can make use of this. We can add as many lanes as we want in a pool.

Process using pools and lanes:

Embedded subprocess:
This allows us to group elements of the process. Few scenarios where we can make use of this:
• When we need to run set of tasks in loop
• When we need to use Boundary events (will see about Events in detail in next article).

Process using embedded subprocess:

How to start process instance:

As in previous article, we learnt how to deploy BPMN process, lets see how to start the process execution.

Find your process Id by opening the BPMN in the Camunda modeler and check “id” field in properties panel.
Start the spring boot application and call below end point with the process id. This is internal REST end point exposed by Camunda engine.
Method: POST
URL: http://localhost:8080/service/demo/rest/engine-rest/process-definition/key/ProcessId/start

Viola! This will create process instance for your process.

Once process instance started, all the tasks will be executed and if no failures, process instance will end.

Let’s add wait task to our BPMN and check the process execution via cockpit:

Deploy this process in the engine and start the process instance.
In Cockpit, we can see the process instances which is waiting for user action.

On click of process instance id highlighted above, we can see variables stored in the process instance.

Let’s complete the wait task and progress the process instance.

In above screen, navigate to User Tasks tab, click on the taskId and it will get you to the Camunda tasklist screen.

In this screen, on click of Claim button, complete button will be enabled. Click on complete button and we can see process instance getting completed.

Hope you understood more notations used in BPMN and how to start the process instance in this article.

Try creating BPMN with the notations you have learned so far and start the process instance and check out the behaviour. Drop a comment in case of any queries.

Let’s learn about Events and error handling in next article.

Happy Learning! 😊

Integrating Rest API with BPMN

Jeya — Tue, 15 Feb 2022 19:30:18 +0000

In previous article, we learned about how to create BPMN and set up an environment. If you have not gone through yet, follow this link: https://dev.to/jeyaauthithan/how-to-get-started-with-camunda-platform-5eik

At the end of this article, you will be able to write your own BPMN and integrate with REST API.

Let’s get started!

As we have already downloaded bpm spring boot project , Lets add below dependency in pom.xml to make use of Groovy scripting in BPMN.

      <dependency>
         <groupId>org.codehaus.groovy</groupId>
     <artifactId>groovy-all</artifactId>
     <version>3.0.0-rc-2</version>
     <type>pom</type>
  </dependency>

We have below BPMN with us which we created in previous article. Now let’s integrate it with Business logic.

T1 is the service task which can be used to integrate with REST APIs.

In Camunda modeler, Click on T1 and expand Properties panel which is present in right middle.
In properties panel we can see id, name, Implementation dropdown. Leave id and name as is and click on Implementation dropdown.

Choose “Connector” option to integrate Rest API. Upon selection, the link “Must Configure Connector” will appear.

Click on the link and you will be directed to the next tab.
Before filling the values, lets checkout the fields here.

Connector-id: We can provide “http-connector” for REST call integration and “soap-http-connector” for Soap call integration.
Input parameters: These are the parameters required to make the REST call.
url – End point of REST API
method – HTTP method (ex. GET, POST, PATCH, PUT, DELETE etc.)
headers – HTTP headers
payload – Request payload (Not applicable for GET method)

Now that you understood these input parameters, click on the “+” symbol next to Input parameters and fill the values as shown in below screenshots:

Output parameters: These are the parameters we are expecting to receive from the REST API.

statusCode – HTTP status code which denotes the request status (ex. 200, 201, 500)
headers – HTTP response headers
response – response body returned from REST API.

Let’s fill output parameters as shown in below screenshot.

Now that REST API is integrated and we have response for Checking ticket availability, We can write the logic and add condition to our sequence flow.
Add one more output parameter and store the variable with the result (preferably Boolean).

Use this variable and add condition in the Sequence flow.

We have used conditionType as Expression which will be of below format:
Format: ${conditions}
Ex. ${condition1 && condition2 || condition3}

As for second “Ticket Not available” sequence, we can either add negative condition of same flag or we can set it as default sequence flow.
Sequence flow which is marked as Default will be chosen if no other sequence flow(s) conditions are met.

Now for our T2 task, as it is script task, we can incorporate any business logic. Instead of directly integrating REST API from bpm, if we choose to do it in microservice layer, we can write the code to make Rest call in our microservice class and invoke it from bpm.

Checkout below script. utilityClass is the object of the class which contains method bookTicket.

In other script tasks T3, T4, T5, Lets simply put print statements.

How to deploy BPMN in the engine:

If you have not yet integrated the BPMN with REST API, make all the tasks as script tasks and add some print statements and try deploying it engine in by following below steps.

Place the BPMN in src/main/resources folder in the Spring boot microservice.
Start the microservice. All the BPMNS placed in src/main/resources will be deployed into engine automatically.
Open Camunda GUI URL: http://localhost:8080/service/demo/rest/camunda/app/welcome/default/#!/welcome
Login with default username and password configured in the application.yaml file
Click on cockpit

Under process definition, we can see the processes deployed. Currently we can see 1 process deployed.

On click of the process name, we can see the BPMN we created.

We can debug running and failed process instances here along with error message.
Take your time and explore the options here in GUI.

Hope you understood how to integrate REST API with BPMN in this article. Let’s see about more notations and its usages and also how to start process instance in the next article.

Happy Learning! 😊

How to get started with BPM Platform

Jeya — Tue, 01 Feb 2022 07:42:48 +0000

If you want to understand how bpm workflow engine works and start writing your own workflows for any business use case, you are in the right place. At the end of this article, you will be able to have your own environment setup for workflow engine and sample BPMN.

Let’s get started!

What is BPM engine?

BPM or process workflow engine is a engine wherein we can orchestrate the set of tasks.

It provides BPMN (Business Process Management and Notation) which can be embedded in Java applications and with other languages via REST.
BPMN is visual modelling language for Business analysis applications. Using this, we can define our workflows in much more readable way.

In this article, we will be using BPM engine offered by Camunda.

Software requirements

Camunda modeler: https://camunda.com/download/modeler/
Camunda platform: There are different distributions for various application servers. In this tutorial, we will use Spring boot project distribution. https://start.camunda.com/ In above link, Click on Generate project and the zip file for simple Spring boot application will be downloaded. This can be imported into any IDE (ex. Eclipse, IntelliJ).

In src/main/resources path, there will be sample process.bpmn
file. All the bpmn files we create must be placed in this path.

Now that our environment setup is ready, Let’s learn how to draw BPMN.

Some basic notations

Using Camunda modeler, we can draw BPMN and deploy the same in Camunda engine.

Start event:
This is used to specify the start of the process. Any pre
activities can be done here.
Script task:
This is used for writing any business logic or checks in the
BPMN internally.
For ex. Basic condition check or validations. Script
format can be Groovy, JavaScript, or Python.
Service task:
This is used when we want to define the logic externally and
make a call from BPMN to plug in the logic. It provides
different implementation options like Java Class,
Expression, Connector etc. Using connector, we can integrate
rest calls to external or internal APIs.

Sequence flow: This is used to denote the sequence in which process must proceed.

Exclusive gateway: As name suggests, this is used for deciding the sequence based on the certain condition.

End event: This is used to specify the end of the process.

Using all the notations we learned above, lets draw a BPMN for below use case.

Use case

Booking flight ticket for given source and destination.

Below could be the BPMN process for achieving the use case.

Here, T1 is the task to check the ticket availability and we have Exclusive gateway to determine the flow based on the result of T1. If ticket is available, we proceed to T2 or else we proceed with T5.
After T2, again there is the Exclusive gateway which will decide the sequence based on results of T2. If Book ticket task is success, proceed to T3 or else T4.

Arrows in between the tasks denotes the sequence. Note that, these arrows can be drawn in reverse as well. Wherever the arrow points will decide the flow. So, to proceed from T1 to T2, arrow must be drawn from T1 to T2 not vice versa.

By deploying above BPMN with all logics and API integration in the Camunda engine, we can test all possible scenarios. Debugging can be done easily via the GUI provided by Camunda engine. Camunda GUI offers Cockpit which can be used to debug the process if it gets failed.

This is very simple use case with basic notations used.
Camunda BPM provides much more notations to serve complex use cases.

Hope you understood some basics of Camunda and BPMN in this article. Let’s see how to create Rest API and integrate it with our BPMN and deploy to our Engine in the next article.

Few buzz words

Process: In BPM engine, every workflow is called as a process and instance of the process is called process Instance. (As in Class and Object).
Task: Task is the activity we perform inside the process.
Sequence flow: The arrows which determines the path.
Event: Represented in circles, describes something that happens during process execution. (for ex. start event, end event, error event etc.,.)
Gateway: This is used to decide the path based on data or condition.

Happy Learning! 😊