Die Option Entitätsattribute ignorieren ist per Standard ausgewählt.

Beim Vergleichen von "Entitätsdaten" werden die sogenannten Entitätsattribute dann nicht ausgewertet.

Beispiel: Als Eingabewert liegen die volatilen Daten einer beliebigen Entität vor, die (ohne Konfiguration für den Vergleichswert) mit dem serverseitigen Datenstand abgeglichen werden sollen. In der rechts oben abgebildeten Standardkonfiguration für den Änderungsprotokoll-Wertauflöser ist die Option Entitätsattribute ignorieren ausgewählt.

Falls die volatilen Daten der Entität als einzige Änderung einen "Besitzerwechsel" - also einen gegenüber dem Original-Objekt veränderten Wert für das Entitätsattribut "Besitzer" (Feld ownerId) aufweisen, gibt der Wertauflöser trotzdem "Kein Wert" ($null) zurück, da der volatile Datenstand trotz der Änderung als unverändert gewertet wird.

Wird die Option Entitätsattribute ignorieren abgewählt, dann bezieht der Vergleich zwischen Eingabewert und Vergleichsobjekt für das Änderungsprotokoll auch alle Entitätsattribute mit ein.

Für das obige Beispiel bedeutet dies, dass auch ein "Besitzerwechsel" als Änderung gewertet wird, so dass im Rückgabewert des Änderungsprotokoll-Wertauflösers u. a. ein SimpleValueChangeLog-Objekt für das ownerId-Feld zu finden ist.

Die Option Änderungen auch für gelöschte und erstellte Werte erzeugen ist per Standard abgewählt.

Falls der Vergleich Werte als "erstellt" oder "gelöscht" klassifiziert, erscheint für diese im Rückgabewert des Änderungsprotokoll-Wertauflösers nur der minimale Funktionsumfang. Der jeweilige "Änderungstyp" (changeType), also DELETED oder CREATED wird im Kopf des betreffenden Änderungsprotokoll-Eintrags angegeben, ohne dass alle Details zum Objekt genannt werden.

Beispiel: Als Eingabewert liegen volatile Daten für ein Firmenkonto vor, in denen die serverseitig (noch) gespeicherte Adresse gelöscht wurde. Bei einem Vergleich mit abgewählter Option Änderungen auch für gelöschte und erstellte Werte erzeugen (s. Screenshot rechts oben) wird für das Feld address ein EntityCahngeLog (mit der eingebetteten Adresse als Entität) ausgegeben, das den "Änderungstyp" (changeType) DELETED ausweist und dabei die gelöschte Entität nur über die Felder fromClass und fromId identifiziert.

Wird die Option Änderungen auch für gelöschte und erstellte Werte erzeugen ausgewählt (s. Screenshot rechts unten), dann liefert im oben beschriebenen Szenario der Vergleich detaillierte Informationen für die gelöschte Adresse, die zu diesem Zweck mit "Kein Wert" ($null). Das EntityChangeLog für das address-Feld enthält zusätzlich zu den auch im Standardfall angeführten Daten (fromClass, fromId) im Listenfeld changeLogs eine ggf. sehr umfangreiche Auflistung von untergeordneten Änderungsprotokollen, so als wäre jedes Merkmal innerhalb der Adresse individuell gelöscht worden. Durch die Rekursion bezieht dies auch Attribute der Adresse, Adresskontakte, deren Attribute usw. mit ein.

Der optionale Parameter Vergleichswert kann verwendet werden, um dem Eingabewert ein Vergleichsobjekt gegenüberzustellen.

Wird auf eine Konfiguration für den Vergleichswert komplett verzichtet (Standard, s. Screenshot rechts), dann wird als Vergleichsobjekt das "Originalobjekt" zum Eingabewert verwendet.

• Für eine Entität als Eingabewert bedeutet dies, dass ein volatiler und ggf. veränderter Datenstand mit dem serverseitige Stand vom Anfang der Transaktion vergleichen wird.

• Für alle anderen Eingabewert-Typen wird der Eingabewert selbst als Vergleichsobjekt betrachtet, sodass kein Änderungsprotokoll zu erwarten ist. Der Rückgabewert lautet dann "Kein Wert" ($null).

In der Konfiguration rechts soll die Adresse der Firma der Session (im Eingabewert) mit der für den Benutzer der Session angegebenen Adresse verglichen als Vergleichsobjekt verglichen werden.

• Der Firmenadresse im Eingabewert wird hier durch eine Verkettung mit dem Firma der Session-Wertauflöser und einem Objekt-Feld-Wertauflöser bereitgestellt, der auf das address-Feld des Firmenkontos zugreift.
  
  

• Im Parameter Vergleichswert wird ausgehend vom Benutzer der Session-Wertauflöser über den Eingabeobjekt (Typsicher)-Wertauflöser sichergestellt, dass ein Benutzerkonto (und nicht etwa ein Gastbenutzerkonto) vorliegt. Anschließend erfolgt der Zugriff auf das address-Feld, wie beim Eingabewert.

►ANMERKUNG◄ Falls ein Gastbenutzer (s. Gastbenutzer) angemeldet ist, liefert der Benutzer der Session-Wertauflöser kein Benutzerkonto (s. Benutzer). Dann gibt der verkettete Eingabeobjekt (Typsicher)-Wertauflöser "Kein Wert" ($null) an den Objekt-Feld-Wertauflöser weiter. Da ein Gastbenutzerkonto nicht über ein address-Feld verfügt, würde dieser aber ohnehin ins Leere greifen. Falls eine Wertauflöserkette für den Vergleichswert konfiguriert ist, die zur Laufzeit "Kein Wert" ($null) als Rückgabewert liefert, wird $null als Vergleichsobjekt verwendet. Falls eine Entität als Eingabewert anliegt, ergibt dies ein EntityChangeLog das die Entität im Eingabewert als "erstellt" (CREATED) bewertet. Ohne Konfiguration für den Vergleichswert würde dagegen $null zurückgegeben, wie oben beschrieben.

"ABC"

"XYZ"

{
	"class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
	"fromIndex": -1,
	"fromValue": "DEF",
	"name": null,
	"toIndex": -1,
	"toValue": "ABC"
}

• Für einen Textwert (String) wird die Zeichenfolge insgesamt als Wert (fromValue, toValue) betrachtet.
  
  

• Ein Vergleich für die Länge (length), die im Objekt-Feld-Wertauflöse als "Feld" angeboten wird, findet nicht statt, da es sich dabei um eine berechnete Größe handelt.
  
  

• Für einen eigenständigen String spielen der Index (fromIndex, toIndex) und der Name (name) keine Rolle.

4711

3210

{
	"class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
	"fromIndex": -1,
	"fromValue": {
		"class": "java.lang.Integer",
		"value": 3210
	},
	"name": null,
	"toIndex": -1,
	"toValue": {
		"class": "java.lang.Integer",
		"value": 4711
	}
}

• Ein Zahlenwert wird unter Berücksichtigung des Datentyps (class) als Wert (fromValue, toValue) betrachtet.
  
  

• Im Beispiel oben wird die Ziffernfolge (in JSON) für die verglichenen Werte als Integer interpretiert..
  
  

• Für einen eigenständigen String spielen der Index (fromIndex, toIndex) und der Name (name) keine Rolle.

{ "class": "java.lang.Long", "value": "4711" }

z. B. aus einem Long-Wertauflöser

{ "class": "java.lang.Integer", "value": "4711" }

z. B. aus einem Ganzzahl-Wertauflöser

{
	"class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
	"fromIndex": -1,
	"fromValue": {
		"class": "java.lang.Integer",
		"value": 4711
	},
	"name": null,
	"toIndex": -1,
	"toValue": {
		"class": "java.lang.Long",
		"value": "4711"
	}
}

• Eingabewert und Vergleichswert unterscheiden sich hier nur im Datentyp (class).

• Das SimpleValueChangeLog registriert daher insgesamt eine Änderung des Werts, weist dabei aber nicht etwa das Feld class als geändert aus.

Aufzählungswert "Ost" (E) aus der benutzerdefinierten
Dynamischen Aufzählung DIRECTIONS:

s. a. Jede dynamische Aufzählung

Aufzählungswert "Nord" (N) aus der benutzerdefinierten
Dynamischen Aufzählung DIRECTIONS:

s. a. Jede dynamische Aufzählung

{
	"class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
	"fromIndex": -1,
	"fromValue": {
		"class": "de.lobster.scm.denum.DynamicEnumDto",
		"enumName": "DIRECTIONS",
		"name": "N"
	},
	"name": null,
	"toIndex": -1,
	"toValue": {
		"class": "de.lobster.scm.denum.DynamicEnumDto",
		"enumName": "DIRECTIONS",
		"name": "E"
	}
}

• Die Werte von statischen und dynamischen Aufzählungen werden als "Einfache Werte" verglichen.

• Für eigenständige Aufzählungswerte spielen der Index (fromIndex, toIndex) und der Name (name) keine Rolle.

["Tom","Dick","Harry","Sally"]

["Tom","Dick","Harry"]

{
	"class": "de.lobster.scm.persistence.history.CollectionChangeLog",
	"changeLogs": [
		{
			"class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
			"fromIndex": -1,
			"fromValue": null,
			"name": null,
			"toIndex": 3,
			"toValue": "Sally"
		}
	],
	"changeType": null,
	"fromIndex": -1,
	"fromLength": 3,
	"name": null,
	"toIndex": -1,
	"toLength": 4
}

• Einer Liste (List) von Textwerten wurde (am Ende) ein Eintrag hinzugefügt.
  
  ►ANMERKUNG◄ Tatsächlich wird die Liste im Eingabewert mit einer anderen Liste im Vergleichswert verglichen, die an den drei ersten Positionen dieselben statischen Einträge enthält. Eine echte "Veränderung" an der statisch definierten Liste (z. B. per Liste modifizieren) könnte nicht per Änderungsprotokoll untersucht werden, da kein Original-Objekt als Referenz zur Verüfgung steht.
  
  

• Das CollectionChangeLog registriert einerseits die Änderung der Länge der Liste (fromLength, toLength).
  
  

• Im Listenfeld changeLogs erscheint andererseits ein SimpleValueChangeLog, das für die hinzugefügte Listenposition (toIndex) den neuen Wert (toValue) angibt.

["Tom","Dick","Harry"]

["Tom","Dick","Harry","Sally"]

{
	"class": "de.lobster.scm.persistence.history.CollectionChangeLog",
	"changeLogs": [
		{
			"class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
			"fromIndex": 3,
			"fromValue": "Sally",
			"name": null,
			"toIndex": -1,
			"toValue": null
		}
	],
	"changeType": null,
	"fromIndex": -1,
	"fromLength": 4,
	"name": null,
	"toIndex": -1,
	"toLength": 3
}

• Aus einer Liste (List) von Textwerten wird der letzte Eintrag "entfernt" (s. Anmerkung oben).
  
  

• Das CollectionChangeLog registriert einerseits die Änderung der Länge der Liste (fromLength, toLength).

• Im Listenfeld changeLogs erscheint andererseits ein SimpleValueChangeLog, der das "Verschwinden" der gelöschten Listenposition (fromIndex, fromValue) als Wertänderung zu "Kein Wert" ($null) protokolliert.
  
  ►HINWEIS◄ Dass der Listenposition nicht wirklich der Wert $null zugewiesen wurde, erkennt man daran, dass der Index (toIndex) zu -1 wechselt. Mit der Liste ["Tom","Dick","Harry",null] als Eingabewert würde als toIndex hier unverändert 3 gelten.

{ "class": "set", "data": [ "Tom", "Harry" ] }

{ "class": "set", "data": [ "Tom", "Harry", "Dick"] }

{
	"class": "de.lobster.scm.persistence.history.CollectionChangeLog",
	"changeLogs": [
		{
			"class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
			"fromIndex": -1,
			"fromValue": null,
			"name": null,
			"toIndex": -1,
			"toValue": "Dick"
		}
	],
	"changeType": null,
	"fromIndex": -1,
	"fromLength": 2,
	"name": null,
	"toIndex": -1,
	"toLength": 3
}

• Einer "Eindeutigen Liste" (Set) wird ein Eintrag hinzugefügt (s. Anmerkung oben).
  
  

• Das CollectionChangeLog registriert einerseits die Änderung der Länge der Liste (fromLength, toLength).

• Im Listenfeld changeLogs erscheint andererseits ein SimpleValueChangeLog, der den zusätzlichen Eintrag benennt (toValue).

►HINWEIS◄ Die "Eindeutige Liste" verwaltet keine Indexnummern für die Einträge. Die Felder fromIndex und toIndex zeigen daher den Standardwert -1.

[1,2,3]

[3,2,1,0]

{
	"class": "de.lobster.scm.persistence.history.CollectionChangeLog",
	"changeLogs": [
		{
			"class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
			"fromIndex": 3,
			"fromValue": {
				"class": "java.lang.Integer",
				"value": 0
			},
			"name": null,
			"toIndex": -1,
			"toValue": null
		},
		{
			"class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
			"fromIndex": 2,
			"fromValue": {
				"class": "java.lang.Integer",
				"value": 1
			},
			"name": null,
			"toIndex": 0,
			"toValue": {
				"class": "java.lang.Integer",
				"value": 1
			}
		},
		{
			"class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
			"fromIndex": 0,
			"fromValue": {
				"class": "java.lang.Integer",
				"value": 3
			},
			"name": null,
			"toIndex": 2,
			"toValue": {
				"class": "java.lang.Integer",
				"value": 3
			}
		}
	],
	"changeType": null,
	"fromIndex": -1,
	"fromLength": 4,
	"name": null,
	"toIndex": -1,
	"toLength": 3
}

• Zwei Listen mit statischen Integer-Werten werden verglichen. Alle Werte im Eingabewert tauchen auch im Vergleichswert auf, allerdings in teilweise abweichender Reihenfolge. Der Vergleichswert enthält noch ein zusätzliches Element (0) an der letzten Position.
  
  

• Das CollectionChangeLog registriert einerseits die Änderung der Länge der Liste (fromLength, toLength).

• Das Feld changeLogs weist für folgende Listenpositionen Änderungen per SimpleValueChangeLog aus:
  
  

  • Die letzte Position (fromIndex 3) gilt als zu "Kein Wert" ($null) geändert, also gelöscht. Das ist auch an der Änderung des Index

  • Der Wert 1 gilt als "unverändert verschoben" an die erste Position im Eingabewert (toIndex 0).
    
    

  • Der Wert 3 gilt als "unverändert verschoben" an die letzte Position im Eingabewert (toIndex 2)

►ANMERKUNG◄ Der Wert 2 taucht im Feld changeLogs nicht auf, da er als komplett unverändert gilt.

Eine mit dem Erzeuge Liste angelegte Collection enthält volatile Daten von unterschiedlichen Entitäten, die gegenüber dem serverseitigen Stand geändert sein können:

• Als erstes Listenelement wird der Wert einer Variablen cneCompany definiert, die auf ein bestimmtes Firmenkonto (s. Firmen) verweist.
  
  

• Als zweites Listenelement wird der Wert einer Variablen cneKeyUser definiert, die auf ein bestimmtes Benutzerkonto (s. Benutzer) verweist.

Beide Konten wurden bereits erstellt und wurden im aktuellen Kontext unter Umständen verändert. Der Änderungsprotokoll-Wertauflöser sollen alle "volatilen" Änderungen an den als Entitäten aufgelisteten Konten feststellen.

Als Vergleichswert soll der Liste von Entitäten im Eingabewert eine Liste der zugehörigen "Originalobjekte" gegenübergestellt werden.

Dies kann mit dem Sammle Werte-Wertauflöser erreicht werden, der hier als Wert zum Sammeln auf den Original-Objekt-Wertauflöser zurückgreift, um den serverseitigen Stand für jedes Element der als Eingabewert vorliegenden Liste von Entitäten abzurufen.

{
	"class": "de.lobster.scm.persistence.history.CollectionChangeLog",
	"changeLogs": [
		{
			"class": "de.lobster.scm.persistence.history.EntityChangeLog",
			"changeLogs": [
				{
					"class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
					"fromIndex": -1,
					"fromValue": true,
					"name": "active",
					"toIndex": -1,
					"toValue": false
				}
			],
			"changeType": "MODIFIED",
			"fromClass": "de.lobster.scm.base.security.user.User",
			"fromId": "1901",
			"fromIndex": 1,
			"name": null,
			"toClass": "de.lobster.scm.base.security.user.User",
			"toId": "1901",
			"toIndex": 1
		}
	],
	"changeType": null,
	"fromIndex": -1,
	"fromLength": 2,
	"name": null,
	"toIndex": -1,
	"toLength": 2
}

• Das CollectionChangeLog (rechts) listet im changeLogs-Feld nur einen einzigen Eintrag auf, das das Benutzerkonto an der zweiten Listenposition betrifft.
  
  

• Das changeLogs-Feld im EntityChangelog für diesen Listeneintrag gibt an, dass der Wert für das Feld active von true auf false gewechselt hat. Das Benutzerkonto soll also offenbar deaktiviert werden.
  
  

• Am Firmenkonto wurden offenbar keine Änderungen vorgenommen.

{ "class": "de.lobster.scm.utils.date.DateTime",
"dateValue": "...", "timeZone": "Europe/Berlin" }

Ein als Relatives Datum mit Zeit ermitteltes "Datum mit Zeit"-Objekt:

• "Anfang des nächsten Tages" in der Zeitzone Europe/Berlin

{ "class": "de.lobster.scm.utils.date.DateTime",
 "dateValue": "...", "timeZone": "Europe/Rome" }

• "Anfang des nächsten Tages" in der Zeitzone Europe/Rome.

{
	"class": "de.lobster.scm.persistence.history.ObjectChangeLog",
	"changeLogs": [
		{
			"class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
			"fromIndex": -1,
			"fromValue": {
				"timeZoneId": "Europe/Rome"
			},
			"name": "timeZone",
			"toIndex": -1,
			"toValue": {
				"timeZoneId": "Europe/Berlin"
			}
		}
	],
	"changeType": "MODIFIED",
	"fromClass": "de.lobster.scm.utils.date.DateTime",
	"fromIndex": -1,
	"name": null,
	"toClass": "de.lobster.scm.utils.date.DateTime",
	"toIndex": -1
}

• Da der Datentyp "Datum mit Zeit" in Lobster Data Platform / Orchestration als Objekt mit den Feldern dateValue und timeZone definiert ist, ergibt der Vergleich zwischen zwei Datumswerten per Änderungsprotokoll-Wertauflöser ein ObjectChangeLog.
  
  

• Im Beispiel wird der "Anfang des nächsten Tages" für zwei unterschiedliche Zeitzonen verglichen. Da die verglichenen Zeitzonen denselben Versatz zu UTC aufweisen, unterscheiden sich die verglichenen Objekte nur im Feld timeZone, während das dateValue-Feld in beiden Fällen denselben Zahlenwert für die Millisekunden seit 01.01.19700 00:00:00.000 (UTC) ausweist.

{ "name": "Darth Vader", "nickname": "Dee-Vee" }

{ "name": "Anakin" }

{
	"class": "de.lobster.scm.persistence.history.ObjectChangeLog",
	"changeLogs": [
		{
			"class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
			"fromIndex": -1,
			"fromValue": "Anakin",
			"name": "name",
			"toIndex": -1,
			"toValue": "Darth Vader"
		},
		{
			"class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
			"fromIndex": -1,
			"fromValue": null,
			"name": "nickname",
			"toIndex": -1,
			"toValue": "Dee-Vee"
		}
	],
	"changeType": "MODIFIED",
	"fromClass": "flex.messaging.io.amf.ASObject",
	"fromIndex": -1,
	"name": null,
	"toClass": "flex.messaging.io.amf.ASObject",
	"toIndex": -1
}

• Zwei "Client-Objekte" werden miteinander verglichen.
  
  

• Das ObjectChangeLog wertet den Objektzustand im changeType-Feld als "verändert" (MODIFIED).
  
  

• Im changeLogs-Feld werden zwei Änderungen per SimpleChangeLog ausgewiesen:
  
  

  • Das name-Feld wird als geändert von "Anakin" (fromValue) zu "Darth Vader" (toValue) gewertet.
    
    

  • Das nickname Feld, das nur im Eingabewert vorkommt, wird als von "Kein Wert" ($null) geändert gewertet.

{ "name": "Luke", 
  "tools": { "class": "list", "data": [ 
               { "skill": "TheForce™" },
               { "item": "LightSaber™" }      ]

           }
}

{ "name": "Luke" }

{
	"class": "de.lobster.scm.persistence.history.ObjectChangeLog",
	"changeLogs": [
		{
			"class": "de.lobster.scm.persistence.history.CollectionChangeLog",
			"changeLogs": [
				{
					"class": "de.lobster.scm.persistence.history.ObjectChangeLog",
					"changeLogs": [
					],
					"changeType": "CREATED",
					"fromClass": null,
					"fromIndex": -1,
					"name": null,
					"toClass": "flex.messaging.io.amf.ASObject",
					"toIndex": 0
				},
				{
					"class": "de.lobster.scm.persistence.history.ObjectChangeLog",
					"changeLogs": [
					],
					"changeType": "CREATED",
					"fromClass": null,
					"fromIndex": -1,
					"name": null,
					"toClass": "flex.messaging.io.amf.ASObject",
					"toIndex": 1
				}
			],
			"changeType": null,
			"fromIndex": -1,
			"fromLength": 0,
			"name": "tools",
			"toIndex": -1,
			"toLength": 2
		}
	],
	"changeType": "MODIFIED",
	"fromClass": "flex.messaging.io.amf.ASObject",
	"fromIndex": -1,
	"name": null,
	"toClass": "flex.messaging.io.amf.ASObject",
	"toIndex": -1
}

• Zwei "Client-Objekte" werden miteinander verglichen.
  
  

• Das ObjectChangeLog wertet den Objektzustand im changeType-Feld als "verändert" (MODIFIED).

• Das changeLogs-Feld des (äußeren) ObjectChangeLog beinhaltet ein CollectionChangeLog, da im Eingabewert ein zusätzliches Listenfeld tools erkannt wurde.
  
  

• Das changeLogs-Feld des CollectionChangeLog beinhaltet zwei ObjectChangeLog-Instanzen, die außer der Listenposition (toIndex) und dem "Änderungstyp" (CREATED) keine weiteren Details zu den hinzugefügten "Tools" verzeichnen.
  
  ►HINWEIS◄ Offensichtlich wurde hier der Änderungsprotokoll-Wertauflöser verwendet, ohne die Option Änderungen auch für gelöschte und erstellte Werte erzeugen auszuwählen. Sonst würde der Rückgabewert auch Informationen über die Objekt-Felder (skill und item) als SimpleValueChangeLog im changeLogs-Feld des betreffenden ObjectChangeLog enthalten.

Eine Ereignisbehandlung wird durch das Ereignis "Ändern" (s. Allgemein (Ereignisse)) ausgelöst, so dass sie auf das Speichern bereits erstellter Entitäten reagiert. Eine Typprüfung stellt sicher, dass die Ereignisaktion nur im Kontext von Zuordnungskriterien aktiv wird.

Als Eingabewert liegen also immer die ggf. geänderten volatilen Daten des Zuordnungskriteriums vor, das gespeichert werden soll. Vor dem Speichern von Änderungen soll ein Änderungsprotokoll erstellt werden, damit - abhängig von der Art der Änderungen - ggf. ein Administrator benachrichtigt werden kann.

Beispiel:

<?xml version="1.0" encoding="UTF-8"?>
<core:AssociationCriteria ... priority="100" name="XF_MFST_AGV" description="PLEASE CHECK!" onlyForLogic="false">
   <core:RuleJunction junctionType="CONJUNCTION">
      <core:CheckTypeRule type="mfst:Manifest" isCollectionOf="false" checkNullValue="false"/>
      <core:EntityPropertyRule>
         <core:EqualsMatcher deepCompare="false">
            <core:LiteralValueResolver>
               <value enumName="mfst:ManifestType" name="AGV" xsi:type="core:DynamicEnumValue"/>
            </core:LiteralValueResolver>
         </core:EqualsMatcher>
         <core:PropertyResolver property="manifestType"/>
      </core:EntityPropertyRule>
   </core:RuleJunction>
</core:AssociationCriteria>

• Im Beispiel wurde dem Zuordnungskriterium nur ein Text für das Feld "Beschreibung" (description) hinzugefügt. Das EntityChangeLog dokumentiert im changeLogs-Listenfeld genau diese eine Änderung per SimpleChangeLog.

nicht konfiguriert, also das Original-Objekt zur betreffenden Entität

{
	"class": "de.lobster.scm.persistence.history.EntityChangeLog",
	"changeLogs": [
		{
			"class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
			"fromIndex": -1,
			"fromValue": "",
			"name": "description",
			"toIndex": -1,
			"toValue": "PLEASE CHECK!"
		}
	],
	"changeType": "MODIFIED",
	"fromClass": "de.lobster.scm.association.criteria.AssociationCriteria",
	"fromId": "9901",
	"fromIndex": -1,
	"name": null,
	"toClass": "de.lobster.scm.association.criteria.AssociationCriteria",
	"toId": "9901",
	"toIndex": -1
}

Ausgehend vom geänderten Stand des Zuordnungskriteriums im vorherigen Beispiel hat der benachrichtigte Administrator das Zuordnungskriterium überprüft und möchte es nun mit Änderungen wieder abspeichern.

Die Ereignisbehandlung reagiert wiederum und ermittelt die Änderungen am Zuordnungskriterium über den Änderungsprotokoll-Wertauflöser.

Beispiel:

<?xml version="1.0" encoding="UTF-8"?>
<core:AssociationCriteria ... priority="50" name="XF_MFST_AGV" description="CHECKED AND APPROVED W/CHANGES" onlyForLogic="false">
   <core:RuleJunction junctionType="CONJUNCTION">
      <core:CheckTypeRule type="mfst:Manifest" isCollectionOf="false" checkNullValue="false"/>
      <core:EntityPropertyRule>
         <core:EqualsMatcher deepCompare="false">
            <core:LiteralValueResolver>
               <value enumName="mfst:ManifestType" name="AGV" xsi:type="core:DynamicEnumValue"/>
            </core:LiteralValueResolver>
         </core:EqualsMatcher>
         <core:PropertyResolver property="manifestType"/>
      </core:EntityPropertyRule>
      <core:AssociationSubCriteriaRule id="2651"/>
   </core:RuleJunction>
</core:AssociationCriteria>

• Das changeLog-Feld im EntityChangeLog listet nun mehrere untergeordnete Änderungsprotokolle für das Zuordnungskriterium auf:
  
  

  • Das SimpleValueChangeLog an der ersten Position belegt, dass das Feld "Beschreibung" (description) erneut geändert wurde.
    
    

  • Das SimpleValueChangeLog an der zweiten Position belegt, dass die "Priorität" (priority) von 100 auf 50 verringert wurde.
    
    

  • Das nachfolgende ObjectChangeLog weist eine Änderung am "Regelwerk" im Feld rule des Zuordnungskriterium aus, der man entlang der Verschachtelung stufenweise "auf den Grund" gehen kann:
    
    

    • Das CollectionChangeLog betrifft das Listenfeld rules innerhalb der äußeren RuleJunction, also die Liste der untergeordneten Regeln innerhalb der UND-Verknüpfung (CONJUNCTION):
      
      

      • Dass dieser Collection ein zusätzliches Element hinzugefügt wurde belegt schon die Änderung seiner "Länge" (fromLength, toLength).
        
        

      • Für das erstellte Element erscheint ein untergeordnetes ObjectChangeLog für dessen changeType-Feld den Wert CREATED angibt. Auch die Position des erstellten Elements wird auf dieser Ebene angegeben (toIndex).
        
        ►ANMERKUNG◄ Offenbar wurde die Option Änderungen auch für gelöschte und erstellte Werte erzeugen für den Änderungsprotokoll-Wertauflöser ausgewählt, sodass das changeLogs-Listenfeld weitere Details des hinzugefügten Objekts enthält:
        
        

        • Das enthaltene SimpleValueChangeLog gibt den Wert (2651) wieder, der dem id-Feld der hinzugefügten Sub-Zuordnungskriterium-Regel (AssociationSubCriteriaRule) in der Konfiguration zugewiesen wurde.
          
          Der folgende Screenshot unten zeigt die Regel-Konfiguration im vom Administrator überarbeiteten Stand des Zuordnungskriteriums:

nicht konfiguriert, also das Original-Objekt zur betreffenden Entität

{
    "class": "de.lobster.scm.persistence.history.EntityChangeLog",
    "changeLogs": [
        {
            "class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
            "fromIndex": -1,
            "fromValue": "PLEASE CHECK!",
            "name": "description",
            "toIndex": -1,
            "toValue": "CHECKED AND APPROVED W/CHANGES"
        },
        {
            "class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
            "fromIndex": -1,
            "fromValue": {
                "class": "java.lang.Integer",
                "value": 100
            },
            "name": "priority",
            "toIndex": -1,
            "toValue": {
                "class": "java.lang.Integer",
                "value": 50
            }
        },
        {
            "class": "de.lobster.scm.persistence.history.ObjectChangeLog",
            "changeLogs": [
                {
                    "class": "de.lobster.scm.persistence.history.CollectionChangeLog",
                    "changeLogs": [
                        {
                            "class": "de.lobster.scm.persistence.history.ObjectChangeLog",
                            "changeLogs": [
                                {
                                    "class": "de.lobster.scm.persistence.history.SimpleValueChangeLog",
                                    "fromIndex": -1,
                                    "fromValue": null,
                                    "name": "id",
                                    "toIndex": -1,
                                    "toValue": {
                                        "class": "java.lang.Long",
                                        "value": "2651"
                                    }
                                }
                            ],
                            "changeType": "CREATED",
                            "fromClass": null,
                            "fromIndex": -1,
                            "name": null,
                            "toClass": "de.lobster.scm.association.criteria.rule.AssociationSubCriteriaRule",
                            "toIndex": 2
                        }
                    ],
                    "changeType": null,
                    "fromIndex": -1,
                    "fromLength": 2,
                    "name": "rules",
                    "toIndex": -1,
                    "toLength": 3
                }
            ],
            "changeType": "MODIFIED",
            "fromClass": "de.lobster.scm.association.criteria.rule.RuleJunction",
            "fromIndex": -1,
            "name": "rule",
            "toClass": "de.lobster.scm.association.criteria.rule.RuleJunction",
            "toIndex": -1
        }
    ],
    "changeType": "MODIFIED",
    "fromClass": "de.lobster.scm.association.criteria.AssociationCriteria",
    "fromId": "9901",
    "fromIndex": -1,
    "name": null,
    "toClass": "de.lobster.scm.association.criteria.AssociationCriteria",
    "toId": "9901",
    "toIndex": -1
}