Output mapping with all local variables and some additional ones

I am looking for a efficient way to declare for a Receive Task that all variables received in the message should be merged into the process instance and in addition create some new variables using the received data.

However, if I use an Output Mapping it creates a local scope and I have to explicitly list all received variables in the mapping.

For example, I receive the following variables in the message:

 {
   "customerId": "1000027115",
   "accountNo": "30405060",
   "sortCode": "607080",
   "dateOfBirth": "1955-08-25",
   "contactNo": "447000044444",
   "emailAddress": "john.doe@example.com",
   "emailLastUpdated": "2020ā€‘01ā€‘01 10:45:30.005",
   "accountAddressStreet1": "Flat 4",
   "accountAddressStreet2": "18 Queen Street",
   "accountAddressCity": "London",
   "accountAddressState": "Greater London",
   "accountPostCode": "EC2A 4AA",
   "accountAddressCountry": "GB"
 }

And I would like to compute the age with FEEL as an additional variable.

Furthermore, Iā€™d like to filter out some variables that already exist in my process and should not be overwritten, e.g. customerId, accountNo, and sortCode.

@Philipp_Ossler Could this be done with some clever FEEL context functions?

If you use output mappings, you need to list all variables to be merged.

It is easier if the variables are bundled in an object and stored as a single variable.

1 Like

Yes, I thought about that as a workaround but even creating that context is a lot of repetition:

 {
   dateOfBirth: dateOfBirth,
   age: years and months duration(date(dateOfBirth), today()).years,
   contactNo: contactNo,
   emailAddress: emailAddress,
   emailLastUpdated: emailLastUpdated,
   accountAddressStreet1: accountAddressStreet1,
   accountAddressStreet2: accountAddressStreet2,
   accountAddressCity: accountAddressCity,
   accountAddressState: accountAddressState,
   accountPostCode: accountPostCode,
   accountAddressCountry: accountAddressCountry
 }

And this is still a small example.

Do you think it would make sense to introduce a helper function to get all variables of a BPMN scope as a FEEL context?

Yes. We had the idea to introduce the execution context and give access to the variables of the current scope.

1 Like