Hi folks,
I wonder, why the LockedExternalTask is not extending VariableScope. The handling of variables in external service tasks needs to be implemented differently than with delegate execution, delegate task and anything else…
Is there a reason for that?
Kind regards,
Simon
Interested in this. whats the impact?
Nothing special, but just a uniform access to anything carrying variables.
Currently, you can get a Map<String, Object> by calling LockedExternaTask.getVariables(), but in fact it is a VariableMapImplwhich offers all common convenience methods.
One could build an adapter for that, but why is it not a part of the API?
What is the difference between Task / DelegeateTask, Execution/DelegateExecution and LockedExternalTask from the point of view of variable handling?
I suppose this is more a question to the Core Team if it is worth to think of it and possibly provide a PR…
Hi Simon,
LockedExternalTask returns VariableMap which is consistent with all other APIs that return variables (camunda-bpm-platform/engine/src/main/java/org/camunda/bpm/engine/externaltask/LockedExternalTask.java at 7.11.0 · camunda/camunda-bpm-platform · GitHub).
The difference is that in case of DelegateTask and DelegateExecution, you have a hierarchy of variable containers. The VariableScope interface gives access to that by getVariable and getVariableLocal methods. In contrast, a VariableMap is a non-hierarchical container of variables.
Wherever variables are potentially passed out of the Camunda transaction (i.e. all service API methods), it is always VariableMap, never a VariableScope (e.g. see all variable methods in RuntimeService). Inside a Camunda transaction (e.g. a delegate), you get access to a VariableScope (from which you can also extract a VariableMap).
Not sure if there was a specific reason for that design. For a uniform handling in both cases, you could program against VariableMap and do scope.getVariablesTyped() wherever you have a VariableScope.
Should we change this and hand VariableScope out of the service API? If the only reason is consistency in certain cases, then I don’t think this will outweigh the complexity this would introduce (VariableScope is more complex than VariableMap; a lot of new redundant methods to avoid breaking backwards compatibility).
Cheers,
Thorben