This is basically an attempt to deal with the fact that activity names are not exposed to the external task workers (see External Task name is not there in rest API response).
Thanks to the documentation of Internal Context Variables, I found that a DelegateExecution
is available for scripting input parameters to an external Service Task. So my attempt was the following:
<bpmn:serviceTask id="Activity_0tckfn5" name="TestTask" camunda:modelerTemplate="de.unibi.nca.avikom.Echo" camunda:modelerTemplateVersion="20210909" camunda:type="external" camunda:topic="EchoTask">
<bpmn:extensionElements>
<camunda:field name="Element Documentation">
<camunda:string>
...
</camunda:string>
</camunda:field>
<camunda:inputOutput>
<camunda:inputParameter name="stepName">
<camunda:script scriptFormat="javascript">execution.getCurrentActivityName()</camunda:script>
</camunda:inputParameter>
</camunda:inputOutput>
</bpmn:extensionElements>
</bpmn:serviceTask>
Unfortunately stepName = None
in the external worker. Other calls like execution.getActivityInstanceId()
do work though and execution.getCurrentActivityName()
also returns a value in a Script Task. So this:
<bpmn:scriptTask id="Activity_0x92qyr" name="Hello You1" scriptFormat="javascript">
<bpmn:incoming>Flow_1wzy0ub</bpmn:incoming>
<bpmn:outgoing>Flow_1894o5u</bpmn:outgoing>
<bpmn:script>execution.setVariable("stepName", execution.getCurrentActivityName()) </bpmn:script>
</bpmn:scriptTask>
results in stepName
being correctly assigned. In external Service Tasks, execution. getCurrentActivityId()
also returns None
but this isn’t a big deal since the activity ID is already passed to the external worker automatically.
Motivation: We use a string input parameter to retrieve related information in the external worker from a database. The database uses a ‘task summary’ as a unique key (e.g. “Boil some eggs”). Since these keys have been chosen to be memorable for humans, we more or less always use these keys as task names as well. Thus, when modelling service tasks, users have to enter this string twice . First, as the name that is shown in the BPMN diagram and second, as the parameter passed to the external service worker (stepName
). This is error-prone when both strings get out of sync. Especially, when stepName
contains wrong spelling.