INTRODUCTION TO MODEL DRIVEN ARCHITECTURE
This chapter describes Compiere's Model Driven Architecture and the Data Dictionary functionality in Compiere.
In most applications, developers must design code and test every screen. This can be very time consuming and lead to inconsistency across an application in terms of look and feel, as well as functionality. This can also make it difficult for users to learn new areas of a complex application like ERP. Compiere simplifies the task by using a more advanced concept of a central active data dictionary. Windows are generated at runtime from the data dictionary. Developers simply define the rules for how the window displays and in what conditions. This results in windows that only display data that the user needs to see for a given situation. For example, if a Sales order involves the customer taking the merchandise with them and paying you, there is no need to display fields like Shipping Rule, Invoice Rule or Payment Term. But, if a Sales Order involves you shipping merchandise to the customer and sending them a bill for payment at a later time, these fields are necessary. In addition to providing a consistent look and feel, it also enables data and fields to be displayed based on a user's security. In other applications this would require the definition of multiple windows.
THE DATA DICTIONARY
Compiere's data dictionary is an integral part of the application. It "knows" how to access data and how data is related. The data dictionary contains definitions of a data entity (type, validation, etc.), how it is displayed (label on screens reports, help, display sequence position relative to other fields), and the display rules. Security and access rules are also maintained here.
The data at runtime is context sensitive. For example: it "knows" that a counter sale does not have a payment term, so it does not display one. It also knows that there must be stock available even if the inventory record shows zero (because, for example, a material receipt has not been processed). However if the user changes the transaction type to a standard order, a payment term becomes a mandatory part of the transaction and the transaction recognizes the "out of stock" situation. Additionally, translations of the user interface as well as Business Partner documents is done in the data dictionary.
The Data Dictionary is user extensible and can include user specified rules and information. This enables authorized users to add new tables and new screens and additional fields to existing screens. All added items are automatically able to be listed and reported using the standard reporting functionality available throughout the application.
The Data Dictionary is comprised of six main entities
- Table & Column
- Window, Tab and Field
- Reports and Processes
Elements provide a central reference for all fields. Any field defined for any table in Compiere has a corresponding Element. This provides for consistent labeling of fields, display on reports, and help text. It also means that an element needs to be defined only once even though it may be used in hundreds of tables and multiple windows (e.g. Organization). The data from the Element (Name, Print Text, Description, and Comment) is automatically synchronized with the corresponding fields in both tables and windows.
Elements are defined in the Element window. This window can be accessed when logged in with a System Administrator role.
Each Element must have a DB Column Name. This is the reference that is used when linking an Element to a specific field in a table. A Name and Print Text are also required. The Name is the label that will be used on any window, form or parameter form where the element is referenced. The Print Text is the column heading that will print on reports. There may be instances where you will want a shorter Print Name to maximize report layout. For example, the Element ISVendor is a 1 position Boolean. For a report heading you may want to print 'Vend'.
The Description and Comment fields are not required. In most instances you will want to provide values for these fields. The Description field is the text that will display in 'bubble help' when you hover your cursor over a field. The Comment field will display as the online help (F1) for that field.
The Active check box indicates that this Element is active and can be referenced when defining columns of tables.
The Entity Type will default to User Defined for any records you add. You can change this to another Entity Type that you have defined. You should not use Compiere or Dictionary if you want your additions preserved when migrating.
The Element window also contains a Used in Column tab. This displays all of the columns where this Element is referenced. This can be helpful if you are considering changing an existing element as it will indicate what other entities your changes would affect.
TABLE AND COLUMN
Tables are the entity that Windows are built on. You can define a table and its associated columns directly in the user interface and then synchronize the definition to the database (basically running a table create statement). Alternatively, you can create the table using a SQL tool and then create the columns from the database. Then, simply update the table and column definitions with the appropriate data dictionary parameters.
New table can be created by opening the Table and Column window, while logged in with a System Administrator role.
Enter a DB Table Name. If you have created the table in the database make sure that the name provided here is the same. This will enable you to create the columns from the database.
You also must enter a Data Access level (for automatic Roles) and a Transaction Type. The Transaction Type will indicate if an explicit Organization value (other than *) is or is not required when a record is saved to this table.
Other fields are optional. Some of these have a direct impact on the data dictionary functionality.
The Window and PO Window fields indicate which window will be the 'Zoom Target'.
The High Volume check box, if selected, will cause the window that references this table to initially display a query window. If the checkbox is deselected, it will return all active records.
If the Table has been created in the database, select the Create Columns from Database button to create the columns in the Data Dictionary.
Columns will display as fields in the windows that reference the table. Columns can either be entered in the Data Dictionary and then synchronized with the database or they can be created from the table already populated in the database.
The values selected and data entered in the column will determine how and when the fields display in windows. There is further refinement that can be done in the Window definition, which will be covered in the next section.
The DB Columns Name is required (we suggest using the same name as the Element)
Select the Element that corresponds to this column. If you create the columns from the database and an Element with the same name does not exist, the process will create the Element.
Enter a Name. You can leave the Description and Comment blank as they will be synchronized with the Element when the record is saved.
Some of the other fields in Column which are used by the Data Dictionary include:
- Reference field determines how the field is accessed. For example, TableDir indicates that the table name can be determined by removing the _ID from the field name. A value of List will prompt for a Reference for the List (discussed later).
- Default Logic allows for defining rules which will populate the field when creating a new record. This logic can include variables based on selections made at login time or based on the user who logged in
- Mandatory Logic allows for defining the circumstances in which this column is required.
- Callout Code allow for the execution of code when the user tabs off of the field. This is a data entry consequence and should not be used for validation (which should occur before a user leaves the field). An example of a callout is in the Sales Order window. When the user enters a Business Partner, the callout that is executed updates other fields in the window such as Price List, Delivery Rule and Partner Addess.
- Identifier indicates what displays in the field or drop down list when a user selects it. For example, when the user selects a Partner Group, the Partner Group Name not the Partner Group ID displays. It is possible to have multiple Identifiers defined and the fields will display separated by an '_'.
- Selection Column indicates what fields display in the initial search window if Search is selected. All fields on a table are available in the Advanced Search tab.
The Synchronize Column should be selected if you are creating the columns in the database or if you have changed part of the table definition (e.g. the Constraint Name or increased the Field Length).
WINDOW, TAB AND FIELD
The Window, Tab & Field Window defines the presentation of tables and columns within each window. Each Tab in a Window refers to a single Table. The Fields in the Tab of a Window refers to the Columns in the Table.
The Window Tab defines each window in the system. The Name and Window Type are required. The Name is what displays in the window heading. It is also the Name that displays in the Menu. The system will synchronize the Window Name with the Menu entity.
The Window Type determines the behavior of the window when the user opens it. For example if the Window Type is Maintain, then all active records are retrieved. If the Window Type is Transaction then only those records that were created or updated today or that are not Completed will be displayed. (Note that all records can be retrieved using the Search facility). Generally, when dealing with transaction windows, e.g. Invoices, you do not want to retrieve invoices that are 2 years old, you want to see what was worked on today and what still needs further work.
The Window Access Tab defines the Roles which have access to this Window. This is generally defined in the Role Window.
The Tab Tab defines each Tab within a Window. Each Tab refers to a single table. All columns on the table can be displayed but generally a specific selection of fields is used. Note that the display and read only logic (along with the default logic defined for the Table/Column) is evaluated when loading the window.
In Tab, the required fields are Name, Table, Sequence and Tab Level. The Name indicates what displays in Help text and the Table will determine what fields are available for display as well as the table that will be updated when a record is added, deleted or modified in this window tab.
The Sequence determines the order the tabs will appear in the window. By default, the system will increment the Sequence by a value of 10 for each new tab added.
The Tab Level determines is the tab is a child record of a previous tab. A Tab Level of 0 indicates it is the starting Parent Tab. A Tab Level of 1 indicates it is a child of the Parent Tab (e.g. in the Product Window, BOM tab is a child of the Product Tab). A Tab Level of 2 indicates it is a child of the previous Tab Level 1 (e.g. BOM Component is a child of the BOM Tab).
Some of the other features of the Tab definition are:
- Process indicates that a process which can print a document will be enabled for this tab. This is what will control if the Print Button on the window is enabled (e.g. on Invoice window there is a process defined and the print button is enabled and on Product window there is no process defined and the print button is not enabled).
- Single Row layout, if selected indicates that when the window opens it will display in single record mode (swing only).
- Advanced, Accounting and Translation Tab check boxes indicate if the display of this tab will be controlled, along with security, by the settings defined in Preferences.
- Display and Read Only Logic allow the definition of business rules to control the display and update of a tab. For example, in the Product Window, the BOM tab is has Read Only Logic which prevents entry of data if the BOM check box is not selected.
The Field Tab defines the Fields displayed within a tab. Changes made to the Field Tab become visible after restart due to caching. If the Sequence is negative, the record are ordered descending. Note that the name, description and help is automatically synchronized if centrally maintained.
The Name and Column are required. The columns available for selection is based on the table defined for the Tab. The Name, Description and Comment will synchronize from the Columns definition (which has synchronized from the Element definition). If, in a specific window you want to use a different field label or have a different help definition, simply enter the desired content and de-select the Centrally Maintained check box. This will prevent the synchronization of this specific field from the Table/Column values.
Some other attributes of Fields which affect the display are:
- Displayed indicates if the field will be displayed. If a field is not needed in a specific implementation you can de-select this flag. Note that if the field is required you must first ensure there is a default value defined. Also, if a field is not displayed that may compromise the field layout..
- Read Only indicates that the field will be displayed but cannot be updated. For example, if you do not want users to update the Price List in a Sales Order set the field to Read Only. The Price List field is required, but there is a default (either from the Business Partner or Tenant Level).
- Sequence and Same Line determine where it displays in the Window.
- Default Focus indicates that when a new record is entered, the user's cursor will be on this field.
- Obscure allows you to obfuscate the field (e.g. show just the last 4 digits of a credit card number). This is how it will also print on reports. However, it is stored as clear text in the database. You can encrypt fields for display and in the database by selecting Encrypted.
Context allows the definition of alternate field labels for given windows. For example, the field Business Partner means different things to the user in different Contexts. In a Sales Order, the Business Partner is 'Customer', in a Purchase Order it is 'Vendor'. The Context window defines the different contexts for the system. Different field labels are then defined for the appropriate Elements and the Context is assigned to the desired Windows.
A number of Contexts are defined (for example, Sales, Purchasing and Request). You can add new Context records if necessary.
Next for the appropriate Element new Names, Print Text, Description and Comment are added. It is not necessary to define context values for all fields. The system will use the standard element definitions if no context is defined.
Lastly, select the appropriate Context for the Window (e.g. in Sales Order the Context is defined as Sales).
Reports and Processes
In Compiere, Reports and Processes are technically the same entity. Both can have a pre-process (e.g Parameter Selection) and both can have output (e.g. Report Viewer). To a user, however they are viewed as separate entities. For that reason, they are differentiated in the Menu by the icon.
To define a Report, open the Reports and Processes window.
The Name is the Name that will display in the Menu as well as in the report header.
The Description and Comment will display in the confirmation window that displays when the user clicks on the report icon in the menu. This is a good way to provide information on what the Report or Process is used for.
The Data Access Level is used for automatic generation of Role security.
Select the Report View checkbox to indicate that this is a Report. This will assign the Report Icon to this menu item as well as display the appropriate fields (e.g. Report View) for further defining the report.
Enter the remaining fields as appropriate. The only other field that is required is the Report View.
The Direct Print check box indicates that the report will print automatically when the report is executed.
If desired, you can enter a Print Format to use when this report is generated. If no print format is selected.
Select the Parameter tab to define the parameters for this Report. The fields available for selection are restricted to those fields in the selected Report View.
Parameters allow for default values, required or optional and ranges for values or dates.
Any Parameters that are used when generating the report are printed in the Report header.
As mentioned previously, Processes are defined in a similar manner to Reports.
As the Report View check box is not selected the Process icon will be used in the Menu. Also, the Report View, Print Format and Direct Print fields do not display (this is an example of display logic defined for the window).
Here you will enter a Classname and/or Procedure that is associated with the Process. You can also select Server Process if this should run only on the Server (as opposed to the client when using the Swing client).
The Workflow field is used when the Process you are defining is a process that is started by the selection of a button (e.g. the Complete button on a document).
Same as Reports, Processes can also have Parameters for the user to entered when executing the process.
Forms are complex windows that are hardcoded. Generally they involve data from more than one table and may have a one to many or many to many relationship. Unlike other entities, forms are defines separately in the Swing client and HTML client.
The Classname is the code that is used to generate the form for the Swing client.
The Java Classname for the WebUI is the code that is used to generate the form for the HTML UI.
If defined, the jsp URL defines the URL that is used for running the java class for the HTML UI.
Reference is used in Column (of Table and Column) to control what displays in a field and how it displays. References can be one of three different Validation Type; DataType, List or Table Validation. The type selected is generally based on how the field is used and the level of control desired.
A Validation Type of DataType is used to define different field types (e.g. Button, Date Time, Number). Generally you will not need to create new References of a Validation Type of DataType
!reference DataType.jpg!A Reference Validation Type of Table Validation is used when you want to present the user with a list of values for their selection and that list is based off of a table that the user may or may not have the ability to add records to.
When you select a Validation Type of Table Validation, the Table Validation tab is enabled (this is an example of read only logic defined for a Tab in Window, Tab and Field).
Here you select the Table Name and the Key column for the Table. The display column is what will display in the drop down list box.
Select the Display Value check box to display the field value in the drop down list box.
Select the Display Identifiers checkbox if the list should display all fields that are indicated as identifiers for the table.
If appropriate, enter a SQL WHERE and ORDER BY clause to control what displays in the list and in what order. This is used to prevent summary organizations from appearing in the organization drop down list box in documents.
A Reference Type of List is used where you want to present the user with a list of values from which to make a selection, but that list is defined in Reference (as opposed to being derived from a table). Lists are most often used in situations where there is some logic associated with the value selected, and therefore code is involved. In those situations you need to know what the possible values could be. Examples of this are the Shipping Rule in Sales Order. These values are restricted to the list defined in Reference and the value selected impacts the Generate Shipment process. Therefore it would not be appropriate to allow users to enter any value they want.
When a Validation Type of List Validation is selected, the List Validation tab is enabled. This allows the entry of the values that will be displayed to the user for selection.
The Search Key is used to control the order the values appear in the list, while the Name is what is presented to the user for selection.
Validation Rules are used to control what is displayed for selection to a user (similar to a SQL Where Claus in a Reference entry). However, these can be used for any field type in a Column. It is selected in the Dynamic Validation Rule in Table and Column. As indicated by the name, it is dynamically executed when selecting the list or lookup.
In this example, the validation is being used to ensure that the selection presented to the user contains just Locations that are defined for the Business Partner selected that have the Ship to Address check box selected. This prevents the display of locations that are associated with other Business Partners or locations that are not indicated as Ship to Addresses.
This validation is dynamic because it is based on the value selected in another field (in this case Business Partner).
As with other Data Dictionary windows in Compiere, the Validation Rule has a Used in Column tab. This is helpful if you want to change a Validation Rule as you can see from this tab what other areas of the system.
The Data Dictionary in Compiere is a powerful development tool. Much of what is done in code in a traditional system can be accomplished in the Data Dictionary. This helps to provide consistency across the application (especially when multiple developers are involved), stability in addition to fast, agile development.
The Compiere application is full of examples which displays how different features of the dictionary work. No matter what type of extension or customization you are working on, you can generally find an instance else where in the application that works in a similar manner.