Skript: Recycling-Heroes - Virtual elements for UI Features (Contact) [013]
Wie kannst du über virtuelle Felder dem UI weitere Informationen zur Verfügung stellen und damit sogar bestehende Felder beeinflussen? In dieser Folge schauen wir uns verschiedene Punkte rund um das Thema virtuelle Felder an.
Inhaltsverzeichnis
Einleitung
Beim letzten Mal hatten wir das UI unserer Anwendung angepasst und die technischen Identifikatoren mit Texten ersetzt oder ergänzt. Zusätzlich haben wir an den wichtigsten Feldern Wertehilfen implementiert, um mehr Komfort bei der Arbeit mit der App zu haben. In dieser Episode schauen wir uns virtuelle Felder im Consumption View an und wie wir sie nutzen können, um zusätzliche Informationen anzuzeigen und überflüssige Informationen auszublenden. Dabei legen wir ein Konstanteninterface an und fokussieren dann auf die Arbeit mit den Feldern.
Konstanteninterface
Im ersten Schritt legen wir ein neues Interface im Bereich SHARE an. Hier wollen wir den "ContactType" einigen Konstanten geben, damit wir später mit den Konstanten arbeiten können und nicht auf die hartkodierten Werte gehen müssen. Die Konstanten legen wir als Struktur im Interface an und geben ihnen sprechende Namen. So können wir später im Code über einen sprechenden Namen zugreifen.
Virtuelle Felder
Möchten wir in unserem UI zusätzliche Informationen anzeigen, die aber vielleicht nicht auf der Datenbank gespeichert sind, aber vielleicht von diesen Informationen abgeleitet werden, dann können wir virtuelle Elemente verwenden. Dazu definieren wir auf Consumption Ebene ein neues virtuelles Element und geben ihm einen Namen und einen Typen. Wir legen dabei vier Elemente an, ein Icon das später für jeden Typen anders aussehen soll und drei Felder, mit denen wir bestimmte Informationen im UI ausblenden wollen. Telefon, E-Mail und der Geburtstag sind Felder, die wir nicht bei jeder Art von Kontakt benötigen. Damit für die Felder unser ABAP Exit aufgerufen wird, müssen wir diesen am Feld definieren. Über "CalculatedBy" geben wir unsere ABAP Klasse mit, die aufgerufen werden soll.
Damit wir den Fehler wegbekommen, müssen wir noch die Klasse im System anlegen. Über das Kontextmenü können wir eine neue Klasse anlegen, geben ihr einen sprechenden Namen und eine Beschreibung. Dann suchen wir nach dem Interface für den Exit und werden mit IF_SADL_EXIT fündig. Haben wir alles befüllt, ordnen wir einen Transport zu und legen die Klasse im System an. Formatieren wir entsprechend die Klasse und aktivieren sie.
Nach Prüfung des Core Data Service sollten nun alle Fehler verschwunden sein und wir können den View auch aktivieren, um bei der Implementierung der Logik weiterzumachen.
Implementierung
Die Klasse verfügt über zwei Methoden, über CALCULATE befüllen wir später die virtuellen Felder und über GET_CALCULATION_INFO sagen wir, welche Felder und Informationen wir für die Berechnung benötigen.
Schauen wir uns erst einmal die Signatur der Methode an, hier erhalten wir eine Information über die angefragten Felder und die Entität die gerade geladen wird. Damit können wir nun weitere Felder anfragen, die wir später benötigen. Führen wir also im ersten Schritt eine Prüfung durch, dass auch gerade die richtige Entität vom System angefragt wird. Handelt es sich um eine andere Entität, dann soll die Logik verlassen werden. Dann übergeben wir den "ContactType" an die angefragten Felder, da wir diesen für die Prüfung und Ableitung benötigen.
Dann können wir auch schon die zweite Methode implementieren. Zuerst benötigen wir eine typisierte Tabelle, da wir eine Tabelle vom Typ ANY TABLE erhalten, wir aber später auf die spezifischen Felder zugreifen wollen. Dazu mappen wir die eingehenden Daten auf unsere neue typisierte Tabelle. Wenn wir mit unserer Logik fertig sind, übergeben wir die Daten per Mapping an die Rückgabestruktur zurück.
Nun können wir die eigentliche Mappinglogik implementieren. Dazu loopen wir über die Tabelle und arbeiten mit einer Referenz, da wir die Daten gleich noch verändern wollen. Wir beginnen mit dem Icon für den "ContactType", dabei verwenden wir den neuen SWITCH und benötigen dazu auch die Konstanten aus dem Interface. Über die SAP Icons wählen wir uns nun drei passende Icons aus, die wir später im UI sehen wollen. Als nächstes blenden wir die Felder aus, die wir im UI nicht mehr sehen wollen, wieder abhängig vom Typen.
UI Annotationen
Um nun zum Beispiel ein Icon anzuzeigen benötigen wir im Header die Annotation "UI.headerInfo.typeImageUrl" dort binden wir unser neues Feld ein. Über das Raute-Symbol und in Klammern das Feld, übergeben wir den Inhalt des Feldes an die Annotation. Gehen wir dann zurück in unsere App und aktualisieren einmal das UI, dann sollten wir nun auf der Object Page im oberen Bereich ein Bild finden. Für den Kunden verwenden wir nun ein anderes Bild als für einen Angestellten. Damit kann der Sachbearbeiter später bei der Erstellung und Bearbeitung einfacher die Klassifizierung des Eintrags machen.
Im nächsten Schritt möchten wir nun die Felder Geburtstag, Telefon und E-Mail deaktivieren. Dafür verwenden wir in der jeweiligen Annotation das Attribut "hidden" und setzen als Referenz das jeweilige Feld, um den Inhalt auszublenden. Laden wir dann das UI erneut und schauen in die Details, werden wir keine Änderung feststellen. Was ist also das Problem bei der Verwendung? Die Annotation ist als Boolean definiert und benötigt daher den Typ Boolean um zu funktionieren. das Thema ist in der ABAP Entwicklung schon seit Beginn ein Thema, da es keinen richtigen Boolean gibt. Wir müssen also noch einmal in den Consumption View gehen und den Datentypen gegen ein ABAP_BOOLEAN austauschen. Dieser Datentyp wird eigentlich in allen Fällen empfohlen, da es sich im Gegensatz zu ABAP_BOOL um ein Datenelement handelt und damit an mehr Stellen eingesetzt werden kann. Ist der Core Data Service dann aktiviert, tauschen wir die Werte noch in unserem Exit aus und laden das UI einmal neu.
Schauen wir uns nun den Customer an und gehen auf die Detailseite, dann wir der Geburtstag auf dem UI nun ausgeblendet. Die Annotation greift damit und blendet die Elemente aus. Legen wir uns im nächsten Schritt eine Adresse an, wo mehr Elemente ausgeblendet werden. Dazu legen wir uns einen neuen Datensatz an, definieren das Attribut Contact Type als Adresse und speichern den Eintrag. Nach dem Sichern werden die Daten neu geladen und wir sehen, dass die drei Felder nun ausgeblendet sind. Allerdings haben wir nun das Problem, dass unsere Facet nun leer angezeigt wird.
Daher gehen wir in unsere Consumption View und definieren uns ein neues virtuelles Element, um auch die Facet im UI ausblenden zu können. Das Feld befüllen wir ebenfalls in unserem ABAP Exit, wenn wir den Typen Adresse haben. Zum Abschluss gehen wir in die Metadata Extension und ergänzen das Attribut "hidden" in der Digital Contact Facet. Gehen wir zurück ins UI und laden die Daten neu, sollte nun auch die Facet auf der Detail Page ausgeblendet sein und wir erhalten eine saubere Ansicht.
Requested Elements
Schauen wir uns zum Abschluss der Folge noch die angefragten Elemente im Exit an. Dazu deaktivieren wir in der Methode GET_CALCULATION_INFO das angefragte Element und testen im UI das Verhalten. Dazu deaktivieren wir im List Report einige Felder, sodass wir unser Icon als Spalte sehen, aber nicht den Contact Type. Führen wir nun die Selektion aus, dann bleibt das Feld leer. Grundsätzlich werden in Fiori nur die Felder vom Backend angefragt, die der User auch im UI sieht. Das spart Datenbankperformance, Übertragungskapazität und hält die Ladegeschwindigkeiten klein. Das führt am Ende aber dazu, das unser virtuelles Feld nicht die Informationen bekommt, die wir zur Ableitung benötigen und damit bleibt die Anzeige leer.
Über die Method fordern wir dieses Element an und bekommen es in die Methode geliefert. Grundsätzlich haben wir hier auch die Möglichkeit Informationen von der Datenbank nachzulesen, um die fehlenden Informationen zu bekommen. Mit der Standardlogik können wir allerdings erreichen, so wenig Aufrufe wie nötig zu haben.
Felder ausblenden
Rufen wir noch einmal das UI auf und schauen uns die Liste der Felder an. Aktuell sehen wir die virtuellen Felder in der Auswahlliste. Diese bringen normalerweise nur einen kleinen Mehrwert für den User, da sie nur einen steuernden Charakter haben. Damit die Felder nicht mehr zur Auswahl stehen, können wir diese vor dem User verstecken. Dazu nehmen wir die Felder in die Metadata Extension auf und blenden sie über UI.hidden aus. Gehen wir zurück in die App und aktualisieren das UI, dann sind die Felder nun aus der Auswahlliste der möglichen Felder verschwunden. Weiterhin nutzen wir die Felder, um die Eigenschaften der UI zu steuern.
Zusammenfassung
In dieser Folge haben wir uns angeschaut, wie wir virtuelle Felder zur Laufzeit zur Verfügung stellen und die richtigen Inhalte ableiten. Wir können damit in der UI zusätzliche Felder einblenden oder andere Felder in ihrer Sichtbarkeit einschränken. Zum Abschluss haben wir geklärt, wofür wir die Felder brauchen und welchen Einfluss die Sichtbarkeit darauf hat. Damit ist das UI nun vollständig und wir können uns in der nächsten Folge die Erzeugung der Instanzen anschauen.
Danke fürs Zuschauen, viel Spaß beim Lernen und bis zum nächsten Mal.
YouTube
Video