Working with Model Display | ||
---|---|---|
Previous | Next | |
Integration Process Design | Working with Applications |
The content of the MDM hub can be accessed by connecting to a given data edition, which is based on a deployed edition of the model.
When a user performs such an access, a web user interface is automatically generated for this user.
The default layout of this interface includes the entities of the model, displayed based on their display properties, and filtered by the model security. This chapter describes how to to define the display properties used when accessing the entities via the web interface.
Tip: To define specific a user or role specific access to the MDM hub content, including human workflows for managing the hub data, it is necessary to create an Application.
The display properties of the entities are defined as part of the model.
The
Labels and
Descriptions provided when creating and editing the entities, attributes, types and references are are used when displaying the entities of the model. For more information about these properties, see the
Logical Modeling chapter.
Other artifacts specific to displaying a model can be defined in the model. They include the Entity Display Names, Complex Types Display Names, Attribute Groups and Localization, described in the following sections.
An entity is a structure containing several attributes (simple and complex). When an entity value needs to be displayed in a compact form (for example, in a table, or in a single field), the Display Name is used.
The display name defines how an entity is displayed in compact form. It is a concatenation of several attributes, separated by a
Separator.
For example, a
Contact entity is shown as
<first name>˽<last name>.
To create or modify an entity display name:
Note: Only one display name can be created for a given entity.
A complex type is a structure containing several attributes. When a complex attribute value needs to be displayed in a compact form (for example, in a table, or in a single field), the Display Name is used.
The display name defines how a complex attribute is displayed in compact form. It is a concatenation of several definition attributes, separated by a
Separator.
For example, the
GeocodedAddress complex type contains a large number of attributes, from the simple
StreetNumber down to the
longitude and
latitude. A display name would be for example:
StreetNumber
StreetName
City
Country .
To create or modify a complex attribute display name:
Note: Only one display name can be created for a given complex type.
Attribute Groups define UI sections into which the attributes are shown.
For example, displaying a contact attributes in
General,
Phone Numbers,
Addresses and
Internet sections
To create an attribute group:
Note: It is possible to have multiple attribute groups on a single entity. In addition, an attribute can be used in several attribute groups at the same time.
Attribute groups will appear as sections when viewing this entity’s data. It is possible to edit, order or delete attributes groups in an entity from the Attribute Groups list in the entity editor.
To order the attributes in an entity:
When designing a model, labels, descriptions and other user-facing text strings are entered to provide a user-friendly experience. These strings are natively externalized in Semarchy Convergence for MDM, and can be translated (localized) in any language.
A user connecting an application created with Semarchy Convergence for MDM will see these strings (label of the entities, attributes, list of values, etc.) translated in the locale of his web browser if such translation is available. If no translation is available in his locale for a given text, the default string (for example, the label or description specified in the model) is used. These default strings are the base translation.
Warning: make sure to translate the entire model in a given language to avoid partially translated user interfaces.
Strings translation is performed using
Translation Bundles, attached to model editions. A translation bundle is a properties file that contains a list of key/value pairs corresponding to the strings localized in a given locale. The translation bundle file is named
translations_<locale>.properties
, where
The following example is a sample of a translation bundle file for the English language (
translations_en.properties
). In this file, the label for the
Employee entity is the string “Staff Member”, and its description is “A person who works for our company”.
...
Entity.Employee.Label=Staff Member
Entity.Employee.Description=A person who works for our company.
Attribute.Employee.FirstName.Label=First Name
Attribute.Employee.FirstName.Description=First name of the employee
Attribute.Employee.Picture.Label=<New Key TODO>
...
To translate a model:
To export translation bundles:
To import translation bundles:
translations_<locale>.properties
or a zip file containing several of these properties files.
The translations for the model edition in the selected languages are updated with those contained in the translation bundles. If the Cleanup Removed Keys During Import was selected, translations in these languages no longer used in the model are removed.
The lifecycle of the translations is entirely decoupled from the model edition and deployment lifecycle:
Tip: Decoupling the translation lifecycle from the model edition avoids binding the critical model development and release process to the translation process, as the latter frequently is managed by a separate team. This also allows adding new translations or fixing translations without having to re-deploy a new model edition.
Warning: When creating a new model edition, the translations from the previous model edition are not copied to the next edition. It is necessary to export and import translations between editions.
Previous | Top | Next |
Integration Process Design | Working with Applications |