Overcoming Camunda’s Biggest Weakness

As someone who has worked with Camunda for almost 10 years, and one of the few people on the planet who are certified in it, I can unequivocally say that it’s a wonderful platform for process automation. 

I like its scalability. Camunda is designed to handle large volumes of data and processes, and it can be easily scaled to meet the needs of growing organizations, and is able to automate complex, data-intensive processes with ease.

I like its customizability. Camunda offers a wide range of customizations, including the ability to create custom workflows, forms, and user interfaces. This has made it easy for me to tailor the platform to the specific needs of my organization and our business processes.

I like the ease with which it integrates with other systems and technologies, like CRM, ERP, and other business applications. This makes it easy for me to connect Camunda to existing systems and workflows, and to extend capabilities as needed.

I like Camunda because it is easy to use & understand, even for those who are new to process automation. It offers a wide range of tools and resources to help people get up and running quickly, and it is supported by a large and active community of users and developers. 

However, I sort of hate interacting with data in Camunda: specifically, complex data. For example, assume that you make a restful call in Camunda process, and it’s returned a complex object, like this.

No alt text provided for this image

Now, you can use SPIN to do parse this, but I really hate doing that. It’s verbose, and it’s hard to debug. And did I mention that it’s verbose?

A brief digression on SPIN

Let’s just get it out there: SPIN in Camunda can be tedious. 

The library can be complex to use, especially for the uninitiated. It requires a strong background in Java & JSON, and it’s difficult to master. 

Frankly, new Camundos often find it time-consuming and tedious, especially on complex projects with a lot of data.

I’ve also found that SPIN can be overkill for simple projects. It is designed to work with more complex data structures like trees and graphs, but if I am only working with simple structures like hashmaps and arraylists, I may not need the full power of SPIN. More of that later. 

SPIN is an absolute go-to for data elements over 4K in size, but if you find yourself going down that dark alley, you may want to reconsider your life choices. 

Finally, I have noticed that using SPIN can have an impact on the performance of my projects, and it’s not really very interoperable. It is a Java library, which means that it can only be used in a Java environment. This has made it difficult for multi-language or multi-framework projects. 

Polyglot what?

Look, SPIN is powerful, and it has its place for manipulating and transforming complex JSON data. 

But that’s the bad place, and you want to avoid it if you can.  

In my experience, 90% of the time, it’s complex, overkill, non-performance, and has limited interoperability. In many cases, simpler tools may be more suitable for working with data in Camunda.

But but but..Complex objects!

I generally like storing my complex data in HashMaps and ArrayLists. For one thing, I can easily use dot notation to get to sub elements. For another, it’s a lot more concise to write my logic. That makes for better performance, and it’s more easily maintainable code.

Here are the positive features I see:

Ease of use: Hashmaps and arraylists are simple data structures that are easy to use and understand. They allow you to store and retrieve data in a logical, organized way, and can be easily accessed and modified in your code.

Flexibility: Hashmaps and arraylists are very flexible data structures, and they can be used to store a wide variety of complex objects. This makes them ideal for storing data in Camunda, which is a flexible and powerful process automation platform.

Performance: Hashmaps and arraylists are generally very fast and efficient data structures, especially when compared to more complex data structures like trees or graphs. This can be important in Camunda, where performance is often a critical factor.

Interoperability: Hashmaps and arraylists are widely used data structures that are supported by many programming languages and frameworks. This makes them easy to work with and ensures that your data will be easily accessible and usable by other developers working with Camunda.

But but but…how?

There are three things you need to think about when standardizing your complex objects as hashmaps and arraylists:

  1. Initiating a process with a complex object that is interpreted by the engine as a hashmap
  2. Transforming the response of a restful API call to a HashMap or ArrayList
  3. Using the hashmap/arraylist in the content of the Execution. 

Initiating a process with a Hashmap

Let’s say you want to start a process in Camunda, and you expect the process to using notation of the type “${good.type==”Apple”} in a gateway. In order to do that, you would set your payload as follows. This tells the Camunda engine to interpret your input as a HashMap. Incidentally, you could do the same thing for a list using an ArrayList of hashmaps. 

No alt text provided for this image

Transforming the response of a rest call to a HashMap

Now, if you want to transform a response of a restful call to an object that can both be easily stored in the execution content, and which can use dot notation, you might want to do something like this when your connector receives the response.

No alt text provided for this image

Using the hashmap/arraylist in the content of the Execution

On the other hand. If you want to just pull the data model in and out of the execution context, it’s as easy as: execution.getVariable(“response”)  and execution.setVariable(“response”,response);,execution, allowing you to do things like this in your gateways and rules.

No alt text provided for this image