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?
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…
VariableMap which is consistent with all other APIs that return variables (https://github.com/camunda/camunda-bpm-platform/blob/7.11.0/engine/src/main/java/org/camunda/bpm/engine/externaltask/LockedExternalTask.java#L110).
The difference is that in case of
DelegateExecution, you have a hierarchy of variable containers. The
VariableScope interface gives access to that by
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
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
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).