Camunda 8 - flexible JSON processing

Hi there,

Our use-case requires parsing messages which can vary considerably in their associated JSON properties (e.g. might be 50 to 1000+ fields depending on the msg input).

We require that both flow conditions and rules can be based on any of these fields. However, we see that the default behaviour of Camunda is to raise an incident and pause execution whenever there is no corresponding field in the token’s variables.

Can we override this behaviour to handle nulls without raising an incident (i.e. just ignore and treat as null so is no condition match)?

Having to prepare/preset all “missing” properties as null, creates a very large overhead for processing overall and each external task call.

Thanks for your time and help

Does this help?

Thanks @jwulf

Will try defined() out and revert …

@jwulf, before I get there am encountering the following issue re JSON … I simply want to return a nested JSON (object / not string), from a job to a flow.

Believe this is possible here : Variables | Camunda Platform 8 Docs

Using SpinJsonNode. Can convert from a json file or string to this object type, but cannot return from as JSON object per se - only as a String form.

Hence, trying to access an associated nested property in a flow, does not work in subsequent tasks.

Thanks for your time

Is this feature available in Camunda 8 or just in 7? How to return a full JSON object (with all its nested glory) to Camunda 8 Flow.

Every method am trying from SPIN and Jackson JSON are just serialising the object’s metadata back into the flow at best.

Tried the below resources without luck … pls help.

https://groups.google.com/g/camunda-bpm-users/c/IYdZmFehj5Q

Can someone pls confirm whether Camunda 8 supports Spin or not, and if not how to get as JSON object into the flow ( not string ).

According to this …

"## Use primitive variable types or JSON

Camunda 7 provides quite flexible ways to add data to your process. For example, you could add Java objects that would be serialized as byte code. Java byte code is brittle and also tied to the Java runtime environment. Another possibility is magically transforming those objects on the fly to XML using Camunda Spin. It turned out this was black magic and led to regular problems, which is why Camunda 8 does not offer this anymore."

vs

Hi @dred,

in Camunda 8 you don’t need Spin as a library anymore.

A quote from the docs you posted above:

A variable has a name and a JSON value.

Internally all variables are JSON, the data are transferred as JSON over GRPC and the Spring-Zeebe client has some magic to handle the JSON Variables as Java Objects: GitHub - camunda-community-hub/spring-zeebe: Easily use the Zeebe Java Client in your Spring or Spring Boot projects or GitHub - camunda-community-hub/spring-zeebe: Easily use the Zeebe Java Client in your Spring or Spring Boot projects or simply

String variable1 = (String)job.getVariablesAsMap().get("variable1");

Hope this helps, Ingo

Hi @Ingo_Richtsmeier

The issue wasn’t getting variables from the flow, but ensuring when returned they are available as JSON objects. Whenever I passed a JSON as a Java String, it was a String, not a JSON, evident by the quote escapes displayed in Operate and the inability to target a nested property.

It started working as expected when returned variables from the client worker to the flow as a Map<String, Object>. So this issue is fine now.