Business Object Provider API: BEHAVIOR

Die Business Object Provider API: BEHAVIOR ist die Schnittstelle, mit der ein RAP-Business Object sein Verhalten definiert. Sie beschreibt, wie sich die Entitäten verhalten, also welche Aktionen, Lese- oder Schreiboperationen möglich sind.


Behavior Definition

Das Behavior Definition legt fest, welche Interaktionen erlaubt sind und wie sie verarbeitet werden. Dazu gehören etwa Standardoperationen wie create, update, delete sowie eigene Aktionen und Validierungen. Die Implementierung erfolgt in Behavior-Handler-Klassen, die auf CL_ABAP_BEHAVIOR_HANDLER und CL_ABAP_BEHAVIOR_SAVER basieren.

CL_ABAP_BEHAVIOR_HANDLER

Die Klasse CL_ABAP_BEHAVIOR_HANDLER ist die Basisklasse für alle Behavior-Handler im RAP. Sie wird genutzt, um Geschäftslogik für Interaktionen wie Aktionen, Validierungen oder Autorisierungen zu implementieren. Von ihr leiten die spezifischen lokalen Handler-Klassen ab, die im Behavior-Pool definiert sind. Jede Methode im Handler verarbeitet Anfragen, die aus der Behavior Definition abgeleitet werden. Damit bildet sie das Fundament für die Umsetzung der Interaktionslogik in RAP.

CL_ABAP_BEHAVIOR_SAVER

Die Klasse CL_ABAP_BEHAVIOR_SAVER ist die Basisklasse für alle Saver im RAP. Sie wird verwendet, um Datenänderungen aus den Behavior-Operationen dauerhaft in der Datenbank zu speichern. Von ihr leiten die lokalen Saver-Klassen ab, die im Behavior-Pool implementiert werden. Typische Aufgaben sind das Verarbeiten von `create`, `update` und `delete`-Operationen. Damit stellt sie sicher, dass die im RAP ausgeführten Änderungen konsistent und dauerhaft übernommen werden.

Tipp: Lokale Klassen

In Eclipse ADT siehst du bei globalen Klassen einen eigenen Objektreiter, der die Definition und Implementierung der Klasse enthält. Sie liegt im Repository und ist systemweit nutzbar. Lokale Klassen befinden sich dagegen im Reiter Local Types, also innerhalb eines Reports oder einer Behavior-Implementierung. Sie gelten nur in diesem Programmkontext und können dort für Hilfslogik oder spezielle Implementierungen genutzt werden. Global bedeutet also eigenständiges Repository-Objekt, lokal bedeutet eingebettet im Programmcode.