Skip to main content

Introduction to Data Objects

Data object models are supported in Flowable Work.

A data object model allows defining the structure of 'business data' or 'business objects'. For example, a data object could represent a 'customer', a 'patient', a 'project', etc. with for example a name, address and/or other relevant information. From such a data object model, data object instances or more simply said data objects can be created, updated, queried, ... which will all have the modeled structure.

Flowable supports two ways of working with data objects, depending on whether Flowable will be responsible for managing the data or whether the data is managed by an external system or service:

  • Letting Flowable manage the underlying storage of the data objects based on a data object model is useful when there is no external system available. The internal data object engine - which is an engine like the process or case engine, with an API that follows the same programming patterns - will use tables in the relational database that Flowable uses and generate SQL queries when using data objects in process or case instances.
  • Alternatively, when the data is managed externally from Flowable, a data object model can be created as an abstraction for the data in this external system or service. In this situation, the data object engine will fetch or change the data when needed in the external service through REST.

The main benefits of using data objects are the same for both options:

  • High level abstraction: the details of how the data is actually handled behind the scenes (through SQL or through an external REST API) is hidden away from the modeler. The modeler only works with the data object, without having to worry about how the data is fetched, created, updated, etc.

  • Richer models: creating process or case models using data objects instead of a collection of different variables makes the model more clear and easier to understand. For example, a process working with a customer data object variable that contains all customer-related information is easier to grasp compared to having a number of variables in the process that implicitly together form a customer.

  • Data separation: avoid storing (sensitive) data like for example client identifying data as variables in process or case instances. If Flowable is responsible for storing the data object data, all data will be stored in a separate table. When using an external system, Flowable won't store the data of that data object in the process or case instance (only a reference is stored).

  • Data corruption: avoid that data gets 'out of sync' by having a copy of the data stored in process or case instance variables. The data is stored and managed on one central location (by Flowable or external) and referenced in the instances.

Data Objects in Relation to Service models​

Data object models are conceptually quite simple: they define a structure (sometimes also called the schema by technical oriented people) of a business object. This means that such a model describes the fields that make up the business object and the type of each field, and acts as a sort of 'container for these fields.

The data object models themselves don’t define how they get read, created, updated, deleted or queried. These actions are called operations in a Flowable service model and they define how the fields and the values for those fields are used to implement the operation. Simply said: the data object model defines the structure of the data, the service model defines how that data is managed.

Service models are generic, in the sense that they allow to create free-form operations that can be used in process or case models and hide the actual logic for the modeler. When creating a service model that is based upon a data object model however, the basic operations (the so-called CRUD or Create, Read, Update and Delete operations) are fixed and are pre-generated using the structure of the data object.

Supported Implementations​

Flowable currently supports two types of service models for data objects:

  • Database: use this type of service model when Flowable should be responsible for storing and managing the data object data.

  • REST: use this type of service model when the data for the data objects exists in an external system and is accessible using a REST API.

In the example Managing Customers with Data Objects both implementation types will be covered. That demonstrates the power and flexibility of data object and service models: the CMMN model contains no details on how the actual data is retrieved and restored. The business modeler only needs to worry about modeling the business problem, without having to worry about how the customer data is actually stored.