Skript: Recycling-Heroes - Validation and Determination (Contact) [016]
In dieser Folge stellen wir sicher, dass die eingegebenen Daten sauber validiert sind und wir nur vollständige Datensätze in unserer App akzeptieren. Außerdem implementieren wir eine erste Schnittstelle, um Daten nachzuladen.
Inhaltsverzeichnis
Einleitung
Aktuell können wir in unserer Anwendung neue Datensätze anlegen, ohne das Felder validiert werden. So sollte zum Beispiel für einen Mitarbeiter der Name als Pflichtfeld definiert sein, da wir diesen in unserem Prozess benötigen. Ebenso wollen wir einen Kontakt für Notfälle zu diesem Mitarbeiter haben. Legen wir hier zum Beispiel einen Datensatz an, dann wird dieser einfach gespeichert und die wichtigen Informationen fehlen.
Definition
Dazu legen wir im ersten Schritt die entsprechenden Methoden in unserer Verhaltensdefinition an. Eine Validierung startet mit dem Schlüsselwort "VALIDATION", gefolgt vom Namen der Validierung. Die Validierung soll immer beim Speichern ausgeführt werden, damit keine falschen Datensätze gesichert werden können. Zum Abschluss soll die Validierung bei der Anlage eines Datensatzes und bei der Aktualisierung greifen. Entsprechend kopieren wir uns dann die Validierung, da wir drei unterschiedliche Implementierungen anlegen wollen.
Zusätzlich legen wir uns eine Ermittlung an, die mit dem Schlüsselwort "DETERMINATION" beginnt. Diese soll uns später Adressdaten ermitteln, die wir im Prozess benötigen. Die Ermittlung soll immer dann ausgeführt werden, wenn der Datensatz geändert wird, und zwar wieder bei Anlage und bei Änderung.
Nach der Definition können wir uns die Methoden per Quick Fix oder STRG + 1 anlegen lassen. Dabei werden die vier Methoden in der Verhaltensimplementierung angelegt, wo wir dann weiterarbeiten können.
Validierung
Implementieren wir dazu nun die erste Validierung als Prototypen für die anderen Fälle. Dazu möchten wir wieder eine Hilfsmethode in unserer Zusatzklasse definieren, um die Daten der aktuellen Anfrage einzulesen. In unserer Validierung legen wir uns dazu erst einmal wieder eine Instanz der Hilfsklasse an und rufen dann die Methode auf. Da diese noch nicht vorhanden ist, können wir sie per Quick Fix anlegen lassen. Im nächsten Schritt benötigen wir noch den richtigen Typ für die Übergabe der Schlüssel an die Methode. Über F2 erhalten wir die Elementinfo und können von dort den Typen in unsere Klasse übernehmen. Dann können wir den READ ENTITY in der Methode implementieren. Grundsätzlich bietet sich immer an, nicht alle Felder zu lesen, sondern nur die Felder, die für die Validierung benötigt werden. Da wir das Ergebnis zurückgeben wollen, müssen wir uns in der Klasse noch einen Rückgabetypen anlegen, diesen erhalten wir über die Elementinfo auf dem Ergebnis des EML Statements. Ist die Methode dann vollständig implementiert, können wir noch einmal mit dem ABAP Cleaner formatieren, dann aktivieren und das Objekt schließen, da wir hier keine Änderungen mehr vornehmen.
Beginnen wir nun mit der Implementierung der Logik in der Validierung. Dazu gehen wir über die aktuell zu prüfenden Datensätze. Hier reicht es die Datensätze zu verarbeiten, die im Moment fehlerhaft sind. Das bedeutet in der WHERE Bedingung schränken wir auf Datensätze ein, wo E-Mail und Telefon noch leer sind, da mindestens eine Information befüllt sein soll. Damit sind alle Datensätze innerhalb der Schleife fehlerhaft. Zuerst befüllen wir die FAILED Struktur, um RAP mitzuteilen, dass dieser Datensatz noch fehlerhaft ist. Über das Feld %TKY werden alle relevanten Schlüssel befüllt, damit müssen wir bei längeren Schlüsseln weniger schreiben. Als nächstes wollen wir dem Anwender eine Fehlermeldung mitgeben, dazu müssen wir die Struktur REPORTED befüllen. In dem Feld %MSG erzeugen wir die Fehlermeldung, die im UI angezeigt werden soll. Die Severity stellen wir dabei auf Fehler und dies führt zu einer roten Meldung im UI. Um eine Nachricht anzulegen und übersetzbar zu halten, erzeugen wir eine neue Meldung in der Nachrichtenklasse unserer Komponente. Haben wir den Text angelegt und gespeichert, können wir die Nachrichtenvariablen in der Validierung befüllen.
Testen wir nun einmal den aktuellen Stand der Validierung und gehen dazu ins UI. Wir legen uns einen neuen Kundensatz an und speichern diesen mit den leeren Informationen. Wir erhalten nun eine entsprechende Fehlermeldung im UI oben und über die Nachrichtenausgabe.
Aktuell weiß der User allerdings noch nicht, welches Feld eigentlich davon getroffen ist. Daher wollen wir die beiden Felder im UI hervorheben. Dazu befüllen wir die entsprechenden Elemente in der Reported Struktur über das %ELEMENT. Hier setzen wir für die beiden Felder den Wert auf ON. Prüfen wir das Verhalten nun noch einmal im UI, dann ist die Fehlermeldung von oben verschwunden. Klicken wir auf die Fehlermeldung direkt, dann gelangen wir im UI zum Feld für das Telefon. Beide Felder sind in diesem Fall rot markiert, sodass der Anwender weiß, welche Informationen noch fehlen. Damit die Validierung nun vollständig ist, müssen wir noch den Kontakt Typen einschränken, da sonst die Validierung für alle Datensätze greift, diese aber nur für den Kunden gedacht ist.
Weitere Validierungen
Finalisieren wir nun die weiteren Validierungen im Objekt, dazu kopieren wir unsere Validierung als Vorlage und befüllen die restlichen Informationen. Da die Struktur der Schlüssel nicht exakt gleich definiert ist, aber die gleichen Felder enthält, ergänzen wir hier noch ein CORRESPONDING als Mapping. Dann passen wir die geprüften Felder an und dass diese Validierung nur für den Mitarbeiter greift. Da hier eine andere Fehlermeldung erscheinen soll, legen wir noch eine zusätzliche Meldung an und tauschen die aktuelle Meldung in der Methode aus.
Die dritte Prüfung soll validieren, dass für den Kunden und unsere Mitarbeiter auch ein Vor- und Nachname definiert ist. Daher passen wir hier wieder die Where Bedingung an und schränken die Daten ein. Ebenfalls legen wir für diesen Fall eine eigene Fehlermeldung an und ändern die Felder ab.
Für den Test wechseln wir auf das UI und legen uns einen neuen Mitarbeiter an. Wir lassen hierbei alle Informationen leer und versuchen den Datensatz zu speichern. Wir erhalten hier Fehlermeldungen pro Abschnitt auf dem Formular und können damit die Pflichtfelder befüllen, die Nun rot auf dem Formular hervorgeheben werden. Vergeben wir hier nun einen Namen und eine E-Mail und speichern den Datensatz nun vollständig.
Ermittlung
Für die Ermittlung legen wir nun eine neue Schnittstelle an. Dazu benötigen wir im ersten Schritt aber ein entsprechendes Paket in der Hierarchie. Dazu definieren wir uns zuerst ein allgemeines Paket für Schnittstellen. Darunter legen wir uns dann eine Schnittstelle an, die Adressdaten ermitteln soll.
Um nun die neue Schnittstelle zu definieren, verwenden wir eine IDE Action in Eclipse. Diese findest du auch als Open Source Projekt verlinkt in der Beschreibung. Die Action nimmt uns die Generierung der Artefakte ab und setzt zwischen den Klassen die verschiedenen Beziehungen. Dazu benötigen wir erst einen Namen und eine Beschreibung, mit der die Objekte später angelegt werden. Der Name der Instanz ist dann innerhalb der Verarbeitung wichtig. Passen so weit alle Daten, dann lassen wir die Objekte generieren. ist die Generierung abgeschlossen, erhalten wir eine Übersicht mit den Objekten. Von hier aus können wir direkt in die passenden Objekte springen. Vielleicht musst du an dieser Stelle noch den Dialog bestätigen, um in das Objekt abspringen zu können.
Gehen wir einmal durch die Objekte und formatieren sie bzw. schauen uns den Nutzen an. Über den Injector können wir später Test-Doubles übergeben, ohne die eigentliche Logik anzupassen. Die Factory erzeugt uns entkoppelte Objekte, damit wir von der eigentlichen Implementierung getrennt sind. Damit haben wir die Möglichkeit zur Laufzeit die echte Instanz oder ein Test-Double zu erzeugen. Im Interface definieren wir unsere API Methode, die wir dann später aufrufen wollen. In der eigentlichen Klasse implementieren wir dann die Methode. In diesem Beispiel legen wir uns erst einmal eine Dummy Implementierung an und mappen zwei Postleitzahlen auf Stadt und Land. In einem späteren Video würden wir dann eine echte API dafür nutzen. In diesem Beispiel verwenden wir Berlin und Köln, um Daten zur Verfügung zu stellen. Nach der Aktivierung sind wir mit der Schnittstelle fertig.
In der eigentlichen Implementierung erzeugen wir eine Instanz von dem Service, den wir dann gleich nutzen wollen. Hier können wir wieder die Logik zur Ermittlung der selektierten Datensätze kopieren. Im nächsten Schritt rufen wir für jeden Datensatz die API auf. Da die Datensätze unterschiedliche Typen haben, müssen wir sie auf die Zielstruktur mappen. Zum Abschluss wollen wir die Datensätze aktualisieren, dazu verwenden wir den MODIFY ENTITY und übergeben Stadt und Land zur Aktualisierung. Damit wir nur Änderungen vornehmen, wenn die Bedingungen erfüllt sind, setzen wir in der Schleife noch eine WHERE Bedingung. Die Postleitzahl sollte befüllt sein und eine der beiden Zielfelder mindestens leer sein.
Testen wir zum Abschluss noch die Ermittlung im UI. Dazu legen wir eine neue Adresse an und befüllen die Postleitzahl. Beim Speichern des Datensatzes wurden nun die Stadt und das Land ermittelt und in die Felder übernommen.
Side Effects
Aktuell stört uns ein Punkt, und zwar das die Daten erst aktualisiert werden, wenn wir Speichern. Damit sieht der Anwender noch nicht vor dem Speichern, ob die richtigen Daten ermittelt wurden. Daher stellen wir die Ermittlung um, und zwar soll diese durchlaufen werden, wenn sich das Feld ZipCode verändert. Zusätzlich implementieren wir einen Side Effect auf dem Feld. Damit wird das UI automatisch aktualisiert, wenn das Feld geändert wurde und der Cursor das Feld verlässt. Damit der Seiteneffekt auch verwendet wird, müssen wir die Verwendung auf Consumption Ebene bekannt machen.
Geht en wir dann in die Anwendung und legen eine neue Adresse an, dann können wir die Postleitzahl mit einem neuen Wert befüllen. Wechseln wir dann mit dem Cursor das Feld, dann wird Stadt und Land automatisch befüllt.
Zusammenfassung
In der heutigen Folge haben wir zusätzliche Prüfungen im UI implementiert, um die Vollständigkeit der Eingaben zu validieren. Über eine Ermittlung können wir abhängig von den Eingaben noch weitere Informationen ergänzen, ohne dass der Anwender eingreifen muss. Über die Seiteneffekte können die Veränderungen sofort im UI anzeigt werden, ein manuelles Aktualisieren ist nicht mehr nötig. Damit würden wir uns beim nächsten Mal mit der Erstellung und dem Deployment der Anwendung befassen.
Danke fürs Zuschauen und bis zum nächsten Mal.
YouTube
Video