Json serialization "losing" a field in a specific step in process

We are experiencing a really strange issue with process engine json serialization:

  • We have implemented custom serialization and at a specific point in the process (after one External Task) the process engine “loses” one field in the JSON.

  • The process engine fails to deserialize the JSON when moving to the next External Task as it is a mandatory field.

  • If we manually intervene to set that property in the JSON through the Camunda cockpit, the process can move forward correctly

  • After we manually restore the missing property in the json, the process engine correctly serialize and deserialize that field.

It’s probably impossible to reproduce this issue, how would investigate what’s happening? It doesn’t happen in test, just in Tomcat. Where can we place a breakpoint for example?

I’m just guessing - hope this helps.

A few things that help me visually trace values through a process:

  1. I add an extra task listener or task delegate responsible for printing out all the process variables. Once things start working w/o issue, I simply clean-up the code.

sample code here at github: method printvariables(DelegateExecution execution)
NOTE: I use CDI and EL. Some refactoring is required to get the example to work in tomcat.

  1. for the more complex tasks, I’m now adding interfaces to task-delegates. Goal is to add in ReST-driven triggers to help discretely test each task-delegate source. I’ve also just started (maybe…) following Camunda’s example for services (i.e. RuntimeService, etc). I’m only doing this for ‘phat’ (complicated) components only. But, it really speeds up test-cycles when tracking down pernicious issues.

This code isn’t yet checked into GitHub. But, the goal is to isolate the complicated components as their own test’able services.

This said - I’m guessing your trouble is:

  • The field is getting lost when a down-stream client reads prior to complete serialization of the object itself.
  • Or, maybe you have some ‘unsafe’ concurrent access into the object. Meaning, the downstream consumer isn’t aware that an upstream field is getting written prior. I think somebody mentioned “application scope” or “singleton”… not sure.
  • If you’re using an annotated java class representing your JSON object, I’d either review the annotation or simply avoid it. I’ve switched over to direct JsonNode types - meaning, there are no underlying java-class representations.

Hey Gary,

so what we are doing is the following:

  • We use a typesafe library for JSON serialization written in Scala

  • We had written down a process engine extension so to support this serializers

All our classes are immutable. The interesting thing is that I have checked the variable at some steps before and it is correct , so it seems that in a specific step in the process serialization is not working correctly. I think I have no other options but to put a breakpoint somewhere