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.