Camunda 7 Migration to Flowable - First Steps

Back in April 2022, Camunda announced the end of the road for Camunda Platform 7. The Community Edition will have its final release in October 2025 with version 7.24, after which all related resources will be archived on GitHub. For those using the Enterprise version, there will still be some additional support and possible patch updates for a limited time. The successor, Camunda 8, is a brand-new product designed specifically for cloud deployment. However, it has limited compatibility with its predecessor. We've already gone over the differences between these two versions in a previous post.

Given the announced end of Camunda 7, users of this platform need to consider how to handle their process applications and plan for a future without Camunda 7. While Camunda 8 might be the first option that comes to mind, it's important to realize that both migration and operation can present significant challenges. Additionally, the SaaS offering isn't always the preferred choice for everyone. Furthermore, starting from version 8.6 (set for release in October 2024), there’ll be a change in licensing terms, meaning there won’t be a free version of the product available for production use. In light of this, we aim to explore how to migrate a sample process application from Camunda 7 to other solutions.

Starting Point

Let's look at our hypothetical invoicing process scenario¹. Here’s how it goes: Incoming invoices are checked based on their subject and amount. Depending on the result of this check, the invoice has to be manually reviewed before it can be either accepted or rejected. This scenario includes the following technical components:

• A Start Listener
• A Rule Task implemented with DMN (Decision Model and Notation)
• A User Task designed with a Camunda Forms
• A Service Task called 'Accept Invoice', implemented as a Java-Delegate
• A Service Task called 'Decline Invoice', implemented as an External-Task² (for more details, check out our blog post on Camunda External-Task-Worker)
• A process interface to start process instances, implemented as a REST-Controller

1: A streamlined process focusing mainly on the technical aspects of implementation.

2: For simplicity, the implementation of the External-Task-Worker is included within the same project and is not separate; however, communication still occurs via the Rest-Api.

You can find the code for our examples on GitHub: https://github.com/viadee/process-engine-migrations 

Flowable

Just like Camunda, Flowable offers an open-source platform for Business Process Management (BPM) and workflow automation based on BPMN. However, these two products share more than just their purpose. Both Camunda and Flowable originated from the Activiti BPMN Engine. While Camunda forked off back in 2013, Flowable branched out from the same source in 2016. This common heritage suggests that many concepts used in Camunda process applications may also work seamlessly with Flowable.

Proceeding

Here’s how we transitioned a process application based on Camunda 7 into a Flowable application.

Replace dependencies

Let's assume we're starting off with a Spring Boot implementation. The first step in our migration process is to replace the Camunda engine with the Flowable engine. For this, we'll need at least the flowable-spring-boot-starter. To implement the Service Task as an External Task, we'll make use of the Flowable REST API. There's a dedicated Spring Boot starter for this, similar to what you're used to with Camunda. For the actual implementation of the External Task Worker, there's already a suitable Spring Boot-Starter available. We'll add this as a dependency in our project too.

Here’s how the necessary dependencies in our pom.xml look now. You can find the complete file on GitHub.

After swapping out the dependencies for the corresponding Flowable artifacts, we encountered a few compilation errors due to missing classes that we need to fix.

ADJUSTING TO THE FLOWABLE JAVA-API

While resolving these compilation errors, we noticed that Camunda and Flowable share the same roots, with many concepts dating back to the Activiti days. For instance, the interface classes from Activiti, like JavaDelegate.java, ExecutionListener.java, and others. Because of this, these Java interfaces work almost identically, with the key difference being the necessary imports. The actual implementation in these cases remains unchanged. The adjustments to the delegate are simply as follows:

Or the necessary tweaks to the startup listener: 

Migrating External Tasks

A few years back, we introduced the External-Task Pattern in one of our articles. It's an architectural pattern that's gained popularity for its practicality. Both Camunda and Flowable provide support for this pattern, including officially supported client libraries for Java and even a Spring Boot-Starter. These tools handle many configuration aspects for you, making it easier to get started. Camunda offers a Spring Boot-Starter that simplifies some default configurations, while Flowable provides a similar Spring Boot Starter project. This enables you to implement "FlowableWorkers" that subscribe to specific topics in a familiar manner.

However, there's a key difference between the Camunda and Flowable approaches. With Camunda, developers need to manually complete the task themselves, which often requires additional coding effort. On the other hand, Flowable takes a more streamlined approach. In Flowable, task completion is implemented as an "AutoCloseable" method. This means, the external task is automatically marked as completed once the method runs successfully—potentially returning values that can be stored in the process context.

Bottom line, if you're looking for a more automated approach to task management, Flowable might just have the edge with their out-of-the-box AutoCloseable approach. Either way, both platforms offer robust solutions for managing external tasks effectively.

ADJUSTING APPLICATION PROPERTIES

In our demo project, we're working with a very basic example, which we’re running only locally. That’s why both solutions can get by without extensive configuration. Most properties are related to configuring the External Tasks Clients. Here's a comparison of the necessary application properties (summarized in one file):

Changing the Process Model

In our scenario, the most labor-intensive task is migrating the process model. Originally created using the Camunda Desktop Modeler, this model is crafted in BPMN 2.0—a globally managed standard by OMG. But here's the kicker: this standard allows for custom extensions. This means that within the model's XML, there are technical attributes from the Camunda namespace, giving specific instructions to the corresponding Process Engine. For instance, a service task might look like this:

Unlike Camunda, Flowable currently doesn’t offer a freely available modeler or designer for process models and decision tables. This is why you won’t find any Flowable tools listed in the BPMN-compatible tools directory maintained by MWIG. In the OpenSource release of Flowable 7.0.0, the UI and its built-in modeler were removed. Now, the designer provided by Flowable is tied to a SaaS license.

However, some XML constructs need tweaking due to engine-specific tags. For migrating the Camunda process application, we ultimately opened the process model using the IntelliJ plugin Flowable BPMN Visualizer to track the necessary changes for migrating to a different BPMN-2.0 engine. Using a mix of this plugin, Flowable documentation, and the Flowable XML namespace, we managed to get a working version where all previous components run smoothly. Below, we’ve compared the relevant elements for the service tasks, both as Java-Delegate and External-Task. Interestingly, the final result wasn’t achieved by migrating or adjusting the original model, but rather by recreating the process model using the IntelliJ plugin with manual tweaks.

While the Camunda Desktop Modeler adds sequence flows as their own incoming and outgoing XML elements in the relevant activities, the Flowable Visualizer represents process flows using standalone sequenceFlow-elements with sourceRef- and targetRef- attributes.

BUSINESS RULE TASK / DECISION TASK

One of the main differences you'll notice is in how decision rules are integrated. Unlike in Camunda, Flowable uses a Service Task instead of a Business Rule Task. The Flowable Engine and Flowable Modeler interpret this Service Task as a Decision Task. Just like in Camunda, the ID of the DMN is referenced in the BPMN using the decisionTableReferenceKey.

The final step is to move the resources for the process model and the decision table for Flowable's auto-deployment into the /resources/processes and /resources/dmn folders, respectively. Also, don't forget to change the file extension of the process model from .bpmn to .bpmn20.xml.

Adapting DMN-Rules

When working with DMN rules, one crucial step is checking whether a given variable contains a specific text or not. In the original decision rule designed for the Camunda process application, this was handled using a FEEL expression (Friendly Enough Expression Language), which is evaluated at runtime by the built-in DMN engine.

However, in Flowable, this script language is not supported. Instead, it uses JUEL (Java Unified Expression Language). This means we need to tweak the rule a bit. So, the FEEL expression contains(reason, "important") becomes ${reason.contains("important")}. Apart from this adjustment and a null-check, which was also implemented using FEEL, the remainder of the decision table remains unchanged. Comparing the two Rule Tables:

Replacing User-Task Forms

In the original process application, a Camunda form was provided for the user-task form used within the user-task. This form was responsible for displaying tasks in the Camunda Tasklist at the appropriate point.

On the flip side, Flowable's OpenSource version doesn't come with a ready-made solution for this. So, we came up with a workaround by creating a REST API. With this API, you can fetch a list of all tasks that need to be done, and also complete individual tasks. Plus, there's a second endpoint that lets you save the necessary variables into the process context. These variables are crucial for evaluating the following gateway, similar to how things work with the Camunda Tasklist.

Here's an example of how you might use the Task API:

Conclusion

In the end, we successfully migrated the Camunda 7 process application to a new process application based on the open-source solution Flowable 7. The success of this endeavor is confirmed by the correct output in the application log, which looks identical in both cases: 

Key takeaways:

A lot of interfaces with the process engine work quite similarly due to the shared history of the two products. Concepts like a Java-Delegate can be reused in the same way – just remember the necessary Java imports might differ. Newer concepts, like the External-Task-Pattern, also have replacement options available that are easy to adapt, including a Spring Boot-Starter.

The integration of BPMN process models is quite similar to what you've already seen in the Camunda ecosystem. Using technical expressions in the usual ${} format should be familiar to any process developer and shouldn't pose any issues. You can find details on technical attributes in the BPMN-Xml documentation and namespace. Unfortunately, process modeling isn't as straightforward and intuitive as with the Camunda Desktop Modeler or similar tools. The mix of using an IntelliJ plugin and manually tweaking the Xml can feel cumbersome but is doable. Similarly, there’s no tool for viewing running processes and instances at runtime like the Camunda Cockpit. Also, the Flowable version we’re using doesn’t currently offer a way to design forms for user tasks and display them enriched with context data for editing on a task list. However, most organizations probably have their own activity management solutions in place already, so you can consider this point minor for now—just keep in mind that your activity management system will eventually need to interact with Flowable.

Remember, this is a showcase to test the waters with an alternative to Camunda Platform 7. Before migrating a productive application, make sure to test all the constructs from the BPMN modeling standard and ideally run existing integration and regression tests on the migrated process application before going live.

Questions about BPMN, Camunda, or process automation? Need help migrating your process applications? Feel free to reach out!