Cloud Datastores Simplify Business Automation

Binding a datastore shape in BPMN (or an input data in DMN) syncs the shape to the datastore content, indicated by a lock icon inside the can shape. Unlike a database table, which requires a Service task to perform a query, insert, or update operation, operations on a datastore use standard FEEL list functions and operators. They are typically performed by data associations, i.e., the input and output mappings of a Script task, Decision task, or User task, tasks which can perform actions in addition to the datastore read or write. To perform a datastore operation and nothing more, a Script task is simplest, as shown in the model below:

Here the Script task Get Available Days queries the datastore to find the accrued vacation time for the employee identified by the data input Vacation Request. This involves selecting the employee record from the datastore and then extracting the AvailableDays value from that record. Since both the input mapping and the script are FEEL expressions, you have several possible ways to do this: Get the entire datastore in the input mapping and extract AvailableDays for a particular employee in the script expression; select the employee record in the input mapping and extract AvailableDays in the script; or do it all in the input mapping with the script being just the identity mapping. With datastores there is no difference in performance, but I think it’s most “natural” to do it the second way, as shown here. The input mapping selects Employee record using a filter of the datastore, and the script extracts AvailableDays.

While querying a datastore usually involves a filter, inserting a record in the datastore uses the standard FEEL list functions, append, insert before, or insert after. Deleting a record uses the list function remove. Some of these require knowing a record’s position in the datastore, which you can get using the index of function. The more interesting operation is a record update. Let’s say in this example we want to reduce the employee’s AvailableDays value by the vacation days requested, as in the process diagram below.

Record updates like this use the list replace function, new in DMN 1.4. This function has two forms: list replace(list, position, newItem) and list replace(list, match, newItem). The first one requires knowing the position, as with insert before. In the second, the parameter match is a function definition, similar to the precedes function in sort. The first argument of match is a range variable representing any item in the list. As with precedes, it is most common to define match inline as an anonymous function using the keyword function.

In this example, the input mapping of Update Employee record is the same as before, a filter extracting the original Employee Record from the datastore. But this time, the script expression uses the context put function to modify the value of that record’s AvailableDays component, subtracting Vacation Request.requested days from the original value.

Then the output mapping uses list replace to replace the original employee record with the updated one. Here match is an anonymous function in which the range variable x stands for any record in the datastore and the function selects the one for which the EmployeeId value matches that of Employee record. The list replace function substitutes the script output Employee record – now updated – for the original datastore record.

Admittedly, datastore updates involve unfamiliar FEEL functions like context put and list replace, but learning those is a small price to pay for the extra convenience. Cloud datastores make data persistence easy. You should give them a try!

To learn how to do Low-Code Business Automation using both datastores and OData, check out my new training.