Specifying Data Structure with a New Model Type: Data Dictionary

Data is a crucial part of modeling and executing cases and processes. Some examples on how we support data requirements in Flowable Design and Flowable Work UI include: form models where data structures can be defined and filled-in by the end user, init variable tasks where variables can be created, service registry tasks with request and response mapping, and data objects that provide a seamless interaction with data from relational databases and REST services.

Despite these features, part of the data and variables that are used in a case and process model were still left unspecified. When the text for a text form field is stored, the type can be identified easily, but for a variable that uses the JSON type and has a nested structure of objects and fields, this is undefined. Additionally, it was not possible to define constraints like a maximum value or a minimum length to data and variables. To solve these challenges, Flowable is introducing a new model type called “data dictionary” to Flowable Design that helps bring more structure into your data. Having defined variables and data in case and process models ensures:

• consistency over the data

• accuracy, as inputs and outputs are clearly defined

• better handling of information throughout the workflow

What is a data dictionary model?

Let's say you are modeling a case or a process as part of a business case for which you create an app in Flowable Design. Analyzing the data you will need should happen early on - and this is where the Data Dictionary comes into play. It empowers modelers to define which data structures and constraints are needed in the case or process model and all its child models. For example, if a case model is about managing the onboarding of a new customer, a customer data dictionary type can be defined with a name, account number, age, email, and addresses properties. For these properties, the following definition could be used:

• name is a string field and required

• account number is a string field with a minimum length of 9 and maximum length of 11 and required

• age is a number field with a minimum value of 18 and required

• email is a string field with an email value regex constraint and required

• addresses is an array of address data dictionary objects which is optional

As you can see, the definition of a data dictionary type can be a mixture between simple property types like string and number, as well as references to other data dictionary types to support nesting. You can define any number of simple and complex types using the data dictionary model and it can also reference another type in the same model. When you add the data dictionary model to an app in Flowable Design, it doesn’t have a link with the case or process model yet, so this needs to be done as an additional step. For this, we’ve introduced a “data contract” in a case and process model that links variable names to their corresponding data dictionary type definition.

Defining a data contract in a case or process model

A "data contract" is a definition that specifies a list of variables and the data dictionary type it should adhere to. It can be defined on a case or process model level. This will allow you to easily use data in case and process models by retrieving and storing variables. For the customer data dictionary type, we could for example specify in the data contract that a variable with the name "customer" will be using the customer data dictionary type. When a customer variable is then created by filling in a start form of a case model with fields that have a value binding like {{customer.name}} and {{customer.email}} and has a multi sub form where an array of addresses can be defined, the variable will be stored on the case instance with a reference to the customer data dictionary type. Furthermore, when the customer variable is created the structure and the constraints defined for the data dictionary type are validated. When for example, the email field is not filled, Flowable Work will throw a validation exception that the email field is required and needs to be provided. Similarly, when the email value doesn’t match the defined regex expression then it will also throw a validation exception.

From a modeling point of view, when the customer variable is defined in the data contract of a case or process model, the variable assistant that is provided when filling-in a condition or typing an expression in a form model, will be able to help referencing specific fields of the variable. This way, it is less error prone to reference variables and nested properties of variables, and this significantly speeds up modeling business use cases. On top of that, the data contract also provides a good overview of the variables that are used within a case or process model and its child models. Per variable an overview can be provided where the variable is used. It can be made clear even where the variable is read and where a write action on the variable is performed.

Summary

The data dictionary feature is planned to be released in the next major release of Flowable Design and Work (version 3.14.0). This powerful new feature will be incorporated into the new Design application. In this initial version, the functionality that is outlined in this article will be made available. In future versions this functionality can be extended with enhanced capabilities such as generating form models based on one or more data dictionary types, using data contracts for sub-processes, and much more. The introduction of the data dictionary and the contract capabilities is an important milestone for us as data is truly established as a first-class citizen in Flowable products.