In the preceding chapters we illustrated the transactional processes of Compiere, and in this chapter we will be dealing with more advanced aspects of Compiere, including the following areas:
- Overview of the Compiere Application Dictionary and its components
- Adding a custom field in Compiere
- Setting up a basic document process approval workflow in Compiere
The Application Dictionary is what 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—refer to www.omg.org). This means that the system design conforms to an open standard in its layered architecture between business, application, and platform logic. What MDA tries to achieve is to separate 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 follows:
To access the Application Dictionary you need to log in as a System Administrator and refer to the following sub menu:
Note
We will use the Java Swing (Compiere Standard Edition) user interface for illustration purposes in this section.
The Application Dictionary consists of the following configuration.
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 is 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 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 following screenshot, 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.
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 follows:
Based on the example shown above, a dynamic validation will be set up for the C_BPartner_ID column field (the Business Partner table key identifier) on the Order table, as follows:
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 follows:
The list defined through a Search Key and a Name is shown below:
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:
Compiere generates all of its windows in a standard dynamic way by reference to the defined AD. This AD window thus relates to setting up the Windows, and the Tabs (sub-linked windows) and Fields that are displayed on those Windows.
Illustrated here is an example of the Calendar and Period window that defines the structure of the periods within Compiere:
Windows may be of the following Window Types:
The Window Tabs refer to the sub-linked windows of the main window header, or the preceding tab. In the example below, the Calendar window is built by defining the Calendar, applicable Year, Period and Period control, and Non Business Day:
The window's Fields are populated from the Table and Columns associated with the window:
Forms are windows that are not automatically generated through the AD but are static and are usually for custom purposes, based on specific Java code classes.
Below is a Form that defines the File Import Loader process:
Once a Form has been defined, it is linked to the Java classes through the Classname (Swing) and Java Classname for Web UI fields. These classes will contain the source code to build these custom Forms.
These are windows that are used for quick searches and information views.
Here is the Info window for viewing invoices. It is defined through an SQL query on a table and then defining the columns within the Info Window:
Where database views may exist within the underlying database, the AD requires the Database views to be defined in the system in order to be accessible.
Here is an example of the Invoice database view for a week:
To distinguish them from normal tables, Compiere uses the RV_ prefix convention to name a Report View within the underlying database.
These are used to set up reports (link to a Report view) or a process that can link to a Java code class. Reports and processes may have parameters that define a selection process. Examples of a report would be an invoice enquiry, and an example of a process would be to generate invoices from orders.
Here is the actual Report that defines the Invoices per week report:
Reports may have access restrictions and selection parameters. If a report is also displayed as a Dashboard (Compiere Enterprise version 3.5 onwards) then an underlying dashboard widget needs to be defined.
An example of the Invoice Generate Process that links to the underlying Java class is as follows:
In windows, Buttons may be linked to processes (i.e. C_Invoice Copy From which copies lines from other invoices on the Invoice windows) and Processes need not all be manually run as such. Processes can be defined as server processes, and can also be scheduled through the Compiere scheduler.