Dynamic enumerations
Define and use enumerations
Dynamic enumerations are used to define enumeration types, i.e. data types that store a selection decision from a list of alternative options defined for the enumeration type as a value.
Degrees of freedom for enumerations
The following cases must be distinguished with regard to ‘customisability’ for Dynamic enumerations:
The enumeration as a whole is read-only. No enumeration values or direct properties of the enumeration can be edited.
This applies to enumerations predefined by the system (Print document type, Mail state, etc.) that have the ‘Internal dynamic enumeration’ indicator (systemDynamicEnum).
The definition of the enumeration can be opened via ‘Edit’. However, the ‘Save’ function is then not available in the detailed view.
Customised extensions are not provided.
The enumeration cannot be deleted, but enumeration values can be edited (created, changed and deleted if necessary).
This concerns enumerations predefined by the system (e.g. Locale, Country, Salutation, Working state, Company type, Number range type etc.), whose enumeration values can and should be adapted to specific requirements.
An important fraction within this group are enumerations that define ‘sub-types’ for predefined typed attribute types (Text type, Numeric types, Reference type, Flag type, Date types, Contact type, etc.).
For this purpose, the configuration for enumeration values provides the ‘Plural attribute’ (pluralAttribute) option, which regulates for each sub-type whether it can be assigned to the same owner once or multiple times.
The 'Enumeration name' (enumName) of predefined enumerations always refers to a namespace that begins with the string 'de.lobster.' (e.g. de.lobster.scm.base.address.Salutation for the Salutation).
Many of the relevant enumerations contain predefined enumeration values ex works, which can either be adopted or replaced or supplemented as desired.
The enumeration as a whole is customised so that there is full access to all properties and the enumeration values it contains.
This applies to Dynamic enumerations that were newly created by authorised Users after installation.
User-defined Dynamic enumerations can refer to a Custom dynamic enum configuration, which can be used to assign specific properties to enumeration values.
If a user-defined enumeration does not refer to a Custom dynamic enum configuration, it is assigned the configuration type ‘Typed attribute (configuration)’ (TypedAttributeConfiguration) by default.
This type provides the ‘Plural attribute’ (pluralAttribute) option in the event that the enumeration is to be used to define ‘sub-types’ for a Eigenes typisiertes Attribu.
►IMPORTANT◄ Regardless of whether Dynamic enumerations are predefined or customised, deleting enumeration values from the enumeration (as well as the enumeration itself) can be problematic if they have already been used ‘operationally’ so that transaction data and/or configuration refer to the values to be deleted.
View enumeration definition and edit if necessary
The menu item for Dynamic enumerations opens an overview that lists all enumerations defined in the system:
In the screenshot, a filter has been set for the Enumeration name (enumName) column, which lists two enumerations (see Mode of transport vs. Modes of transport) with the identical Enumeration label ‘Transport’.
While the Enumeration name is the same localisation for the data type based on the enumeration, the unique fully qualified class name appears in the Enumeration name column.
The following steps relate to the second list entry highlighted in the image.
Double-clicking in the list field opens the detailed view for the relevant enumeration in a new view, as does clicking on the Edit ribbon button (in conjunction with a selection).
More specifically, a ‘Combined view’ appears, which combines the header data of the enumeration (Enumeration name, Description – if applicable) with a detail area for editing enumeration values, which are displayed below as a list:
►NOTE◄ The Mode of transport was selected here as an example because it only provides minimal configuration options for enumeration values.
Dynamic enumerations can provide more or less complex configuration options for enumeration values, which then appear in the detail area of the view.
The data model for enumeration values therefore contains a configuration field to which a data object of the relevant configuration type must be assigned as a value.
For the Mode of transport, only the Icon URI (iconUri) field affects the (general) configuration type used (DynamicEnumConfiguration).
The Ordinal (ordinal), Name (name) and Description (description) fields are part of the parent data structure (DynamicEnumValueDefinition).
The Localised name is assigned via the Localization or Company specific localization and is not saved in the enumeration value.
Edit enumeration values in a predefined enumeration
Example: Mode of transport (predefined enumeration, with editable enumeration values).
The screenshot shows a list with definitions for values of the Mode of transport enumeration, with the options stored ‘ex works’ in Lobster Data Platform / Orchestration.
Each selection option identifies a unique Name (name) within the enumeration, whereby the enumeration here reflects the terminology and selection for the ‘transport mode’ (ROAD, SEA, AIR, RAIL) commonly used in freight logistics.
This Name appears, for example, in the XML structure of an entity if it has a field in which a selection for the Mode of transport is saved (see Dynamic enum field).
Typically, however, the Name is not stored as a String in the corresponding database table when the relevant entity is saved, but rather the Ordinal – which is also clearly assigned within the enumeration.
The Ordinal (ordinal) is automatically assigned during the definition of the enumeration and is therefore usually ‘forever’ in a (1:1) relationship with the corresponding Name.
The Ordinal values define the ranking of the values within the enumeration, which can be decisive if, for example, a Sorting in a Search or a rank compare in an Entity property rule (see Compare with) refers directly to enumeration values.
The Localised name is subsequently assigned in Lobster Data Platform / Orchestration via the Localization or Company specific localization in order to be able to present enumeration values as meaningfully and comprehensibly as possible.
There is no obligation to create a localisation for each enumeration value. However, Localization automatically displays entries for new enumeration values as soon as the enumeration is saved.
If there is no localisation for an enumeration value, the Name appears as the default value in many places (possibly in slightly ‘transformed’ notation, e.g. ‘Road’ instead of ROAD, unfortunately also ‘Mb’ instead of MB).
In order to avoid the possibly undesirable transformation of abbreviations in the Name field, a localisation (e.g. ‘MB’) should be stored for ‘English’ at least. This ‘spelling’ then applies as a fallback for all languages not localised elsewhere.
It is often also possible to control whether the internal name or the localisation (or both) identifies an enumeration value in the specific context of use – e.g. for the label in the dropdown of a Combobox element for a form.
The following screenshot shows the detail screen for editing an enumeration value selected in the list area with form elements for all properties that are supported for the Mode of transport:
|
|
Add and remove enumeration values
The New button (green in the screenshot above) adds a further definition to the list of enumeration values for the Mode of transport.
The Remove button (red in the screenshot above) removes the definition for a selected enumeration value from the list.
Extend enumerations:
If predefined Dynamic enumerations are not provided by the system as read-only, the value list contained can be extended if required.
Whether an additional Mode of transport (such as HYPERLOOP or UAV) needs to be added in the future should not be a concern today when defining the enumeration values for the Mode of transport. As soon as the additional type becomes relevant, it can simply be added.
Adjustments to configurations (e.g. in Input forms or Association criteria) may be required sporadically as a result of an extension.
However, interventions in the data model of entities that use the Mode of transport should not be necessary when a new option is added.
Remove values from enumerations:
It is also possible to remove values from an enumeration. There are also enumerations in which entries provided by the system are protected, while entries added as extensions are deleted.
►IMPORTANT◄ The removal of deletable enumeration values should ideally take place before Users (including configurators) are given the opportunity to ‘work’ with the configured values.
In many cases, the deletion of enumeration values is automatically blocked as long as there are still incoming references for the enumeration value to be deleted (e.g. via value resolvers such as Dynamic enumeration).
However, only current configurations are taken into account and not any existing ‘historical’ statuses (History (Configurations)), which could possibly be restored.
To 'remove from the catalog' enumeration values that are already in use or were used in the past, dynamic enum filters often offer viable solutions for the future.
Association criteria can be used to control in detail in which situations, for whom and, if applicable, with which time windows restrictions should apply to the selection and display of enumeration values.
Localise enumerations
The localisation of the enumeration types takes place in the Localization and, if necessary, via Company specific localization and affects the name of the enumeration as a whole, as well as the plain text for each individual element.
For the example of a custom dynamic enumeration for ‘cardinal points’, the localisation of the enumeration values could look like this:
The internal Enumeration name, for which the simple character string ORIENTATION was selected here, is used as the Resource bundle.
For predefined enumerations, a usually longer class name appears here, e.g. de.lobster.scm.base.bto.ModeOfTransport for the Mode of transport (see above).
The name of the enumeration as a whole can be localised via the Resource name $name.
Localisations for enumeration values define their Names as the value for the Resource name in the same Resource bundle.
►NOTE◄ The elements of an enumeration appear in selection elements of forms in ascending alphabetical order according to localisation. To ensure that the cardinal points appear in the usual order (clockwise starting with North), an index number has been placed in front of them. This also ensures that the options appear in the same order regardless of the language selection.
Enumerations with more complex configuration for enumeration values
Some of the dynamic enumerations provided by the system also offer specific parameters that can be assigned individual values for each element. For example, parameters for conversion functions are provided for Units (see columns ‘Alias’, ‘Base’ etc. in the screenshot below), each Working state can be linked to a hexadecimal colour value and individual check functions and message texts can be stored for each Delivery instruction type. Detailseiten für vordefinierte Dynamischen Aufzählungen are listed at the bottom of this page. If available, the parameters are also described there.
The following screenshot shows an example of the configuration interface for the Length unit enumeration, which contains specific fields for Units (Alias, Base, etc.):
