Company value
Value resolver – Abstract
Purpose: Returns the data of a statically selected company account.
See also: Role
The Company value resolver calls the company account data specified by static selection for the optional Company value parameter from the server.
Without a selection for the Company value parameter, 'no value' (null) is the return value.
A new instance of the Company value resolver is added without a selection and appears with an 'empty label', as shown above.
When an exisiting selection (or the 'empty label') is removed by clicking the 'X' symbol within the label, the combobox appears empty. Saving a configuration with a Company value resolver in this state will make the 'empty label' reappear.
►IMPORTANT◄ In place of the Company value resolver, the Input object (type safe) resolver could also be used for the 'Company account' type, to which the ID (id) of a company (e.g. as a static Long value) is supplied as an input value via concatenation. There is no difference in the runtime behaviour of the two methods, but there is an important difference when Lobster Data Platform / Orchestration configurations are exchanged between systems via the Meta exchange in the context of implementation. If the Company value resolver is used to access a specific company, relevant links between company accounts (e.g. between test and production systems) are taken into account during the Meta exchange, in order to automatically assign the 'corresponding' company regardless of the ID (id) valid in the respective environment. However, if a company account is addressed by a Long value with the Input object (type safe) resolver, then this service does not take effect. This is because it can have a fatal effect on the runtime behaviour of configurations transferred between two systems.
CAUTION
The Role resolver is not available in a Client workflow! The reference to a statically determined role can be established in a Client workflow by performing a Search as a substitute. With regard to the Meta exchange, however, it is not guaranteed that the search criteria used will 'find' the corresponding role (according to the Meta exchange links) across systems.
Configuration
|
The optional Company value parameter lists all Company accounts accounts for a static single selection in a Combobox element, for which read access exists in the session in which the resolver is configured. At runtime, the resolver returns the company account data selected in the configuration without considering access restrictions in the applicable login context. The input value is ignored. |
|
Examples
Example: Association criteria for the recognition of 'test objects'
An association criteria checks whether the owner of an entity belongs to a statically defined list of 'test companies'.
Configuration:
|
An association criteria named 'IS_TEST_ENTITY' is configured as shown on the right:
►NOTE◄ The procedure of first building a list of complete company accounts and then reducing them into a list of Long values may seem awkward. However, it is the only method that avoids 'surprises' for the configurator in a system landscape with different environments (or constant checks and adjustments of company IDs statically defined for each environment), if configurations are exchanged between environments via the Meta exchange. |
|
Example: Automatic adjustment of the owner when creating certain entity types
When implementing configurations in a Lobster Data Platform / Orchestration environment, it is recommended to use a Fast switch for thorough testing, e.g. to verify how the current configuration affects different logon contexts (especially company and role). Occasionally, with this method, a new configuration, e.g. an association criteria or an event handling, will be created inadvertently in the context of a 'wrong' company. Since the system automatically assigns the Company of session as the owner of a created entity, this can cause, for example, a technically correctly created association criteria to take effect only in parts of the company hierarchy, which can trigger far-reaching and diverse indirect 'malfunctions'.
In the present example, the risk of assigning a configuration to the wrong company 'in the heat of the moment' is minimized by an automatic function that works as follows:
Usually configurations like an Association criteria and Event handling are created and owned by the main company 'Xflow AG'.
When creating an entity for one of these types, the system checks whether the Company of session is a 'subcompany' directly or indirectly subordinate to the 'Xflow AG'.
If this is the case, then the 'Xflow AG' is automatically assigned as the 'owner' (ownerId).
Configuration:
|
An event handler that reacts to the Triggering events 'Create' (see Common action event) is configured as shown on the right:
|
|
|
The Action on passed rule is relatively simple:
|
|
►NOTE◄ Depending on the access rights and Company authorizations applicable in the logon context, the change of ownership for the entity may cause it to no longer be accessible (or write-accessible) after the saving process. At the latest then, the previously missed Fast switch to 'Xflow AG' should be made to continue the configuration in its context.