In a JavaDelegate, I can reliably set a variable such that the historic variable instance references the service task instance

[ThorbenLindhauer]

This issue was imported from JIRA:

Field	Value
JIRA Link	CAM-5465
Reporter	@ThorbenLindhauer
Has restricted visibility comments	true

---

Problem description:

When executing a non-scope service task that is implemented by a JavaDelegate, the delegation code may call DelegateExecution#setVariableLocal. The historic variable instance that results from this call references an activity instance id. This is either the id of the current activity instance or of the parent BPMN scope instance (confer https://github.com/camunda/camunda-bpm-platform/blob/7.4.0/engine/src/main/java/org/camunda/bpm/engine/impl/history/producer/DefaultHistoryEventProducer.java#L302-L308). For a non-scope service task, the actual value is hard to predict because which one is chosen depends on whether the task is executed by a concurrent or scope execution.

Desired behavior:

It should be possible to control which scope a historic variable instance is assigned to via API.

Solution possibilities:

• make it possible to configure a service task to become a scope (other than by an inputOutput mapping or a boundary event, which would be workarounds)
• make all service task scopes (beware the migration implications though; this could also be a problem regarding backwards compatibility)
• implement an API that allows to set a variable in a scope (e.g. execution.setVariableLocal("name", "value", "activityId")) and that sets the isConcurrentLocal flag to true if the activity is not a scope

Notes:

• the current behavior for setting a local variable on a concurrent execution is inconsistent with respect to the history entries. When the non-scope task that set the variable ends, the variable is not removed because the execution continues executing the next activity. Yet its historic variable instance entry may reference the activity instance id that just finished.

Links:

• is depended on by https://jira.camunda.com/browse/SUPPORT-2137

[ThorbenLindhauer]

This comment was imported from JIRA and written by user J884YbD

What is this name?

This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.

---

I think, solution 1, "make it possible to configure a service task to become a scope", would be the easiest way to use it and will be compatible backwards, if "become a scope" is not checked as default.