Ist Gleich
Siehe auch: Vergleiche mit (Vergleichstyp)
Der Ist Gleich-Vergleichstyp prüft, ob die als Prüfwert (Wert-Konfiguration links) und Vergleichswert (Wert-Konfiguration rechts) ermittelten Werte nach den anwendbaren Kriterien als übereinstimmend gelten.
Die Option Objektinhalt vergleichen sollte nur aktiviert werden, um zwei komplexe Datenobjekte einem "tiefen Vergleich" (im Hinblick auf die Übereinstimmung aller Merkmale) zu unterziehen. Details beschreibt der Abschnitt "Konfiguration" (unten).
►WICHTIG◄ Werte unterschiedlicher Typen vergleichen?
Falls Prüfwert und Vergleichswert nicht demselben Datentyp angehören, greifen Regeln für die automatische Typumwandlung, die einen Vergleich der Werte ermöglichen sollen:
Eine automatische Typumwandlung versucht immer, den Vergleichswert (rechts) in den Typ des Prüfwerts (links) umzuwandeln und nicht umgekehrt.
Zur Veranschaulichung:Der Prüfwert "0815" (String) gilt als nicht gleich einem Vergleichswert 815 (Long), da der Vergleichswert per Typumwandlung als String "815" interpretiert wird.
Der Prüfwert 815 (Long) gilt dagegen als gleich einem Vergleichswert "0815" (String), da der Vergleichswert per Typumwandlung als Long 815 interpretiert wird.
Ob eine Typumwandlung gelingt, kann auch vom Ausführungskontext (Server/Client) abhängig sein. Vergleiche können in Zuordnungskriterien, Ereignisbehandlungen, usw. anders ausfallen als in einem Client Workflow.
Um Unwägbarkeiten und "Überraschungen" zu vorzubeugen, empfiehlt es sich den Typ von Prüfwert und Vergleichswert für den Vergleich soweit erforderlich ausdrücklich zu definieren, z. B. über einen verketteten Eingabeobjekt (Typsicher)-Wertauflöser.
Konfiguration
Die Wert-Konfigurationen für Prüfwert (links) und Vergleichswert (rechts) sind für den Endet mit -Vergleichstyp nicht optional.
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 Ist Gleich-Vergleich für komplexe Datenobjekte nur in den folgenden Fällen bestanden:
|
|
Wird die Option Objektinhalte vergleichen eingeschaltet, dann werden (ggf. auch rekursiv) alle Merkmale (wie Felder, Attribute, usw.) der als Prüfwert und Vergleichswert übergebenen Datenobjekte abgeglichen, um festzustellen, ob sinngemäß und formal das gleiche Objekt beschrieben wird. Die Prüfung berücksichtigt aber nicht, ob des sich technisch um dasselbe Objekt handelt. Diese inhaltliche Prüfung ist grundsätzlich zeitaufwändiger als der per Standard (s. oben) vorgenommene simple Abgleich bzgl. der Identität zweier Objekte. Das |
►WICHTIG◄ Die Option Objektinhalte vergleichen sollte nicht ausgewählt werden, wenn der inhaltliche Vergleich zwei "Listen" (als Prüfwert und Vergleichswert) betrifft.
Im Server-Kontext berücksichtigt der "inhaltliche" Vergleich sonst nur das length-Feld der Liste, was bedeutet, dass Unterschiede zwischen Listeneinträgen ignoriert werden, solange deren Anzahl übereinstimmt.
In einem Client Workflow werden zwei Listen unabhängig von der Option Objektinhalte vergleichen inhaltlich - also unter Berücksichtigung der einzelnen Listeneinträge und deren Reihenfolge - verglichen.
Beispiele
Übereinstimmung von zwei Zeichenfolgen prüfen
Um eine "kritische" Operation in einem Workflow zu bestätigen, soll vom Benutzer ein Code-Wort abgefragt werden.
Die eingegebene Zeichenfolge soll ohne Beachtung der Groß-/Kleinschreibung mit einem (hier ausnahmsweise statisch definierten) Vergleichswert übereinstimmen, damit die Operation ausgelöst wird.
Konfiguration:
Die rechts abgebildete Objekt-Feld-Regel kann in die Prüfende Regel einer Ereignisbehandlung oder in einer Wenn Dann Sonst-Ereignisaktion verwendet werden, um die kritische Operation bedingt auszuführen:
►ANMERKUNG◄ Die fehlerfreie Eingabe einer Zeichenfolge wie CHATGPTMEIFYOUCAN fällt Menschen wesentlich leichter, wenn die Sequenz durch den Wechsel zwischen Klein- und Großbuchstaben aufgelockert wird. |
|
Ganzzahl-Anteil einer berechneten "Zahl mit Einheit" mit einem konkreten Zielwert vergleichen
Ein Objekt-Feld-Regel soll genau dann zutreffen, wenn das rechnerisch ermittelte Gewicht einer flüssigen Ladung im Sollbereich für einen Transportbehälter (zwischen 8 und 9 Tonnen) liegt.
Das Flüssigkeitsvolumen wird mit wählbarer Volumeneinheit angegeben. Eine Variable volume_in_cbm liefert den Skalar für die Anzahl der entsprechenden Kubikmeter (cbm).
Über eine Variable weight_per_cbm wird das Gewicht eines Kubikmeters der betreffenden Flüssigkeit in einer wählbaren Masseneinheit (Gewicht- & Masseneinheiten) bereitgestellt.
Konfiguration:
►HINWEIS◄ Für einen Vergleich zwischen Zahlenwerten sollte bevorzugt der Vergleiche mit (Vergleichstyp)-Vergleichstyp verwendet werden und nicht der Ist Gleich. Trotzdem wird hier zunächst der erfolgreichen Einsatz des Ist Gleich-Vergleichstyps im Sinn der Aufgabenstellung demonstriert.
Der rot schattierten Bereich der Tabelle erläutert anhand einer Konfigurationsvariante mögliche Missverständnisse und Probleme beim Vergleichen von Zahlenwerten, die bei Verwendung des Vergleiche mit (Vergleichstyp)-Vergleichstyps allerdings keine Rolle spielen sollten.
Die rechts abgebildete Objekt-Feld-Regel verrechnet die Eingangsgrößen, prüft die Bedingung ("Ladungsgewicht im Sollbereich") und speichert das Ladungsgewicht in einer Variablen weight für die weitere Verwendung ab:
|
|
►WICHTIG◄ Der Ist Gleich-Vergleichstyp versucht den Datentyp des Vergleichswerts (rechts) in den Typ des Prüfwerts (links) umzuwandeln. In der Konfiguration rechts erscheint der für den Vergleich maßgebliche Datentyp Long in dem sechseckigen Symbol für den Vergleichstypen (Matcher). Bei der Umwandlung von Dezimalzahlen in Ganzzahlen wir dabei nicht gerundet. Die Dezimalen werden schlicht abgeschnitten. |
|
►ANMERKUNG◄ In der Konfiguration rechts sind "nur" die Wert-Konfigurationen für Prüfwert und Vergleichswert vertauscht. Man könnte vermuten, dass ein solcher "Seitenwechsel" einem Ist Gleich-Vergleich nichts anhaben kann. "Gleichheit" klingt intuitiv schließlich nach "Symmetrie" und "Austauschbarkeit". Das ist allerdings nicht in jedem Fall gegeben:
|
|
►WICHTIG◄ Auch wenn der berechnete Prüfwert (Anzahl Tonnen für das Ladungsgewicht im Feld "Wert" links) dem Vergleichswert mathematisch exakt entspricht, ergibt ein Ist Gleich-Vergleich der Werte als BigDecimal-Objekte eventuell keine Übereinstimmung, wie die Darstellung der im Vergleich tatsächlich gegenübergestellten Werte verdeutlicht: { "class": "java.math.BigDecimal", "value": "8.000"} /* berechneter Prüfwert */ Der berechnete Prüfwert enthält drei Nullen als angehängte Dezimalstellen, die für einen numerischen Vergleich nicht relevant sind aber dennoch die Übereinstimmung mit dem Vergleichswert stören, der denselben Zahlenwert ohne die angehängten "wertlosen" Dezimalen wiedergibt. ►ANMERKUNG◄ Ob im Zuge der Berechnung im Prüfwert Dezimalen angehängt werden, hängt von den konkreten Zahlenwerten und den ausgeführten Rechenoperationen ab. Im konkreten Fall wurde das Flüssigkeitsvolumen in der Einheit Liter (l) angegeben und dann in Kubikmeter (m3) umgerechnet (s. Volumeneinheit). Durch die Multiplikation mit 0.001 kommen hier die "wertlosen" Dezimalen ins Spiel. Fazit: Man könnte auf der linken Seite des Vergleichs unten an die Wertauflöserkette für den Prüfwert einen Eingabeobjekt (Typsicher)-Wertauflöser anhängen, der den "Wert" von BigDecimal in den Typ des Vergleichswerts (Long) umwandeln. Dann zeigt die Konfiguration das Laufzeitverhalten der Originalversion, obwohl Prüfwert und Vergleichswert vertauscht sind. Der Einsatz der floor()-Funktion für die Rundung des Berechnungsergebnisses (in einer zusätzlichen Instanz des Berechne Wert-Wertauflösers hätte denselben Effekt für die Objekt-Feld-Regel. Einen robusteren Vergleich von Zahlenwerten bietet in jedem Fall die Verwendung des Vergleiche mit (Vergleichstyp)-Vergleichstyps anstelle des Ist Gleich-Vergleichstyps. |
Listen vergleichen
Ein Zuordnungskriterium (s. Zuordnungskriterien) soll genau dann als bestanden gelten, wenn dem Firmenkonto (s. Firmen), das als "Besitzer" einer im Kontext als Eingabewert gegebenen Entität gilt, dieselben "Firmentypen" (types) zugeordnet sind, wie für die Firma der Session.
Konfiguration:
Das rechts abgebildete Zuordnungskriterium definiert innerhalb einer UND-Verknüpfung (s. Verknüpfung) eine zweistufige Prüfung:
►HINWEIS◄ Der Liste sortieren-Wertauflöser muss im Prüfwert und im Vergleichswert beiden Fällen ein gleichsinnig wirkendes Sortierkriterium verwenden. Nur dann ist sichergestellt, dass die verglichenen Firmentypen-Listen auch dann als übereinstimmend gewertet werden, wenn sie dieselben Einträge in unterschiedlicher Reihenfolge enthalten. Laufzeitbeispiel: (Regel gilt als bestanden)
|
|
Datenobjekte vergleichen
Eine Listenvariable tour beschreibt Wegpunkte entlang eines geplanten Transports durch eindeutige Kombinationen für die Merkmale "Land" (country), "Bereich" (area) und optional "Zone" (zone). Jeder Wegpunkt innerhalb der Liste als "Client-Objekt" mit den genannten Feldern abgebildet, ohne dass diesen Einträgen (bislang) persistierbare Entitäten gegenüberstehen würden.
Als Kennung für einen "Bereich" gelten per Standard die ersten drei Zeichen aus der Postleitzahl einer konkreten Zieladresse.
Besondere Ziele (z. B. Industrieparks oder logistische Knotenpunkte) können zusätzlich durch einen Textschlüssel "Zone" identifiziert werden, der für die Land/Bereich-Kombination eindeutig sein muss.
Für eine gegebene Adresse soll geprüft werden, ob der zuzuordnende Wegpunkt in einer bestehenden Tour enthalten ist. Für diesen Abgleich wird ein weiteres "Client-Objekt" erzeugt, dem anhand der Adressdaten Feldwerte für "Land", "Bereich" und ggf. "Zone" zugeordnet werden. Anschließend soll die Liste tour nach einem Wegpunkt mit derselben Merkmalskombination durchsucht werden.
Laufzeitbeispiel: konkrete Tour ...
Zielort |
Wegpunkt (Felder) |
Listenvariable tour |
||
Land |
Bereich |
Zone |
||
■ Prag, |
CZ |
360 |
n/a |
{ |
▼ Regensburg, |
DE |
930 |
n/a |
|
▼ Burghausen, |
DE |
844 |
CTR |
|
▼ Rennstein, |
AT |
950 |
n/a |
|
■ Logatec, |
SI |
137 |
n/a |
Konfiguration:
Die rechts abgebildete Wertauflöserkette untersucht die in per Variable tour bereitgestellte Liste von Client-Objekten, die Wegpunkte repräsentieren:
►WICHTIG◄ Für denIst Gleich-Vergleichstyp (unten) wurde hier die Option Objektinhalte vergleichen gesetzt, da die Frage nicht ist, ob das "Client-Objekt" in der Variable candidateWpt der tour-Liste bereits hinzugefügt wurde. Vielmehr geht es darum festzustellen, ob die tour-Liste einen Wegpunkt enthält, der inhaltlich in allen Feldern mit dem "Kandidaten" in der Variablen candidateWpt übereinstimmt (s. Laufzeitbeispiel unten). |
|
►ANMERKUNG◄ Wenn sich die Prüfung darauf beschränkt, ob die tour-Liste mindestens ein zum "Kandidaten" passendes Wegpunkt-"Client-Objekt" enthält, könnte prinzipiell auch der In Liste-Vergleichstyp in einer einfachen Objekt-Feld-Regel (ohne den Regel-Listen Resolver) eingesetzt werden. Allerdings funktioniert dieser Ansatz nur im Server-Kontext, weil "Client-Objekte" serverseitig grundsätzlich per Objektinhalt vergleichen werden. Deshalb könnten man auch auf die Option Objektinhalte vergleichen in der obigen Konfiguration verzichten, wenn gesichert ist, dass die Konfiguration ausschließlich im Server-Kontext verwendet und niemals in einen Client Workflow kopiert wird. In einem Client Workflow akzeptiert der In Liste-Vergleichstyp (wie derIst Gleich-Matcher mit abgeschalteter Option Objektinhalte vergleichen) nur wirklich identische Objekte als Treffer, was für das vorliegende Beispiel nicht zielführend wäre. |
Laufzeitbeispiel:
Zusätzliche Zieladresse |
"Kandidat" transformiert als Wegpunkt-"Client-Objekt" |
Prüfergebnis |
FROSTRANS KG |
{ |
Kandidat gilt als neuer Wegpunkt, obwohl sich der dritte Wegpunkt ("Burghausen") auf dasselbe Land (DE) und denselben Bereich (844) bezieht. Dem Kandidaten fehlt das Merkmal "Zone" (zone). |
FROSTRANS KG |
{ |
Der Hinweis auf das "Combi-Terminal-Rail" (s. Zieladresse) spiegelt sich systematisch im zone-Feld des Wegpunkts. Damit wird nun auch anerkannt, dass das Ziel durch den dritten Wegpunkt der Tour abgedeckt ist. |
Entitäten vergleichen
Für den Vergleich zweier Entitäten ist es für den Ist Gleich-Vergleichstyp nicht ausreichend, wenn sich Prüfwert und Vergleichswert auf denselben Entitätstyp und dieselbe ID (id) beziehen.
Ist die Option Objektinhalte vergleichen ausgeschaltet (Standard), dann muss es sich um dasselbe Datenobjekt für dieselbe Entität handeln, damit der Vergleich bestanden wird.
Wird die Option Objektinhalte vergleichen eingeschaltet (Standard), dann gilt der Vergleich als bestanden, solange Prüfwert und Vergleichswert inhaltlich (bzgl. aller Feldwerte) komplett übereinstimmen.
►WICHTIG◄ Ob eine Objekt-Feld-Regel mit dem Ist Gleich-Vergleichstyp beim Vergleichen zweier Entitäten erwartungsgemäß urteilt, hängt wesentlich davon ab, inwieweit diese Erwartung und das Verständnis für das Laufzeitverhalten beteiligter Wertauflöser im client- oder serverseitigen Kontext korrekt sind.
Die folgende Tabelle zeigt einige einfache aber potenziell "gemeine" Beispiele, die zwar inhaltlich kaum praxisrelevant sind, aber für die Stolperstellen einer Ist Gleich-Prüfung von Entitäten sensibilisieren sollen:
Prüfwert |
Vergleichswert |
Ergebnis für Ist Gleich |
Begründung |
|
... ausgeschaltet |
... eingeschaltet |
|||
|
|
|
|
Als Prüfwert und als Vergleichswert liefert je eine Instanz des Erzeuge Instanz-Wertauflösers eine jeweils "neue" Entität des Typs "Benutzer" (s. Benutzer). Obwohl sich diese direkt nach dem Erzeugen inhaltlich nicht unterscheiden, gelten sie für Ist Gleich als nicht übereinstimmend, solange die Option Objektinhalte vergleichen ausgeschaltet ist. Den mit eingeschalteter Option ausgeführten Vergleich der Objektinhalte bestehen sie dagegen. |
|
|
|
|
Als Prüfwert und als Vergleichswert liefert je ein Instanz des Rolle der Session-Wertauflösers einen individuellen "Klon" der in der Sitzung verwendeten Rolle (s. Rollen). Obwohl sich diese zwei Klone inhaltlich nicht unterscheiden, gelten sie für Ist Gleich als nicht übereinstimmend, solange die Option Objektinhalte vergleichen ausgeschaltet ist. Den mit eingeschalteter Option ausgeführten Vergleich des Objektinhalte bestehen sie dagegen. |
|
|
|
|
Als Prüfwert wird die vom System bereitgestellte Variable entity angegeben, die auf das im Kontext aktuelle Bezugsobjekt verweist. Durch den verketteten Wert als Variable speichern-Wertauflöser wird eine Referenz auf dieses Bezugsobjekt einer zweiten Variablen entity2 als Wert zugewiesen. Die Wert-Konfiguration für den Vergleichswert bezieht sich auf die Variable entity2. Da diese eine Referenz auf das Bezugsobjekt enthält und nicht etwa einen "Klon" des Bezugsobjekts wie im vorigen Beispiel, gelten Prüfwert und Vergleichswert unabhängig von der Option Objektinhalte vergleichen als übereinstimmend. |
|
|
im Server-Kontext: im Client Workflow: |
im Server-Kontext: im Client Workflow: |
Für Prüfwert und Vergleichswert wird zunächst auf die Rolle der Session zugegriffen. Da dieser Wertauflöser zwei "Klone" der eigentlichen Rolle liefert (s. oben), greifen wir per Verkettung auf das Feld "ID" (id) des jeweiligen Klons zu beziehen damit per Eingabeobjekt (Typsicher)-Wertauflöser die betreffende Rolle in den aktuellen Kontext ein, ohne dass sie geklont wird. Bei einer serverseitigen Ausführung (z. B. in Ereignisbehandlungen) gilt der Ist Gleich-Vergleich daher als bestanden. ►HINWEIS◄ Der Eingabeobjekt (Typsicher)-Wertauflöser liefert nur im Server-Kontext wirklich die Daten der per ID referenzierten Rolle. In einem Client Workflow liefert er stattdessen ein Datenobjekt, für das nur die Felder class und id gefüllt sind. Im konkreten Anwendungsfall gelten die verglichenen Datenobjekte also ausschließlich deshalb als identisch, weil deren ID übereinstimmt. |
|
|
im Server-Kontext: im Client Workflow: |
im Server-Kontext: im Client Workflow: |
Im Prüfwert liefert der Rolle der Session-Wertauflöser einen "Klon" der in der Sitzung verwendeten Rolle. Als Vergleichswert wird wie im vorigen Beispiel über die in der Rolle der Session vorgefundene ID dieselbe Rolle als "Eingabeobjekt" hinzugezogen. Die Ist Gleich-Prüfung scheitert in dieser Konstellation in allen Fällen aus unterschiedlichen Gründen:
|