ABAP, Eclipse, HANA
Obwohl das Business Object Processing Framework der SAP schon seit mehreren Jahren für Kunden zur Verfügung steht, ist es für viele ABAP-Entwickler – und erst recht für viele Berater – ein unbeschriebenes Blatt. Einige kennen die Abkürzung BOPF, ohne dessen Bedeutung zu erfassen. Andere schreckt die vermeintliche Komplexität davon ab, es einzusetzen
Aus diesem Grund, und auch, weil ich BOPF für überaus hilfreich und durchaus erlernbar halte, habe ich mich dazu entschieden, ABAP-Entwicklern mit diesem Buch einen praktischen Einstieg in das Thema zu ermöglichen.
Nach einer kurzen Erläuterung der Beweggründe, warum das BOPF geschaffen wurde, lernen Sie direkt dessen Relevanz mit Blick auf das neue ERP-System SAP S/4HANA im ABAP-Programmiermodell für SAP Fiori kennen.
Das Konstrukt der »Geschäftsobjekte« ist im Umfeld von SAP nicht neu. Viele Entwickler kennen diese Objekte, erreichbar etwa über die Transaktion SWO3. Mit dem Business Object Processing Framework (kurz BOPF) wird dieses Konzept durch ein technisch aktuelles Framework mit großem Funktionsumfang unterstützt – etwa für ausführbare Aktionen, aber auch zur Archivierung, Änderungsprotokollierung u. v. m.
Frameworks sind in der Softwareentwicklung weitverbreitet. In Form eines Programmiergerüsts bieten sie feste Abläufe und stellen Schnittstellen bereit, die der Entwickler implementieren und registrieren muss. Das Framework steuert die Zugriffe auf die Funktionen und gibt einen Rahmen für die Anwendungsarchitektur vor.
Das Business Object Processing Framework wurde ursprünglich aus SAP-internen Anforderungen heraus entwickelt. Man benötigte ein Gerüst, das im Vergleich zu den klassischen Geschäftsobjekten einen gesteigerten Funktionsumfang besitzt und gleichzeitig für verschiedenste Anwendungen flexibel einsetzbar ist.
Mit BOPF wurde vor einigen Jahren ein solches Framework auf Basis von ABAP Objects erschaffen und 2013 schließlich auch für SAP-Kunden freigegeben. Es ist in der Softwarekomponente SAP_BS_FND angesiedelt und kann daher nicht auf einem reinen SAP-NetWeaver-Applikationsserver genutzt werden. Wie jedes Framework dient auch BOPF dazu, einem Anwendungsentwickler wiederkehrende Aufgaben bei der Programmierung abzunehmen.
Seit einiger Zeit steht es fest: Das bekannte SAP ERP wird mittelfristig durch die neue ERP-Suite SAP S/4HANA abgelöst. Technisch basiert diese auf einem SAP-NetWeaver-System mit darunterliegender HANA-Datenbank. Als Oberflächentechnologie wird SAPUI5 eingesetzt.
In Abbildung 1.1 sehen Sie die Darstellung des ABAP-Programmiermodells für SAP Fiori (engl.: ABAP programming model for SAP Fiori), wie es in der aktuellen Roadmap für den SAP NetWeaver Application Server for ABAP abgebildet ist.
Bevor eine theoretische Einleitung Verwirrung stiftet und ein zu abstraktes Bild des BOPF zeichnet, starten wir direkt in die Praxis und erstellen gemeinsam Schritt für Schritt unser erstes Geschäftsobjekt.
Um Stück für Stück ein Verständnis für die Arbeit mit und die Nutzung von Geschäftsobjekten (engl.: Business Objects, kurz BO) zu schaffen, baut das gesamte Buch auf einem durchgehenden Beispiel auf. Dieses ist bewusst aus dem Alltag eines x-beliebigen Menschen genommen, damit Sie keine modulspezifischen SAP-Kenntnisse mitbringen müssen.
Für die Verwaltung und Bearbeitung von Geschäftsobjekten stehen in SAP BOPF theoretisch mehrere Transaktionen zur Verfügung. Ich möchte diese kurz nennen, auch wenn wir uns nachfolgend nur in der Transaktion BOBX bewegen werden:
Ausgehend von der Detailansicht eines Geschäftsobjekts (siehe Abbildung 2.4), sind zwei Bildbereiche zu unterscheiden:
1 zeigt den Übersichtsbaum der Elemente zum Geschäftsobjekt. Der oberste Knoten ist das eigentliche Geschäftsobjekt. Ein Doppelklick darauf öffnet die an diesem Knoten hinterlegten Informationen (2).
Als Framework bietet BOPF neben der Modellierung von Datenmodellen vielfältige weitere Unterstützung. Es erleichtert (über vorgegebene Schnittstellen) das Zugreifen auf die Knoteninstanzen, deren Pufferung oder Sperrung und selbst das Navigieren zwischen verschiedenen Instanzen. Auch die Steuerung aller Änderungen sowie des Puffers übernimmt BOPF.
In einer Anwendung gibt es in der Regel nur wenige Zugriffe auf den Transaktionsmanager. Es ist dennoch wichtig, sich grob über die dahinterliegenden Abläufe im Klaren zu sein. Dadurch fällt es Ihnen leichter, Abbrüche oder unerwartete Verhaltensweisen bei der Arbeit mit BOPF zu verstehen und die Ursachen zu finden.
Ein Transaktionsmanager wird gegen das Interface /BOBF/IF_TRA_TRANSACTION_MGR typisiert (Listing 3.1). Über die Factory-Klasse /BOBF/CL_TRA_TRANS_MGR_FACTORY holen Sie sich die gültige Instanz für Ihre Session. Vermeiden Sie eine Instanziierung des Objekts direkt über eine Klasse.
DATA lo_transaction_manager TYPE REF TO /bobf/if_tra_transaction_mgr. lo_transaction_manager = /bobf/cl_tra_trans_mgr_factory=>get_transaction_manager( ).
Als zentralen Zugriffspunkt für die Interaktion mit Geschäftsobjekten nutzen Sie ständig einen Servicemanager. Pro Geschäftsobjekt benötigen Sie eine eigene Instanz. Über die Factory-Klasse /bobf/cl_tra_serv_mgr_factory können Sie sich den richtigen Servicemanager zu Ihrem Geschäftsobjekt geben lassen (Listing 3.2):
DATA lo_service_manager_kr TYPE REF TO /bobf/if_tra_service_manager.
lo_service_manager_kr = /bobf/cl_tra_serv_mgr_factory=>get_service_manager( iv_bo_key = zif_kr_kundenrechnung_c=>sc_bo_key ).
Klassen bestehen in der Objektorientierung vereinfacht ausgedrückt aus Attributen und Methoden, die in Sichtbarkeitsbereiche eingeteilt werden: public, protected oder private. Auch ein Geschäftsobjekt besitzt ein solches Meta-Modell, das die zur Verfügung stehenden Entitäten beschreibt.
Bei der Implementierung eines Geschäftsobjekts steht der Entwickler vor der Entscheidung, welche Funktionalität er wie in das Objekt integriert.
Alle dargestellten Entitäten mit Ausnahme des Business Objects (= Geschäftsobjekts) der Nodes (= Knoten) werden in diesem Kapitel ausführlich vorgestellt. Außerdem werde ich für jede Entität eine Beispiel-Implementierung durchführen.
Es gibt Funktionen, die in vielen Geschäftsobjekten benötigt werden; etwa bestimmte technische Prüfungen oder das Schreiben von Daten wie dem Erstellungsdatum und Ersteller. Einige dieser hilfreichen Funktionen werden von der SAP in den sogenannten »Library-Klassen« ausgeliefert.
Library-Klassen können Sie daran erkennen, dass ihre Namen mit /BOBF/CL_LIB* beginnen. Sie werden im Entwicklungspaket /BOBF/LIBRARY gesammelt. Darunter finden Sie u.a. auch die Klasse /BOBF/CL_LIB_AUTHCHECK_W_QUERY, der Sie im Rahmen der Berechtigungsprüfungen in Abschnitt 4.8.2 bereits begegnet sind.
Als »Verwaltungsdaten« bezeichne ich nachfolgend
In Abschnitt 4.5 haben Sie Alternativschlüssel als fachliche Schlüssel am Knoten kennengelernt und eingerichtet. Dabei haben Sie auch festgelegt, ob dieser eindeutig ist oder nicht. Für die Eindeutigkeit gab es mehrere Auswahlmöglichkeiten, wie z.B. »eindeutig, wenn nicht initial«.
Falls Sie es bereits ausprobiert haben, ist Ihnen sicher aufgefallen, dass Sie abhängig von Ihren Einstellungen am Datenbankindex entweder
Beide Verhaltensweisen sind für eine produktive Anwendung unerwünscht. Sie erzeugen entweder Inkonsistenzen im Datenmodell oder nicht nachvollziehbare Programmabbrüche.
Als statische Eigenschaften eines Knotens können Sie Attribute als »obligatorisch« definieren. Wie in Abschnitt 4.9 beschrieben, führt das Framework keine impliziten Prüfungen auf diese Eigenschaft durch. Dennoch ist es für die Konsistenz des Datensatzes wichtig, dass alle Pflichtfelder bei der Erstellung neuer Knoteninstanzen gefüllt sind.
Als Library-Klasse steht für diese Überprüfung der Datensatzattribute /BOBF/CL_LIB_V_MANDATORY_ATTR zur Verfügung. Das mittlere »_V_« verweist darauf, dass es eine Validierungsklasse ist. Es ist möglich, dass Sie für diesen Zweck eine Aktions- oder eine Konsistenzvalidierung erstellen.
Ähnlich wie bei Dynpros ist auch die Analyse von Fehlersituationen in auf BOPF basierenden Anwendungen und Datenmodellen zu Beginn ungewohnt und mag Ihnen vielleicht umständlich erscheinen. Um Ihnen den Einstieg zu erleichtern, zeige ich Ihnen meine üblichen Ansatzpunkte für eine Ursachenanalyse von Fehlern und Abbrüchen.
Durch den Einsatz eines funktionsstarken Frameworks wie BOPF wird die Fehleranalyse nicht einfacher, denn die Zahl der zunächst einmal unbekannten Fehlerquellen ist hoch.
Obwohl es auf den ersten Blick anders aussehen kann, sind 99 % aller Fehlerursachen in Ihrem Einflussbereich zu suchen. Dazu gehören die Einstellungen am Geschäftsobjekt und dessen Entitäten, die implementierenden Klassen wie auch die Aufrufe des Service- oder Transaktionsmanagers durch Ihre Anwendungen.
Um Ihre eigenen implementierenden Klassen über den Debugger zu analysieren, setzen Sie einen externen Breakpoint an den gewünschten Punkt der implementierten Methode. Ich persönlich nutze immer externe Breakpoints, da diese im Gegensatz zu Session-Breakpoints in Kombination mit Klassen zuverlässig funktionieren. Beachten Sie dabei jedoch die Gültigkeitsdauer der Breakpoints und erneuern Sie diese ggf. im Testverlauf.
In diesem Kapitel verbinden wir das Framework mit einer Anwendung, die auf Ihr Geschäftsobjekt zugreift. Denn um schlussendlich mit BOPF arbeiten zu können, benötigen Sie noch Anwendungsbausteine, die über die Schnittstellen des Servicemanagers ein Geschäftsobjekt ansprechen: die sogenannten »Verwender«.
Ich möchte Ihnen in diesem Kapitel den Einsatz eines Geschäftsobjekts in einem ABAP-Programm zeigen. Das ist nach meiner Erfahrung aus Schulungen und Coachings das letzte noch fehlende Puzzleteil, um die Theorie mit der Praxis zu verbinden.
Zu Beginn des Buches habe ich sinngemäß bereits folgende Aspekte zu BOPF angesprochen:
Zu diesen drei Aussagen möchte ich Ihnen erste Ansätze liefern, anhand derer Sie sich weiter in die Themen einarbeiten können.
Es ist geschafft – Sie haben den Grundstein für eine Nutzung des BOPF in Ihrer ABAP-Entwicklung gelegt. Mit BOPF als Entwicklungsframework erreichen Sie im Vergleich zu herkömmlichen Eigenentwicklungen ein neues Level der Modularisierung. Und nicht zuletzt gehen Sie damit einen Schritt in Richtung »ABAP-Entwicklung unter S/4HANA«.
[wp-review id="154"]
Obwohl das Business Object Processing Framework der SAP schon seit mehreren Jahren für Kunden zur Verfügung steht, ist es für viele ABAP-Entwickler – und erst recht für viele Berater – ein unbeschriebenes Blatt.
Themen: ABAP, Eclipse, HANA
