Cloud Software Group, Inc. EBX®
Documentation > User Guide > Data models > Implementing data models
Navigation mode Documentation > User Guide > Data models > Implementing data models

# Data model extensions

## Extensions used by the data model

On any data model, it is possible to specify some extensions to be used. These extensions will have the capacity to define additional features around the data model and to enrich the current data model after the publication by adding properties and constraints to the data model elements. Data model extensions are displayed in the navigation pane under the section 'Extensions'.

The following extensions are automatically enabled on new data models:

- Toolbars

- Entity mappings

- Replications

- Indexing and search strategies

- Business objects

- Custom forms

- Scripts

- Record permissions

- Node confidentiality

Some extensions are optional and defined in dedicated datasets. These extensions can be disabled or enabled through the user interface.

Optional data model extension can be disabled by selecting the action 'Disable extension' from the menu to the left of extension to disable.

##### Note

When disabling an extension its dedicated dataset is also deleted and it is not possible to recover it after its deletion

From the menu to the left of 'Extensions' entry in the navigation pane, you can enable an extension by selecting the action 'Enable an extension'. This option is only displayed if some extensions are available. When selecting this action a form displays the available data model extensions.

Once a data model extension is activated then it is displayed under the entry 'Extensions' in the navigation pane and can be edited as a regular dataset. That is, the configuration of an extension is embedded in a dedicated dataset that benefits of all EBX® features available on datasets.

## Indexing and search strategies

This feature is documented in the chapter Search.

## Business objects

A business object is an abstract layer that allows manipulating records from several tables within the same data model. The definition of business objects, named business object model, can be performed in the data model via the 'Extensions' section. A business object model is defined on a main table and contains child entities that are defined using the relationships from this main table.

Create a business object model from the Business objects > Definitions section of the navigation pane, by clicking on the menu located to the left of Business Objects, then selecting the Create Business Object option. Follow the creation wizard to create a business object model. A business object model defines the following information:

Business object name | Business object model's name. The name must be unique in the context of the data model since it is used to uniquely identify the business object model. That is, it is not allowed to create several business objects with the same name.
Label and description | Internationalized labels and descriptions to be displayed to end users.
Main table | Defines the main table of this business object model. Specified path must be absolute (must start with "/"). The main table of this business object model cannot be used if it is already a part of another business object model. That is, the main table cannot be used if it is already defined as the main table or as a child entity of another business object model.

### Defining the structure of a business object model

A business object model is composed of a main table and child entities. Child entities are defined using the relationships contained in the main table.

Add a child entity under a business object model by clicking on the menu located to the left of the existing business object, and by selecting the Add child entity option. Then, follow the creation wizard to create a child entity. The following information must be set:

Relationship to table | This field defines the relationship to the table to add as a child entity. The path to the relationship must be absolute (must start with "/"). Only foreign key constraints and associations by inverse foreign key are supported. Also these relationships must comply with the following constraints: Foreign key constraints cannot be a list or under a list. Associations by inverse foreign key must refer to a foreign key field that cannot be a list or under a list. Also, the target table of the relationship cannot refer to a table that is already used by this business object model or another one. That is, the target table cannot be used if it is already defined as the main table or as a child entity of a business object model.

## Toolbars

A toolbar allows to customize the buttons and menus that are displayed when viewing tables or records in a dataset. The customization of toolbars can be performed in the data model via the 'Extensions' section.

Add a toolbar from the Toolbars section of the navigation pane, by clicking on the menu located to the left of [ All elements ], then selecting the Create toolbar option. Follow the creation wizard to create a toolbar. A toolbar defines the following information:

Name | Toolbar's name. The name of the toolbar must be unique in the context of the data model. That is, it is not allowed to create several toolbars with the same name.
Label and description | Internationalized labels and descriptions to be displayed to end users.
Default template | Allows to create a toolbar with the structure of a default toolbar.
Locations | Specifies the locations where the toolbar can be used in associated datasets. Tabular view top: Defines the toolbar to use on top of the default table view. Tabular view row: Defines the toolbar to use on each row of the default table view. Tile view item: Defines the toolbar to use on each item of the tile view. Record top: Defines the toolbar to use in the record form. Hierarchy top: Defines the toolbar to use in the default hierarchy view of the table. Known limitations A toolbar defined to be used as "Tile view item" cannot have more than six items and it can only define action items. The display of those action buttons are always in mode "Icon only".

### Defining the structure of a toolbar

A toolbar can define the following elements:

- Action button

- Menu button

- Separator

- Menu group

- Action menu item

- Sub menu item

Add one of these elements under a toolbar or to an existing element by clicking on the menu located to the left of the existing element, and by selecting a creation option in the menu. Then, follow the creation wizard to create an element.

#### Action button

This type of element allows to associate an action to a button in a toolbar. The action will be triggered when the user clicks on the associated button in one of the toolbars. A Action button type element defines the following information:

Service | Defines the service that will be executed when the user clicks on the button. It is possible to select a built-in service, or a user service defined in a module or in the current data model. If the 'Web component' target is selected, the service will have to be declared as available as a web component for toolbars.
Label and description | Internationalized labels and descriptions to be displayed to end users.
Layout | Defines how this element will be displayed in datasets using the toolbar. It is possible to display: the icon only, the text only, text with the icon to the left or text with the icon to the right.
Icon | Icon to display. It is possible to use an icon to choose from a set of suggested icons, or to refer to an icon using a URL.
Relief | Defines how this button will display. The button can be displayed as embossed or flat.
Is highlighted | Indicates if the button should be highlighted by default.

##### Note

A Action button type element can only be created under a toolbar type element.

#### Menu button

This type of element allows to define a menu that will be displayed when the user clicks on the associated button in a toolbar. An element of the Menu button type defines the following information:

Label and description | Internationalized labels and descriptions to be displayed to end users.
Layout | Defines how this element will be displayed in datasets using the toolbar. It is possible to display: the icon only, the text only, text with the icon to the left or text with the icon to the right.
Icon | Icon to display. It is possible to use an icon to choose from a set of suggested icons, or to refer to an icon using a URL.
Relief | Defines how this button will display. The button can be displayed as embossed or flat.
Is highlighted | Indicates if the button should be highlighted by default.

##### Note

An element of the Menu button type can only be created under an element of the toolbar type.

#### Separator

This type of element allows to insert a separator in the form of spacing between two elements of a toolbar.

##### Note

An element of the Separator type can only be created under an element of the toolbar type.

#### Menu group

This type of element allows to define a group of elements in a menu. An element of the Menu group type defines the following information:

Label and description | Internationalized labels and descriptions to be displayed to end users.
Group type | Specifies the type of menu group to create: - 'Local' allows to create an empty fully customizable menu group. - 'Service group' allows to assign an existing service group to this menu group. - 'Menu builder' allows to assign a predefined menu content to this menu group. Once created, it is not possible to change the type of this menu group.
Service group name | Specifies an existing group of services to reuse. A group is declared in a module and can include other groups of services. All services contained in this group will be displayed to end users in associated datasets.
Menu builder name | Specifies the predefined menu content to assign to this menu group: - 'Default menu "Actions"' has the same content as the default toolbar 'Actions' menu. Standard and custom services are displayed without distinction. - 'Default menu "Actions" (with separator)' has the same menu content as above, but displays differently since standard and custom services are separated (standard services first, then custom services).
Excluded services | Indicates the services to exclude from the group of reused services. These services will not be displayed to end users in associated datasets.
Excluded service groups | Indicates the groups to exclude from the group of services to reuse. Services in excluded groups will not be displayed to end users in associated datasets.
Filtering policy | In case of "Smart filtering", services that are configured in direct access, i.e. via an action button or an action menu item, will be removed from the automatic generation of this group.

##### Note

An element of the Menu group type can only be created under the following elements:

- Menu button

- Sub menu item

#### Action menu item

This type of element allows to associate an action to a menu item in a toolbar. The action will be triggered when the user clicks on the corresponding item in a menu. An element of the Action menu item type defines the following information:

Label and description | Internationalized labels and descriptions to be displayed to end users.
Service | Defines the service that will be executed when the user clicks on the button. It is possible to select a built-in service, or a user service defined in a module or in the current data model. If the 'Web component' target is selected, the service will have to be declared as available as a web component for toolbars.

##### Note

An element of the Action menu item type can only be created under a Menu group type element.

#### Sub menu item

This type of element allows to add a sub menu to a toolbar menu. Un Sub menu item defines the following information:

Label and description | Internationalized labels and descriptions to be displayed to end users.

##### Note

An element of the Sub menu item type can only be created under an element of the Menu group type.

### Deleting elements

All the elements of a toolbar can be deleted from it by using the menu located to the left of the element to be deleted.

If an element containing other elements is deleted, then the deletion is recursively performed on all elements located below the deleted element.

### Duplicating existing elements

To duplicate an element, click on the menu located to the left of the element to duplicate. Specify the name and properties of the duplicated element. All the source element properties are duplicated.

The duplicated element is added on the same level than the original element, in the final position. When an element containing other elements is duplicated, all the sub-elements are duplicated with their properties.

### Moving elements

In order to move an element, click on the menu and select the moving option to be used.

### Associate with existing tables

To associate a toolbar with existing tables, click on the menu located to the left of the toolbar and select the option Associate to tables. This service allows to set the toolbar has the default toolbar of several tables in one shot. To do so, specify the target locations of the toolbar and select the tables or complex data types, that define table properties, to be associated with the toolbar.

### Exporting the toolbars

It is possible to export the toolbars defined in the model into an XML document. To do so, select the XML export option available in the Actions menu of the 'Toolbars' section. Follow the wizard to export the toolbars.

##### Note

A selection of toolbars can be exported by selecting in the 'Toolbars' section the toolbars to be exported and then by selecting the XML export option available in the Actions menu. The toolbars can also be exported by using the data model export service. It can be found in the Data model 'Actions' menu in the navigation pane.

##### See also

- Data model import and export

### Importing toolbars

It is possible to import existing toolbars from an XML document. To do so, select the XML import option available in the Actions menu of the 'Toolbars' section. Then follow the wizard to import the toolbars.

##### Note

The toolbars can also be imported by using the data model import service accessible via the Data model 'Actions' menu in the navigation pane.

##### See also

- Data model import and export

##### See also

- Use of toolbars

## Entity mappings

You can refer to tables in SQL requests and data service operations using unique names instead of their paths. To accomplish this, you must define entity mappings to create an association between a table path and a name. When referencing a table you then use this name as a WSDL suffix in data service operations and an alias in SQL requests.

##### Note

EBX® automatically creates an entity name for the tables defined in a data model. The last step of the table's path is used as the default entity name. Since entity names must be unique in a data model, an error is now raised during compilation if the model contains tables with the same name. To prevent an error in this case, you must explicitly set the entity names.

To define an entity mapping through the user interface, in the navigation pane when viewing a data model, navigate to Extensions > Entity mappings and create a new record. You can define the following properties:

Table path | Specifies the path of the table in the current data model that is to be referred by this name in SQL requests or WSDL operations.
Entity name | This name is used to suffix all WSDL operation names of the concerned table and as an alias in SQL requests. If undefined for a given table, the last element of the table path is used instead. This name must be unique in the context of this data model.

##### See also

- Data services

## Replication of data to relational tables

In any data model, it is possible to define replication units for data in the repository to be mirrored to dedicated tables in the relational database. These tables then enable direct access to the data by SQL requests and views.

To define a replication unit through the user interface, create a new record in the 'Replications' table under the extensions' section in the navigation pane. Each replication unit record is associated with a particular dataset in a given dataspace. A single replication unit can cover multiple tables, as long as they are in the same dataset. A replication unit defines the following information:

Name | Name of the replication unit. This name identifies a replication unit in the current data model. It must be unique.
Dataspace | Specifies the dataspace relevant to this replication unit. It cannot be a snapshot.
Dataset | Specifies the dataset relevant to this replication unit.
Refresh policy | Specifies the data synchronization policy. The possible policies are: On commit: The replicated table content in the database is always up to date with respect to its source table. Every transaction that updates the EBX® source table triggers the corresponding insert, update, and delete statements on the replicated table. On demand: The replicated table in the database is only updated when an explicit refresh operation is performed.
Tables | Specifies the tables in the data model to be replicated in the database. Table path: Specifies the path of the table in the current data model that is to be replicated to the database. Table name in database: Specifies the name of the table in the database to which the data will be replicated. This name must be unique amongst all replications units.
Aggregated lists | Specifies the properties of the aggregated lists in the table that are replicated in the database. Path: Specifies the path of the aggregated list in the table that is to be replicated to the database. Table name in database: Specifies the name of the table in the database to which the data of the aggregated list will be replicated. This name must be unique amongst all replications units.

##### See also

- Replication

## Node confidentiality

The confidentiality of a node defines whether or not it can be used in a Query or in a Request when hidden for a specific user. By default, all nodes are confidential.

This can be configured in the DMA, by using the "Extensions" tab in the node form editor. It is possible to define the confidentiality at several levels:

- at a data model level (root node): defines the default confidentiality for the data model terminal nodes, unless a more specific definition is set (that is on the table or the node itself).

- at a table level (table node): defines the default confidentiality for the table terminal nodes, unless a more specific definition is set (that is on the node itself).

- at a terminal node level: defines the confidentiality of the node.

For more information, see Defining confidentiality

User guide table of contents

Documentation > User Guide > Data models > Implementing data models