Input/output variable mapping

Hi everyone,

I have a generic service task handler, which takes arbitrarily structured input and returns an output (think of them as Map<String, Object>). This task will be used intensively in many processes. So, there is a need to map different process variables into some input variable with predefined name and custom structure, and the other way around for output.
I found an exact solution to my problem in another well-known open-source BPM engine (don’t want to advertise here :slight_smile: ). They allow to specify input/output variable mapping for tasks, subprocesses, and events, which can have list/map structure, as well as basic types. However, I was unable to find similar solution in Flowable.
The closest thing I found is field injection, but it seems only supporting string values (or expressions, which resolve to string).

Any suggestions on how this can be achieved?

Thanks in advance.

P.S. Currently I’m adding a script task in front of every service task to assemble this input variable, but this is not a solution for production use.

Do you mean like the in/out mappings on Call Activity?


Thanks for reply, Paul.

Yes, I mean something like that, but also with support of more complex mappings (like lists and maps), like this:

  <flowable:in name="x">
      <flowable:value>Fixed value</flowable:value>
      <flowable:value>${5 + 6}</flowable:value>
  <flowable:in name="y">
      <flowable:entry key="foo">bar</flowable:entry>
      <flowable:entry key="map">
          <flowable:entry key="hello">world</flowable:entry>
          <flowable:entry key="flowable">bpm</flowable:entry>
  <flowable:out name="z">${taskVariable1 + taskVariable2}</flowable:out>

Hi @PHH , @mikayelaghasyan ,

we are actually looking for something similar on events. Currently, you can define e.g. an escalation (intermediate/end) event in a subflow to raise an escalation to the parent flow. However, you cannot pass any data along with that. Looking at the link Paul shared, we are wondering whether the same mechanisms using input/output variable mapping available on a call activity when completing a subflow with a regular end event could also be applied to escalation end events?
Do you see any conceptual issues with this?
Best regards,

1 Like