Im Allgemeinen greift im Server-Kontext (z. B. beim Verarbeiten von Zuordnungskriterien oder Ereignisbehandlungen) für Daten, die in einer (1:n)-Beziehung zu einer Entität stehen und deshalb im Datenobjekt der Entität über Listenfelder gehandhabt werden, das Lazy Loading-Prinzip.

Was bedeutet Lazy Loading?

• Unabhängig davon, ob eine Entität als Eingabewert vorliegt oder durch einen Eingabeobjekt (Typsicher)-Wertauflöser in den Ausführungskontext einbezogen wurde, wird der ggf. bereits persistierte Bestand für in Listenfeldern gespeicherte Daten nur bei Bedarf aus der Datenbank von Lobster Data Platform / Orchestration abgerufen.

  • Änderungen an "Listendaten" einer Entität, die außerhalb des gegebenen Ausführungskontexts verursacht und zeitlich vor dem lazy ausgeführten Abruf persistiert werden, gelangen also ggf. "nachträglich" in den Ausführungskontext.

  • Der Datenstand im Ausführungskontext kann also Kombinationen von Kopf- und Detaildaten enthalten, die in dieser Form nie in der Datenbank persistiert wurden (oder werden).

• Als "Bedarf" gilt dabei ein beliebiger Zugriff auf das jeweilige Listenfeld für die Entität oder das zugehörige Original-Objekt, sofern die Daten nicht bereits abgerufen wurden.

  • Der Datenabruf betrifft grundsätzlich sämtliche Einträge der Liste.

  • Abgerufene Listendaten gelten direkt nach dem Abruf immer sowohl für die Entität und das Original-Objekt.

• Die folgenden konkreten Beispiele verdeutlichen das Prinzip:

  • Ein Lesezugriff auf die Anzahl der Einträge in der Liste aller Attribute (attributes.length) der Entität führt zum Abruf aller Attribute der Entität von der Datenbank, sofern diese noch nicht im Ausführungskontext vorliegen.

  • Jeder direkte oder indirekte Zugriff auf Einträge des Listenfelds für Positionen (lineItems) - z. B. per Liste modifizieren-Ereignisaktion, den Listenwert-Wertauflöser oder den Direkte Positionen-Wertauflöser - löst den Abruf der gesamten Positionshierarchie der Entität aus.
    ►HINWEIS◄ Beim Abrufen von Positionen zu einer Entität werden ausnahmsweise deren Attribute (attributes) automatisch "mitgeliefert". Auf dieser Ebene findet also kein Lazy Loading statt.

Was bedeutet Lazy Loading für den Original-Objekt-Wertauflöser?

• Der Original-Objekt-Wertauflöser liefert für "Listendaten" (z. B. Attribute oder Positionen) einer Entität denjenigen Datenstand, den die Datenbank zum Zeitpunkt des ersten Bedarfs im Ausführungskontext per Lazy Loading bereitgestellt hat.

• Falls die betreffende "Liste" im Ausführungskontext zuvor noch nicht geladen wurde, löst ein Listenzugriff für das Original-Objekt ggf. auch das gemeinsame Lazy Loading für die Liste der Entität und das Original-Objekt aus.

• Solange Listendaten während der Ausführung nicht verändert werden, liefert ein Lesezugriff auf Listendaten für das Original-Objekt immer dieselben Daten wie der direkte Zugriff auf die Daten der Entität im Cache des Ausführungskontexts.

ACHTUNG Unter Umständen gibt das Original-Objekt für lazy nachgeladene Listendaten nicht unbedingt den Datenbankstand wieder, der vorlag als die Ausführung gestartet bzw. die Entität dem Ausführungskontext als Eingabeobjekt (Typsicher) hinzugefügt wurde, sondern ggf. einen außerhalb des Ausführungskontexts gespeicherten abweichenden Stand zum Zeitpunkt des Abrufs per Lazy Loading.

Das folgende konkrete Laufzeit-Szenario verdeutlicht den Zusammenhang:

1. Eine Ereignisbehandlung (s. Ereignisbehandlungen) "holt" eine eine Entität vom Typ "Bestellung" (s. Bestellungen) ausgehend von einer als Long-Wert gegebenen ID (id) über den Eingabeobjekt (Typsicher)-Wertauflöser in den Ausführungskontext.
   

2. Unmittelbar anschließend soll eine Benutzer-Rückfrage-Ereignisaktion vom Benutzer eine Ja/Nein-Entscheidung zur Ausführung eines optionalen Prozessschritts (hier: Schritt 4) abfragen.

3. Während der Benutzer noch überlegt, ändert ein anderer Benutzer über eine Erfassungsmaske ein Attribut der fraglichen Bestellung - z. B. indem er den Wert eines benutzerdefiniertes Kennzeichenattributs (s. Kennzeichentyp) "Priority" setzt - und speichert die Bestellung ab.
   

4. In dem zustimmungspflichtigen Prozessschritt müssen im Kontext einer Fallunterscheidung per Wenn Dann Sonst-Ereignisaktion einige Kennzeichenattribute der Bestellung (darunter auch das "Priority"-Kennzeichen) ausgewertet werden.

   1. Beim ersten Lesezugriff auf ein beliebiges Attribut werden sämtliche Attribute der Bestellung von der Datenbank abgerufen.

   2. Für diese Auswertung gilt im konkreten Beispiel das "Priority"-Kennnzeichen also als gesetzt, auch wenn es beim Start der Ereignisbehandlung noch als "nicht gesetzt" (bzw. nicht vorhanden) gegolten hätte.

   3. Sofern in der "fremden" Sitzung noch andere Attribute geändert wurden, werden diese der Entität im Ausführungskontext ebenfalls on-the-fly "zugeschrieben".

►HINWEISE◄

• Falls die Auswertungslogik per Objekt-Feld-Regel prüfen soll, ob der Wert des "Priority"-Kennzeichens gegenüber dem Original-Objekt verändert wurde, wird diese im beschrieben Szenario keine Änderung anzeigen. Der nach der Benutzer-Rückfrage abgerufene Datenstand für die Attribute wird direkt nach dem Abruf auf die Bestellung und das zugehörige Original-Objekt abgebildet, so dass für Attribute nur nachträgliche Änderungen gegenüber diesem Stand erkannt werden.

• Falls dagegen zu Beginn der Ereignisbehandlung ein Lesezugriff auf ein beliebiges Attribut der Bestellung oder auch nur Anzahl der Attribute (attributes.length) ausgeführt wird, erfolgt der Abruf der Attributdaten von der Datenbank bereits zu diesem Zeitpunkt. Dann gilt das "Priority"-Kennzeichen für Bestellung und Original-Objekt als "nicht gesetzt" (bzw. nicht vorhanden) und eine Veränderung in einer "fremden" Sitzung (s. Schritt 3) wird im Ausführungskontext nicht berücksichtigt, weil die Attribute einer Entität nur einmalig abgerufen werden.

• Ein Speichern der Bestellung innerhalb der Ereignisbehandlung (z. B. per Änderungen später speichern) wird in jedem Fall durch den Schreibkonflikt mit der in Schritt 3 persistierten Aktualisierung unmöglich.