Liste modifizieren / Entfernen
Mit der Operation "Entfernen" der Ereignisaktion Liste modifizieren kann ein einzelnes Element aus einer bestehenden Liste entfernt werden.
ACHTUNG
Die Konfiguration der Liste modifizieren-Ereignisaktion für die Operation "Entfernen" wirkt eher trivial.
Allerdings erzielt sie nur dann zuverlässig das gewünschte Ergebnis, wenn sie so konfiguriert wird, dass die Identifikation des zu entfernenden Eintrags unter Berücksichtigung der ggf. spezifischen "Behandlung" für den jeweiligen Datentyp im vorgesehenen Ausführungskontext (Server/Client) wie gewünscht gelingt.
Eine "solide" Identifikation für den zu löschenden Eintrag zu definieren, ist eine Herausforderung darstellen, die Aufmerksamkeit und Sorgfalt erfordert. Ausführliche und aussagekräftige Tests sind zu empfehlen, auch bzw. gerade wenn eine Konfiguration einfach aussieht und auf Anhieb zu funktionieren scheint.
Die folgenden Hinweise erklären Abhängigkeiten abstrakt, von denen die Charakteristik beim "Entfernen" abhängen kann. Weiter unten folgen Beispiele, die diese Themen konkret illustrieren.
►WICHTIG◄ Wie wird der zu entfernende Eintrag identifiziert?
Die Liste modifizieren-Ereignisaktion vergleicht die Einträge einer durch die linke Wert-Konfiguration gegebenen Liste in der gegebenen Reihenfolge mit durch die rechte Wert-Konfiguration gegebenen Vergleichswert.
Falls dabei ein Listeneintrag als übereinstimmend mit dem Vergleichswert gewertet wird, wird dieser Listeneintrag entfernt und die Suche beendet. Es wird also nur der "erste Treffer" aus der Liste entfernt.
Ob ein Listeneintrag als "Treffer" gilt, hängt davon ab, ob er nach der im Ausführungskontext (Client/Server) für den betreffenden Datentyp anwendbaren Logik als übereinstimmend mit dem Vergleichswert gilt.
Im Unterschied zu anderen Vergleichsszenarien (z. B. Objekt-Feld-Regel oder Feld Einschränkung) erfolgt dabei keine automatische Typumwandlung. Dies gilt unabhängig vom Ausführungskontext (Server/Client).
Selbst das Entfernen eines simplen Werts ist nicht unbedingt trivial. Folgende Aspekte sind zu berücksichtigen:
Der Datentyp muss exakt übereinstimmen. Ein Long-Wert 2 gilt z. B. nicht als übereinstimmend mit einem Integer-Wert 2, obwohl eine Objekt-Feld-Regel mit dem Ist Gleich-Vergleich anders urteilt.
Im Client-Kontext werden Long-Werte im Unterschied zu anderen numerischen Datentypen als komplexe Datenobjekte behandelt, was z. B. dazu führt, dass selbst Rückgabewerte aus unterschiedlichen Instanzen des Wertauflösers für statische Long-Werte mit demselben Wert (z. B: 2) nicht als übereinstimmend gelten.
Wenn zum Identifizieren des zu entfernenden Eintrags eine weniger kritische "Diskriminierung" gewünscht ist, sollte dieser daher über einen Regel-Listen Resolver mit einem geeigneten Kriterium (z. B. Objekt-Feld-Regel) direkt aus der Liste identifiziert werden.
Komplexe Werte (Datenobjekte mit Feldern), die keine Entitäten sind, werden je Ausführungskontext unterschiedlich behandelt:
Im Server-Kontext werden komplexe Werte im Allgemeinen "inhaltlich" verglichen. Sie gelten genau dann als übereinstimmend, wenn alle Feldwerte übereinstimmen (s. "Objektinhalte vergleichen" mit dem Ist Gleich-Vergleichstyp).
Im Client-Kontext gelten komplexe Wert im Allgemeinen nur als übereinstimmend, wenn sie identisch sind und nicht über nur übereinstimmende Feldwerte verfügen (s. a. Anmerkung für Long-Werte im Client-Kontext, oben).
Enthält eine Liste inhaltlich übereinstimmende komplexe Werte kann man im Client-Kontext über den Listenwert-Wertauflöser jede einzelne Instanz eindeutig als zu entfernenden Eintrag identifizieren. Im Server-Kontext würde dagegen immer der erste Eintrag gelöscht, der inhaltlich mit dem adressierten Listenwert übereinstimmt.
Wenn zum Identifizieren des zu entfernenden Eintrags eine weniger kritische "Diskriminierung" gewünscht ist, sollte dieser daher über einen Regel-Listen Resolver mit einem geeigneten Kriterium (z. B. Objekt-Feld-Regel) direkt aus der Liste identifiziert werden.
Komplexe Werte, die zur Unterkategorie der Entitäten zählen, werden je Ausführungskontext unterschiedlich behandelt:
Im Server-Kontext werden die Daten von Entitäten, die als Eingabeobjekt in den Kontext einer Transaktion einbezogen wurde, über einen Cache verwaltet, der als Schlüsselwert die "ID" (id) der Entität verwendet.
Beim Zugriff auf eine bereits erstellte Entität wird daher im Allgemeinen zuerst im Cache nach einem (ggf. volatilen) Datenstand zu deren "ID" (id) nachgeschlagen. Existiert dieser, wird er für die anfragende Lese- oder Schreiboperation verwendet.
►WICHTIG◄ Ein im Cache vorgefundener volatiler Datenstand übersteuert auch im Rückgabewert einer Suche den eigentlich durch die Suche vom Server geholten Datenstand für die betreffende Entität.
Im Client-Kontext gibt es keinen Cache. Daher erzeugt der Abruf einer Entität über eine Suche immer ein eigenständiges Datenobjekt, das auch dann nicht identisch mit anderen Datenobjekten ist, wenn diese sich auf dieselbe Entität beziehen und keinerlei Unterscheide in Feldwerten aufweisen.
Wenn zum Identifizieren des zu entfernenden Eintrags eine weniger kritische "Diskriminierung" gewünscht ist, sollte dieser daher über einen Regel-Listen Resolver mit einem geeigneten Kriterium (z. B. "ID" (id) in einer Objekt-Feld-Regel) direkt aus der Liste identifiziert werden.
Konfiguration
►HINWEIS◄ Nach dem Hinzufügen einer Liste modifizieren-Ereignisaktion zu einem Workflow ist per Standard die Operation "Hinzufügen" ausgewählt. Ein Klick auf das Symbol für die Operation öffnet ein Kontextmenü, das die Auswahl einer anderen Operation ermöglicht.
Die Wert-Konfiguration für die zu modifizierende Liste (links) muss zur Laufzeit eine aktualisierbare Liste liefern.
Wird auf eine Wert-Konfiguration für die zu modifizierende Liste (links) verzichtet, wird automatisch auf das Bezugsobjekt im Kontext der Liste modifizieren-Ereignisaktion zurückgegriffen.
Die Wert-Konfiguration (rechts) definiert den zu entfernenden Eintrag.
Wird auf eine Wert-Konfiguration für den zu entfernenden Eintrag (rechts) verzichtet, gilt als Standardwert "Kein Wert" ($null).
Eine explizite Wert-Konfiguration für den zu entfernenden Eintrag (rechts) kann allerdings trotzdem auf das Bezugsobjekt im Kontext der Liste modifizieren-Ereignisaktion zugreifen.
Beispiele
Einfache Anwendungsfälle: Simple Werte entfernen
Die folgende Serie von Beispielen demonstriert unterschiedliche einfache Anwendungsfälle für das Entfernen von Einträgen aus einer gegebenen Liste von simplen Werten mit der Liste modifizieren-Ereignisaktion.
Die Spalte "Ergebnis" zeigt das JSON-Abbild des resultierenden Werts für die in der Variable list gespeicherte Liste nach der sequenziellen Ausführung aller Konfigurationen bis zur jeweilige Tabellenzeile.
|
Konfiguration |
Beschreibung |
Ergebnis |
|
|
Die Wert-Konfiguration für die zu modifizierende Liste (links) erzeugt aus statischem Text ["A","B",null,"B","A","C"] über den verketteten Objekt aus JSON erzeugen-Wertauflöser eine Liste und weist diese über den Wert als Variable speichern-Wertauflöser der Variablen list zu. ►HINWEIS◄ Der Typhinweis für den Rückgabewert lautet hier nur Objekt (und nicht etwa Objekt[]), was dem allgemeinen Fall für den Rückgabewert des Objekt aus JSON erzeugen-Wertauflöser entspricht. Als Wert-Konfiguration für den zu entfernenden Eintrag (rechts) dient ein Wertauflöser für statischen Text mit dem Textwert B . Wie der Spalte "Ergebnis" (rechts) zu entnehmen ist, wird zur Laufzeit der erste übereinstimmende Eintrag aus der Liste entfernt, während das zweite B erhalten bleibt. |
["A",null,"B","A","C"] |
|
|
Dieser Schritt soll demonstrieren, dass eine als Bezugsobjekt vorliegende Liste für die Wert-Konfigurationen auf beiden Seiten der Liste modifizieren -Ereignisaktion als Eingabewert genutzt werden kann. Im Kopf einer Ausführen mit-Ereignisaktion greift der Objekt-Wertauflöser auf die Variable list zu, also die Liste, die als Ergebnis der vorangegangenen Modifikation vorliegt. Im Variable-Wertauflöser wählen wird hier zur Verdeutlichung den Typ "Objekt" in Verbindung mit der Option Ist Liste von. Deshalb erscheint der Typhinweis Objekt[] für den Aktionsblock. Derselbe Typhinweis erscheint auch im Platzhalter für die Wert-Konfiguration für die zu modifizierende Liste (links) in der Liste modifizieren-Ereignisaktion im Aktionsblock. Dies signalisiert, dass die als Bezugsobjekt vorliegende Liste modifiziert wird, wenn auf eine Wert-Konfiguration komplett verzichtet wird. Als Wert-Konfiguration für den zu entfernenden Eintrag (rechts) ist ein Listenwert-Wertauflöser mit dem Modus "Wert (vom Ende)" und einem Offset von 0 konfiguriert, der zur Laufzeit den Textwert C liefert, da dies der letzte Wert der als Bezugsobjekt vorliegenden Liste ist. ►WICHTIG◄ Wie die Ergebnisspalte zeigt, wird tatsächlich das C am Ende der Liste entfernt. Allerdings klappt das nur, weil keiner der vorherigen Einträge mit diesem Textwert übereinstimmt. Wenn die Wert-Konfiguration für den zu entfernenden Eintrag einen simplen Wert zurückgibt, wird der erste "gleichwertige" Eintrag in der Liste (vom Anfang her) entfernt. |
["A",null,"B","A"] |
|
|
Nun soll der null-Wert aus der verbleibenden Liste entfernt werden. Als Wert-Konfiguration für die zu modifizierende Liste (links) in einer Liste modifizieren-Ereignisaktion wird auf die Variable list zugegriffen. Ohne eine Wert-Konfiguration für den zu entfernenden Eintrag wird die erste Übereinstimmung für "Kein Wert" ($null) entfernt. |
["A","B","A"] |
|
|
Abschließen sollen alle Instanzen für den Textwert A aus der verbleibenden Liste entfernt werden. Diese Aufgabe kann nur den wiederholten Einsatz der Liste modifizieren-Ereignisaktion erreicht werden. Für eine unbestimmte Anzahl von übereinstimmenden Einträgen kann das nur mit Hilfe einer Für jeden Eintrag wiederholen (Schleife) gewährleistet werden. Allerdings ist es nicht erforderlich, über alle Einträge einer ggf. sehr umfangreichen Liste zu iterieren, wie der Lösungsansatz im Screenshot links zeigt:
|
["B"] |
Komplexerer Anwendungsfall: Komplexen Wert (keine Entität) entfernen
Als einfaches Beispiel für einen komplexen Datentyp, bei dem es sich nicht um eine Entität handelt, dient in den folgenden Beispielen das "Datum mit Zeit" (DateTime)-Objekt, das über zwei Felder verfügt:
Das Feld "Datumswert" (dateValue) enthält einen Long-Wert, der den Zeitpunkt als Offset zum Zeitursprung (01.01.1970 00:00:00.000 UTC) in ganzzahligen Millisekunden datiert.
Das Feld "Zeitzone" (timeZone) verweist auf eine Java-Zeitzone, die mit dem Zeitpunkt als "Quell-Zeitzone" verknüpft werden soll.
Diese Struktur qualifiziert jede Datumsangabe per DateTime als komplexen Wert, auch wenn das Datenobjekt mit zwei Feldern eher überschaubar wirkt als komplex.
|
Der Screenshot rechts zeigt eine Konfiguration im Überblick, die als Basis für eine Reihe von Experimenten genutzt wird, um die Vergleichslogik der Liste modifizieren-Ereignis beim Entfernen von komplexen Werten in unterschiedlichen Kontexten zu demonstrieren und möglichen Missverständnissen vorzubeugen:
|
|
|
►HINWEIS◄ Wie im Screenshot für den Objekt-Wertauflöser (oben links) zu sehen, beziehen sich alle Instanzen des Relatives Datum mit Zeit-Wertauflösers in der Liste auf den Typ "Ende heute" in Kombination mit einer spezifischen Zeitzone. Während für den ersten und letzten Listeneintrag dieselbe Zeitzone (UTC) referenziert wird, weicht der mittlere Listeneintrag ab (Africa/Cairo). Die Hinweis anzeigen-Ereignisaktion würde die erzeugte Liste wie folgt abbilden, wenn die Liste modifizieren-Ereignisaktion nicht vorhanden (oder deaktiviert) wäre: [UTC,Africa/Cairo,UTC] |
|
Die folgende Tabelle stellt Konfigurationsvarianten für die Liste modifizieren-Ereignisaktion mit dem je Ausführungskontext erzielten Ergebnis gegenüber:
|
Konfiguration |
Ergebnis |
Beschreibung |
|
|
Server-Kontext: [Africa/Cairo,UTC] |
Im Server-Kontext gilt der Rückgabewert des Relatives Datum mit Zeit-Wertauflösers für den zu entfernenden Wert (rechts im Screenshot) als übereinstimmend mit dem ersten und letzten Listeneintrag, da die Parametrierung übereinstimmt und - unter der Bedingung, dass das Erstellen und Modifizieren der Liste an demselben UTC-Kalendertag erfolgt - einen "Datum mit Zeit" (DateTime)-Wert mit übereinstimmenden Feldwerten (dateValue, timeZone) erzeugt. Da nur der erste "Treffer" aus der Liste entfernt wird, verbleiben der zweite und dritte Eintrag im Ergebnis. |
|
Client-Kontext: [UTC,Africa/Cairo,UTC] |
Im Client-Kontext wird kein Listeneintrag entfernt, da der zu entfernende DateTime-Wert als Datenobjekt definitiv nicht identisch mit einem der Listeneinträge ist. Auch wenn das Datenobjekt in sämtlichen Feldwerten mit zwei Listeneinträgen übereinstimmt, wurde es mit dem Relatives Datum mit Zeit-Wertauflöser erst nach den Einträgen für die Liste erzeugt. |
|
|
|
Server-Kontext: [Africa/Cairo,UTC] |
In dieser Variante wird als zu entfernender Eintrag der erste Wert der Liste über den Listenwert-Wertauflöser mit Modus "Wert (vom Anfang)" und Offset 0 referenziert. Diese Konfiguration eignet sich, um unabhängig vom Ausführungskontext zuverlässig den ersten Wert der Liste zu entfernen. Der Grund für den Treffer ist dabei allerdings jeweils unterschiedlich:
|
|
Client-Kontext: [Africa/Cairo,UTC] |
||
|
|
Server-Kontext: [Africa/Cairo,UTC] |
In dieser Variante greift der Listenwert-Wertauflöser mit dem Modus "Wert (vom Ende)" und Offset 0 auf den letzten Listeneintrag zu, um den zu entfernenden Wert zu benennen. Da dessen Feldwerte mit dem ersten Listeneintrag komplett übereinstimmen, wird im Server-Kontext der erste Listeneintrag gelöscht, während der letzte erhalten bleibt. |
|
Client-Kontext: [UTC,Africa/Cairo]
|
Im Client-Kontext ist die Identität zwischen einem Listeneintrag und dem zu entfernenden Wert ausschlaggebend. Diese ist unabhängig von der Übereinstimmung der Feldwerte nur für den letzten Listeneintrag gegeben, sodass dieser zuverlässig entfernt wird. |
|
|
|
Server-Kontext: [Africa/Cairo,UTC] |
Die letzte Variante zeigt eine etwas aufwändigere Konfiguration für den zu entfernenden Wert, mit der erreicht werden kann, dass der erste Treffer für einen über den Relatives Datum mit Zeit-Wertauflöser bestimmten Wert unabhängig vom Ausführungskontext (Server/Client) zuverlässig entfernt wird: Der Regel-Listen Resolver wird hier verwendet, um in der als temporäres Bezugsobjekt vorliegende Liste per Objekt-Feld-Regel nach dem ersten Eintrag zu suchen, der mit dem Vergleichswert (rechts) aus dem Relatives Datum mit Zeit-Wertauflöser übereinstimmt. Mit den gegebenen Daten identifiziert der Regel-Listen Resolver damit zuverlässig den ersten Listeneintrag als zu entfernenden Wert. ►HINWEIS◄ Das Prinzip dieser Variante sollte immer dann verwendet werden, wenn die Liste modifizieren-Ereignisaktion zuverlässig den ersten Eintrag entfernen soll, der eine im Regel-Listen Resolver konfigurierbare Bedingung erfüllt. Dann funktioniert das Entfernen unabhängig vom Ausführungskontext (Server/Client) und es besteht kein Risiko für abweichende Ergebnisse beim Übertragen der Konfiguration aus einer Ereignisbehandlung in einen Client Workflow per Kopieren und Einfügen. ►ANMERKUNG◄ Sinngemäß bewirkt diese Methode, dass im Client-Kontext die eigentlich nur im Server-Kontext anwendbare Vergleichslogik zum Identifizieren des zu entfernenden Werts greift. Es existiert allerdings kein vergleichbar einfaches Konzept, dass die im Client-Kontext anwendbare Vergleichslogik (Identität der Datenobjekte) im Server-Kontext erzwingen könnte. |
|
Client-Kontext: [Africa/Cairo,UTC]
|
Besonderer Anwendungsfall: Entität entfernen
Als willkürliches Beispiel für eine Entität wird in den folgenden Beispielen das "Firmenkonto" (CompanyAccount) herangezogen, da diese in jeder Lobster Data Platform / Orchestration-Implementierung vorhanden sind.
|
Der Screenshot rechts zeigt eine Konfiguration im Überblick, die als Basis für eine Reihe von Experimenten genutzt wird, um die Vergleichslogik der Liste modifizieren-Ereignis beim Entfernen von komplexen Werten in unterschiedlichen Kontexten zu demonstrieren und möglichen Missverständnissen vorzubeugen: Um eine Liste von Entitäten (hier: Firmen/Mandanten) erzeugen zu können, muss zunächst Zugriff auf die Entitäten gewährleistet sein, die als Einträge verwendet werden sollen. Grundsätzlich könnte man Firmen/Mandanten ausgehend von Long-Werten für die "ID" (id) des Kontos als Eingabeobjekt (Typsicher) einbeziehen. Das klappt aber nur im Server-Kontext. Damit dieselbe Konfiguration auch im Client-Kontext funktioniert, kommen rechts drei Instanzen der Suche zum Einsatz, die je ein Firmenkonto auf eine bestimmte Variable (ca1, ca2, ca3) abbilden. In Anlehnung an die Beispiele für das Entfernen komplexer Werte (s. oben) soll als Basis für eine Serie von Tests eine Liste mit drei Einträgen erzeugt werden, von denen sicher der erste und letzte Eintrag auf dieselbe Entität bezieht. Die Suche-Ereignisaktionen für die Variablen ca1 und ca3 werden daher übereinstimmend parametriert, sodass diese Entität als einziger Treffer als Wert der Variablen gilt.
|
|
|
Für die Dokumentation der folgenden Beispiele nehmen wir an, dass der Name der per Variable ca1 und ca3 referenzierten Firma "A" lautet und die Variable ca2 eine Firma mit dem Namen "B" referenziert. Die Hinweis anzeigen-Ereignisaktion würde für die komplette Liste also folgende Zeichenfolge als Meldung ausgeben: [A,B,A] |
|
Die folgende Tabelle stellt Konfigurationsvarianten für die Liste modifizieren-Ereignisaktion mit dem je Ausführungskontext erzielten Ergebnis gegenüber:
|
Konfiguration |
Ergebnis |
Beschreibung |
|
|
Server-Kontext: [B,A] |
Hier wird, um den zu entfernenden Eintrag zu identifizieren, die Variable ca1 verwendet, die bereits beim Aufbau der Liste den Wert für den ersten Listeneintrag beigesteuert hat. Der Wert der Variable ca1 ist logischerweise mit dem ersten Listeneintrag identisch und stimmt nicht nur inhaltlich überein, sodass im Server-Kontext wie auch im Client-Kontext zuverlässig genau dieser Wert entfernt wird. Man hätte stattdessen auch den Listenwert-Wertauflöser mit dem Modus "Wert (vom Anfang)" und Offset 0 einsetzen können, der sich im gegebenen Szenario ebenfalls exakt auf das in der Variable ca1 referenzierte Suchergebnis bezieht. |
|
Client-Kontext: [B,A] |
||
|
|
Server-Kontext: [B,A] |
In dieser Variante greift der Listenwert-Wertauflöser mit dem Modus "Wert (vom Ende)" und Offset 0 auf den letzten Listeneintrag zu, um den zu entfernenden Wert zu benennen. Dass daraufhin im Server-Kontext trotzdem der erste Listeintrag gelöscht wird, mag auf den ersten Blick unerwartet erscheinen. Allerdings ist dies nur ein indirekter Effekt des Zugriffs auf den nur im Server-Kontext relevanten Cache für Entitäten: Der Wert für die Variable ca3 wird (wie oben beschrieben) ausgehend vom Ergebnis einer Suche gesetzt, die dasselbe Firmenkonto liefert, das bereits von der für die Variable ca1 ausgeführte Suche "gefunden" und dem Cache hinzugefügt wurde. Dieser Cache-Wert wird daher beim zweiten Zugriff der Variable ca3 zugewiesen. Da ca1 und ca3 dasselbe Datenobjekt für das Firmenkonto "A" referenzieren, sind der erste und der letzte Listenwert identisch. Deshalb wird der erste Eintrag gelöscht, obwohl sich die Konfiguration auf den letzten Listeneintrag bezieht. |
|
Client-Kontext: [A,B]
|
Im Client-Kontext ist ebenfalls die Identität zwischen einem Listeneintrag und dem zu entfernenden Wert ausschlaggebend. Da der Client-Kontext keinen Cache für Entitäten vorsieht, referenzieren die Suchergebnisse in den Variablen ca1 und ca3 hier technisch unterschiedliche Datenobjekte, auch wenn diese inhaltlich komplett übereinstimmen. Folglich wird in diesem Fall "wie bestellt" der letzte Listeneintrag entfernt. |
|
|
|
Server-Kontext: [B,A] |
Die letzte Variante zeigt eine etwas aufwändigere Konfiguration für den zu entfernenden Wert, mit der erreicht werden kann, dass der erste Listeneintrag, der sich auf das hier per Variable ca3 referenzierte Firmenkonto bezieht, unabhängig vom Ausführungskontext (Server/Client) zuverlässig entfernt wird: Der Regel-Listen Resolver wird hier verwendet, um in der als Bezugsobjekt vorliegenden Liste durch prüfen einer Objekt-Feld-Regel nach dem ersten Eintrag zu suchen, der im Feld "ID" (id) der mit dem Vergleichswert (rechts) - hier: die Variable ca3 - übereinstimmt. Mit den gegebenen Daten identifiziert der Regel-Listen Resolver damit unabhängig vom Ausführungskontext (Server/Client) zuverlässig den ersten Listeneintrag als zu entfernenden Wert. ►WICHTIG◄ Im Beispielszenario beinhaltet die Liste ausschließlich Entitäten desselben Typs "Firmenkonto" (CompanyAccount). Beim Zugriff auf die Variable ca3 wird derselbe Entitätstyp per Parameter Typ adressiert, sodass der Rückgabewert "Kein Wert" ($null) lautet, falls sich ca3 nicht auf ein "Firmenkonto" bezieht. Nur unter diesen Bedingungen kommt die Regel im Regel-Listen Resolver ohne eine zusätzliche Prüfung für die Übereinstimmung des Entitätstyps von Listenwert (links) und Vergleichswert (ca3) aus. Um ein Firmenkonto anhand seiner "ID" (id) zuverlässig aus einer Liste mit Einträgen potenziell unterschiedlicher Typen zu entfernen, müsste explizit abgesichert werden, dass für den Listeneintrag nicht nur dieselbe "ID" (id) sondern auch der "gesuchte" Entitätstyp übereinstimmt. Zu diesem Zweck müsste im Regel-Listen Resolver per UND-Verknüpfung eine zweite Bedingung ergänzt werden, die sicherstellt, dass für den Listeneintrag nicht nur die gesuchte "ID" vorliegt, sondern auch der gesuchte Entitätstyp (z. B. per Typprüfung). |
|
Client-Kontext: [B,A]
|
