Fiori für ABAP - Rich Text Editor
Du möchtest einen Langtext in deiner RAP Anwendung als HTML und durch den Nutzer pflegen lassen? Dazu gibt es nativ für ABAP keine Funktion, doch dies ist recht einfach erweiterbar.
Inhaltsverzeichnis
In diesem Artikel schauen wir uns die Einbindung eines Rich Text Editor in unsere Anwendung an und wie du das einfach über das Flexible Programming Model umsetzen kannst.
Einleitung
Aktuell haben wir unsere Sales App über Guided Development und einzelne Anpassungen (Page Map) erweitert. Dabei sind wir bisher noch nie auf größere Erweiterungen oder Ausbrüche aus dem Fiori Elements Framework gestoßen. Deshalb wollen wir uns in diesem Artikel einmal anschauen, wie wir eine Anpassung an einer Anwendung durchführen, deren Anforderungen über den Standard von Fiori Elements hinausgehen. Dazu wollen wir das Flexible Programming Model verwenden, eine komfortable Möglichkeit zur Erweiterung von Fiori-Elements-Anwendungen.
Schauen wir in unsere Anwendung, so finden wir unter dem Bereich „Differenzen“ aktuell eine Sektion für Informationen. Diese umfasst ein Kommentarfeld, welches als String-Feld auf der Datenbank definiert wurde. Aktuell ist das Feld auf der Benutzeroberfläche relativ klein gehalten, wir können kaum Text eingeben, geschweige denn Formatierungen vornehmen. Dieses Feld ist jedoch eigentlich dazu gedacht, Informationen so aufzubereiten, dass sie später als E-Mail versendet werden können oder den Kollegen besser strukturiert zur Verfügung stehen.
Daher wollen wir das einfache Textfeld austauschen und durch einen Rich Text Editor ersetzen. Dieser bietet uns deutlich mehr Formatierungsoptionen und liefert uns automatisch den passenden Text als HTML-Template zurück.
Development Portal
Das SAP Fiori Development Portal ist der neue zentrale Zugriffspunkt für das Thema Flexible Programming Model und die Erweiterung von Fiori-Elements-Anwendungen. Im Portal erhältst du zahlreiche Informationen darüber, wie Erweiterungen durchgeführt werden, welche Building Blocks es gibt und wie du die verschiedenen Erweiterungspunkte gezielt einsetzt. Darüber hinaus gibt es weitere flexible Möglichkeiten zum Testen bestimmter Features und zur Anpassung der Einstellungen. Hier verweisen die meisten Modelle auf die native Anpassung über XML-Fragments, CAP und RAP, wobei RAP aktuell noch einige Lücken in der Dokumentation aufweist. Der große Vorteil des Development Portalsist, du siehst direkt die vorhandenen Features und kannst viele Funktionen live ausprobieren, bevor du sie in deine eigene Anwendung einbaust. Daher handelt es sich um eine Must-have-Ressource, die du definitiv in deinem Portfolio speichern solltest.
Begriffe
Wenn du dich mit dem Thema noch nicht allzu sehr auseinander gesetzt hast, hier einige Begriffe in einer kompakten Form erklärt.
Flexible Programming Model
Das Modell beschreibt die Möglichkeiten, in Anwendungen, die auf OData-Services Version V4 basieren, Erweiterungen durchzuführen. Dabei stehen bestimmte Erweiterungspunkte zur Verfügung, die du nutzen kannst, um individuelle Logik oder UI-Elemente zu implementieren.
Erweiterung
Grundsätzlich ist Fiori Elements relativ strikt darin, wie die Anwendungen generiert werden und wie die Templates entsprechend aussehen. Deshalb muss es hier eine Varianz zwischen einer Freestyle-Anwendung und einer Fiori-Elements-Anwendung geben, nämlich um eigene Nuancen und Erweiterungen in die Applikation bringen zu können, ohne Fiori Elements komplett zu verlassen und direkt in die Freestyle-Entwicklung zu gehen. Die Freestyle-Entwicklung kann in der Erstellung und Wartung im Vergleich deutlich teurer sein.
Building Blocks
Benötigst du eine Komponente, die du wiederverwenden willst, wie zum Beispiel die Filter Bar, die aus verschiedenen Elementen besteht, oder die Tabelle, die mit einer Filter Bar gekoppelt ist, dann gibt es die sogenannten Building Blocks. Dies sind vorgefertigte UI-Komponenten, die du ganz einfach in deiner Entwicklung verwenden kannst. Sie ermöglichen es dir, deine Anwendung einfach und schnell aufzubauen, ohne tief in die komplexe Freestyle-Entwicklung eintauchen zu müssen.
Vorbereitung
Bevor wir zur direkten Implementierung der Rich-Text-Editoren übergehen, müssen wir einen Bereich schaffen, in dem wir uns frei bewegen und Erweiterungen im Framework durchführen können. Dazu erweitern wir die Object Page und erstellen eine Custom Section, in der wir anschließend weitere Implementierungen vornehmen können.
Page Map
Hierzu starten wir die Page Map unserer Anwendung. Weitere Details zur Page Map und den genauen Aufruf findest du in dem passenden Artikel dazu.
Als Nächstes navigieren wir von der Page Map über das Stift-Icon auf die Object Page unserer Hauptentität Verkäufe, da wir dort die Anpassungen vornehmen wollen.
Im nächsten Schritt betrachten wir den Aufbau unserer Object Page. Im oberen Bereich finden wir den Header; hier sind alle Informationen wie Icons und Überschriften definiert. Im mittleren Teil haben wir die verschiedenen Sections. Das sind die Bereiche, in denen unsere Felder und Informationen über Facets gruppiert sind. Ganz unten befindet sich der Footer, der meistens für die Aktionen zuständig ist, wie zum Beispiel das Speichern oder Discard Draft. Wir navigieren daher als Nächstes in den Bereich Sections. Dort klicken wir auf das Plus-Icon und wählen den Punkt "Add Custom Section" aus, um einen eigenen Bereich anzulegen.
Im Popup geben wir nun alle Informationen ein, die wir für die Custom Section benötigen. Zuerst geben wir einen Titel ein, der später als Überschrift über der Sektion erscheint. Im zweiten Punkt definieren wir ein neues Fragment, da aktuell noch keine Fragmente existieren. Fragmente sind dabei kleine UI-Bestandteile, die wir entsprechend in das Framework einfügen können. Anschließend vergeben wir einen Namen, da hierfür im Anschluss eine Datei angelegt wird, und definieren einen entsprechenden Anker. In diesem Fall wollen wir das Element nach den Differenzen einfügen; daher wählen wir als Anchor Element die ID aus und setzen das Placement auf "After". Einen Event Handler benötigen wir in diesem Fall nicht, da wir keinen JavaScript-Code implementieren müssen.
Ergebnis
Als Ergebnis erhalten wir verschiedene Anpassungen in unserer Fiori-Anwendung. In der Page Map findest du nun die Custom Section, die neu angelegt wurde. Parallel dazu wurde ein neuer Ordner für Extensions (ext) und ein Bereich Fragments erstellt. Dort wurde unsere Datei angelegt und ein Dummy-Code implementiert.
Technisch wurde dabei im Hintergrund die manifest.json erweitert und zwar die entsprechende Object Page, wo wir die Erweiterung auch eingefügt haben. Dort findest du neue Elemente unter der Object Page, wie zum Beispiel den Body mit den Sections. Wir finden entsprechend die Definition unseres Fragments, also wo das Fragment definiert ist, und auch die Position dazu. Das Element soll nach der idDifference eingefügt werden.
Anzeige
Schauen wir uns nun die Anwendung im Preview-Modus an. Dort befindet sich mittlerweile die neue Section oberhalb unserer bisherigen Informationen und unterhalb der Differenzen. Auch der Dummy-Code wurde bereits implementiert, das heißt, wir sehen bereits den eingebundenen Text des Fragments in der Applikation.
Richt Text Editor
Rich-Text-Editoren gehören zum Konzept des WYSIWYG (What You See Is What You Get). Das heißt, der User bearbeitet und formatiert einen entsprechenden Text direkt in der Oberfläche. Genau das, was er dort sieht, zum Beispiel anhand von Formatierungen, Bildern oder Farben, die er einfügt, erhält er auch so im Endergebnis.
Aufbau
Schauen wir uns dazu nachfolgend zwei verschiedene Konzepte an, einerseits die Building Blocks, die zum Flexible Programming Model gehören, und andererseits die Freestyle-Komponenten, die wir ebenfalls verwenden können. Grundsätzlich besteht das Fragment aus XML-Elementen. Dabei haben wir eine Fragment-Definition, die außen herum gegeben ist, diese dürfen wir auch nicht verändern und müssen sie soweit beibehalten. Diese wird später in die Seite eingebunden, allerdings können wir den Inhalt innerhalb der Fragment-Definition ändern, um unsere angepassten Controls einfügen zu können.
Wollen wir in XML ein Feld aus dem OData Service verwenden, dann greifen wir mit geschweiften Klammern auf den Hauptservice und das entsprechende Feld zu. In dem Fall unseres Kommentars verwenden wir daher "{SaleComment}", um das Feld aus dem Service zu binden.
Variante - Building Block
Über das SAP Fiori Development Portal finden wir weitere Informationen zum Building Block und wie dieser konfiguriert wird. Im Grunde besteht dieser aus einem einfachen Macro-Element, welches wir dann wiederum einbinden können. Haben wir das Macro entsprechend auf unserer Seite eingebunden, müssen wir noch das Feld definieren, gegen welches wir im OData-Service arbeiten wollen. In diesem Fall haben wir das Feld "SaleComment" im Modell des OData-Services. Dazu vergeben wir noch eine eindeutige ID für den Editor.
<core:FragmentDefinition
xmlns:core="sap.ui.core"
xmlns="sap.m"
xmlns:macros="sap.fe.macros"
>
<macros:RichTextEditor
value="{SaleComment}"
id="idCommentEditor"
excludeDefaultPlugins="false"
/>
</core:FragmentDefinition>
Schauen wir uns eine Preview unserer Applikation an, so ist der Text-Editor nun eingebunden. Wir haben die Formatierungsoptionen im oberen Bereich, können Text eingeben und diesen auch formatiert anzeigen. Im Development Portal findest du auch noch, zum Beispiel, eine Einschränkung der verschiedenen Buttons und Aktionen, die im Control möglich sind. Dazu gibt es in der Dokumentation weitere Hinweise, wie über eine ButtonGroup zum Beispiel nur bestimmte Elemente für den User eingeblendet werden können. So sind verschiedene Einstellungen am Control möglich, um eine einfache Implementierung durchzuführen.
Variante - Freestyle Komponente
Enthält dir die Komponente zu wenig Funktionen oder möchtest du zum Beispiel Bilder verwenden, die du inline einfügst, dann funktioniert das vielleicht mit dem Makro aktuell nicht. Daher kannst du auch überlegen, den Freestyle-Editor einzubinden. Dieser stammt nicht aus Fiori Elements, sondern aus dem SAPUI5-Portfolio. Dafür musst du allerdings den Namespace erweitern. Diesen erweiterst du im Fragment oben (xmlns:rte="sap.ui.richtexteditor"), um den Editor mit aufzunehmen. Danach führen wir den Editor auf und aktivieren spezifische Funktionen, die wir zum Editieren später benötigen. Grundsätzlich kannst du auch noch eine HTML-Klasse hinterlegen und die Größe des Editors beeinflussen, was wir in diesem Fall machen.
<core:FragmentDefinition
xmlns:core="sap.ui.core"
xmlns="sap.m"
xmlns:macros="sap.fe.macros"
xmlns:rte="sap.ui.richtexteditor"
>
<rte:RichTextEditor
id="idCommentEditorRT"
class="sapUiSmallMarginBeginEnd"
width="98%"
height="500px"
value="{SaleComment}"
sanitizeValue="false"
customToolbar="true"
showGroupFont="true"
showGroupLink="true"
showGroupInsert="true"
editable="{ui>/isEditable}"
/>
</core:FragmentDefinition>
Als Spezialität müssen wir in diesem Fall auch noch den Status der Editierbarkeit definieren. Dazu binden wir ein Element aus dem lokalen UI-Modell. Dort gibt es das Attribut "isEditable", welches wir in die Einstellungen übernehmen. Damit wird automatisch beim Klicken auf den Edit-Button der Editor geöffnet, und wenn wir den Draft beispielsweise verlassen, wird das Feld wieder auf Anzeige umgestellt. Über diese Statusänderungen müssen wir uns in Fiori Elements keine Gedanken machen, das übernimmt das Framework für uns, und wir können aus dem entsprechenden Modell die Eigenschaften einfach übernehmen. Die geschweiften Klammern greifen auf die Attribute und Modelle zu. In diesem Fall verwenden wir das Modell "ui>" und greifen auf das Attribut "/isEditable" zu.
{ui>/isEditable}
Haben wir den Editor am Ende eingebunden und konfiguriert und hierbei auch das entsprechende Feld wieder an den OData-Service gebunden, dann können wir uns den Editor im Preview anzeigen lassen. Grundsätzlich sieht dieser erst einmal gleich aus. Hier sehen wir aber auf den ersten Blick, dass wir mehr Funktionen haben, um Texte zu formatieren, wie zum Beispiel verschiedene Schriftarten, Größen und weitere Einstellungen.
Vergleich
Grundsätzlich gibt es Unterschiede bei der Verwendung der beiden unterschiedlichen Controls. Beim Makro haben wir hier den Standard von Fiori Elements und eine relativ leichte Einbindung in unsere Fiori-Applikation. Weiterhin können wir aktuell zwei unterschiedliche Status an das Element koppeln, was die Flexibilität ohne viel Programmieraufwand erhöht. Der Freestyle-Editor, den wir hier verwenden können, hat den Vorteil, dass wir zum Beispiel den Sanatizer deaktivieren können, wodurch wir Bildcontent auch innerhalb des Strings speichern können. Weiterhin können wir verschiedene Gruppen einblenden, um die verschiedenen Tools und Werkzeuge sichtbar zu machen, die wir verwenden. Andererseits ist der Konfigurationsaufwand für das Freestyle-Element etwas größer, da wir auch hier zum Beispiel den Edit-Flow beachten müssen, welchen wir im Standard geschenkt bekommen. Es macht daher Sinn, grundsätzlich zu schauen, welches der beiden Elemente du in deinem Fall benötigst. Das Makro ist der einfachste und standardisierte Weg und ohne viel Konfigurationsaufwand umsetzbar.
Bereinigung
Passen wir noch einige Dinge in der Sales App an, dazu schauen wir uns in diesem Kapitel zwei weitere Punkte auf ABAP Seite an.
Konvertierung
Aktuell gibt es noch einen Punkt, den wir in unserer Anwendung korrigieren müssen. Wenn du die Texte speicherst, wird dir auffallen, dass diese in Großbuchstaben konvertiert werden. Hier müssen wir noch die Eigenschaften der Domäne anpassen, um die Groß- und Kleinschreibung im Element zu aktivieren. Eigentlich handelt es sich bei diesem Feld um ein String-Feld, doch der Standard übernimmt hier die Konvertierung in Großbuchstaben, da wir die entsprechende Eigenschaft nicht gesetzt haben. Dazu musst du in das ABAP-Projekt gehen und die Domäne ZBS_DEMO_SA_COMMENT öffnen. Dort setzt du das Flag für die Groß- und Kleinschreibung, speicherst und aktivierst das Element wieder.
Damit funktioniert in unserer Anwendung die Groß- und Kleinschreibung, und wir können die Texte so, wie wir sie formatiert haben, speichern, ohne dass die Buchstaben wieder automatisch konvertiert werden.
Facet
Im zweiten Teil haben wir aktuell eine Facet zu viel definiert. Hier handelt es sich um die Informationen, die wir im UI ausgeben. Da wir nun eine neue Custom Section eingeführt haben mit einem eigenen Editor, können wir das Feld und die eigentliche Section vom UI entfernen. Dazu können wir die Facet in der Metadata Extension löschen sowie das eigentliche Feld im UI deaktivieren. Dazu kommentieren wir die Bestandteile in der Metadata Extension aus, damit wir diese später noch nachvollziehen können.
// {
// id: 'idInformation',
// label: 'Information',
// position: 30,
// type: #IDENTIFICATION_REFERENCE,
// targetQualifier: 'INFO'
// },
...
// @UI.identification: [ { position: 100 , qualifier: 'INFO' } ]
// @EndUserText.label: 'Comment'
@UI.hidden: true
SaleComment;
Dies ist auch der Grund, warum wir die Custom Section an die Facet gehängt haben. Denn wir benötigen ein sichtbares Element, woran sich die Custom Section orientiert. Hätten wir sie an eine Information gebunden und später gelöscht, wäre auch das Element und der Zusammenhang verloren gegangen. Daher ist es wichtig, diese Sektion (Differenzen) auch in Zukunft verfügbar zu haben.
Vollständiges Beispiel
Die gespeicherten Ressourcen zu unserer Anwendung findest du in unserem GitHub Repository. Damit kannst du in Zukunft alle Anpassungen an der Fiori App mit nachvollziehen oder die Ressourcen für ein Deployment nutzen. Die aktuellen Änderungen findest du in diesem Commit wieder. Die Änderungen in ABAP findest du in diesem Commit im entsprechenden RAP GitHub Repository.
Fazit
In diesem Artikel haben wir uns angeschaut, wie wir eine bestehende Fiori-Elements-Anwendung mit dem Flexible Programming Model erweitern, eine Custom Section anlegen und dort ein Custom Control definieren, welches wir an unseren Service binden, um Inhalte verändern zu können. Dabei haben wir verschiedene Szenarien für verschiedene Controls angeschaut und diese miteinander verglichen.
