BOPF – Business Objects Processing Framework

BOPF (Business Objects Processing Framework) ist ein Framework für die Programmierung und Modellierung von SAP Business Objects. Es vereinfacht, standardisiert und beschleunigt Entwicklung und Wartung.

Was ist BOPF im Detail?

BOPF ist ein vollständig in ABAP OO entwickeltes Framework, das eine einheitliche Architektur und Struktur für die Entwicklung von Geschäftsobjekten (Business Objects) in ABAP bietet.

Es stellt im Standard eine Reihe von Services und Funktionalitäten zur Verfügung, die Entwickler sonst häufig manuell programmieren müssen:

  • CRUD-Operationen auf ein Datenmodell
  • Pufferung von der Datenbank bereits gelesener Datensätze
  • Transaktionsmanagement, um Daten nach dem „Alles-oder-Nichts“-Prinzip entweder zu speichern oder die Änderungen zu verwerfen
  • Berechtigungsprüfungen auf allgemeine Zugriffs- und datenbezogene Lese- und Bearbeitungsrechte eines Benutzers
  • Steuerung von Sichtbarkeiten einzelner Funktionen in Richtung der Verwender
  • U.v.m.

Für die Zugriffe auf die mit BOPF modellierten Geschäftsobjekte werden vordefinierte Schnittstellen über sogenannte Service Manager bereitgestellt, die nach dem Entwurfsmuster „Kommando“ implementiert sind und dadurch für alle Geschäftsobjekte funktionieren.

Für folgende Komponenten müssen keine Adapter oder Integrationen entwickelt werden:

  • Gateway (OData)
  • Business Object Layer & GenIL
  • Post Processing Framework
  • Archive Development Kit
  • Change Documents (Änderungsdokumente)
  • Business Application Log (BAL)
  • Enterprise Search
  • Business Rule Framework Plus (BRF+)
BOPF

Abbildung 1: BOPF bietet eine Reihe vordefinierter Schnittstellen

Voraussetzungen

BOPF wurde von der SAP viele Jahre intern für die Entwicklung von Geschäftsanwendungen verwendet. 2013 wurde es auch für Kunden veröffentlicht. Ab SAP Netweaver Application Server 7.4 ist es im System integriert und kann kostenfrei von Kunden genutzt werden. Es müssen keine gesonderten Lizenzen erworben oder weitere technische Voraussetzungen erfüllt werden.

Für eine erfolgreiche Anwendung benötigen Entwickler allerdings solide Kenntnis objektorientierter Konzepte, zum Beispiel bezüglich Interfaces und Vererbung.

Grundprinzipien

BOPF liegen einige zentrale Entwicklungsparadigmen zugrunde, deren Einhaltung durch das Framework sichergestellt werden:

  1. Der Zugriff auf die zentralen Services des Geschäftsobjekts darf nur über bereitgestellte Schnittstellen möglich sein.
  2. Es besteht eine klare Trennung zwischen prüfender und ändernder Geschäftslogik.
  3. Es besteht eine klare Trennung zwischen Geschäftslogik und Datenpuffer.
  4. Es besteht eine klare Trennung zwischen Datenpufferung und Datenbank.

Die vier Paradigmen stellen sicher, dass ein Geschäftsobjekt nach dem initialen Aufbau leicht erweitert und angepasst werden kann, da jede Funktion in sich klar abgegrenzt ist und nur genau einen Zweck erfüllt.

Aufbau eines Geschäftsobjekts in BOPF

Ein Geschäftsobjekt besteht aus einer Baumstruktur von Knoten, die Entwickler in BOPF in der Transaktion BOBX modellieren:

BOPF

Abbildung 2: Einstiegsbild der Transaktion BOBX

Jedes Business Object verfügt über einen Root-Knoten und beliebig viele Unterknoten, die jeweils wieder Unterknoten haben können.

Anwendungsbeispiel Lieferbeleg: Das Geschäftsobjekt Lieferbeleg würde aus einem Root-Knoten „Belegkopf“ und diversen „Belegpositionen“ als Unterknoten bestehen. Beide Knoten wären mit einer Datenbanktabelle verknüpft (LIKP für Belegkopf und LIPS für Belegpositionen), die als Datenquelle dienen.

Um Funktionen im Geschäftsobjekt bereitzustellen, können in jedem Knoten, egal ob Root-Knoten oder Unterknoten, folgende Komponenten (Entitäten) genutzt werden:

BOPF

Abbildung 3: Aufbau eines Geschäftsobjekts

  • Attribute = Struktur und damit Felder der Daten, die zur Laufzeit von diesem Knoten bereitgestellt werden
  • Alternativschlüssel (Alternative Key) = Schlüsselkombinationen für einen optimierten Zugriff auf die Daten, vergleichbar mit Primärschlüsseln oder Indizes einer Datenbank
  • Assoziationen (Association) = Beziehungen zwischen Knoten innerhalb eines Geschäftsobjekts oder zwischen verschiedenen Geschäftsobjekten
  • Authorization Check = Berechtigungsprüfungen, die bei Lese- oder Schreibzugriffen automatisiert durchlaufen werden
  • Query = Abfragen für lesende Datenzugriffe auf einen Knoten
  • Validierungen (Validation) = Automatische Prüfungen auf die Daten des Knotens, die vom Framework zu bestimmten Zeitpunkten im Ablauf durchlaufen und von außen nicht übersteuert werden können
  • Ermittlungen (Determination) = Automatische Ergänzung von Daten, die vom Framework zu bestimmten Zeitpunkten im Ablauf durchlaufen und von außen nicht übersteuert werden können
  • Aktionen (Action) = Für das Geschäftsobjekt bereitgestellte Funktionen, die von einem das Objekt verwendenden Programm aufgerufen werden können. Aktionen werden nie automatisch durchlaufen.
E-Book: SAP HANA

Das E-Book ermöglicht Ihnen einen leichten Einstieg in das Thema SAP HANA und lichtet den Nebel um das Begriffswirrwarr.

Vorteile

Die Anwendung von BOPF führt zu einer signifikanten Kosten- und Zeitersparnis in der Entwicklung und Wartung von Geschäftsanwendungen. Gleichzeitig führt die Vereinheitlichung der Architektur zu einer größeren Personenunabhängigkeit und ermöglicht ein schnelleres Onboarding neuer Entwickler, was sich wiederum positiv auf die Effizienz auswirkt.

  1. Einfache Datenmodelle sind inklusive CRUD-Operationen, Sperren und Pufferung innerhalb weniger Minuten einsatzbereit – ohne, dass eine einzige Zeile Code geschrieben werden muss.
  2. Viele vorgefertigte Integrationen in andere Technologien wie Floorplan Manager (FPM), BRF+ und Gateway Services (OData) werden mitgeliefert und senken die Total Cost of Development.
  3. Die zentrale Verwaltung der Geschäftsobjekte und die Verwendung einheitlicher Schnittstellen macht eine Wiederverwendung sehr einfach.
  4. Die starke Kapselung einzelner Funktionen innerhalb eines Geschäftsobjekts ermöglicht einfache Erweiterbarkeit und Wartung.
  5. Integriertes Transaktionsmanagement nach dem Alles-oder-nichts-Prinzip – BOPF sorgt dafür, dass entweder alle oder keine Änderungen auf der Datenbank gespeichert werden und nicht wie bei Dynpro-Anwendungen implizit gespeicherte Änderungen nicht in die Datenbank übernommen werden.
  6. Die Integration in das ABAP Development Model für SAP Fiori beschleunigt auch die Entwicklung von Fiori Apps. Über Annotationen an ABAP CDS Views können automatisch BOPF-Geschäftsobjekte generiert werden, auf deren Basis das System dann ODATA Services bereitstellt.
  7. Bei konsequenter Verwendung von BOPF entsteht unternehmensweit eine einheitliche Anwendungsarchitektur, die die Verständigung der Entwickler und ihren flexiblen Einsatz erleichtert.
BOPF

Abbildung 4: BOPF ist in das SAP Development Model for SAP Fiori integriert

Nachteile

BOPF ist ein relativ komplexes Framework, das den anwendenden Entwicklern ein hohes Kompetenzniveau abverlangt. Sie sollten über ein gutes Verständnis von Normalisierung, Modellierung und Abstraktion verfügen sowie über fundierte Kenntnisse in ABAP OO.

Die Vorteile von BOPF lassen sich nur ausspielen, wenn Entwickler die vorgesehenen Standardwege kennen und einhalten.

Bei großen Anwendungen bzw. Datenmengen kann die integrierte Pufferung von BOPF zudem zu Performance- oder Speicherengpässen führen, für deren Behandlung Detailwissen notwendig ist.

Praxisrelevanz und Ausblick

BOPF ist ein leistungsstarkes Framework für die Anwendungsentwicklung in Unternehmen, die den SAP Netweaver zwischen 7.31 und 7.51 nutzen. Es beschleunigt die Abbildung von Standardfunktionalitäten, sodass mehr Zeit für das Wesentliche, die Entwicklung der Geschäftslogik, bleibt. In Kombination mit dem Floorplan Manager (FPM) führt BOPF auch zu spürbaren Zeitersparnissen in der UI-Entwicklung.

Trotz der potenziell hohen Kostenvorteile ist BOPF allerdings relativ unbekannt geblieben und wird nur in wenigen Unternehmen eingesetzt.

In Zukunft wird BOPF an Bedeutung verlieren. Für Kunden, die in absehbarer Zeit auf SAP Netweaver 7.53 wechseln oder die ABAP Platform auf der SCP zur Entwicklung nutzen wollen, ist BOPF eine Investitionsentscheidung: Es ist nach wie vor ein sehr hilfreiches Framework, fällt aber aus dem „ABAP RESTful Programming Model“ als feste Komponente heraus. Das Geschäftsobjekt-Prinzip wird ab SAP Netweaver 7.53 statt mit BOPF durch die sogenannte Behavior Definition Language realisiert. SAP hat allerdings eine Migrationsfunktion für bestehende BOPF-Geschäftsobjekte angekündigt, sodass diese in die Behavior Definition Language übernommen werden können.


Das könnte Sie auch interessieren:


Schreiben Sie einen Kommentar

Bitte füllen Sie alle mit * gekennzeichneten Felder aus. Ihre E-Mail Adresse wird nicht veröffentlicht.





Angebot anfordern
Preisliste herunterladen
Expert Session
Support