Modellieren mit dem BOPF

Von Jacques NomssiABAP Development, Allgemein

Business Object Processing Framework

Entwickler sind daran gewöhnt, Funktionen aus einer Library in Ihren Programmen aufzurufen. Im Gegensatz dazu implementieren Sie bei einem Framework Erweiterungen, die zu gegebenen Zeiten aufgerufen werden. Mit diesem Ansatz (Inversion of Control) verwalten Frameworks wie BOPF komplexe Aspekte einer Anwendung eigenständig.

Das Ergebnis ist zweischneidig: das BOPF ist mächtig und übernimmt sehr viele Aufgaben. Es schränkt jedoch mit starren Abläufen ein. Der Entwickler muss von vornherein dessen Arbeitsweise und Grenzen begreifen, um es effektiv einzusetzen.

Im Folgenden versuche ich, dem interessierten ABAP-Entwickler ein Verständnis für das BOPF vermitteln.

Was ist ein Business Object?

Ein Geschäftsobjekt (Business Object, BO) ist lediglich ein Baustein, eine Komponente in einer Anwendung, die technische Details der Anwendungslogik versteckt und in Begriffe aus der Welt der Anwender (Geschäftswelt) übersetzt.

Ein Objekt wird von Anwendungsentwickler als Abstraktion für eine Entität (Produkt, Route, Kunde, Auftrag, Bestellung, Reisekosten…) mit Zustand, eigener Identität und definiertem Verhalten. Bei einem gelungenen Design sprechen Anwender und Entwickler die gleiche Sprache.

Formal hat ein Business Object

  • eine Struktur im Sinne eines Datenmodells. Vergleichbar mit den Attributen einer ABAP Klasse sind beim BOPF die Knoten einer Baumstruktur.
  • ein Verhalten: Das BO kapselt die Geschäftslogik und stellt es den Verbrauchern als Dienst oder Protokoll zur Verfügung. In ABAP OO wäre das die öffentliche Schnittstelle einer Klasse.
  • eine Implementation: die Entwicklersicht, wo die Komplexität dem Verbraucher möglichst verborgen sein sollte, um Wiederverwendbarkeit zu erreichen.

Historie

Über die Jahre hat SAP hat mehrere BO Konzepte implementiert. Vorläufer waren BO im Workflow und die standardisierte Schnittstelle BAPI. CRM benutzt die Frameworks Business Object Layer (BOL) und Generic Interaction Layer(GenIL). Das Business Object Processing Framework (BOPF) wird seit Jahren in Produkten wie Supplier Relationship Management, Transport Management, Change Management, Supplier LifeCycle Management, Environment, Health and Safety, Quality Issue Management verwendet.

Seit Netweaver 7.31 können SAP Kunden mit der Komponente SAP_BS_FND (Business Suite Foundation) die alten BOPF Transaktionen /BOBF/CONF_UI, /BOBF/CUST_UI, /BOBF/TEST_UI nutzen. Allgemeinen freigegeben ist das BOPF ab Netweaver 7.40 Basis mit den neuen Transaktionen BOB, BOBX, BOBT und später das BOPF Eclipse Plug-In. CDS Views können BOPF Objekte generieren.

Die Cloud Version von ABAP enthält bereits die Weiterentwicklung von BOPF: BOs werden als Core Data Services modelliert.

Die BOPF Modellierung wurde in das RESTfull Programming Model (RAP) übernommen, mit einer nativen Unterstützung in der Programmiersprache ABAP mit der Entity Manipulation Language (EML, Create/Update/Delete Interface, Aktionen und Ermittlungen und zusätzlich Funktionen ohne Seiteneffekten) und Tools (Integration in Eclipse).

BOPF Architektur

BOPF_Architektur

Transaktion /BOBF/CONF_UI generiert zu jedem BO eine Visualisierung und Entwurfsdokument. Darin findet man diese Bild der BOPF Architektur:

Der Verbraucher (Consumer, z.B. die UI) nutzt Dienste aus dem Transaktionsschicht. Diese enthält den Transaktionsmanager, der Änderungen verwaltet, den Service Manager, mit dem BOs gelesen und Aktionen aufgerufen werden, und ein Konfigurationsmanager, der Meta-Daten auslesen kann. Dabei wird das BOPF Datenmodell verwendet, das zur Entwurfszeit gepflegt wurde.

Die BO Laufzeit führt die Dienste aus, d.h. Anwendung starten, bei Aufruf von Aktionen Objekt zu definierten Klassen instanziieren und deren Methoden aufrufen, Ergebnisse dem Verbraucher bereitstellen.

BOPF Meta Data Model

Sowie ABAP OO Klassen anbietet, um Daten und Routinen als Objekt zu modellieren, bietet BOPF ein Meta Model, um Geschäftsobjekte zu modellieren.https://archive.sap.com/documents/docs/DOC-45425

Das BOPF zwingt zur einer strikten Klassifizierung nach Verhalten (Eigenschaften, Validierung und Änderungen werden unterschiedlich definiert) um ein UI-unabhängiges Datenmodell zu erreichen.

Der BOPF Entwickler definiert das Verhalten seine BOs in ABAP Object Klassen, die nach dem Command Pattern eine vorgegebene Schnittstelle implementieren.

Command Pattern

Über ein Kommando kann ein Aufrufer eine Operation ausführen, ohne die konkrete Logik oder den Befehlsempfänger zu kennen. BOPF arbeitet mit GUID für die Aktionen, die über ein Konstanten-Definition zu lesbaren Namen umgesetzt werden. 

Falls der Verbraucher (z.B. die GUI) eine Aktion über das DO_ACTION Service aufruft, wird  das BO zur Laufzeit ein Objekt der Klasse zur Aktion anlegen und Ihre EXECUTE( ) Method ausführen, mit dem aktuellen BO Schlüsseln als Parameter.

Falls diese Aktion validiert werden muss, werden vorher die Validierung instanziiert und die EXECUTE( ) Methode ausgeführt. Die BOPF Laufzeit entscheidet aus dem Ergebnis ob die Aktion ausgeführt werden kann. Falls ja, wird das Ergebnis dem Verbraucher zur Verfügung gestellt.

Vor- und Nachteile

  • Die Einarbeitung kann langwierig werden falls Konzepte aus Design und Modellierung neu sind, vor allem wenn kein erfahrener Kollege im Team ist. Der Entwickler gibt die Kontrolle und damit Flexibilität an das Framework ab. Es bedarf ein Verständnis der BOPF Möglichkeiten, um möglich wenig selbst zu implementieren. 
  • Nach der Eingewöhnung die Entwicklungszeit reduziert und die Arbeit lässt sich besser parallelisieren. Hat man einmal ein Business Object in implementiert, dann kann man in fremden Programmen BOPF Verbraucher warten.
  • Es stehen sehr unterschiedliche BOPF Verbraucher zur Verfügung, sei es SAP GUI Reports oder Web Dynpro Anwendungen die mit dem Floor Plan Manager generiert werden BRF+ Business Rules oder UI5 Fiori Apps. Viele diese Verbraucher sind kein Teil der Toolbox des Durchschnitts-ABAP-Entwickler.

Ein Szenario wird oft besonders hervorgehoben: die Erstellung des Datenmodells mit  dem BOPF und das generieren der WebDynpro-Oberfläche mit dem Floor Plan Manager. Nach jeder Änderung kann man neu generieren und hat eine lauffähige Anwendung.

  • Beim BOPF ist auch das Transaktionsmanagement hervorzuheben: es gibt z.B. keine Überraschung mit implizite COMMITs, Sperren, Entsperren, Pufferverwaltung und sicheres Schreiben sind kein Problem. Es wird wahrscheinlich der Grund, warum dieses an sich alte Framework jetzt wieder in neuen Entwicklungen aufgenommen wird (CDS + BOPF, RAP).

Fortsetzung folgt…