Hi,
We have a BPMN with multiple sub processes(PFA attachedSampleBPMN.bpmn (11.9 KB) ).
Each of the sub process has the same Execution Listener attached to it(for the sake of this scenario, dataChangeListener).
A few of the tasks also have the same execution listener(dataChangeListener) attached.
All these sub processes and tasks also have the same input parameter(for the sake of this scenario, input, a Map), with different values for different sub processes/tasks.
The dataChangeListener class:
1. Accesses a complex variable(let’s say, state) through scope.getVariableTyped(variableName, false);
2. Deserializes the value received from getValueSerialized(), using the jackson objecRreader in the notify method,
3. Modifies some value and then saves it back.
All of this works fine in general.
The issue is encountered during testing.
We’re using the startProcessInstanceByKey and passing in the complex object(state) as a variable.
The default serialization format is “application/json”.
When we pass the variables directly using TypedValue API, like this:
Variables.objectValue(stateObject).create()),
we get the error: Exception while closing command context: Cannot find serializer for value ‘Typed value ‘state’, isTransient = false’.
To mitigate this, we’re doing the following two things:
-
Variables
.serializedObjectValue(Spin.JSON(stateObject).toString())
.serializationDataFormat(Variables.SerializationDataFormats.JAVA)
.objectTypeName(stateObject.getClass().getCanonicalName()).setTransient(false)
.create(); -
processEngine.getProcessEngineConfiguration()
.setJavaSerializationFormatEnabled(true);
We are using Camunda Platform Scenario library, and following Testing process definitions | Camunda Platform 8 Docs for testing the wider process, including the execution listener code.
Now since the same listener dataChangeListener is being used in multiple sub-processes/tasks, without any wait state, the listener properly deserializes the state object during the first call to the listener from the process instance Parent_Process, but since there is no wait state, the listener gets called again, but the deserialization fails this time, since the previously deserialized value is persisted in the h2 db, and the code again tries to deserialize the deserialized
Questions:
- What’s a better way to implement this, or is this acceptable?
- Is there a way to handle this scenario for testing without changing the actual Process definition?
- Could this issue be resolved using the DataFormatConfigurator?
- Could this issue be resolved at all?
NOTE: We do not use any cfg files, nor will we only for the sake of testing.*