Flowable 5 to Flowable 6 migration questions

Hi all,

We are trying to migrate our Flowable 5 codebase and we are hitting a number of blockers, suggestions would be appreciated:

  1. We used to use ProcessDefinitionEntity.setProperty during parse to set custom attributes, which we retrieved in a helper bean at runtime using this code:
    ExecutionContext context = Context.getExecutionContext();
    ProcessDefinitionEntity definition = context.getProcessDefinition();

get/setProperty came from the PVM class that has been removed. I don’t see anything obvious on BpmnModel that we could use to store custom key/value pairs… any suggestion?

  1. In a FlowableEventListener, is
    the correct replacement for
    event.getEngineServices().getRuntimeService(). ?

  2. In Flowable 5 I used to set the configuration on the Context before building the engine:

    _processEngine = cfg.buildProcessEngine();

… can I just skip that step?

  1. In a custom parse handler we used to define process variables directly on the process entity:
    processDefinition.getVariables().put(BpmnUtil.getJavaName(dataObject), value)

… in version 6 getVariables() returns null in that phase, what would be to correct alternative?


  1. Custom key value pairs are typically added in the extensionElements of an element, under a custom namespace. At runtime, these can be read in the ActivityBehaviour.

  2. Correct

  3. Yes, that is automatically done now.

  4. Hmm what’s the use case here? Afaik, process definitions didn’t have variables before … Or do you mean processInstance?

On #4 the use case was to have predefined variables created on startup, initialized with default object instances, for all process instances.
I have created our own context and I am passing the variables to every start process call, that works too. I also use it for the properties, which I indeed retrieve from extension elements. They are used in places where going back to the BPMN model would be painful.

We have successfully upgraded, I am in the process of trying to optimize for orchestration type processes with no async continuations, using the new pluggable persistence layer… not too successful so far but I’ll keep at it.