ABAP Cloud - Key User Apps
Die Key User Extensibility ist ein Teil von ABAP Cloud, wenn es um die Erweiterung des Core geht, doch wie kannst du die Werkzeuge sinnvoll nutzen und wie ergänzen sie sich?
Inhaltsverzeichnis
In diesem Artikel schauen wir uns einmal die vorhandenen Key User Apps an und wie sie das ABAP Cloud Portfolio ergänzen, aber auch behindern können. Dabei wirst du etwas mehr über die Apps erfahren und in welchen Szenarien sie ein Blick wert sind.
Einleitung
Aktuell unterteilt sich die Extensibility in die Bereiche On-Stack Extensibilty und Side-by-Side Extensibility. Bei On-Stack schauen wir auf die Möglichkeiten in unserem aktuellen System, ohne den Einsatz der Business Technology Platform (BTP). Dabei wird aktuell die Key User Extensibility (Key User Apps) und die Developer Extensibility (ABAP Cloud) angeboten. In dem heutigen Artikel soll es um das Zusammenspiel der Beiden gehen.
Die Side-by-Side Extensibility beschäftigt sich mit der Erweiterung des Core Systems als eigenen Ansatz auf der BTP. Dabei stehen dir das ABAP Environment, kurz Steampunk, mit dem ABAP RESTful Programming Model (RAP) zur Verfügung oder die JAVA/nodeJS Umgebung mit dem Cloud Application Programming Model (CAP). Weiterhin gibt es verschiedene Services im SAP Build Portfolio, wie SAP Build Apps oder SAP Build Process Automation, die verschiedene Ansätze und Möglichkeiten verfolgen.
Key User Apps
Was sind nun also die Key User Apps? In diesem Abschnitt schauen wir uns einmal die Apps, Hilfs-Apps und die Verwendung der Tools an.
Einführung
Dabei handelt es sich um Fiori Anwendungen die in deinem S/4HANA System laufen mit denen ein Key User (Anwender ohne Entwicklungserfahrungen, aber mit IT Knowhow) das System erweitern und neue Objekte erstellen kann. Grundsätzlich sind die Tools aber auch für den Entwickler interessant, da er damit einfache Erweiterungen ohne Programmierung durchführen kann. Die Änderungen werden auf dem Entwicklungssystem durchgeführt und müssen dann klassisch per Transport in der Systemlandschaft zur Verfügung gestellt werden. In vielen Unternehmen übernimmt das Deployment dann auf jeden Fall wieder der Entwickler.
Apps
Welche Apps gibt es nun und für welche Use-Cases sind sie gedacht? In diesem Abschnitt werden wir auf die Details eingehen. Beginnen wir zuerst einmal mit den Haupt-Apps, die du benötigst:
- Custom Fields (F1481) - Es können eigene Felder in Business Objekte übernommen werden. Dabei kümmert sich der Standard darum, dass das neue Feld von der Datenbank bis zum UI oder die API aufgenommen wird.
- Custom Logic (F6957) - Implementierung von vorgedachten BADIs mit der Spracheversion "ABAP for Key-Users" (Version 2). Der Sprachumfang ist soweit stark eingeschränkt.
- Custom CDS views (F1866A) - Über die App können eigene Core Data Services angelegt werden. Damit können verschiedene Daten in einem neuen CDS View zusammengebracht werden und es besteht die Option, den CDS View auch als OData Service zur Verfügung zu stellen. Grundlage sind freigegebene Core Data Services (C1-Contract).
- Custom Business Objects (F1712) - Generiert ein oder mehrere Tabellen, die als Business Objekt dargestellt werden. Als zugrundeliegende Technik wird aktuell auf BOPF gesetzt, dem Vorgänger von RAP. Es können Datenmodelle, APIs und Fiori Apps auf dem Objekt generiert werden.
- UI Adaption - Hierbei handelt es sich nicht um eine Anwendung, sondern eine Funktion. Mit den nötigen Berechtigungen steht in Fiori Apps die Option "Adapt UI" im Menü zur Verfügung, damit kann die App und die Oberflächen angepasst werden.
- Custom Analytical Queries (F1572) - Erstellung von Auswertungen auf CDS-Basis zur Verwendung im Reporting oder als Datenquelle (SAP Analytics Cloud, SAP Datasphere).
- Custom Logic Tracing (F3438) - Erstellung von Traces zur Analyse von kundeneigenen Implementierungen für Business Objekte oder BADI Implementierungen.
Dazu werden noch verschiedene Apps und Programme zur Verfügung gestellt, um am Ende die neuen Objekte auch zur Verfügung stellen zu können:
- Extensibility Inventory (F2587) - Auflistung aller Erweiterungen im System, mit zusätzlichen Statistiken und offenen Punkten zur Abarbeitung.
- Configure Software Packages (F1590) - Registrierung von Paketen, die für die Anlage von Erweiterungen genutzt werden können.
- Register Extensions for Transport (F1589) - Zuweisung von Erweiterungen zu Paketen und Transporten. Damit werden die durchgeführten Erweiterungen für die Produktivsetzung vorbereitet.
Verwendung
Die Key User Apps sind ein mächtiges Werkzeug zur Anpassung von Standardprozessen im System und sollten mit Bedacht verwendet werden. Aus eigener Erfahrung konnten einige Änderungen im System nicht mehr zurückgedreht werden, daher lohnt sich eine Vorabprüfung auf einem CAL- oder Sandbox-System. Als zweiter Punkt sollte geklärt werden, welche User Zugriff zu den Möglichkeiten bekommen. Bei nicht zu erfahrenen Key Usern sollten auch vorher Schulungen durchgeführt werden, damit die Risiken bekannt sind.
Wenn du Objekte mit den Key User Apps erstellst, werden diese zuerst einmal in einem temporären Paket abgelegt. In diesem Paket werden alle Objekte ohne Transport angelegt, da es sich um ein temporäres Paket handelt. Die Konfiguration des Pakets und der Namenskürzel musst du allerdings zuvor über die Transaktion S_ATO_SETUP erledigt haben. Die Objekte sind somit nicht transportierbar. Über die App "Register Extensions for Transport" kannst du dann die Objekte vom temporären Paket in ein kundeneigenes Paket übernehmen und die Objekte normal transportieren.
Abgrenzung
In diesem Abschnitt wollen wir uns einmal die Abgrenzung zu ABAP Cloud anschauen und wie du die beiden Modelle verwenden kannst.
Einschränkungen
Die Key User Apps stellen verschiedene Funktionen zur Verfügung, die auch mit ABAP Cloud möglich sind. Außerdem generieren sie Objekte mit der Sprachversion 2 (ABAP for Key Users) und sind damit nicht durch ABAP Cloud wiederverwendbar (Sprachversion 5). Genau das ist auch der Punkt, an dem du dich entscheiden solltest, welche Objekte du mit welchem Tool zur Verfügung stellst. Einige Objekte können allerdings auch übergreifend verwendet werden, mehr Informationen dazu findest du in der SAP Help.
Im 3-TIER Modell würdest du die Objekte entweder in TIER-3 einordnen oder als Stand-Alone-Paket neben das Modell stellen. In TIER-1 können die Artefakte nicht verschoben werden, APIs für TIER-2 sind es auch nicht.
Vorschlag
Sollte also ein Entwickler an den Objekten beteiligt sein, empfiehlt es sich eigene Objekte (CDS Views, Business Objekte, Analytische Queries und BADI Implementierungen) über ABAP Cloud umzusetzen. Die Objekte können vom Entwickler frei erstellt und angepasst werden und es besteht zusätzlich die Möglichkeit für das Objekt einen C1-Contract zu erzeugen, der das Objekt auch für die Key User Apps zur Verfügung stellt. Dies ist auch der Weg, zusätzliche kundeneigene Funktionen für die Apps zur Verfügung zu stellen.
Allerdings gibt es auch Punkte, da sind die Key User Apps besser, einfacher oder die einzige Möglichkeit. Zum Beispiel bei der Integration eines neuen kundeneigenen Felds in Standard-Business-Objekte. Die UI Adaption und die Bereitstellung von App Varianten ist einfach und flexibel, um Anpassungen an Standard Fiori Apps zur Verfügung zu stellen.
Hintergrund des Vorschlags ist die bessere Handhabung der Tools durch dich als Entwickler, um weitere Anforderungen an Objekten einfach realisieren zu können. Zum anderen sparst du dir dann wiederrum veraltete Objekte im System, wie BOPF Business Objekte, die du vielleicht später für Erweiterungen umbauen müsstest. Das Framework ist auch nicht jedem Entwickler bekannt.
Fazit
Die Key User Apps bereichern das Portfolio der Extensibility im ABAP Cloud Bereich, sollten allerdings mit Bedacht genutzt werden. Für was willst du die Objekte in Folge nutzen? Mit den Hilfsmitteln solltest du eine ungefähre Richtung bekommen haben.
Weitere Quellen:
YouTube - Understand the clean core extensibility options for Cloud ERP
YouTube - What software developers want to know about Key User Extensibility
SAP Help - Key User Extensibility
SAP Fiori Apps Reference Library
