Original entity

See also: Value changed (Compare type)

Value resolver – Abstract

Purpose: Returns the server-side (persisted) data state of the entity in the input value, if it exists.

Tooltip

• Usage: The value resolver returns the server-side data state of an entity present as an input value, if it exists. This original entity can be used, for example, for comparisons with a deviating volatile entity state.

• Note:

  • If the input value is not entity data, the input value is returned.

  • If the entity in the input value does not exist because it has not been saved yet, then the return value is $null.

• Warning: Although the Original entity value resolver can be selected in a Client Workflow, it is effectively useless because it always returns only the volatile state of the entity in the input value and not the 'original' value that is only available on the server side.

The Original entity resolver returns the server-side (persisted) data state of the entity in the input value, if it exists.

• If the input value is data of an entity according to its type, but the entity is not yet created, then 'No value' ($null) is returned.

• If the input value is not an entity according to its type, then the input value is returned.

Access to the original entity enables matching between server-stored data of an entity and a volatile, 'edited' state.

►NOTE◄ In principle, the Original entity value resolver can also be used for 'non independent' entities such as attributes. However, in practice it is usually more useful to compare attributes starting from the attribute owner (and its original entity). This is demonstrated by the second example below (More complex use case:').

►WARNING◄ Although the Original entity value resolver can be selected in a Client Workflow, it is effectively useless because it always returns only the volatile state of the entity in the input value and not the 'original' value that is only available on the server side.

►IMPORTANT◄ Effect of lazy loading on entity and original object.

---

In general, the lazy loading principle applies in the server context (e.g. when processing Association criteria or Event handling) for data that has a (1:n) relationship to an entity and is therefore handled in the entity's data object via list fields.

What is lazy loading?

• Regardless of whether an entity is present as an input value or is included in the execution context through an Input object (type safe) resolver, the existing inventory for data stored in list fields will only be retrieved from the Lobster Data Platform / Orchestration database if needed.

  • Changes to the 'list data' of an entity that are caused outside the given execution context and persisted before the lazily executed retrieval may potentially be applied 'retroactively' to the execution context.

  • The data state in the execution context may therefore contain combinations of header and detail data that have never been or will never be persisted in the database in this form.

• In this context, a 'need' refers to any access to the respective list field for the entity or the associated Original entity, provided that the data has not already been retrieved.

  • The data retrieval basically concerns all entries of the list.

  • Retrieved list data always applies to both the entity and the Original entity immediately after retrieval.

• The following specific examples illustrate the principle:

  • A read access to the number of entries in the list of all attributes (attributes.length) of the entity leads to the retrieval of all attributes of the entity from the database, if they are not already present in the execution context.

  • Any direct or indirect access to line item list field entries – e.g. via Modify list event action, the List item value resolver, or the Direct line items value resolver – triggers retrieval of the entity's entire line item hierarchy.

    ►NOTE◄ When retrieving line items for an entity, its attributes (attributes) are automatically 'supplied' as an exception. Therefore, no lazy loading takes place at this level.

What does lazy loading mean for the Original entity value resolver?

• For 'list data' (e.g. attributes or line items) of an entity, the Original entity value resolver returns the data state that the database provided via lazy loading at the time of the first demand in the execution context.

• If the 'list' in question has not been loaded before in the execution context, a list access for the Original entity may also trigger joint lazy loading for the entity's list and the Original entity.

• As long as list data is not modified during execution, a read access to list data for the Original entity always returns the same data as a direct access to the entity's data in the execution context cache.

---

CAUTION Under certain circumstances, the Original entity for lazy loaded list data does not necessarily reflect the database state that existed when the execution was started or the entity was added to the execution context as an Input object (type safe), but possibly a different state stored outside the execution context at the time of lazy loading.

The following specific runtime scenario illustrates the relationship:

1. Event handling (see Event handling) 'fetches' an entity of the 'Order' type (see Orders) from an ID (id) given as a Long value via the Input object (type safe) value resolver into the execution context.

2. Immediately afterwards, a User callback event action requests a yes/no decision from the user to execute an optional process step (here: step 4).

3. While the user is still considering, another user changes an attribute of the order in question via an input form – e.g. by setting the value of a user-defined indicator attribute (see Flag type) 'Priority' – and saves the order.

4. In the process step requiring approval, some indicator attributes of the purchase order (including the 'Priority' indicator) must be evaluated in the context of a case differentiation per If then else event action.

   1. The first read access to any attribute retrieves all attributes of the order from the database.

   2. In this example, the 'Priority' flag is considered to be set, even if it would have been 'not set' (or not present) at the start of event handling.

   3. If other attributes were changed in the 'foreign' session, these are also 'attributed' to the entity on-the-fly in the execution context.

►NOTE◄

• If the evaluation logic checks whether the value of the 'Priority' indicator has been changed compared to the Original entity via an Entity property rule, this will not display any changes in the scenario described. The data status for the attributes retrieved after the User callback is mapped directly after the retrieval to the order and the associated Original entity, so that only subsequent changes to this status are detected for attributes.

• If, on the other hand, a read access to any attribute of the order or even number of attributes (attributes.length) would be executed at the beginning of the event handling, the retrieval of the attribute data from the database already takes place at this time. Then the "priority" flag for order and Original entity is considered 'not set' (or not present) and a change in a 'foreign' session (see step 3) is not considered in the execution context because the attributes of an entity are retrieved only once.

• Saving the order within the event handling (e.g. Save changes later) becomes impossible in any case due to the write conflict with the update persisted in step 3.

Configuration

The value resolver expects an entity as input value' and does not use any parameters.

Examples

Simple use case: Check a specific value change for a field

An association criterion (see Association criteria) determines whether the volatile data in the context of a shipment (see Shipments) contains a lower 'Number of packages' (numberOfPackages) for this entity than the number (last) stored on the server.

Configuration:

►NOTE◄ The evaluation of this association criteria only makes sense in a context in which a volatile state of the respective shipment can exist. It could be evaluated e.g. as a Sub criterion rule in the validating rule of an event handling which reacts to the 'Update' event (see Common action event) and contains actions which are only relevant if the 'Number of packages' of a shipment was reduced in the course of an update of the shipment data triggered via the interface or interactively.

More complex use case: Checking whether (singular) reference attributes differ

An association criterion (see Association criteria) is intended to determine in the context of a shipment (see Shipments) whether the reference values specified in reference attributes have changed from the server-side state.

Configuration:

The task requires pairwise checking of reference values in reference attributes with the same Reference type between the volatile data state and the associated original entity representing the server-side state.

For convenience purposes, the following configuration makes the following simplifying assumptions:

• All reference attributes used in the context of Shipments are defined as non-plural (='singular') in the Reference type. For each Reference type there is exactly one or no reference attribute in the shipment data.

• In the volatile state of the shipment, no reference attributes have been removed compared to the server-side state, so that every Reference type represented by a reference attribute on the server side is also present in the volatile state (with an empty reference value '' if applicable).

Under these conditions, the criterion in the sense of the task can be formulated as follows: 'The rule in the association criteria is passed if the volatile state of the shipment contains at least one reference attribute whose value differs from the value of the reference attribute corresponding to the Reference type in the state stored on the server side'.

The following configuration implements this logic: