We will convert everything we implemented with Camunda 7 to Camunda 8. Make it work and run in our cluster!

We continue where we left – Make Use Of My Local Camunda 8 Cluster.

Preparing the BPMN model

Polishing my old BPMN model made for Camunda 7

Let’s take a look at the BPM model I created for one of the previous posts Camunda on Oracle Cloud – will it work?:

There is one change that has to be applied immediately. The activity Store invoice is doing nothing in the above model. This won’t work in Camunda 8. Let’s convert it in to a Script Task, that would print something to the console:

And this is how the script can be provided directly in the Modeler:

More complex scripts can be added to the BPMN file if needed, but for testing purposes, this would be enough. Here is also a link to the documentation – https://docs.camunda.org/manual/7.18/reference/bpmn20/tasks/script-task/

And after we deploy it to the server and start the process, we will see the following in the engine log file:

This prints to the console. Date = 1675368717649
This prints to the console. Date = 1675421469210
This prints to the console. Date = 1675421505432

And, just for fun, this is the console output of our small Create Invoice service:

Client_1 –> completed task aaa5d668-a3b0-11ed-a97c-1e2a4b590b03
Starting handler…
Handler done
Database connected, making query
Closed database client connection
Query done, do the business logic and report success back to the engine
Success reported to the engine
✓ completed task c046a45d-a3b0-11ed-a97c-1e2a4b590b03
Client_1 –> completed task c046a45d-a3b0-11ed-a97c-1e2a4b590b03

Let’s discuss what actually happens here.

In our Create Invoice application, which in fact, a Service Task, we set the variable date to the current date, and when the task completes, it is returned as a process variable alongside with the invoice binary object:

...
const date = new Date();
...
const variables = new Variables().setAll({ invoice, date });
...
taskService.complete(task, variables);
...

This process variable, in turn, triggers the Boundary Event, and the process moves on to the next activity – Store Invoice. And it logs the date to the console as a Unix timestamp.

Converting to Camunda 8

Meanwhile, Camunda has published very useful guidelines to help to migration from Camunda 7 to Camunda 8. Here is the page – https://camunda.com/platform-7/migrate/. There is one great tool referenced on this page, and this is the Backend Diagram Converter – https://github.com/camunda-community-hub/camunda-7-to-8-migration/tree/main/backend-diagram-converter#backend-diagram-converter. An executable JAR file can be downloaded here: https://repo1.maven.org/maven2/org/camunda/community/migration/backend-diagram-converter-cli/0.4.3/backend-diagram-converter-cli-0.4.3.jar.

Let’s try it:

C:\Users\XXX>java -Dfile.encoding=UTF-8 -jar backend-diagram-converter-cli-0.4.3.jar engine -d –csv –username=demo –password=demo http://192.168.2.243:8080/engine-rest
Created .\converted-c8-order.bpmn
Created .\converted-c8-invoice.v2.bpmn
Created .\converted-c8-reviewInvoice.bpmn
Created .\conversion-results.csv

The tool connected to our Camunda 7 engine, analyzed three BPMN process models deployed to the engine and produced three converted models together with a CSV file that contains some explanations. Let’s open the converted BPMN model for our process:

We can see that there are just two error messages. One for the timer and another one for the conditional event. Let’s fix it.

Timer fix

The timer is easy to fix; it’s just about adding the proper type. Let’s do it.

We just set the Type to Cycle and the Value to “R10/PT5S”, the same as before. At this moment, I realised that the timer definition was wrong in the original model; it had the type “Duration”, which was incompatible with the Value “R10/PT5S” and, in fact, didn’t work.

Fix Conditional Boundary Event

The second error message tells us that our Conditional Boundary Event is not supported in Camunda 8 (yet). Here is a good overview of what is currently supported: BPMN coverage. What do we do about that? Well, let’s take a shortcut.

Our Conditional Boundary Event is supposed to wait for the process variable date to be set. But given the fact that we have only one activity in our BPMN model, and this is our Create Invoice Service Task, only this Service Task can change/set the process variable. So, the model can be simplified with a gateway like this:

And the gateway will implement the following logic. If the variable date is set, it will continue to the Store Invoice step or just finish the process.

Tidy up Service Task

Our Service Task Create Invoice was automatically converted, but let’s make sure everything is OK with it. Here is its Properties Panel:

Our very friendly conversion tool added a comment which explains what happened during the conversion. We now have Type = invoice-creator and this is the only thing we need to note down and use when creating our Service Task client.

Read on to the next article Make Use Of My Local Camunda 8 Cluster – Part III, final.

Comments

comments