To improve the reusability of source code and business logic, Camunda BPM offers input/output mapping of process variables. This can be used for tasks, events and subprocesses.
I think it is great idea, thanks a lot to support it!
However it doesn’t work for a Task.
Caused by: org.camunda.bpm.engine.ProcessEngineException: ENGINE-09005 Could not parse BPMN process. Errors:
* camunda:inputOutput mapping unsupported for element type 'task'.
Doing some investigation I found root cause of the problem in the BPMNParser.checkActivityInputOutputSupported method:
if (!(tagName.contains("Task")
|| tagName.contains("Event")
|| tagName.equals("transaction")
|| tagName.equals("subProcess")
|| tagName.equals("callActivity"))) {
addError("camunda:inputOutput mapping unsupported for element type '" + tagName + "'.", activityElement);
return false;
}
My question is, why camunda:inputOutput mapping unsupported for Task?
It seems so natural and so convenient and will increase usability much more.
Hi Mike,
It should work as the logic is the exception is thrown if the tag name does not contain ‘Task’. However I note in your exception message, your tagName is a lower case ‘task’. Hence could this be your problem? How did you model your process?
My motivation regarding input/output parameters is simple, sometimes from logical standpoint I need emphasize a step that actually just ingest a variable into a context.
A plain Task is perfect to do it.
Yeah, the modeler should probably not allow defining input/output mappings here. Async and listeners are supported by the way.
Not sure I get this. I understand that when you use BPMN for documentation purposes that you would like to document logical input and outputs of activities. For that, BPMN has data objects which serve the purpose nicely. What I don’t understand is why you would use the technical Camunda properties that have runtime semantics for something that is essentially pointless at runtime.
Later we want to know how many processes were finished with success and with failure.
We can use HistoryService, but we need to put something into the process context.
IMO The plain Task with camunda io extension is best suit for this. Correct me if I am wrong.
Thanks for explaining your use case. I’d like to propose two alternative solutions:
Instead of the tasks SUCCESS and FAILURE, you could have execution listeners on the sequence flow or on the end events that set a variable to the desired value (e.g. set variable process-result to either success or failure). Then query the history data by that variable. That way, you do not have tasks in the model that do not contribute to the process and are only there for technical reasons (i.e. being able to query the history).
If your prefer a visual representation in the process model, then a popular approach is to use blank intermediate throw events to mark milestones in a process. So the model would look like the one below. This is maybe better than using tasks, as a task in BPMN suggests that something is being done in the process, whereas an event suggests that something has happened (in this case: the milestones have been reached). For these events, you can also use input/output mappings or execution listeners to set the desired variable.
It is not supported in the sense that data objects have no runtime semantics in the engine. However, the engine also does not complain about them. It will simply ignore them. They won’t help for the use case you explained.
