Data Object Modeler Guide
A data object model allows defining the structure of a business object that typically is stored in an external data store or service.
For example, a data object could represent a 'customer' business object with name, address and other information. In process and case instances, this customer data object model can be used to create instances of this data, yet the data itself is never store in the process or case instance itself.
The main purposes are:
Richer models: creating process or case models using business objects instead of a collection of different variables makes the model clearer.
Data segregation: avoid storing (sensitive) data like for example client identifying data as variables in process or case instances.
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 and only referenced when using data objects in Flowable.
Data object models are conceptually quite simple: they define the structure or schema 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 a 'contract'.
The data object models themselves don’t define how they get read, created, updated, deleted or queried. To define this, a service model needs to be created that is based on the data object model. That service model will define how the data object model data is retrieved and sent back to the external service or data store.
Service models are typically generic, in the sense that they allow to create free-form operations on services 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-populated using the structure of the data object.
Flowable currently supports three types of service models, when basing that definition on a data object model:
See each section or the left-hand navigation panel for a link to a dedicated section on each type.
The same example (a customer data object with a customer CMMN case) will be implemented for each type, which demonstrates the power of the 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, wihtout having to worry one bit about what’s happening behind the scene.
This type of service model is used when the data for the data object is exposed by a REST API.
See Creating a Data Object Model With a REST Service Model for more details.
When using the database type of service model in combination with a data object model, the data is stored in a relational database table (next to the Flowable database tables). This is a useful option when there is no external data store for the business object.
See Creating a Data Object Model With a Database Service Model for more information.
A service model using expressions allows to reference logic that is encapsulated in Java classes. When data for a data object is needed or gets manipulated, methos on the Java class will be called. Through this expression mechanism, any currently unsupported service type can be implemented by wrapping the calls in a custom Spring bean.
See * Creating a Data Object Model With an Expression-based Service Model for more information.