Skript: Recycling-Heroes - Create by Factory Actions (Contact) [015]
In dieser Folge beschäftigen wir uns mit Factory Actions, Late Numbering und Nummernkreise. Zum Abschluss vervollständigen wir die UI und Navigation und kümmern uns um ein besseres Fehlerhandling.
Inhaltsverzeichnis
Einleitung
In der letzten Folge hatten wir das UI entsprechend vorbereitet und die Abgrenzung mit virtuellen Feldern durchgeführt. Ein Problem bleibt allerdings noch im UI, wenn wir einen neuen Datensatz anlegen, ist der Typ noch zu Beginn unbekannt und damit werden Felder angezeigt, die eigentlich ausgeblendet werden sollen. Daher gehen wir in diesem Video auf die verschiedenen Factory Aktionen ein.
Aktionen
Dazu legen wir drei neue Factory Actions in der Behavior Definition an. Wir definieren die Aktion als Statisch, da wir jederzeit eine neue Entität anlegen wollen und diese nicht abhängig ist von einem anderen Eintrag. Der Action geben wir einen entsprechenden Namen und definieren die Ergebnismenge. Eine Action erzeugt immer genau einen neuen Eintrag. Dann definieren wir die Berechtigungen für die Aktion. "Global" bedeutet daher, dass zum Start der Anwendung die Berechtigung für die Action definiert wird, ob der aktuelle Nutzer sie ausführen kann. Dann Kopieren wir die Aktion und geben jeweils einen sprechenden Namen. Über den "Quick Fix" lassen wir uns dann die Implementierung generieren, formatieren die Klasse und aktivieren die beiden Objekte.
Nun müssen wir die Aktionen noch im Consumption View veröffentlichen, damit unsere Anwendung darauf Zugriff hat. Das können wir über "Use Action" machen. Damit wir nun die Aktion im UI sehen, müssen wir sie über die Metadata Extension einblenden. Dabei ist es eigentlich egal, an welchem Feld wir das tun. Hier definieren wir für die ContactID die Aktionen am LineItem, da wir sie in der Liste haben möchten. Neben FOR ACTION, definieren wir die eigentliche Aktion die aufgerufen werden soll und geben dem Ganzen ein Label, dass wir später auch übersetzen können. Zum Abschluss noch die Objekte aktivieren.
Gehen wir nun in das UI und aktualisieren die Anwendung, dann werden die Aktionen neben dem Standard "Create" angezeigt. Damit ist die Anlage und Implementierung bis zum UI abgeschlossen.
Implementierung
Als nächstes können wir nun die Aktionen implementierend, dabei verwenden wir eine "Auxiliary Class". Diese Hilfsklasse ist mit dem RAP Objekt verbunden und ermöglicht uns, Funktionen aus der lokalen Implementierung auszulagern, um diese übersichtlich zu halten. Dann legen wir die globale Klasse mit dem Namen an. Hier gibt es leider keine Unterstützung von den ABAP Development Tools. In der globalen Klasse definieren wir über den Zusatz "FOR BEHAVIOR OF" die Verbindung zu unserem RAP Objekt. Damit die Fehlermeldung nun verschwindet, aktivieren wir die beiden Objekte.
Wir können nun mit der Implementierung der Klasse beginnen, dazu starten wir in der Create Methode für die Adresse, erzeugen uns eine Instanz der Klasse und verarbeiten die übergebenen Schlüssel. Über eine neue Methode der Klasse übergeben wir die CID und das Draftkennzeichen an die Methode. Zusätzlich übergeben wir noch den Typ des Kontakts, damit wir einen neuen Kontakt anlegen können. In der Methode erstellen wir einen neuen Eintrag über ein EML Statement auf unser RAP Objekt. Da wir hier eine Hilfsklasse verwenden, können wir auch den Zusatz IN LOCAL MODE verwenden. Für die Anlage verwenden wir direkt ein VALUE Statement. Da wir die MAPPED Struktur zurückgeben wollen, erzeugen wir uns in der Klasse einen Typen, den wir dann als RETURNING Parameter definieren können. Nun übergeben wir die Informationen an das EML Statement. Die CID benötigen wir aus der Action, da diese durch das Framework vorbefüllt wird. Ebenfalls übernehmen wir das Draftkennzeichen, um den Datensatz im Zustand Draft zu erzeugen. Da wir den Kontakt Typ setzen wollen, übernehmen wir diesen aus den Parametern, hier auch nicht vergessen, dass das CONTROL Flag gesetzt werden muss. Sind wir damit fertig, aktivieren wir die Klasse.
Nun können wir die Methode in der lokalen Implementierung ausprägen und die einzelnen Parameter befüllen. Für den Kontakt Typ verwenden wir das Konstanteninterface und fügen zum Abschluss den neuen Datensatz in die Mapped Struktur ein. Sind wir mit dieser Methode fertig, können wir den Aufruf kopieren und für die anderen Methoden anpassen. Damit wären wir mit dieser Implementierung fertig. Gehen wir zum Abschluss ins UI und aktualisieren die Anwendung. Legen wir nun eine neue Adresse an, dann landen wir auf der Objektseite, der Typ Adresse ist bereits borbelegt, ebenso wie das Icon. Da die unnötigen Felder ebenfalls ausgeblendet sind, können wir direkt mit der Befüllung starten.
Late Numbering
Im nächsten Schritt wollen wir ein Late Numbering implementieren. Dabei soll der Datensatz erst seine Nummer erhalten, wenn der User auf Speichern klickt und die Daten feststehen. Dazu ergänzen wir in der Definition den Zusatz LATE NUMBERING. Nun müssen wir allerdings auch die Draft-Tabelle neu generieren, da die DRAFTUUID in der Tabelle benötigt wird. Haben wir das getan, können wir die Artefakte aktivieren. Über den Quick Fix können wir die Methode in der Saver-Klasse implementieren.
In diesem Fall wollen wir wieder unsere Hilfsklasse verwenden und erzeugen uns dazu eine Instanz. In diesem Fall müssen wir über die MAPPED Datensätze loopen und die ContactId befüllen. Hierzu rufen wir unsere neue Methode GET_NEW_NUMBER auf und übergeben die PID, die wir gleich zum Lesen der Daten benötigen. In diesem Fall lassen wir die Methode per Vorwärtsnavigation anlegen und starten nicht in der Hilfsklasse.
Als nächstes Lesen wir den Kontakt Typen über ein EML Statement aus dem Puffer. Da wir hier immer nur einen Datensatz verarbeiten, Lesen wir uns den ersten Datensatz ein, um diesen im Anschluss zu verarbeiten. Dann mappen wir den Typen auf die jeweiligen Konstanten des Interfaces. Als Dummy geben wir erst einmal den Typen zurück, um im nächsten Schritt die Logik testen zu können. Legen wir uns in der Anwendung eine neue Adresse an und Speichern diese, dann wird nun eine ID generiert und gesetzt.
Nummernkreis
Damit wir nun richtige Nummern erzeugen, verwenden wir ein Nummernkreisobjekt, um solche Nummern im System zu generieren. Die Nummern sollen zu Beginn den ersten Buchstaben des Kontakt Typ haben und dann eine neustellige Nummer. Daher legen wir uns eine neue Domain für die Generierung der Nummern an, die allerdings nur neun Zeichen besitzt. Als nächstes benötigen wir das das Nummernkreisobjekt, dass wir über die Suche finden. Da das Nummernkreisobjekt nur 10 Zeichen für die Benamung bietet, müssen wir hier uns etwas einschränken, um einen sprechenden Namen zu erhalten. Im Nummernkreis verwenden wir die eben angelegte Domäne, um die Länge der Zahlen zu definieren.
Nach dem Aktivieren wechseln wir ins Launchpad und geben in die Anwendung "Manage Number Range Intervals", um die für unseren Nummernkreis die verschiedenen Intervalle zu definieren. Insgesamt benötigen wir drei Intervalle, die wir später für die Erzeugung verwenden möchten. Die Intervalle 01, 05 und 09 werden wir dann für die unterschiedlichen Typen einsetzen.
Als nächstes implementieren wir nun die Nummernvergabe in der Methode. Über die Klasse CL_NUMBERRANGE_RUNTIME erhalten wir Zugriff auf die Vergabe der Nummern. Dazu übernehmen wir die Rückgabewerte per Inlinedeklaration und definieren eine eigene Variable für das Intervall. Das Objekt können wir in diesem Fall hartcodiert hinterlegen, da es sich nicht ändern wird. Nun setzen wir jeweils das Intervall abhängig vom Kontakt Typen. Mitarbeiter werden im 1er Bereich angelegt, Kunden im 5er und Adressen im 9er. Da wir den ersten Teil des Typen mit in der Nummer haben wollen, verwenden wir hier die Substring Funktion und lesen das erste Zeichen. Dieses verketten wir dann mit der neuen Nummer, um unsere ID zu erhalten. Da die Nummer als NUMC erzeugt wird und eine größere Länge als unser Datentyp hat, müssen wir zuerst noch ein internes Mapping durchführen.
Zum Abschluss führen wir einen Test durch und legen eine neue Adresse an. Dazu geben wir den Vornamen und Nachnamen an und speichern die neue Adresse. Es wird nun automatisch eine neue Kontakt ID erzeugt, die aus dem 9er Bereich kommt und mit A beginnt. Damit haben wir auch eine automatische Nummernvergabe implementiert, aber auch erst dann, wenn der Datensatz wirklich gesichert werden soll.
Refactoring
Führen wir nun noch ein Refactoring durch. Wir haben in unserer Logik einige Punkte, die wir nicht verwenden, Ausnahmen, die wir noch nicht abfangen und keine Meldungen, die wir ans UI weitergeben. Daher legen wir uns einen neuen Rückgabetypen an. Dieses Mal wollen wir neben der Nummer noch ein Log Objekt zurückgeben, welches mögliche Meldungen enthält. Daher definieren wir uns eine Struktur mit zwei Informationen.
Dann übergeben wir mögliche Ausnahmen aus der Verarbeitung an das Log. Dazu gibt es die Methode ADD_MESSAGE_EXCEPTION. Grundsätzlich müssen wir noch zu Beginn das Log erzeugen, damit es zu keinem Fehler bei der Befüllung kommt. Dann prägen wir die beiden Ausnahmen bei der Verwendung der Standardklasse aus und übergeben die Meldungen an das Log. Zum Abschluss übergeben wir unsere neue Nummer noch an die neue Struktur als Ergebnis. Wird der Return-Code von der Methode gesetzt, dann gab es ebenfalls einen Fehler, wie zum Beispiel, dass der Nummernkreis voll ist. In diesem Fall wollen wir eine T100 Nachricht erzeugen. Legen wir nun eine neue Nachrichtenklasse für die Software Komponente an und geben ihr einen Namen. Dann definieren wir eine Nachricht mit Platzhaltern, die wir dann während der Verarbeitung befüllen. Dazu verwenden wir die Methode ADD_MESSAGE, um eine einfache T100 Nachricht zu erzeugen und zu speichern.
Zum Abschluss müssen wir die Methode ADJUST_NUMBERS anpassen. Hier speichern wir uns das Ergebnis in einer neuen Variable, übergeben die neue Nummer an das Feld und hängen alle Meldungen in Form von RAP Meldungen an die OTHERS Tabelle.
Finalisierung UI
Passen wir noch ein letztes Mal das UI an. Als Titel wollen wir auf der Object Page gern den vollständigen Namen sehen, deshalb übernehmen wir das Feld in den Consumption View und aktivieren die Änderungen. Im Anschluss zeigen wir das Feld im Titel an. Als nächsten Schritt definieren wir im Consumption View den semantischen Schlüssek für die ContactId. Diese Änderung hat zur Folge, dass die ID nun fett hervorgehoben wird im List Report. Schauen wir uns nun die Object Page an, dann finden wir dort den vollständigen Namen im Header. Legen wir einen neuen Datensatz an und verlassen die Bearbeitung ohne Speichern, dann bleibt der Draft weiter bestehen. In der Liste sehen wir nun dank des semantischen Schlüssels die Draft Instanz, sowie einige Informationen, wenn wir mit der Maus darauf gehen.
Create
Ein offener Punkt bleibt allerdings. Schauen wir uns den List Report an, dann finden wir aktuell auch noch die Standard "Create" Aktion, zur Anlage von neuen Kontakten. Allerdings wollen wir diese nicht verwenden, da in der App die drei Aktionen für spezifische Formen verwendet werden sollen. Hier stehen uns aktuell zwei Lösungen zur Verfügung.
Wir können "Create" auf Internal setzen, damit kann die Aktion von außen nicht mehr ausgelöst werden, also weder über das UI noch über EML außerhalb der Verhaltensimplementierung. Dazu müssen wir in der Definition etwas anpassen und die Berechtigungen entfernen. Im Consumption View müssen wir die Nutzung deaktivieren, da die Aktion für Außen nun nicht mehr zur Verfügung steht. Laden wir dann das UI einmal neu, dann werden nur noch unsere Factory Actions angezeigt.
Die zweite Alternative ist, dass wir den Button einfach im UI deaktivieren, in dem wir im Consumption View die Action löschen. Damit steht die Aktion in der App nicht mehr zur Verfügung, über EML könnten wir sie aber weiterhin nutzen. Daher entscheiden wir uns für die zweite Version und blenden den Button im UI aus.
Zusammenfassung
Wir können nun neue Datensätze über Factory Actions erzeugen und damit den Contact Typ direkt bei Erzeugung setzen. Damit sind die entsprechenden Felder auch gleich ausgeblendet und wir befüllen die für uns relevanten Felder. Zum Abschluss hatten wir noch das UI finalisiert und intern das Fehlerhandling vervollständigt, damit eventuelle Fehler bis ins UI gehen und unsere Anwendung stabil bleibt. In der nächsten Folge validieren wir die Eingaben, bevor wir dann zur Erstellung der Anwendung kommen.
Danke fürs Zuschauen und bis zum nächsten Mal.
YouTube
Video