Regel-Listen Resolver
Wertauflöser - Kurzfassung
Zweck: Gibt entweder genau einen Eintrag oder alle Einträge aus dem Eingabewert zurück, die den konfigurierbaren Akzeptanzkriterien entsprechen.
Der Regel-Listen Resolver gibt abhängig von der Option Alle Werte als Liste entweder genau einen Eintrag oder alle Einträge aus dem Eingabewert zurück, die den optional konfigurierbaren Akzeptanzkriterien entsprechen:
Die optionale Auswahl für den Elementtyp wirkt einerseits zur Laufzeit als Akzeptanzkriterium im Sinn einer Typprüfung und beeinflusst andererseits beim Konfigurieren die Auswahlmöglichkeiten für Regeltypen und Wertauflöser in der Konfiguration für die Regel.
Ohne Auswahl für den Elementtyp findet keine Typprüfung für die Einträge aus dem Eingabewert statt.
Das optionale Hinzufügen einer Regel über das
-Symbol, definiert ein frei definierbares Akzeptanzkriterium für Einträge aus dem Eingabewert.Ohne Definition einer Regel gelten alle Einträge als akzeptabel, soweit diese dem ggf. definierten Elementtyp entsprechen.
►WICHTIG◄ Falls als Eingabewert keine Liste sondern ein einzelner Wert vorliegt, wird dieser behandelt als wäre er der einzige Eintrag einer Liste.
Die Option Alle Werte als Liste steuert den Rückgabewert:
Ist die Option abgewählt (Standard), dann liefert der Regel-Listen Resolver den ersten Eintrag aus dem Eingabewert, der alle konfigurierten Akzeptanzkriterien erfüllt.
Wird die Option ausgewählt, dann liefert der Regel-Listen Resolver alle Einträge aus dem Eingabewert, die alle konfigurierbaren Akzeptanzkriterien erfüllen.
Unabhängig von der Option Alle Werte als Liste liefert der Regel-Listen Resolver "kein Wert" ($null) als Rückgabewert, wenn kein Eintrag aus dem Eingabewert alle konfigurierten Akzeptanzkriterien erfüllt.
Falls mit der Option Alle Werte als Liste kein Treffer erzielt wird, ist der Rückgabewert also nicht eine "leere Liste" ([]). Daher kann in jedem Fall ein Standardwert-Wertauflöser verkettet werden, um für diesen Fall einen einzelnen Standardwert oder eine "Standardliste" zu definieren.
Konfiguration
|
Das Auswahlfeld für den Elementtyp ermöglicht eine statische Einfachauswahl eines konkreten Typs oder einer übergeordneten Klasse (im Sinne einer Typprüfung), die unterschiedliche konkrete Typen abgedeckt. Wie im Bild zu sehen wird eine Suchfunktion angeboten, die sowohl die internen Namen als auch die im Kontext anwendbare Lokalisierung betrifft. Falls ein Elementtyp ausgewählt ist, gelten nur Einträge aus dem Eingabewert als akzeptabel, die eine Typprüfung gegen die ausgewählte Klasse bestehen würden. Ohne Auswahl eines Elementtyp gelten alle Einträge aus dem Eingabewert als akzeptabel. |
|
|
Die Option Alle Werte als Liste kann ausgewählt werden, um als Rückgabewert eine Liste aller Einträge aus dem Eingabewert zu erhalten, die alle durch die anderen optionalen Parameter konfigurierten Akzeptanzkriterien erfüllen. Ein Klick auf das Im Beispiel rechts wurde eine Objekt-Feld-Regel ausgewählt, um für Einträge mit dem ausgewählten Elementtyp "Ort" (s. Orte) zu prüfen, ob deren Feld "Bezirk-Code" (countyCode) ausgefüllt (s. Ist leer und not (Vergleichstyp)) ist. ►HINWEIS◄ Sofern aufgrund des Kontexts in der Konfiguration der Eingabewert als Liste von Orten (Ort[]) definiert ist, muss der Elementtyp "Ort" nicht explizit ausgewählt werden, um die "passende" Feldauswahl im Dropdown des Objekt-Feld-Wertauflösers zu erhalten. Die zusätzliche "Deklaration" über den Parameter schadet dann allerdings auch nicht. Entscheidend ist die Angabe des Elementtyps, wenn dadurch nur eine Teilmenge von Einträgen aus einer heterogenen Liste (mit Objekten unterschiedlicher Klassen) als akzeptabel gelten soll. |
|
Beispiele
Demonstrationsbeispiel: Über den "Elementtyp" Einträge nach Typ/Klassenzugehörigkeit einschränken
|
Die rechts dargestellte Konfiguration dient ausschließlich zur Demonstration der Effekte unterschiedlicher Parametrierungen für den Regel-Listen Resolver mit dem immer gleichen Eingabewert. Dieser wird hier im Parameter Objekt Resolver einer Ausführen mit-Ereignisaktion über einen Erzeuge Liste-Wertauflöser als Liste mit statisch bestimmten Einträgen unterschiedlicher Datentypen definiert:
Diese Liste wird per Verkettung als Eingabewert an einen Regel-Listen Resolver übergeben. Die Tabelle stellt unterschiedliche Parametrierungen und das resultierende Ergebnis (als String-Abbild des Rückgabewerts) gegenüber. In der Konfiguration erzeugt eine Hinweis anzeigen (Popup)-Ereignisaktion dieses String-Abbild, indem der Rückgabewert des Wertauflösers als Text einer Meldung ausgegeben wird. Der Titel der Meldung gibt die Anzahl der Einträge in der zurückgegebenen Liste an. |
|
|
Die folgenden Tabelle listet unterschiedliche Parametrierungen für den Regel-Listen Resolver auf, die sich am recht abgebildeten Schema orientieren:
►ANMERKUNG◄ Wie die Darstellungen recht zeigen, beeinflusst die Option Alle Werte als Liste zusammen mit der Auswahl für den Elementtyp den Datentyp für den Rückgabewert. Im konkreten Fall ist als Datentyp für den Rückgabewert oben (mit ausgewählter Option Alle Werte als Liste) eine Liste von Zahlenwerten (Number[]) zu erwarten, während unten nur mit einem einzelnen Zahlenwert (Number) zu rechnen ist. |
"Alle Number-Werte als Liste": "Nur erster Number-Wert": |
Laufzeitbeispiele mit unterschiedlicher Parametrierung:
|
Parameter im Regel-Listen Resolver |
Ausgabe per Hinweis anzeigen (Popup) |
Kommentar |
||
|
Elementtyp |
Option: |
Titel (length) |
Meldung |
|
|
<keine Auswahl> |
|
3 |
[123, 3.57, 0815] |
Ohne Elementtyp gelten alle Einträge als akzeptabel. |
|
|
$null |
123 |
||
|
Long |
|
1 |
[123] |
Nur der erste Wert ist ausdrücklich als Long definiert. Dass der String "0815" in den Long-Wert 815 umgewandelt werden könnte, ist unerheblich. |
|
|
$null |
123 |
||
|
Double |
|
1 |
[3.57] |
Nur der zweite Wert ist ausdrücklich als Long definiert. Dass der Long-Wert "123" in den Double-Wert 123.0 umgewandelt werden könnte, ist unerheblich. |
|
|
$null |
3.57 |
||
|
String |
|
1 |
[0815] |
Nur der dritte Wert ist ausdrücklich als definiert .Eine Umwandlung der Zahlenwerte als "String-Abbild" findet nicht statt. |
|
|
$null |
0815 |
||
|
Number |
|
2 |
[123, 3.57] |
Die übergeordnete Klasse Number deckt Long und Double ab, den String dagegen nicht. |
|
|
$null |
123 |
||
Typischer Anwendungsfall: Einträge über eine Regel für ein Merkmal "auswählen"
Ein Zuordnungskriterium soll genau dann zutreffen, wenn die "angemeldete Firma" (Firma der Session) mehr als einer Gruppe angehört. Die Mitgliedschaft in einer Gruppe wird formal dadurch begründet, dass im Firmenkonto das Listenfeld "Übergeordnete Firmen" (parentCompanies) auf ein übergeordnetes Firmenkonto mit dem Firmen-Metatyp "Gruppe" (GROUP) verweist.
Laufzeitbeispiel:
Das Firmenkonto der "ZWORX Ltd." verweist in der Mehrfachauswahl für Übergeordnete Firmen auf zwei Gruppen ("XFLOW - Key Accounts" und "EMEA") als übergeordnete Firmen.
Zur Verdeutlichung der Zusammenhänge wurde hier das Label in der Service-Konfiguration für das Auswahlfeld/Combobox-Element so angepasst, dass anstelle der Adressdaten (s. übergeordnete Firma "Vortex Inc.") der Metatyp (hier: "Gruppe") der übergeordneten Firma angezeigt wird, wenn dieser nicht "Firma" (COMPANY) ist.
Konfiguration:
|
Der Screenshot rechts zeigt die Konfiguration für ein Zuordnungskriterium, das genau dann zutrifft, wenn die Firma der Session mehr als einem Firmenkonto mit dem Firmen-Metatyp "Gruppe" (GROUP) untergeordnet ist:
|
|
Typischer Anwendungsfall: Einen bestimmten "Zielwert" aus einer Liste auswählen
Auf Knopfdruck soll eine Ereignisbehandlung ermitteln und per Benachrichtigung anzeigen, wie derjenige Benutzer mobil erreicht werden kann, der eine bestimmte Entität (Eingabewert im Datenkontext) zuletzt geändert hat.
Dabei soll in den "Kommunikationsinformationen" des betreffenden Benutzers nach einem Eintrag mit dem Kommunikationstyp "Mobil" (MOBILE) und dem Kontext "24/7" (Textschlüssel) gesucht werden.
Laufzeitbeispiel:
Ein bestimmter Benutzer (mit der Kennung "Querificus") verfügt über folgende "Kommunikationsinformationen":
Angezeigt werden soll hier der erste Eintrag, da dieser gemäß Typ und Kontext relevant ist.
Konfiguration:
|
Der Screenshot rechts zeigt die Konfiguration für eine Ereignisbehandlung, die auf ein eigens eingerichtetes Eigenes Aktionsevent XF_CALL_LAST_MODIFIER als Auslösendes Ereignis reagiert. Die Prüfende Regel beschränkt sich auf eine Typprüfung, die sicherstellt, dass im Kontext des Ereignisses eine Entität vorliegt. Damit sollte gewährleistet sein, dass das Feld lastModifierId existiert und ggf. auf die ID eines Benutzers verweist. ►ANMERKUNG◄ Die Möglichkeit, dass Gastbenutzer eine Entität ändern können, soll hier nicht berücksichtigt werden. Als Aktion bei bestandener Regel wird hier eine Ausführen mit-Ereignisaktion verwendet, da ausgehend von der lastModifierId aus der Entität im Kontext als abweichendes Bezugsobjekt das betreffende Benutzerkonto gesetzt werden soll. Dies ermöglicht der mit der ID verkettete Eingabeobjekt (Typsicher)-Wertauflöser. Mit dem Benutzerkonto als Kontext wird eine Hinweis anzeigen (Popup)-Ereignisaktion ausgeführt, die im Titel innerhalb einer Textverkettung zunächst auf das Feld "Benutzername" (username) zugreift, das den Benutzer in der Benachrichtigung identifizieren soll. Die Meldung verwendet ebenfalls den Textverkettung-Wertauflöser, um die relevante Telefonnummer in Verbindung mit einer Beschriftung auszugeben. Diese wird über eine Verkettung von Wertauflösern beschafft, in der dem Regel-Listen Resolver die buchstäblich entscheidende Rolle zukommt:
►ANMERKUNG◄ Im Beispiel wurde auf eine "Fehlerbehandlung" für den Fall verzichtet, dass im Benutzerkonto kein Wert für die "24/7-Mobilnummer" angegeben ist. Über den Standardwert-Wertauflöser könnte ein Hinweistext wie "n/a" zugewiesen oder mit der im Beispiel demonstrierten Zugriffsmethode nach einer Kommunikationsinformation mit einer abweichenden Spezifikation (z. B. Typ "MOBILE" und Kontext "PRIVATE", s. Beispieldaten oben) als Ersatz gesucht werden. |
|
