Praxishandbuch BOPF – Business Object Processing Framework. Das neue SAP S/4HANA-Programmiermodell

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

Praxishandbuch BOPF – Business Object Processing Framework. Das neue SAP S/4HANA-Programmiermodell

Praxishandbuch BOPF - das Business Object Processing Framework im neuen SAP S/4HANA-Programmiermodell
  • 204 Seiten - 28.02.2019 (Veröffentlichungsdatum) - Espresso Tutorials (Herausgeber)

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.

Einführung in BOPF

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.

Was ist BOPF?

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.

BOPF im ABAP-Programmiermodell für SAP Fiori

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.

Praxishandbuch BOPF - Business Object Processing Framework - Programmiermodell
Abbildung 1.1: ABAP-Programmiermodell für SAP Fiori

Ein Geschäftsobjekt modellieren

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.

Das Beispiel: Kundenrechnung

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.

Praxishandbuch BOPF - Business Object Processing Framework - Beispielprozess
Abbildung 2.1: Einordnung des zu erstellenden Geschäftsobjekts in den Beispielprozess

Das Geschäftsobjekt anlegen

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:

  • BOB – dient dem vereinfachten Anlegen von Geschäftsobjekten über eine Schritt-für-Schritt-Prozedur. Diese ist veraltet und bringt gegenüber dem Prozess, den wir nachfolgend durchführen werden, keinen Vorteil.
  • BOBF – nur für SAP-interne Verwendung gedacht. Darin sind noch veraltete Funktionalitäten und viele Optionen enthalten, die beim normalen Einsatz von Geschäftsobjekten nicht benötigt werden.
  • BOBX – das ist die aktuelle und für Kunden empfohlene Transaktion für die Arbeit mit Geschäftsobjekten. Über die BOBX werden die wichtigsten Funktionen gefiltert zur Verfügung gestellt.

Aufbau eines Geschäftsobjekts

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).

Praxishandbuch BOPF - Business Object Processing Framework- Detailansicht
Abbildung 2.4: Detailansicht von ZKR_KUNDENRECHNUNG

Transaktions- & Servicemanagement

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.

Praxishandbuch BOPF - Business Object Processing Framework - Anwendung
Abbildung 3.1: Anwendungsschichten in Verbindung mit BOPF

Transaktionsmanager

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( ).

Servicemanager

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 ).

Geschäftsobjekt-Entitäten

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.

Praxishandbuch BOPF - Business Object Processing Framework - Meta Modell
Abbildung 4.1: Meta-Modell eines Geschäftsobjekts (Quelle: SAP SE, »Business Object Metadata Model« unter: https://bit.ly/2Qyh3M0 (aufgerufen am 08.01.2019).)

 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.

»Library«-Funktionen des BOPF

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.

Ermittlung von Verwaltungsdaten

Als »Verwaltungsdaten« bezeichne ich nachfolgend

  • einen Zeitstempel für die Erstellung des Datensatzes,
  • den Benutzernamen des Erstellers,
  • einen Zeitstempel von der letzten Änderung des Datensatzes,
  • den Benutzernamen des letzten Änderers.

Validierung von Alternativschlüsseln

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

  • mehrere Datensätze mit dem gleichen Alternativschlüssel anlegen konnten (bei nicht-eindeutigem DB-Index) oder
  • bei dem Versuch, einen zweiten Datensatz mit demselben Schlüssel anzulegen, einen Kurzdump erhalten (bei eindeutigem DB-Index).

Beide Verhaltensweisen sind für eine produktive Anwendung unerwünscht. Sie erzeugen entweder Inkonsistenzen im Datenmodell oder nicht nachvollziehbare Programmabbrüche.

Validierung von Pflichtfeldern

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.

Testen & Fehleranalyse

Ä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.

Die BOPF-Testumgebung

Praxishandbuch BOPF - Business Object Processing Framework - Testumgebung
Abbildung 6.1: Die BOPF-Testumgebung
  1. Auswahl des zu testenden Geschäftsobjekts,
  2. Aktionsleiste,
  3. selektierte Knoteninstanzen,
  4. Interaktion mit Knoteninstanzen selektierter Daten,
  5. Detailsicht zur Knoteninstanz.

Fehlersuche & -analyse

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.

Implementierungs-Beispiele

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.

Weiterführende Themen

Zu Beginn des Buches habe ich sinngemäß bereits folgende Aspekte zu BOPF angesprochen:

  • Es gibt die Möglichkeit, Geschäftsobjekte in den ABAP Development Tools für Eclipse zu entwickeln.
  • Zum Framework selbst gibt es von der SAP bereitgestellte Integrationen, um BOPF mit anderen Technologien schnell und effizient einsetzen zu können.
  • BOPF spielt eine zentrale Rolle im SAP Fiori Development Model.

Zu diesen drei Aussagen möchte ich Ihnen erste Ansätze liefern, anhand derer Sie sich weiter in die Themen einarbeiten können.

Fazit/Ausblick

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«.

Praxishandbuch BOPF - Business Object Processing Framework. Das neue SAP S/4HANA-Programmiermodell 29,95 €
  • Anfänger
  • Fortgeschrittene
  • Experte
4.5

Das erwartet Sie:

Praxishandbuch BOPF – Business Object Processing FrameworkSeiten: 204 – Sprache: de

Lernen Sie SAP BOPF kennen und sehen Sie, wie ein Geschäftsobjekt erstellt wird.

  • effektiv: in 15 Minuten zum funktionierenden Datenmodell
  •  einfach: neue Funktionen gezielt und schnell ergänzen oder erweitern
  •  stabil: Konsistenz durch automatische Validierungen und Berechtigungsprüfungen