Als erfahrener ABAP-Entwickler bei SAP bin ich mir der Frustration nur allzu bewusst, die Anwender angesichts unnötiger Komplexität empfinden können. Mein Ziel war es, aufzuzeigen, wie unkompliziert es sein kann, die Möglichkeiten der Key User Extensibilität in SAP S/4HANA Cloud zu nutzen. In meinem Fall habe ich mich darauf beschränkt, ausschließlich die in SAP Fiori verfügbaren Anwendungen zu verwenden. Dies entspricht einem Szenario mit einer Zwei-System-Landschaft, in der die über die ABAP Development Tools (ADT) verfügbare Entwickler-Erweiterbarkeit nicht genutzt werden kann.
Diese Art der Erweiterung ist für Sap Key User von unschätzbarem Wert, da sie es ermöglicht, Geschäftsprozesse und Anwendungen anzupassen, ohne tiefgreifende Programmierkenntnisse zu benötigen oder auf die Unterstützung eines ABAP-Entwicklers angewiesen zu sein. Es ist eine Demokratisierung der Anpassungsfähigkeit, die es den Anwendern erlaubt, ihre Systeme flexibler an die spezifischen Bedürfnisse ihres Unternehmens anzupassen. Ob es darum geht, neue Felder hinzuzufügen, Geschäftslogik zu definieren oder UI-Anpassungen vorzunehmen, die Key User Extensibilität bietet eine robuste Plattform für agile Änderungen. Diese Anpassungsfähigkeit ist entscheidend in einer schnelllebigen Geschäftswelt, in der die Fähigkeit, schnell auf neue Anforderungen zu reagieren, einen erheblichen Wettbewerbsvorteil darstellen kann. Es ist wichtig, solche mächtigen Werkzeuge im SAP-Ökosystem optimal zu nutzen, um den größtmöglichen Nutzen aus Investitionen in Lösungen wie SAP S/4HANA Cloud zu ziehen und den reibungslosen Start von Produktivitätsanwendungen zu gewährleisten.
Die von mir genutzten Fiori-Anwendungen sind:
- Released ABAP Artifacts
- Extensibility Cockpit
- Custom Fields
- Custom Logic
- Custom Logic Tracing
- Create Production Order
- Manage Production Orders
Mein Implementierungsszenario ist einfach: Ich möchte für jeden Vorgang in jedem von mir angelegten Fertigungsauftrag einen universell eindeutigen Bezeichner (UUID) generieren und speichern können. Zudem möchte ich überprüfen, ob mein Code wie erwartet funktioniert, und somit sein Verhalten testen und validieren. Ich möchte dieses Feld weder den Benutzern anzeigen noch ihnen die Bearbeitung über die Benutzeroberfläche gestatten (obwohl dies bei Bedarf sehr einfach für jede anwendbare UI aktiviert werden könnte, wie im Blogbeitrag In-App extensibility in S/4 HANA Cloud | Part 1 – Adding a custom field on the UI%20The%20field%20will%20now,exit%20the%20UI%20adaptation%20mode.)) veranschaulicht wird.
Ich setze voraus, dass Sie bereits mit der grundlegenden ABAP-Syntax und dem Konzept eines Business Add-Ins (BAdI) sowie mit der Arbeit mit Fiori-Anwendungen vertraut sind. Zusätzlich müssen die für alle genannten SAP Fiori-Anwendungen relevanten Geschäftsrollen Ihrem Benutzer bereits zugewiesen worden sein (die entsprechenden Geschäftskataloge/-rollen finden Sie im Reiter Implementation Information unter dem Abschnitt Configuration der SAP Fiori Apps Reference Library für jeden in der Liste bereitgestellten Anwendungslink).
Der Weg zur Erweiterung: Eine Schritt-für-Schritt-Anleitung
Die Implementierung der Key User Extensibilität erfordert ein systematisches Vorgehen. Vom Auffinden der richtigen Tools bis zur Verifizierung der implementierten Logik sind mehrere Schritte notwendig, die alle innerhalb der Fiori-Umgebung durchgeführt werden können. Dieser Abschnitt führt Sie detailliert durch jeden einzelnen Schritt, um die gewünschte Funktionalität zu erreichen.
Den passenden UUID-Generator finden
Aus meiner bisherigen Erfahrung weiß ich, dass ABAP-Systeme typischerweise vordefinierte Klassen bieten, die gängige Funktionen bereitstellen. Da ich eine UUID generieren möchte, suchte ich in der Anwendung Released ABAP Artifacts nach ‘UUID’ und fand die Factory-Klasse CL_UUID_FACTORY, die ich verwenden kann.
Suche nach ABAP-Klassen für UUID-Generierung in Fiori
Um sicherzustellen, dass diese Klasse das bietet, was ich benötige, klickte ich auf das ‘Dokument’-Symbol neben der Klasse, um ihre Beschreibung einzusehen.
Dokumentation der CL_UUID_FACTORY Klasse in SAP Fiori anzeigen
Ich musste auch wissen, welche Methode ich verwenden sollte, daher navigierte ich zu den Details dieser Klasse und zum Reiter ‘Methods’.
Methodenübersicht der ABAP-Klasse CL_UUID_FACTORY in Fiori
Hier konnte ich auch die Beschreibung der Methode einsehen.
Detailansicht der CREATE_UUID Methode in SAP Fiori
Da diese Methode das Interface IF_SYSTEM_UUID zurückgibt (welches von der in der Klassenbeschreibung erwähnten Klasse CL_SYSTEM_UUID implementiert wird), überprüfte ich anschließend, welche Methode ich dort verwenden könnte, indem ich zur Klasse CL_SYSTEM_UUID navigierte.
Methoden der CL_SYSTEM_UUID Klasse in SAP Fiori überprüfen
Ein geeignetes BAdI identifizieren
Als Nächstes musste ich ein BAdI finden, das ich zum Füllen meines benutzerdefinierten Feldes verwenden konnte. Dafür musste ich den relevanten Geschäftskontext ermitteln, der in meinem Fall Fertigungsaufträge betreffen würde. Das Extensibility Cockpit machte dies sehr einfach. Ich musste lediglich auf dem Reiter ‘All Business Contexts’ nach ‘Production Orders’ suchen, und ich fand sofort einen guten Kandidaten (d.h., einen, bei dem sowohl strukturelle als auch logische Erweiterungen bereits unterstützt wurden).
Suche nach Geschäftskontext "Production Orders" im Extensibility Cockpit
Ich navigierte dann zur Detailseite des Eintrags ‘Manufacturing: Order Operation’, wo ich die aktuell verfügbaren BAdIs sehen konnte.
Anzeige verfügbarer BAdIs für den Geschäftskontext "Manufacturing: Order Operation"
Anschließend klickte ich auf die ‘Enhancement Option’ für das erste BAdI, und nach Prüfung der Dokumentation entschied ich mich, dieses zu verwenden.
Dokumentation eines BAdI im Extensibility Cockpit überprüfen
Ein benutzerdefiniertes Feld erstellen
An diesem Punkt kann ich mit meiner Implementierung beginnen. Ich ging zur Anwendung Custom Fields und suchte nach einem bestehenden benutzerdefinierten Feld, das sich auf eine UUID bezieht und das ich wiederverwenden könnte (es gab jedoch keines).
Suche nach vorhandenen benutzerdefinierten UUID-Feldern in der App Custom Fields
Um ein neues Feld hinzuzufügen, klickte ich auf das ‘+’-Symbol, wodurch ein Popup-Fenster geöffnet wurde, das mich nach dem zu verwendenden Geschäftskontext fragte (welcher der zuvor identifizierte war, der unten hervorgehoben ist).
Erstellung eines neuen benutzerdefinierten Feldes und Auswahl des Geschäftskontextes
Anschließend gab ich alle restlichen Details für mein neues Feld ein und klickte auf die Schaltfläche ‘Create and Edit’.
Details zur Erstellung eines benutzerdefinierten Feldes eingeben und bestätigen
Der Eintrag wurde dann vom System generiert, mit den unten gezeigten Details (beachten Sie, dass das Bild zeigt, dass ich es bereits veröffentlicht habe, aber es würde ‘Created’ anzeigen, wenn Sie das Feld noch nicht veröffentlicht haben).
Übersicht der Details eines neu erstellten benutzerdefinierten Feldes
Alles, was noch fehlte, war die Aktivierung der Verwendung dieses Feldes in meiner erwarteten Benutzeroberfläche und anschließend die Veröffentlichung.
Aktivierung des benutzerdefinierten Feldes für die Verwendung in der UI
Bestätigung der erfolgreichen Erstellung des benutzerdefinierten Feldes
Die benutzerdefinierte Logik implementieren
Der letzte Schritt meiner Implementierung bestand darin, den Code zu definieren, der zum Füllen meines benutzerdefinierten UUID-Feldes erforderlich ist und automatisch für alle neuen/geänderten Fertigungsaufträge ausgelöst werden sollte. Ich kehrte zu meinem Geschäftskontext im Extensibility Cockpit zurück und klickte auf die Schaltfläche ‘Create Enhancement Implementation’ für das BAdI, das bei der Erstellung und Änderung von Fertigungsaufträgen aufgerufen würde.
Erstellung einer BAdI-Erweiterungsimplementierung im Extensibility Cockpit
Da keine zuvor definierten Implementierungen vorhanden waren, wurde eine leere Liste in der Anwendung Custom Logic angezeigt. Ich konnte dann auf das ‘+’-Symbol klicken, um die Erstellung einer neuen Erweiterungsimplementierung zu starten.
Übersicht der Custom Logic App, bereit zur Erstellung einer neuen Implementierung
Ein Popup wurde geöffnet, das mir erlaubte, auszuwählen, welches BAdI ich implementieren wollte (als ersten Schritt). Die Integration von SAP-Systemen ist ein komplexes Feld, in dem Standards wie SAP OData V4 eine wichtige Rolle spielen können, selbst wenn sie hier nicht direkt angewendet werden.
Auswahl des zu implementierenden BAdI in der Custom Logic App
Und dann war der einzige weitere Eintrag, den ich eingeben musste, die Implementierungsbeschreibung, bevor ich auf die Schaltfläche ‘Create’ klickte.
Eingabe der Implementierungsbeschreibung für die Custom Logic
Nach diesem Schritt wird die Implementierung generiert und mit ihrem Standardcode gefüllt (was ich als sehr hilfreich empfand).
Standardcode einer neuen Custom Logic Implementierung in SAP Fiori
Ich änderte den Standardcode, um meinen spezifischen Zwecken zu dienen:
- Ich entfernte die
CHECK-Anweisung am Anfang, damit sowohl Auftragsneuanlagen als auch -änderungen meinen BAdI-Code ausführen würden. - Ich fügte eine Warnmeldung in das Trace-Protokoll für Situationen hinzu, in denen mein UUID-Wert während einer Auftragsänderung neu zugewiesen werden sollte.
- Ich fügte die Logik hinzu, die zum Generieren einer UUID und zum Speichern in das neue benutzerdefinierte Feld des Auftragsvorgangs erforderlich ist.
- Ich fügte eine Fehlermeldung in das Trace-Protokoll für den Ausnahmefall hinzu, wenn der UUID-Generator des Systems nicht ordnungsgemäß funktioniert.
- Ich fügte eine Informationsmeldung in das Trace-Protokoll hinzu, um anzuzeigen, dass mein BAdI seine Ausführung abgeschlossen hatte.
Anschließend klickte ich auf die Option ‘Save Draft’, gefolgt von der Option ‘Publish’.
Angepasster ABAP-Code für die Custom Logic zur UUID-Generierung und Veröffentlichung
Danach blieb nur noch das Testen übrig.
Das Verhalten überprüfen und validieren
Ich entschied mich für die Anwendung Custom Logic Tracing, da sie mir alle benötigten Informationen anzeigen konnte und ich bereits Trace-Log-Anweisungen in meinen Code eingefügt hatte. Mein Plan war, zwei Traces zu erstellen: einen für die Neuanlage eines Fertigungsauftrags und einen für die Änderung eines Fertigungsauftrags. Nachdem ich auf die Schaltfläche ‘Start Trace’ geklickt hatte, wurde ich nach einigen erforderlichen Informationen gefragt und klickte dann auf ‘Start’, wodurch der Trace für meinen Benutzer im Hintergrund für die nächsten 15 Minuten initiiert wurde.
Starten eines Traces für die Erstellung eines Fertigungsauftrags in Custom Logic Tracing
Anschließend ging ich zur Anwendung Create Production Order und kopierte einen bestehenden Auftrag.
Kopieren eines bestehenden Fertigungsauftrags in der App Create Production Order
…
Erfolgreiche Speicherung eines neuen Fertigungsauftrags
…
Bestätigung der Erstellung eines neuen Fertigungsauftrags
Nach der erfolgreichen Auftragsanlage beendete ich das Tracing, indem ich auf die Schaltfläche ‘Finish Trace’ klickte.
Beenden eines Traces nach der Erstellung eines Fertigungsauftrags
Das System beendete daraufhin das Tracing und veröffentlichte meine Trace-Datei zur Einsicht.
Anzeige der Trace-Datei nach Abschluss der Erstellung eines Fertigungsauftrags
Nachdem ich auf den Trace-Dateieintrag geklickt hatte, wurden die Inhalte der Datei (d.h. meine benutzerdefinierte Logik) angezeigt, einschließlich meiner Informationsmeldungen.
Inhalt der Trace-Datei für die Erstellung eines Fertigungsauftrags mit Log-Meldungen
Ich konnte auch die tatsächlichen Werte aller im BAdI verwendeten Parameter einsehen, wo ich feststellen konnte, dass meine Logik mein benutzerdefiniertes Feld erfolgreich mit einer UUID für jeden Auftragsvorgang gefüllt hatte.
Parameterwerte in der Trace-Datei, die die erfolgreiche UUID-Generierung zeigen
Also alles in Ordnung (bisher!). Die letzte verbleibende Überprüfung war, ob die Logik auch während der Änderungen von Fertigungsaufträgen ausgeführt wird. Ich startete einen weiteren benutzerdefinierten Logik-Trace. Bei komplexen technischen Herausforderungen ist es oft unerlässlich, detaillierte Traces zu analysieren.
Starten eines Traces für die Änderung eines Fertigungsauftrags
Ich rief meinen Auftrag über die Anwendung Manage Production Orders ab und klickte dann auf den Eintrag, um dessen Inhalte anzuzeigen.
Verwaltung von Fertigungsaufträgen in der App Manage Production Orders
Die Inhalte wurden angezeigt, und dann klickte ich auf die Schaltfläche ‘Edit Order’.
Bearbeiten eines Fertigungsauftrags aus der Übersicht in Manage Production Orders
Ich änderte das Start- und Enddatum des Auftrags und klickte dann auf die Schaltfläche ‘Save’.
Änderung der Daten eines Fertigungsauftrags und Speichern der Änderungen
Zu diesem Zeitpunkt blieb nur noch der Trace auf die gleiche Weise wie zuvor zu beenden, was dazu führte, dass die neue Trace-Datei in der Liste verfügbar war. Diesmal jedoch hat die Datei eine Schweregrad ‘Warning’.
Beenden des Traces nach einer Auftragsänderung mit einer Warnmeldung
Nachdem ich auf den Eintrag geklickt hatte, wurden die Inhalte wie erwartet angezeigt. Zusätzlich zu meiner Informationsmeldung erzeugte jeder Vorgang auch eine Warnmeldung, da bereits eine UUID in meinem benutzerdefinierten Feld vorhanden war (d.h., dies wurde durch die IF-Anweisung in meiner benutzerdefinierten Logik ausgelöst).
Anzeige der Trace-Inhalte für eine Auftragsänderung, inklusive Warnmeldungen
Und ich konnte sehen, dass tatsächlich neue UUIDs generiert wurden, als ich die Details der tatsächlichen Parameterwerte betrachtete.
Überprüfung der generierten UUID-Werte in den Trace-Details nach einer Auftragsänderung
Also ist wirklich alles in Ordnung!
Fazit und wichtige Erkenntnisse
Zusammenfassend konnte ich ein nützliches, freigegebenes ABAP-Artefakt identifizieren, ein geeignetes BAdI finden, ein benutzerdefiniertes Feld erstellen und dieses mithilfe eines benutzerdefinierten Codes befüllen, der dann automatisch in den Standardgeschäftsprozess integriert wurde. All dies wurde unter Verwendung der Tracing-Funktionalität überprüft, wobei ich mich ausschließlich auf SAP Fiori und seine Key User Extensibilität stützte. Nachdem ich die oben genannten Implementierungsschritte selbst durchgegangen war, blieben mir folgende Gedanken:
- Meine neue Lieblings-SAP-Fiori-Anwendung ist das Extensibility Cockpit.
- Ich schätze den einfachen Zugang zu detaillierter technischer Dokumentation für verfügbare Erweiterungen und/oder Klassen im Extensibility Cockpit bzw. in den Released ABAP Artifacts sehr.
- Das Tracing benutzerdefinierter Logik ist äußerst einfach durchzuführen.
Wenn Sie dieses Szenario ebenfalls nachvollziehen konnten, dann empfinden Sie hoffentlich ähnlich. In Zukunft hoffe ich, die Erweiterungsmöglichkeiten, wie die für Key User oder Entwickler, in den SAP S/4HANA Cloud Extensibility Community Blogs weiter auszuführen.
Weitere Ressourcen & Ausblick
Ich ermutige jeden, Fragen und/oder Antworten in der SAP S/4HANA Cloud Extensibility Community zu posten – eine wirklich großartige Ressource!
Bitte teilen Sie Ihre Gedanken oder geben Sie Feedback in den Kommentaren.
Vielen Dank für Ihre Zeit.