Die rechts abgebildete Ereignisbehandlung reagiert auf das Ereignis "Ändern" (s. Allgemein (Ereignisse)) als Auslösendes Ereignis.

Die Prüfende Regel stellt per Typprüfung sicher, dass die folgenden Ereignisaktionen nur im Kontext einer "Rolle" (Role) ausgeführt werden.

Als einzige Aktion bei bestandener Regel wird eine Setze Wert-Ereignisaktion ausgeführt:

• Die linke Seite definiert das Feld "Rollenbeschreibung" (roleDescription) als Ziel der Zuweisung.
  
  

• Die rechte Seite greift über den Objekt-Feld-Wertauflöser lesend auf dieses Feld zu. Der verkettete Standardwert-Wertauflöser soll genau dann aktiv werden, falls das Feld einen leeren String enthält. Dann soll der Standardwert "Kein Wert" ($null) zugewiesen werden, damit das Feld gelöscht wird und auch aus dem XML "verschwindet".
  
  

  • Die Option Auch bei leeren String wurde ausgewählt, um die gewünschte Ersetzung zu gewährleisten, falls der Benutzer die "Rollenbeschreibung" in der Erfassungsmaske geleert hat.
    
    

  • Existiert das Feld "Rollenbeschreibung" noch nicht, weil es noch nie gefüllt war, wird der Eingabewert ($null) durch den Standardwert ($null) ersetzt. Die Zuweisung ist dann "wertneutral".
    
    

  • Jeder andere von $null verschiedene Wert für die "Rollenbeschreibung" wird diesem Feld unverändert zugewiesen. Damit ist die Zuweisung ebenfalls "wertneutral".

Zu Vorbereitung werden durch zwei Setze Wert-Ereignisaktionen die Adressen aus den beiden Firmen- und Attributen in Variablen übertragen, die Kandidaten für die Initialisierung sind. Das ist technisch nicht erforderlich, ermöglicht aber eine übersichtlichere Darstellung und vereinfacht den Zugriff auf den Fallback-Wert im Standardwert-Wertauflöser, für den die Sendung als Bezugsobjekt nicht automatisch zur Verfügung steht (s. Hinweis im Abschnitt "Konfiguration").

Als Variablenname wird dabei der interne Name für den jeweiligen Firmentyp (AAL, DDA) verwendet.

►HINWEIS◄ Sofern für den betreffenden Firmentyp keine Adresse angegeben ist, wird der Variablen "kein Wert" ($null) zugewiesen.

Die dritte Setze Wert-Ereignisaktion kann mit den beiden Variablen operieren, um die eigentliche Wertzuweisung für die "Rechnungsadresse" (auf der linken Seite der Zuweisung) zu definieren. Auf der rechten Seite der Zuweisung werden zu diesem Zweck zwei Wertauflöser verkettet:

• Der erste Variable-Wertauflöser greift zunächst den höher priorisierten Quellwert aus der Variablen AAL zu.
  
  

• Der verkettete Standardwert-Wertauflöser gibt die AAL-Adresse aus dem Eingabewert zurück, sofern diese existiert (also: nicht $null ist). Falls keine AAL-Adresse vorliegt, wird "ersatzweise" auf die DDA-Adresse zurückgegriffen. Existiert auch diese nicht, wird keine Adresse zugewiesen (bzw. eine ggf. bestehende Zuweisung gelöscht).

Die rechts abgebildete Konfiguration zeigt wie die "Fallback-Kaskade" durch das Verketten von Instanzen des Standardwert-Wertauflösers abgebildet werden kann:

• Der Benutzer der Session-Wertauflöser liefert in Verbindung mit dem Eingabeobjekt (Typsicher)-Wertauflöser das aktuell angemeldete Benutzerkonto.
  
  

• Per Wert als Variable speichern wird dieses Benutzerkonto in der Variable USER gespeichert, um den wiederholten Zugriff durch die diversen Instanzen des Standardwert-Wertauflösers zu vereinfachen.
  
  

• Der verkettete Objekt-Feld-Wertauflöser greift auf das Feld address.name3 zu, dem die höchste Priorität für die Berücksichtigung als Anrede zukommt.
  
  

• Die nachfolgend verketteten Instanzen des Standardwert-Wertauflösers greifen soweit erforderlich, weil noch kein Eingabewert vorliegt gemäß der geforderten Hierarchie auf weitere Quellfeld-Kandidaten zu.
  
  Im Parameter Standardwert muss dabei zunächst das in der Variable USER gespeicherte Benutzerkonto als Bezugsobjekt gesetzt werden.
  
  ►ANMERKUNG◄ Wäre das Benutzerkonto als Bezugsobjekt (z. B. innerhalb einer Ausführen mit-Ereignisaktion) gegeben, könnte auf den Wert als Variable speichern-Wertauflöser verzichtet werden, wenn im Standardwert anstelle der Variablen USER die vom System automatisch befüllte Variable entity angegeben wird.

Die oben gezeigten Verkettung der Standardwert-Wertauflöser führt dazu, dass zur Laufzeit immer alle drei Instanzen des Wertauflösers "seriell" durchlaufen werden, auch wenn bereits ein Wert für die Anrede gefunden wurde. Der Standardwert wird dabei jeweils nur "aufgelöst", solange noch kein Wert für die Anrede gefunden ist. Aber die Kette muss rein technisch bis zum letzten Wertauflöser schrittweise abgearbeitet werden, obwohl das Endergebnis bereits feststeht.

In der rechts abgebildeten alternativen Konfiguration wird durch die Verschachtelung der Instanzen des Standardwert-Wertauflösers erreicht, dass die Fallback-Kaskade nur so weit durchlaufen werden muss, bis ein Ergebnis vorliegt:

• Bis zur ersten Instanz des Standardwert-Wertauflösers ist die Konfiguration mit dem obigen Beispiel identisch.
  
  

• Die zweite Instanz des Standardwert-Wertauflösers wird dagegen nun nicht am Ende der gesamten Verkettung angehängt, sondern an die Wertauflöserkette im Parameter Standardwert der ersten Instanz angehängt. An dieser Position wird die Instanz nur dann verarbeitet, falls das Feld address.name3 keinen Wert enthält.
  
  

• Die Wertauflöserkette im Standardwert der zweiten Instanz wird nur dann ausgeführt, wenn auch address.name2 keinen Wert enthält. Nur dann wird die darin enthaltene dritte Instanz des Standardwert-Wertauflösers überhaupt verarbeitet, um zu prüfen, ob der Zugriff auf address.name1 einen Rückgabewert liefert.
  
  

• Die Wertauflöserkette im Standardwert der dritten Instanz wird nur dann ausgeführt, wenn keines der zuvor geprüften Felder einen Wert enthält. Dann wird der Benutzername (username) als Anrede zugewiesen, der definitionsgemäß für jedes Benutzerkonto ausgefüllt sein muss.