Wert geändert
Der Wert geändert-Vergleichstyp zielt typischerweise darauf ab, im Kontext einer Objekt-Feld-Regel zu prüfen, ob sich der volatile Datenstand einer als Bezugsobjekt vorliegenden Entität hinsichtlich einer bestimmten Prüfwert-Konfiguration vom zugehörigen Original-Objekt unterscheidet.
Der Begriff Prüfwert-Konfiguration bezieht sich hier auf die Wert-Konfiguration in der Objekt-Feld-Regel, die den Wert geändert-Vergleichstyp verwendet. Im Screenshot (oben) ist als Prüfwert-Konfiguration ein Objekt-Feld-Wertauflöser konfiguriert, der auf ein (fiktives) Feld "Prüfwert" einer dem Typ nach unbestimmten Entität zugreift.
ACHTUNG
Im Client-Kontext (Client Workflow) ist der Wert geändert-Wertauflöser effektiv nutzlos, da dort als Original-Objekt immer der volatile Stand der Entität im Ausführungskontext gilt (s. Original-Objekt), so dass der Rückgabewert immer false lautet.
Im einfachsten Fall ermittelt die Prüfwert-Konfiguration einen "simplen Wert" (z. B. ein String aus einem Textfeld), dessen Stand im Kontext mit dem aus dem Original-Objekt ermittelten Wert (nachfolgend als Originalwert bezeichnet) übereinstimmt oder nicht.
Falls die die Prüfwert-Konfiguration sich auf einen "komplexen Wert" bezieht, also ein Datenobjekt mit mehreren Werten in Feldern, dann werden die Rückgabewerte für Bezugsobjekt und Original-Objekt unter Berücksichtigung der Auswahl für die Option Objektinhalte vergleichen nach der Logik eines Ist Gleich-Vergleichs gegenübergestellt.
Für die Auswertung von "komplexen Werten" (Datenobjekte mit Feldern) sind folgende Fälle zu unterscheiden:
Falls die Klasse des Prüfwerts eine spezifische Vergleichslogik bereitstellt, bestimmt diese die Kriterien, nach denen Prüfwert und Originalwert als übereinstimmend oder geändert gelten.
Im Kontext von Entitäten betrifft das insbesondere die Werte von Attributen unterschiedlicher Typen, die einer Entität auf Kopf- oder Positionsebene zugeordnet sein können.
Attributwerte von bestimmen Attributtypen werden auch ohne Auswahl der Option Objektinhalte vergleichen direkt "inhaltlich" verglichen. Dabei werden alle "Nutzdaten" des Attributwerts einbezogen, außer dem index-Feld, das nur Plurale Attribute betrifft.
Für Attributentitäten, also die Einträge im attributes-Listenfeld des betreffenden Attributbesitzers (mit je einem Attributwert im value-Feld), greift dagegen keine spezifische Vergleichsfunktion (s. nächster Punkt).
Sofern die Klasse des Prüfwerts keine spezifische Vergleichslogik bereitstellt (z. B. für eine komplette Position), muss die Option Objektinhalte vergleichen aktiviert werden, damit der Wert geändert-Vergleich aussagekräftige Ergebnisse liefert.
Ohne eine inhaltliche Prüfung würden zwei Datenobjekte, bei denen es sich bestenfalls um inhaltsgleiche Klone handelt, immer als unterschiedlich also "geändert" gewertet.
Der durch die Option Objektinhalte vergleichen angeforderte "tiefe Vergleich" betrifft ggf. rekursiv alle Ebenen eines verschachtelten Datenobjekts und kann abhängig von dessen Komplexität entsprechend rechenintensiv ausfallen. Mit Rücksicht auf das Laufzeitverhalten sollte von der Option Objektinhalte vergleichen deshalb "sparsam" Gebrauch gemacht werden.
Konfiguration
Der Wert geändert-Vergleichstyp erwartet zwingend eine Entität als Bezugsobjekt im Kontext der übergeordneten Objekt-Feld-Regel.
►WICHTIG◄ Liegt als Bezugsobjekt keine Entität vor, dann gilt die Objekt-Feld-Regel pauschal als "nicht bestanden" (false). Die Prüfwert-Konfiguration wird dann nicht ausgewertet.
|
Wenn für eine Objekt-Feld-Regel der Wert geändert-Vergleichstyp ausgewählt ist, wird nur eine Wert-Konfiguration angezeigt, die hier als Prüfwert-Konfiguration bezeichnet wird. Die Option Objektinhalte vergleichen in der Konfiguration für den Vergleichstyp ist per Standard ausgeschaltet (OFF). |
|
|
Im Beispiel rechts wurde über das Kontextmenü der Prüfwert-Konfiguration ein Objekt-Feld-Wertauflöser hinzugefügt, der auf das Feld "Besitzer" (ownerId) zugreift. Dieses Feld ist für jede Entität vorhanden. Es identifiziert ein Firmenkonto als "Besitzer" der Entität über dessen ID und beinhaltet daher einen Long-Wert. Die Option Objektinhalte vergleichen bleibt für den Vergleich daher ausgeschaltet (OFF). |
|
|
Die folgende Konfiguration für eine Objekt-Feld-Regel ist funktional komplett gleichwertig: |
|
|
|
|
|
Der Wert geändert-Vergleichstyp vereinfacht die Konfiguration, da einerseits der Original-Objekt-Wertauflöser (rechts oben) nicht explizit eingesetzt werden muss und andererseits die redundante Wert-Konfiguration im Vergleichswert (rechts unten) wegfällt. In diesem sehr einfachen Beispiel ist der Vorteil noch überschaubar, aber wenn in der Prüfwert-Konfiguration ein komplexerer Verketteter Wertauflöser "erforderlich ist, erspart der Wert geändert-Vergleichstyp nicht nur Aufwand sondern ermöglicht auch eine kompaktere Darstellung und vermeidet das Risiko unbeabsichtigter Abweichungen bei der Anlage und Anpassung redundanter Wertauflöserketten. |
|
Die Option Objektinhalte vergleichen sollte nur verwendet werden, wenn der Vergleich komplexer Datenobjekte dies erfordert:
|
|
Per Standard ist die Option Objektinhalte vergleichen ausgeschaltet (OFF). Dann wird der Wert geändert-Vergleich für komplexe Datenobjekte nur bestanden, falls deren Klasse (z. B. eine Attributwert-Klasse) eine spezifische Vergleichslogik definiert (s. o.). Anderenfalls erscheint ein komplexes Datenobjekt (z. B. eine bestimmte Position einer Entität) immer als "geändert", weil der Zugriff auf das Original-Objekt immer einen Klon als Originalwert liefert, der - selbst wenn alle enthaltenen Werte übereinstimmen - nicht identisch mit dem Prüfwert ist. |
|
|
Wird die Option Objektinhalte vergleichen eingeschaltet, dann werden (soweit erforderlich auch rekursiv) alle Merkmale (wie Felder, Attribute, usw.) der über die Prüfwert-Konfiguration aufgelösten Datenobjekte abgeglichen, um festzustellen, ob inhaltlich und formal das gleiche Objekt beschrieben wird. Die Prüfung berücksichtigt aber nicht, ob des sich technisch um dasselbe Objekt handelt. Dieser "tiefe Vergleich" ist grundsätzlich zeitaufwändiger als der per Standard (s. oben) vorgenommene simple Abgleich bzgl. der Identität zweier Objekte. Das |
Beispiele
Einfacher Anwendungsfall: E-Mail-Versand beim Deaktivieren eines Benutzers
Per Ereignisbehandlung für das "Ändern"-Ereignis (s. Allgemein (Ereignisse)) soll im Kontext eines Benutzerkontos (s. Benutzer) geprüft werden, ob dem betreffenden Benutzerkonto mit dem Abschluss der Transaktion der Status "Aktiv" entzogen wird. In diesem Fall soll eine Benachrichtigung per E-Mail versendet werden.
Konfiguration:
|
Als einziges Auslösendes Ereignis für die rechts abgebildete Ereignisbehandlung ist "Ändern" ausgewählt. Die Prüfende Regel besteht aus drei Bedingungen in einer gemeinsamen UND-Verknüpfung:
►ANMERKUNG◄ Welcher Wert für "Aktiv" im Original-Objekt vorlag wird hier nicht explizit geprüft. Als von false abweichende Originalwerte kommen für für ein Booelan-Feld technisch nur true und null in Frage. Da der Standardwert für das "Aktiv"-Feld im Benutzerkonto als false definiert ist, kann null als Originalwert nur vorliegen, wenn das Benutzerkonto noch nicht gespeichert wurde, so dass kein Original-Objekt existiert. Dieser Fall ist in unserer Ereignisbehandlung ausgeschlossen, da hier nur das "Ändern" Ereignis und nicht auch "Erstellen" als Auslösendes Ereignis vorgesehen ist. Als Aktion bei bestandener Regel ist hier ausschließlich der E-Mail-Versand zur Benachrichtigung des betreffenden Benutzers vorgesehen. |
|
Komplexerer Anwendungsfall: Änderungen an E-Mail-Kommunikationsinformationen registrieren
Beim Speichern eines bereits existierenden Benutzerkontos (→ Allgemein (Ereignisse): "Ändern") soll festgestellt werden, ob Änderungen an den Kommunikationsinformationen für den Kommunikationstyp "E-Mail" (EMAIL) vorgenommen wurden.
Laufzeitbeispiel:
Die Eigenschaften Typ, Kontext und Wert stellen die "Nutzlast" einer Kommunikationsinformation dar.
Jede "Zeile" im Screenshot repräsentiert eine Instanz für diesen pluralen Attributtyp des Adresse-Objekts (s. Adressen), der nicht-typisiert ist, obwohl er ein Typ-Feld beinhaltet.
Konfiguration:
Die folgende Regel-Konfiguration zielt darauf ab, Änderungen an Kommunikationsinformationen in der Adresse eines Benutzers festzustellen, die den Typ "E-Mail" (EMAIL) betreffen.
|
Die im Screenshot rechts abgebildete UND-Verknüpfung für die Prüfende Regel einer Ereignisbehandlung, die auf das Ereignis "Ändern" (Allgemein (Ereignisse)) reagiert, enthält zwei Regeln:
|
|
►WICHTIG◄ Die Option Objektinhalte vergleichen muss ausgewählt sein (AN), sonst gilt die Regel unabhängig von Änderungen an E-Mail-Kommunikationsinformationen immer als bestanden. Der Grund dafür ist, dass der Plurale Attribute (Wertauflöser)-Wertauflöser bei jedem Aufruf immer eine neue Liste mit Attributwerten erzeugt. Der Wert geändert-Vergleichstyp impliziert zwei Aufrufe der Prüfwert-Konfiguration. Also werden zwei Listen verglichen, die ohne die Option Objektinhalte vergleichen auch dann als nicht übereinstimmend gelten, wenn sie dieselben Attribute auflisten und diese keine Wertänderungen beinhalten. Nur der aufwändigere Vergleich der Objektinhalte - hier: der "inhaltliche Vergleich" der Listen - erkennt die Listen als "gleichwertig", solange keines der Attribute geändert wurde.
Allerdings ist die obige Prüflogik (mit der Option Objektinhalte vergleichen) auch noch nicht perfekt in ihrem Urteilsvermögen bzgl. der Änderungen. Die Schwachstelle ist dabei das orderIndex-Feld, das jeder "Kommunikationsinformation" (bzw. jeder Instanz des pluralen Attributs) eine Reihenfolgeposition zuordnet. Der Plurale Attribute (Wertauflöser)-Wertauflöser liefert die Attributinstanzen in der Reihenfolge aufsteigender orderIndex-Werte, was hilfreich für den Abgleich mit dem implizit herangezogenen Original-Objekt ist. Allerdings nur, solange sich am orderIndex der betreffenden Instanzen nicht geändert hat:
Wenn im obigen Laufzeitbeispiel einer der Einträge für "Mobil"-Nummern an einer Listenposition vor dem E-Mail-Eintrag (hier: am Ende der Liste) entfernt wird, sollte das eigentlich im Sinne der Aufgabenstellung nicht als Änderung in Bezug auf die "E-Mail"-Adresse gewertet werden.
Allerdings ändert sich der orderIndex-Wert des "E-Mail"-Eintrags (von 2 auf 1) da er zwar immer noch am Ende der Liste steht, nun aber nur noch einen Vorgänger hat.
Auch das Hinzufügen einer "Telefon"-Eintrags oberhalb des "E-Mail"-Eintrags würde irrtümlich als E-Mail-Änderung interpretiert, außer er würde dafür ein anderer entfern, sodass der "E-Mail"-Eintrag seine absolute Reihenfolgeposition beibehält.
Alternativkonfiguration:
|
Der Screenshot rechts zeigt, wie die Wertauflöserkette für den Prüfwert erweitert werden kann, sodass der Wert geändert-Vergleichstyp nur die relevanten Eigenschaften von Kommunikationsinformationen für "E-Mail"-Einträge berücksichtigt:
►ANMERKUNG◄ Die Methode einer selektiven "Transkription" kompletter Einträge mag radikal erscheinen. Für ein einfaches Objekt wie die Kommunikationsinformation ist sie aber "gangbar" und auch recht effizient. Im konkreten Fall könnte man, da es um String-Felder geht, auch mit einer Textverkettung im Sammle Werte-Wertauflöser zum Ziel kommen. Allerdings muss man dann ein Trennzeichen "reservieren" (ggf. auch eine Trennzeichenfolge), das per Konvention in beiden Felder nicht verwendet werden darf. Natürlich gibt es zahllose weitere Lösungswege, um Unterschiede zwischen der originalen und der potenziell geänderten Liste zu erkennen. Das vorliegende Beispiel soll daher auch für potenzielle "Schwierigkeiten" sensibilisieren, die auch für abweichende Lösungswege relevant sein können. |
|
