Json structure and expression as output parameter

Hello everybody,

I have a process-wide compex data object saved as process-instance variable named “processData” of type json (stored using JavaDelegate as JsonNode). Initial value looks like this:

{
  "customerNumber": 123456,
  "addresses": []
}

Then I have a ExecutionListener for some service-task which loads addresses.
Execution listener has a outout parameter addresses (L-Value expression) like this: ${processData.addresses}.

In the java implementation of this listener I set the output value like this: addressesExpression.setValue(addressesValue, execution)

I experience here several problems:

  1. Does not matter which java type I use for addressesValue (JsonNode, List, List, String) the value is injected into processData.addresses as string with all json escaped. So I do not have a json but a string.

  2. Flowable process engine does not recognized changes in the processData, so it does not store the changes in DB. It is possible to access processData.addreses until transaction boundery (user task, async task). After it the “processData” is reset to its initial value (the value it was stored for the first time).

Is that a bug or is there a way do it right?

Hi,

I think Flowable does not support JSON objects in such a transparent way. I’ve also played around with this and the only way to receive a JSON process variable in a method call was to declare the parameter as com.fasterxml.jackson.databind.JsonNode:

	public void receive(JsonNode invoiceResponseNode) {
		this.invoiceResponse = objectMapper.convertValue(invoiceResponseNode, InvoiceResponse.class);
	}

I think in your case it would result in something like:

	public void setValue(JsonNode processDataNode, Execution execution) {
		ProcessData processData = objectMapper.convertValue(processDataNode, ProcessData.class);
                processData.getAdresses().add(...);
                // TODO: Convert the  processData back to JsonNode and put it to process variable map for update
	}

If there is a better solution, I would also be interested.

Cheers
Martin

thank You, Martin. I came to the similar conclusion/solution.