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.
@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.
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."
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.