Plural typed attribute resolver
Rule types – Abstract
Purpose: In the context of a reference object (entity type must be attribute owner), a 'Typed plural attribute' determined by the 'Subtype' is returned as a list that can be accessed in read and write mode.
The Plural typed attribute resolver value resolver provides access to a (plural) typed attribute of an entity. It expects an entity as a reference object, which is considered as an 'attribute owner' according to its type (see Attribut (Wertauflöser)) and whose data model provides at least one typed attribute type. The return value is a list of single values with the specific data structure for the respective attribute type, which can also be empty. For specific write and read accesses (see 'Examples'), the Resolvers specific to lists (e.g. List item, Rule list resolver) and Event actions (e.g. For each loop, Modify list) can be used. Write access to a field implies the creation of a scalar value, if necessary.
The Typed attribute parameter specifies the type of typed attribute to be returned. The selected type defines the data structure of the attribute. Each attribute type (flag attribute, text attribute, date attribute, etc.) uses a specific field (flagType, textType, dateType, etc.), for the Subtype. Specific Enumerations per type (Flag type, Text type, Date type, etc.) define the values that can be selected as a Subtype in each case (see Business objects and attributes).
►IMPORTANT◄ Writing and reading the attribute usually affects one or more field values within the specific data structure for the attribute type. The corresponding fields must – as demonstrated by the examples below – usually be addressed explicitly, so that a value assignment is successful and/or the return value corresponds to the desired result. This can be achieved either by concatenation (see Chained resolver) or, for example, in the context of an Execute with event action that defines the attribute as an alternative reference object.
Configuration
The Plural typed attribute resolver expects a reference object whose data model contains at least one typed attribute type.
|
The Typed attribute parameter provides a static single selection for the attribute type to be accessed. As long as the context of the configuration does not refer to a specific entity type as a reference object, all types of typed attributes that the system supports will appear for selection. The Combobox element offers a search function that takes into account the internal class names of the attributes as well as associated localizations from the language management. |
|
|
If, on the other hand, the context of the configuration refers to a specific entity type for the reference object, then only the attribute types that are explicitly implemented in the relevant data model appear for selection. On the right, a Check type (not in the image) points to a Routing table entry, so that only the four attribute types provided for this entity type appear in the dropdown. |
|
|
The dropdown for the Subtype offers the values of the respective dynamic enumeration (e.g. Text type) for selection only when an attribute type is selected in the Typed attribute parameter. ►IMPORTANT◄ If Enumeration filters are applicable in the context of a session for the enumeration in question, these also restrict the selection for the Subtype in the course of configuration. On the other hand, Enumeration filters have no influence on the evaluation of the value resolver at runtime. |
|
CAUTION
The selection for the Subtype also provides attribute subtypes that are not marked as 'plural' in the dynamic enumeration definition. If a 'singular' Subtype is selected, the Plural typed attribute resolver value resolver returns the attribute in question (if any) as the only element of a list at runtime.
If no Typed attribute is selected, then the return value of the value resolver is always 'no value' (null).
If a selected Typed attribute is not supported by the type of reference object present at runtime, the return value is also 'no value' (null).
If the reference object present at runtime supports a selected Typed attribute, but the reference object does not contain any relevant data, an empty list is returned.
Examples
Example of 'write access'
|
A Common business object represents a 'train' for the handling of rail traffic. Within the train, it should be possible to maintain the sequence of the wagons as a 'Formation'. For each wagon, the wagon type and a unique identifier (ID) should be specified. Available Wagon types (WAGON_TYPES) are already stored in a specially defined dynamic enumeration. On this basis, a Free enum type 'Train' (TRAIN) has been created, for which the option 'plural' has been set, so that a 'Train' can be treated as a list of 'Wagons'. Each wagon is represented by an instance of the free enumeration attribute 'Train'. The data structure of this attribute type, in addition to the 'Enum value' (enumValue) for the Wagon type, also provides a text field 'Text value' (textValue), which can be used to enter the unique identifier for each wagon. In the example on the right, the elements for the two fields within a data input form have already been labeled as Wagon type and ID and declared as required fields (*). |
|
Requirement:
Whenever the 'New' button is used within a data input form or overview to create a new Common business object of this type, the entry for the first wagon with the type 'Box car' is generated automatically without assigning an ID.
Configuration:
|
An event handler that reacts to the 'New' event (see Common action event) as a Triggering event is configured as shown on the right:
|
|
Example of 'read access'
Following the previous example, when a Common business object of the relevant type is saved, it is checked whether the assembled train contains at least one 'Box car'. If this is not the case, the transaction is aborted with an error message.
Configuration:
|
An event handler that reacts to the 'Change' and 'Create' events (see Common action event) is configured as follows:
|
|
