View source | Discuss this page | Page history | Printable version   

ERP/3.00/Platform Topic Description



This page contains a short description of possible changes and improvements to the Openbravo platform.

It is a proposal, the goal of this page is to describe new ideas in some detail to identify challenges and opportunities.

Separating the Physical and Logical Data Model

In Openbravo 2.50 the logical and physical data model are combined in the AD_Table, AD_Column and AD_Reference (and related) tables. For the next release the idea is to separate the logical and physical in separate concepts. This separation has the following advantages:

The proposal is the following:

A summary of the associations/fields of an Entity and Property and the remaing fields of AD_Table:


Most of the time an entity will have one table but for flexibility we can allow an entity to have zero tables or more than one table (secondary tables). An entity has the following fields:

many of the above fields are currently present in AD_Table.

Note: the audit info fields are not defined here because they are assumed to be handled through concept entities (see later section).


A property is the conceptual/logical representation of a column. A property normally is linked to a column but this is not strictly necessary (for example computed properties). A property has the following fields:


The above field-list only contains fields which are required to support the new UI. It is possible that for backward-compatibility other current fields have to be added (for example callout).


The table and column concepts are discussed below in the section on storing the physical datamodel.

Help, comments

An entity and property can be used to attach different help texts and labels. It needs to be discussed/analyzed what makes sense here:

Help texts should be wiki or web like in that help texts can link to other help texts.

All help/texts/labels should be translatable (as it is now). The current application element structure can be used for that.

Convenience functionality

The system should offer convenience functionality to easily create entities/properties from a table/column definition and vice versa.

From Reference to Domain

The type of a column is currently defined using the AD_Reference table and its related tables. The column type currently describes both the type and also user interface aspects (the visualization method). The proposal in this section is to re-design the current reference implementation to separate the user interface and data modeling concepts.

The proposal is to replace the reference concept with the new concept: domain (or an alternative name: data type). A domain is used to create named primitive types, for example: quantity, price, sequence number etc. A domain has the following main properties:

A list domain definition uses an another entity (domainlist) to store the enumerate values.

The above domain definition fits to the current primitive type (incl. list) reference model. The tabledir, table and search references are not modeled in the domain definition. The following is proposed to handle these:


The validation defined in a domain and property should be based on a pluggable validation framework. The current AD_Val_Rule concept can be re-used for that. Although it can be extended in the following ways:

A validation can be implemented in java, javascript or in scripting language (to be defined). In addition it is possible that validation needs to be implemented differently for user interface and backend operation. This means that one validation can define multiple implementations: one for the user interface (in javascript) and one in java or a scripting language (to run server side). The interface of the client and server side validation needs to be determined (based on experience with prototypes etc.).

Storing the Physical Data Model in the Application Dictionary

The goal for the next Openbravo release is to make it possible to maintain the physical data model completely from the Openbravo user interface. There are multiple aspects to take into account:

This means that additional database schema aspects (than just table/column) need to be defined in the application dictionary:

It should be possible to initiate an update.database from the Openbravo user interface.

Some other aspects:

The last two aspects can be covered by re-using the current XML model and the code using it to create and update databases.


In the new concept the AD_Table will only store the physical database schema relevant data. The new AD_Table will hold the following fields:

Question: what to do with the following fields:


The column information can to a large extend be derived from the property definition. Therefore the column itself only stores additional physical db schema related information:

Question: what to do with these ad_column fields:

Supporting Inheritance

The proposal is to also support inheritance in the new application model. Supporting inheritance has the following advantages:

In general inheritance should be applied with some caution, inheritance structures should not be too deep.

Modeling Inheritance

Inheritance is defined in an entity: an entity can have a reference to its super entity. One thing to note is that if an entity is a subtype then it is not allowed to have its own id and version properties. Id and version properties should always be defined in the root entity of the inheritance structure.

Inheritance and the physical database schema

Inheritance can be supported (by Hibernate) in three different ways in a physical database schema (see here and here for a more complete description of inheritance mapping strategies):

In addition the JPA MappedsuperClass mapping exists. If a class is denoted as a MappedSuperclass then its properties are stored in the table of its subclasses, a MappedSuperclass does not have its own table. MappedSuperclass is similar to the concrete inheritance mapping, with the difference that MappedSuperclass allows much more fine-grained control.

Considering the advantages and disadvantages the proposal is to initialy use the joined-table strategy in Openbravo combined with supporting MappedSuperclass. If inheritance structures are not too deep then the performance penalty is not that much (expectation).

To support the joined-table mapping the following has to be taken into account:

Inheritance and Business Object Java classes

Mapping inheritance to the generated business objects is straightforward: if an entity inherits from another entity then the business object Java class of the sub-entity should inherit from the business object Java class of the super entity.

Concept Entities and Concept Injection

When modeling an application there are concepts which are common and generic for all or many entities, these are so-called cross cutting concerns. Examples of such generic concepts are audit tracing and security. In most systems such cross-cutting concerns need to be implemented and defined for each entity separately. This results in a less flexible system and also does not allow explicit modeling of these cross-cutting concerns.

When thinking about cross-cutting concerns there are different aspects which need to be taken into account:

To solve this in a better and more explicit way in Openbravo the proposal is to introduce the so-called 'Concept Entity'. A concept entity is very much like a normal entity, it has property and a table and columns definition. However, there are also differences:

To illustrate the usage let's do an example. In the next release the idea is not to add explicit audit info fields to each entity but to introduce a new Concept Entity: Traceable, which has four properties:

This concept entity is linked to most entities in Openbravo. This results in 4 additional properties/columns in each of the linked entities. The generated business objects for these entities will implement the Traceable interface (which is generated from the Traceable Concept Entity). The data access layer code performs specific actions when inserting or updating a business object if the business object implements the Traceable interface. The advantage is that by defining audit info like this there is one central location where this definition can be maintained.

Note that

Concept Entity to Java Interface

An entity is normally generated as a Java class to represent it in Java. Concept entities however translate to interfaces on Java level:

By representing concept entities as Java interfaces it is possible to develop specific business logic that makes use of these interfaces.

Concept Entity adds properties/columns to an Entity/Table

The concept entity can add new columns/properties to an entity/table. This has as consequence that special attention needs to be paid to name clashes in both property and column names. The name clash check should be done multi level over an inheritance tree.

Concept Entity with a list property

The introduction of this section only discussed concept entities which add new primitive typed or single reference properties/columns. There are however also concepts which requires a list property.

For example: in Openbravo and in many other systems it is possible to attach files to an object. The idea would be to introduce a concept: Attacheable. The attacheable concept has a property attachments which is a list of attachments. Attachments are stored in a separate table. Then every entity which requires attachments gets the concept entity 'Attachable'.

The difficulty with this model is that different entities can have attachments which has the following consequences:

There are two solutions for this situation:

The advantage of the first approach is that the datamodel has real foreign key constraints. The disadvantage is that it results in many more tables. The second approach results in no extra tables but has as large disadvantage that no foreign key constraints are maintained. These need to be maintained programmatically, in addition the hibernate mapping is more complex.

A choice has to be made which of the above solution strategies is supported.

Allowing custom code in generated business objects

Although this page is mainly about changes in the Application Dictionary there is also a related topic which can be covered in the next release of Openbravo: custom code in generated business objects.

Currently it is not possible to include hand-written code in the generated business objects. This because in the next generation run the complete class is regenerated. The current business objects are therefore 'only' data holders and have no behavior implemented. Although there is a tendency to implement a lot of business logic in service classes it still makes sense to have some code in the business object itself.

Therefore the proposal is make it possible to allow hand-written code in the generated business objects. The templating language used in Openbravo (XPand/XText) provides some possibilities for this with protected regions. It needs to be studied in more detail how protected regions can be generated into the business objects.

Also the generation logic has to be changed in that it currently removes all files in src-gen before regenerating. To support manual code this is not possible anymore, so files are regenerated individually. One thing to take into account is that in this approach files which are not related to an entity anymore (because of a name change) should be deleted explicitly.

Note: if we allow hand-written code then it is also possible to design and implement a new type of property: volatile property. A volatile property is a so-called computed property which is not stored in the database. It is computed on the fly. A separate extension (future) is to allow volatile properties to be implemented using a scripting language.

Versioning, optimistic locking

Although a small topic it influences the datamodel. Each type should have a version property and column. This is a numeric value starting from 0. The version property should be mapped as such in the hibernate mapping.

Data translation, Translatable, a concept?

Openbravo 2.50 has the concept of Trl tables which contain translated versions of data. For example, the name of a country can be translated. This is mainly used to show values of listboxes/comboboxes in the language of the user and to show translated data in reports. The Trl tables are defined explicitly for specific entities in Openbravo 2.50.

In Openbravo 3.00 the question is if we can move to a more generic concept which would allow to 'tag' any entity as being translatable. It can even be imaginable to specify translatability on property level.

If the choice is to do translatability on Entity level then it can be possibly be modeled as a concept-entity. The translatable concept can use a generic table to store the translated texts. This table has the following properties:

The value in the object itself then holds the default value.

To support maintenance of translations there are several options:

In addition, Openbravo core should offer easy api's to get a translated version of an object.

Rules Engines in Openbravo

TBD: summary of aspects of adding rules engines and scripting engines in Openbravo.

Data Versioning

Data versioning is a concept which allows keeping multiple versions of the same object in the database. The system should offer a specific view on this historic data. Data versioning can be used for different purposes:

Saving a new version of an object (actually creating a copy for the archive)

Historical trace

This concept can be achieved by having a separate history table, a common one or a separate history table for each entity. This history table should not have unique constraints and should be able to handle references to non-historized information.

Allow rollback of a change or a set of changes

The same history table as outlined above can be used. Some attention needs to be paid to rolling back as it is only possible to rollback changes in the same order as they were applied. The versioning mechanism should be tightly integrated with the database transaction, all changed/updated objects in a transaction should be versioned.

Override data, change data on multiple levels

This last purpose is very similar to code revisioning systems whereby branches are explicitly named, independently changed and merged (with conflict identification and solution). In this case the version is not automatically created when objects are changed or updated. The version is an explicit concept. Versions can inherit from eachother.

A client (to use an Openbravo term) operates in a certain version and sees all the data defined for this version and the non-overridden data in higher/older versions. As an example:

another object B exists only in version1.

Refers to means that if A-version2 is retrieved and the code calls A.getC() that C-version2 is returned, and if A.getB() is called that B-version1 is returned.

Then when C-version2 gets removed then A.getC() will return C-version1. Note that removing C-version1 is not allowed as A-version1 refers to it and there is no C-version0.

Now how can this concept be used? There are two very usefull scenarios:

The difference with the current Openbravo organization-natural-tree approach is that this versioning approach allows overriding and changing objects on a lower level. The Openbravo approach 'only' allows adding new instances on a lower level but not overriding existing instances.

Data Inheritance/Data Templating

The main purpose of an ERP system is to be able to register and maintain data. The requirements for defining data differ for the type of data. Data maintenance requirements for the system differ for example depending on the type of data (master or transactional) and the volume of data. Some data is simple other data is more complex and allows more advanced structures.

One of the more advanced requirements for a data maintenance system is to define data on different granularity levels. A good example is product data. With large product sets it is possible to divide the product set in different groups. A common characteristic of a group is that product have the same data for specific properties. Now assuming that one group can hold thousands of products it is clear that it makes sense to have some form of efficient maintenance or definition of the value of common properties (=properties that have the same value within a group).

There are different ways to do this:

Let's see how data templating works in practice using the product example. A user clicks on the new-on-tab button in a grid to create a new product. The product entity has been flagged with the data template concept and a data template field has been added to the product page. The page with the product is opened and the user sees several fields. Now assume that he/she selects the data template: high volume. This data template defines values for the order-quantity and the minimum stock level fields. By selecting the data template for these fields, these fields are disabled (not-editable) and the values are set from the data template. The same can be done on coding level, the system should offer an easy api to apply a data template to an object.

Introducting a common type

Instead of letting the user explicitly select a data template it is also possible to introduce another concept: a common type field, and let the data template be defined on type level. Assume that in the system we introduce a type entity which allows to define types for all entities by entity. So there is one type entity which has the following properties:

and a type value:

Note a type can be implemented as a concept-entity.

When an entity has the concept: type. Then when a type is selected for an instance the system should automatically select the data template, fill the properties and make the fields in the UI non-editable.

Explicitly Model: Operations

to prevent changing generated code

Discussion 26th-28th May

Retrieved from ""

This page has been accessed 3,071 times. This page was last modified on 9 June 2009, at 04:58. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.