Eigenes Aktionsevent auslösen (Formulardesigner)
Die Verhaltensweise Eigenes Aktionsevent auslösen (Formulardesigner) löst ein Eigenes Aktionsevent und damit Ereignisbehandlungen aus, die sich auf dieses Eigene Aktionsevent als auslösendes Ereignis bezieht.
Die folgenden Abschnitte erklären Details zu den folgenden Mechanismen:
Bereitstellen von Daten aus dem Formular für das Ereignis
Rückgabedaten des Verhaltens
Ausführen von Aktionen
Bereitstellen von Daten aus dem Formular für das Ereignis
Bezüglich der Bereitstellung von Daten aus dem Formular sind folgende Fälle zu unterscheiden:
Ist kein Element verknüpft, dann werden dem Ereignis die gesamten Formulardaten mitgegeben.
Handelt es sich bei dem Formular um eine Erfassungsmaske, dann erscheint das Datenobjekt der betreffenden Entität als Eingabewert für das Ereignis.
Portale und Dashboards verwenden dagegen eine anonyme Datenstruktur, die dem Ereignis über die Variable formData bereitgestellt wird.
Ist ein Element verknüpft, dann werden dem Ereignis dessen Elementdaten mitgegeben.
Beziehen sich die Elementdaten auf eine Entität, etwa ein Geschäftsobjekt, ein Firmenkonto oder eine Adresse, dann erscheint dieses als Eingabewert für das Ereignis.
Handelt es sich bei den Elementdaten um eine anonyme Datenstruktur, dann wird diese dem Ereignis über die Variable formData bereitgestellt.
Per Standard werden außerdem über den Parameter value (s. Screenshot oben) die ggf. anliegenden Eingabedaten ($input) für das Ereignis bereitgestellt, so dass in Ereignisbehandlungen über eine gleichnamige Variable (value) auf den $input zugegriffen werden kann. Mit derselben Methodik können weitere Daten oder Berechnungsergebnisse aus dem Kontext des Formulars an das Ereignis gebunden werden, indem über einen Klick auf das zugehörige (+)-Symbol weitere Parameter (und entsprechende Variablen) hinzugefügt werden.
Rückgabedaten des Verhaltens
Bezüglich der Rückgabedaten des Verhaltens sind folgende Fälle zu unterscheiden:
Wurde dem Ereignis als Datenobjekt eine Entität als Eingabewert übergeben, wird dieses Datenobjekt ggf. inklusive der Änderungen durch alle aufgerufenen Ereignisbehandlungen an das Verhalten zurückgegeben.
Handelt es sich bei der Entität um das Datenobjekt, auf das sich die aufrufende Erfassungsmaske insgesamt bezieht, werden die Rückgabedaten automatisch als Formulardaten geladen, damit das Formular den geänderten Stand abbildet. Dies erfolgt aber nur, sofern Daten verändert wurden. Dabei werden die Auslöser Formulardaten geladen und "Kontext verändert" für das Formular aktiviert.
Falls ausgehend von einer Elementverknüpfung eine Entität an das Ereignis übergeben wurde, die nicht die das gesamte Bezugsobjekts des Formular darstellt, dann werden die deren Daten zwar auch inklusive der ggf. durch Ereignisbehandlungen vorgenommenen Veränderungen an das Verhalten zurückgegeben, aber nicht automatisch in das Formular geladen. Eventuell (z. B. im Fall einer Position eines Geschäftsobjekts) können sie aber per Aktion Elementdaten setzen in die Formulardaten eingebunden werden.
Wurde dem Ereignis eine anonyme Datenstruktur per Elementverknüpfung (und formData Variable) übergeben, wird der Wert dieser Variablen ggf. inklusive der Änderungen durch alle aufgerufenen Ereignisbehandlungen an das Verhalten zurückgegeben. Diese Daten können dann z. B. per Aktion Elementdaten setzen innerhalb des Formulars zugeordnet werden.
►HINWEIS◄ Die übergebene Datenstruktur kann durch Ereignisbehandlungen modifiziert und dann per Aktion z. B. wieder auf das verknüpfte "Ursprungselement" abgebildet werden. Oder es wird durch die Ereignisbehandlungen ein komplett neues Datenobjekt als Rückgabewert erzeugt (z. B. per Aktion Erzeuge Instanz), das auf ein anderes Formularelement gesetzt wird.
Welche Daten an die Aktionen weitergegeben werden, kann zusätzlich durch den optionalen Parameter Ergebnisausdruck gesteuert werden. Diesem steht als Datenbasis der Inhalt des Storage zur Verfügung, also eine Liste aller Variablen aus dem Kontext des Ereignisses, die über Parameter mit Verhalten, durch Zuweisungen innerhalb von Ereignisbehandlungen oder automatisch mit Werten belegt werden.
Wenn ein Ergebnisausdruck definiert ist, bestimmt dieser den Rückgabewert des Verhaltens. Beispiele:
Der Ergebnisausdruck $input liefert ein Datenobjekt, das das gesamt Storage enthält, so dass jede Aktion mit den Werten sämtlicher enthaltenen Variablen zugreifen kann.
Der Ergebnisausdruck {value} liefert die beim Auslösen des Verhaltens anliegenden Eingabedaten (also den ursprünglichen $input) ggf. inklusive Änderungen durch Ereignisbehandlungen
Ist kein Ergebnisausdruck definiert, dann gilt folgende Fallunterscheidung für den Rückgabewert:
Wurde eine Entität als Eingabewert übergeben, dann wird sinngemäß der Standard-Ergebnisausdruck {entity} angewendet, so dass die ggf. bearbeiteten Daten der Entität weitergegeben werden.
Wurde eine anonyme Datenstruktur übergeben, dann gilt sinngemäß der Standard-Ergebnisausdruck {formData}, so dass der ggf. bearbeitete oder ersetze Inhalt dieser Variablen weitergegeben wird.
Ausführen von Aktionen
Sofern sämtliche ausgelösten Ereignisbehandlungen ohne Fehler abgearbeitet werden, werden die "Aktionen bei 'wahr" mit den Rückgabedaten des Verhaltens ($input) ausgeführt. Dabei wird ggf. der Ergebnisausdruck berücksichtigt, wie im vorigen Abschnitt beschrieben.
Falls während der Ereignisverarbeitung ein Fehler (Exception) auftritt (i. d. R. durch die Abbrechen), werden die Aktionen bei "falsch" mit dem Fehlerobjekt (Fault) als Eingabedaten ($input) ausgeführt.
►HINWEIS◄ Zur Analyse der Fehlerstruktur ist die Aktion In die Konsole loggen ein hilfreiches Werkzeug.
Beispiele
Die Einsatzmöglichkeiten für ein Eigenes Aktionsevent in Verbindung mit den ausgelösten Ereignisbehandlungen sind ausgesprochen vielfältig. In den folgenden Beispielen werden unterschiedliche Konstellationen für den Einsatz Eigenes Aktionsevent auslösen (Formulardesigner) vorgestellt, ohne dass alle Details zu den Ereignisbehandlungen und Stammdaten beschrieben werden. Abstrakt beschrieben bilden die Beispiele die folgenden Anwendungsfälle ab:
Beispiel 1: Aufruf des Verhaltens aus einer Erfassungsmaske mit den kompletten Daten der dort angezeigten Entität (Sendung). Die Daten werden durch das Ereignis verändert und automatisch ins Formular übernommen.
Beispiel 2: Aufruf des Verhaltens aus einer Erfassungsmaske mit den Daten einer bestimmten Position als Entität (Sendungsposition). Die Daten werden durch das Ereignis verändert und anschließend per Aktion als Elementdaten gesetzt.
Beispiel 3: Aufruf des Verhaltens mit einer in einem Portal erfassten anonymen Datenstruktur. Die Daten werden durch das Ereignis verändert und anschließend per Aktion als Elementdaten im Portal gesetzt.
Beispiel 1: Übernehmen von Kopfdaten aus einer interaktiv ausgewählten Sendung zum Initialisieren einer anderen
In einer Erfassungsmaske für Sendungen sollen per Knopfdruck bestimmte Kopfdaten für die Sendung (s. Screenshot: Sendungstyp, Servicetyp und Transporttyp) aus einer bestehenden anderen Sendung übernommen werden. Die Sendung soll nach dem Klick auf einen Button durch eine interaktive Auswahl in einer Liste von Sendungen mit spezifischen Einschränkungen (z. B. Zeithorizont für "Erstellt") ausgewählt werden können.
Laufzeit-Beispiel:
Klick auf den Button "... übernehmen aus anderer Sendung" öffnet eine bestimmte Sendungsübersicht zur Auswahl (s. Verhalten Wähle aus Übersicht):
Bestätigen der Auswahl per Schaltfläche Übernehmen im Ribbon schließt die Sendungsübersicht übernimmt die Daten der Sendung in die aufrufende Erfassungsmaske.
Soweit in den den Daten der in der Übersicht ausgewählten Sendung Angaben für die Felder Sendungstyp, Servicetyp und Transporttyp vorliege, werden diese für die Sendung in der Erfassungsmaske übernommen.
Konfiguration:
Die folgenden Konfigurationen werden für die nachfolgend erörterte Konfiguration der Verhaltensweise vorausgesetzt und nicht im Detail erörtert:
Anlegen der Sendungsübersicht für die Auswahl der Sendung, die als Vorlage dient (s. Eigene Übersichten) und Einrichten der Datengrid-Einstellungen für die Liste.
Anlegen eines Eigenen Aktionsevents (in der Dynamischen Aufzählung Eigenes Aktionsevent) mit dem Namen "Kopfdaten von Sendung übernehmen".
|
Verhalten für die Auswahl der Sendung, deren Daten übernommen werden sollen: |
|
|
|
Für den Button in der Erfassungsmaske wird zunächst das links abgebildete Verhalten konfiguriert, um die Auswahl der Sendung zu ermöglichen, deren Kopfdaten in die aktuelle Sendung übernommen werden sollen:
|
|
Verhalten für die Übernahme der Kopfdaten per Eigenes Aktionsevent |
|
|
|
Das links abgebildete Verhalten wird ebenfalls für den Button zum Übernehmen der Kopfdaten konfiguriert:
|
|
Ereignisbehandlung für die Übernahme der Kopfdaten |
|
|
|
Die Konfiguration für die Ereignisbehandlung wird hier aus Platzgründen in zwei Abschnitten wiedergegeben. Der erste Abschnitt (links) zeigt die Auslösenden Ereignisse (hier nur das Eigene Aktionsevenet "Kopfdaten von Sendung übernehmen") und die Prüfenden Regeln:
Nur wenn beide Regeln erfüllt sind, dann werden die im zweiten Abschnitt (unten) abgebildeten Aktionen ausgeführt. Es handelt sich um drei analog konfigurierte Aktionen vom Typ Setze Wert, die nach demselben Schema die Werte dreier Felder aus dem Sendungskopf der per value übergebenen ausgewählten Sendung in den Sendungskopf der als Eingabewert aus der Erfassungsmaske übernommenen Sendung übertragen:
|
|
|
|
Beispiel 2: Nachschlagen von Details für eine Sendungsposition in den Positionen einer korrespondierenden Bestellung
Ausgehend von per Schnittstelle eingehenden Bestellungen sollen Sendungen für die Belieferung erstellt werden, deren Sendungspositionen mit Bezug zu Bestellpositionen angelegt werden sollen aber nicht müssen. Um dies zu beschleunigen, bietet die Erfassungsmaske für Sendungen eine Nachschlagefunktion, die per Taste F2 gestartet werden kann, nachdem eine Zeichenfolge in das Feld "Warenbeschreibung" eingegeben wurde. Diese Zeichenfolge wird dann als Bestandteil von "Warenbeschreibungen" der Positionen der korrespondierenden Bestellung gesucht. Alternativ kann die vierstellige Referenznummer einer Bestellposition vollständig eingegeben werden. Der erste Treffer wird verwendet, um bestimmte Felder der Sendungsposition ("Bestellposition Referenz", "Warenbeschreibung", "Anzahl Packstücke") zu belegen, die danach bei Bedarf bearbeitet werden können.
Laufzeit-Beispiel:
Hier wurden die Ansichten für Bestelldetails und Sendungsdetails übereinander angeordnet.
In der Erfassungsmaske für die Sendungsdetails sind bereits "passende" Suchbegriffe für die Bestellpositionen eingetragen. Nachdem im jeweiligen Feld F2 gedrückt wurde, ergibt sich folgendes Bild:
Konfiguration:
Wie im vorigen Beispiel werden zwei Verhalten verkettet, um den Nachschlagevorgang zu realisieren.
|
Verhalten zur Übernahme der "Beleg-Nr. der Bestellung" (in der Sendungsmaske) für das Nachschlagen |
|
|
|
Für das Textfeld "Warenbeschreibung" wird das links abgebildete Verhalten konfiguriert:
|
|
Verhalten zum Nachschlagen der Bestellposition über eine Eigenes Aktionsereignis |
|
|
|
Auch dieses Verhalten wird für dasselbe Textfeld und wie links abgebildet konfiguriert. Da es ausschließlich vom obigen Verhalten und über die Aktion Verhalten ausführen ausgelöst wird, bleibt der Auslöser (nicht im Bild) leer.
|
Innerhalb der Ereignisbehandlung, die hier nicht im Detail wiedergegeben wird, kann beim Nachschlagen auf die Variable value zugegriffen werden, um die korrespondierende Bestellung per Suche (Ereignisaktion) zu ermitteln. Deren Direkte Positionen können dann mit einem Regel-Listen Resolver ausgewertet werden, um nach einem Treffer für den Wert im Textfeld "Warenbeschreibung" zu suchen. Ist eine passende Bestellposition ermittelt, werden die gewünschten Eigenschaften bzw. Attributwerte per Setze Wert auf die Sendungsposition-Entität übertragen, die als Eingabewert des Ereignisses gilt.
Beispiel 3: Registrieren von in einem Portal erfassten "Mitgliedskonten" durch Zuweisen eines Nummernkreiswerts
In einem Portal soll eine Liste von "Mitgliedern" (gekennzeichnet durch die Felder "Vorname" und "Nachname") erfasst werden können, für die abschließend in einem gemeinsamen "Registrierungslauf" jeweils eine eindeutige Mitgliedskonto-Nr. zugeordnet werden soll, die aus einem Nummernkreis gezogen wird. Der Prozess könnte weitere Schritte anstoßen, etwa des Druck von Mitgliedsausweisen, den Versand von Benachrichtigungen usw., die hier aber nicht beschrieben werden sollen.
Laufzeit-Beispiel:
|
|
|
Konfiguration:
|
|
Für den Button "Registrieren" wird das links abgebildete Verhalten konfiguriert.
|
|
|
Die Ereignisbehandlung für das Eigene Aktionsevent "Konto registrieren" wird wie links abgebildet konfiguriert:
|
