Um es externen Systemen zu ersparen, jeweils eine eigene Datenpufferung zu definieren, sollten in allen schreibenden (d.h. erstellenden und verändernden) BAPIs vorgefertigte Pufferungsmechanismen implementiert werden.

SAP-intern gilt dies insbesondere für BAPIs ab Release 4.6A. Wenn Sie eine Pufferung für BAPIs auf einem früheren Releasestand implementieren möchten, sollten Sie zunächst mit einem BFA AG-Ansprechpartner Kontakt aufnehmen.

Für BAPIs können die allgemein im R/3-System gebräuchlichen Mechanismen zur Pufferung von Anwendungsdaten eingesetzt werden. Vom BAPI zu erstellende bzw. zu ändernde Daten werden dabei nicht im Puffer des Verbuchers angelegt, sondern zunächst im Puffer der BAPI-Funktionsbausteingruppe gesammelt. Anschließend wird der gesamte Pufferinhalt gemeinsam, zu einem gegebenen Zeitpunkt verbucht.

Dies hat folgende Vorteile:

• Performancegewinn für das Gesamtsystem

Folgende Graphik veranschaulicht zunächst das Transaktionsmodell für BAPIs ohne Pufferung.

Das Transaktionsmodell für BAPIs mit Pufferung ist in folgender Abbildung illustriert.

Für BAPIs mit Pufferung sind neben den geltenden Richtlinien zusätzliche Implementierungsschritte bzw. Eigenschaften erforderlich, die im folgenden im Detail beschrieben werden.

Da BAPIs mit Pufferung Instanzen ausschließlich im Puffer erstellen bzw. ändern, müssen Sie einen oder mehrere Funktionsbausteine für das abschließende Verbuchen des Pufferinhalts bereitstellen. Diese Verbuchungsbausteine übergeben den gesamten Pufferinhalt an den Verbucher.

Diese Funktionsbausteine sollten nicht als BAPIs implementiert werden, da diese nur in dem System verwendet werden, in dem auch der Puffer eingesetzt wird.

Als Namenskonvention für diese Funktionsbausteine wird
<Business-Objektname>_SAVEBUFFER vorgeschlagen.

Es dürfen keine Exceptions für Verbuchungsbausteine definiert sein, da diese erst am Ende der Transaktion durchlaufen werden, wenn keine Fehlerbehandlung mehr möglich ist (s.u. Besondere Eigenschaften).

Um sicherzustellen, daß zu Beginn einer Transaktion der Puffer leer ist, müssen Sie einen Funktionsbaustein für das Löschen des Pufferinhalts zur Verfügung stellen. Dieser Löschbaustein löscht den gesamten Pufferinhalt und beseitigt ggf. vorhandene Sperren der Instanzen. Auch diesen Funktionsbaustein sollten Sie nicht als BAPI implementieren, da er nur in dem System verwendet wird, in dem auch der Puffer eingesetzt wird.

Als Namenskonvention für diesen Funktionsbaustein wird
<Business-Objektname>_CLEARBUFFER vorgeschlagen.

Es dürfen keine Exceptions für Löschbausteine definiert sein, da diese erst am Ende der Transaktion durchlaufen werden, wenn keine Fehlerbehandlung mehr möglich ist (s. u. Besondere Eigenschaften).

BAPIs mit Pufferung müssen besondere Eigenschaften haben, um das erwünschte Pufferungsverhalten zu erzielen. Beispielsweise müssen diese BAPIs im Fehlerfall möglichst robust reagieren, da ein Aufrufer keine Nachbearbeitungen im Puffer durchführen kann. Da die Pufferung implizit erfolgt, stehen einem Aufrufer auch keine BAPIs zur Verwaltung des Puffers zur Verfügung.

Ein BAPI mit Pufferung muß - bis auf die Verbuchung - alle zur Abarbeitung notwendigen Schritte durchführen. Dabei muß die durch die Anwendung festgelegte Konsistenz aller Instanzen, die im Puffer erstellt oder verändert werden, gewährleistet sein.

Dies bedeutet:

• Nur Operationen, die unter Gewährleistung der Konsistenz verbucht werden können, dürfen im Puffer durchgeführt werden. Der Verbuchungsbaustein selbst kann keine Konsistenzprüfung durchführen.
• Alle weiteren, vor der Verbuchung benötigten Schritte wie z.B. Nummernvergabe oder Aufbau von Anwendungssperren, müssen vor Aufruf des Verbuchungsbausteins durchgeführt werden.
• Für Operationen, die nicht konsistent verbucht werden können, darf keine Aktion stattfinden. In diesen Fällen muß die Fehlersituation über den Parameter Return des BAPIs zurückgemeldet werden.

Rufen Sie nach erfolgreichem Abschluß der Pufferoperationen mit dem Kommando

PERFORM <routine> ON COMMIT

eine Formroutine <routine> auf, die ihrerseits den oder die Verbuchungsbaustein(e) aufruft.

Die Verbuchungsbausteine müssen über das Kommando

CALL <Business-Objektname>_SAVEBUFFER IN UPDATE TASK

gerufen werden, um die Ausführung in der Verbuchung zu kennzeichnen.

Durch den Zusatz 'ON COMMIT' im Kommando PERFORM <routine> ON COMMIT wird erreicht, daß die Verbuchung nicht sofort, sondern erst beim nächsten COMMIT WORK-Kommando durchgeführt wird. Auf diese Weise können beliebig viele BAPI-Aufrufe gebündelt werden. Das abschließende COMMIT WORK-Kommando, das vom Aufrufer über das BAPI BapiService.TransactionCommit() durchgeführt wird, führt die Formroutine und damit auch die Verbuchungsbausteine jeweils genau einmal aus. Aus diesem Grund kann in dieser Formroutine und im Verbuchungsbaustein keine Fehlerbehandlung mehr stattfinden.

Zu Beginn jeder LUW muß der Puffer leer sein. Eventuell im Puffer vorhandene Instanzen, die in einer vorangegangenen LUW bereits verbucht wurden, sind nicht mehr gesperrt und können gegenüber dem Stand auf der Datenbank veraltet sein. Eine erneute Verbuchung dieser Instanzen würde zu Inkonsistenzen führen.

Zum Ende jeder LUW muß demnach der Pufferinhalt durch den Aufruf des Löschbausteins gelöscht werden. Dies kann nur von den BAPIs BapiService.TransactionCommit() bzw. BapiService.TransactionRollback() durchgeführt werden. Um diesen BAPIs die hierzu benötigte Informationen bereitzustellen, müssen BAPIs mit Pufferung ihren Löschbaustein bei dem BAPI BapiService.TransactionCommit() bzw. BapiService.TransactionRollback() subskribieren.

Diese Subskription erfolgt durch den Aufruf des zentralen Funktionsbausteins BUFFER_SUBSCRIBE_FOR_REFRESH, wobei im Parameter NAME_OF_DELETEFUNC der Name des Löschbausteins mitgegeben werden muß.

BAPIs mit Pufferung dürfen kein COMMIT WORK bzw. ROLLBACK WORK durchführen.

Jedes BAPI mit Pufferung muß explizit als solches dokumentiert werden.

Sind an einem Business-Objekttyp schreibende BAPIs mit Pufferung implementiert, dürfen lesende BAPIs am gleichen Business-Objekttyp den Puffer nicht verwenden, um von der Datenbank gelesene Daten abzulegen und auf diese Weise weitere Datenbankzugriffe einzusparen.

Da die gelesenen Daten nicht gesperrt sind, würden die entsprechenden Pufferinhalte mit der Zeit veralten. Nachfolgende Leseoperationen würden zuerst auf den Puffer zugreifen und somit die potentiell veralteten Daten lesen, da nur auf der Datenbank nachgelesen wird, wenn sich die zu lesenden Daten nicht im Puffer befinden.

Alle durch schreibende BAPIs im Puffer erstellten oder veränderten Instanzen sind konsistent. Sie stehen anderen verändernden BAPIs zur weiteren Bearbeitung innerhalb derselben LUW zur Verfügung.

Um ein durchgängig analoges Verhalten zu gewährleisten, müssen auch alle lesenden BAPIs die im Puffer, jedoch noch nicht auf der Datenbank, vorhandenen Instanzen als gültige Instanzen betrachten. Lesende BAPIs müssen demnach so implementiert werden, daß sie zunächst versuchen, eine Instanz im Puffer zu lesen und nur wenn diese dort nicht vorhanden ist, in der Datenbank weitersuchen.

Eine Pufferinstanz ist also eine "echte" Instanz, d.h. beispielsweise muß ein BAPI ExistenceCheck() auch im Puffer nach dem Vorhandensein einer Instanz suchen.

Jedes lesende BAPI, das die Pufferung korrespondierender, schreibender Methoden berücksichtigt, muß entsprechend dokumentiert werden.