(For more resources on Compiere 3, see here.)

The Compiere Application Dictionary (AD)

The Application Dictionary makes Compiere a truly unique and flexible business framework. Compiere was originally designed from the ground up on a model driven architecture (MDA), as defined by the Object Management Group (OMG). The system design conforms to an open standard in its layered architecture between business, application, and platform logic. MDA separates the business logic modeling, from technology modeling so as to ensure that both can evolve within their own domains, but still keeping within a framework of an open standard (and platform independent) that interconnects the two.

The benefit in the Compiere environment is that through modeling, design, and build the actual deployment time is greatly reduced. The AD also ensures a seamless upgrade of the platform while having little impact on the environment-specific business objects and processes.

The Application Dictionary of Compiere is meta data driven, meaning that contextual data defines the experience. This also means that the end user presentation layer and thus, the Graphical User Interface (GUI) platform have been defined in different technologies (i.e. Java Swing, HTML, and Ajax) and offers endless possibilities.

The Application Dictionaries can be illustrated as shown in:

To access the Application Dictionary you need to log in as a System Administrator and refer to the sub menu shown in:

We will use the Java Swing (Compiere Standard Edition) user interface for illustration purposes in this section.

Table and columns

This refers to the fundamental building blocks of the system, and links Compiere data to the underlying Table and Column structures in the database. Illustrated below is the Period table in the AD that links to the underlying table name of C_Period, which you will find in the database:

If the underlying database already contains the required fields, then by pressing the Create Columns from DB button and having the correct DB Table Name, Compiere will create the columns from the database in the AD.

Within a table, a key column must be created for use as the table identifier:

Illustrated the key column C_Period_ID. A column links to a System Element, as explained below, and is linked to the underlying table through the Synchronize Column button. In effect, synchronization creates or updates a column to the underlying database.

System elements

System elements are the common data elements and are used for central terminology references. These system elements link the underlying database columns to business-speak, for instance, in the screenshot in Image 5, C_Period_ID would be translated into the actual period.

System elements are also used for setting up translations, as well as help comments on column fields.

Validation rules

Field validation rules that are defined in the context of a column field are dynamically verified based on the predefined rules or user context, at time of rendering the data. For instance, when a Business Partner field is displayed for selecting, the Business Partner account must be active and not be a Summary Account as shown in Image 6.

Based on the example shown in Image 6, a dynamic validation will be set up for the C_BPartner_ID column field (the Business Partner table key identifier) on the Order table, shown in Image 7.

Reference

A Reference refers to database column field types that are either Data Types (i.e. an Amount, Integer, Date, Time, image, hyperlink, etc.) or a List validation (i.e. user pre-defined dropdowns) or Table validation (i.e. drop-downs for table key columns). An example of a Data Type column would be a period start date. The Column field StartDate in the Period table in the database is defined as reference Date

An example of a list validation on a Period Control Action (the actions that you can perform on a period) set-up is as shown in Image 9.

The list defined through a Search Key and a Name.

The list defined through a Search Key and a Name.

Search keys are saved in the database.

Table Validations are data-defined based on existing referenced key columns and SQL selection. An example of a table reference would be a Document type based on a table validation SQL query. Herewith, a Document type (C_DocType) is defined, but it refers to the appropriate Tenant/client so as to ensure that only the document types for a Tenant are displayed, shown in Image 11.