ABAP-Programme arbeiten prinzipiell mit programmlokalen Daten, die im internen Modus des Programms leben. Solche Daten leben nur so lange wie ihr Kontext, das heißt ihre Prozedur bei prozedurlokalen Daten, ihr Objekt bei Attributen von Klassen oder ihr Programm bei den globalen Daten des Programms. Solche Daten heißen transient. Daten heißen persistent, wenn sie dauerhaft, also über die Programmlaufzeit hinaus aufgehoben werden können. Im SAP-System kommen persistente Daten hauptsächlich als Inhalte von Datenbanktabellen, aber auch als Inhalte von Dateien auf Applikations- oder Präsentationsservern vor.

Um mit persistenten Daten zu arbeiten, müssen diese während der Programmausführung in transiente Datenobjekte des ABAP-Programms geladen und nach der Verarbeitung wieder persistent abgelegt werden. Während dieser Zeitspanne liegt der Inhalt der Daten doppelt vor: Einmal transient im ABAP-Programm und einmal persistent in der entsprechenden Ablage. Ein typischer Ablauf ist das Lesen von Daten aus einer Datenbanktabelle mit der Anweisung SELECT in einen transienten Arbeitsbereich, die Modifikation des Arbeitsbereichs und der anschließende UPDATE der Datenbanktabelle. In diesem Fall sind die Inhalte von transienten und persistenten Daten zwischenzeitlich unterschiedlich.

In einer idealen objektorientiert programmierten Anwendung kommen Daten nur noch als Attribute von Objekten vor (wenn wir die lokalen Daten in Methoden hier einmal außer acht lassen). Objekte sind eine Zusammenfassung von Funktionalität in Methoden und Daten in Attributen. Während die Beschreibung eines Objekts, also die Klasse, persistent als Programmtext vorliegt, leben seine Attribute nur solange wie das Objekt. Ein Objekt in ABAP Objects ist aber prinzipiell transient, da es nur zwischen seiner Erzeugung mit CREATE OBJECT und seiner Löschung durch die Garbage Collection im internen Modus des Programms vorhanden ist. Um in Objekten mit persistenten Daten zu arbeiten, müssen also innerhalb der Methoden der Klasse Zugriffe auf deren Ablage programmiert werden.

Bei der vollständig objektorientierten Programmierung einer (betriebswirtschaftlichen) Anwendung ist es aber nicht sinnvoll, die klassische Trennung zwischen Daten und Funktionalität einfach nur in die Methoden zu verlagern, d.h. im Programm zwar mit Objekten zu arbeiten, in den Objekten selbst aber klassisch vorzugehen. Stattdessen wünscht man sich, die Zusammenfassung von Daten und Funktionalität zu einem Objekt persistent abspeichern zu können, damit ein Programm direkt mit dem gleichen Objekt weiterarbeiten kann, wie es ein anderes Programm hinterlassen hat. Während die Klasse eines Objekts ohnehin schon persistent vorliegt, muß es noch eine Möglichkeit geben, die Attribute eines Objekts persistent abzuspeichern und auf die richtige Klasse zu beziehen. Dies ist die Aufgabe des Persistenzdiensts.

Technisch gesehen sind die Objekte von ABAP Objects genau wie die Datenobjekte eines ABAP-Programms immer transient. Es gibt keine persistenten Objekte in ABAP Objects. Um es dem Anwendungsentwickler dennoch zu ermöglichen, mit persistenten Objekten zu arbeiten, gibt es den Persistenzdienst der Object Services. Der Persistenzdienst stellt sozusagen eine Softwareschicht zwischen ABAP-Programm und Datenablage (Datenbank) dar, die es erlaubt, die Eigenschaften von Objekten unter einer eindeutigen Identität abzuspeichern und bei Bedarf wieder zu laden.

Einfach ausgedrückt sorgt der Persistenzdienst dafür, dass ein Objekt bei der Initialisierung in einen bestimmten Zustand gebracht wird und speichert den Zustand des Objekts bei Bedarf wieder ab. Die Beziehung zwischen einem solchen Objekt und der Zustandsbeschreibung auf der Datenbank ist analog zur oben beschriebenen Beziehung zwischen transienten und persistenten Daten. Der Zustand des Objekts nach der Erzeugung gibt den Datenstand auf der Datenbank zum Zeitpunkt der Erzeugung wieder. Änderungen am Objektzustand im ABAP-Programm werden aber nie direkt, sondern nur nach entsprechender Aufforderung (Anweisung COMMIT WORK) vom Persistenzdienst auf der Datenbank festgeschrieben. Persistente Objekte existieren also als Original auf der Datenbank und als Kopie in einem oder sogar mehreren ABAP-Programmen. Wenn mehrere Programme mit dem Persistenzdienst Objekte der gleichen Klasse erzeugen bevor eines der Programme den Zustand mit COMMIT WORK geändert hat, haben alle ihre Objekte den gleichen Anfangszustand. Zur Zeit ist noch kein Sperrkonzept im Persistenzdienst implementiert, der dafür sorgt, dass es nur ein transientes Abbild eines persistenten Objekts gibt. Letztendlich ist es für den ABAP-Programmierer also immer nur scheinbar so, als ob er mit einem persistenten Objekt arbeitet.

Um den Persistenzdienst für Objekte zu nutzen, müssen deren Klassen als sogenannte persistente Klassen im Class Builder angelegt werden. Der Ausdruck persistente Klasse drückt weniger aus, dass die Klasse persistent ist (jede globale Klasse ist als Bauplan für Objekte persistent), sondern dass ihre Objekte und deren Zustand vom Persistenzdienst verwaltet werden. Die Objekte solcher Klassen werden im ABAP-Programm beispielsweise nicht mit der normalen Anweisung CREATE OBJECT erzeugt, sondern mit einer Methode des Persistenzdiensts, die für die richtige Initialisierung sorgt. Beim Anlegen einer persistenten Klasse generiert der Class Builder automatisch eine zugehörige Klasse, den sogenannten Klassenakteur oder Agenten, über dessen Methoden die Objekte der persistenten Klassen verwaltet werden. Persistente Klassen können neben ihrer eindeutigen Identität sogenannte Schlüsselattribute enthalten, über die der Persistenzdienst die inhaltliche Eindeutigkeit von persistenten Objekten sicherstellt.

Die Objekte einer persistenten Klasse werden vom Persistenzdienst verwaltet. Das bedeutet unter anderem, dass sie nicht mit der Anweisung CREATE OBJECT sondern mit entsprechenden Methoden des Klassenakteurs erzeugt werden. Wir nennen diese Objekte verwaltete Objekte. Vom Persistenzdienst verwaltete Objekte können sowohl persistent aber auch transient sein.

• Persistente Objekte müssen durch den Persistenzdienst verwaltet werden. Der Persistenzdienst sorgt für die Verbindung zwischen Objekt und Datenbank.
• Transiente Objekte persistenter Klassen werden ebenfalls vom Persistenzdienst verwaltet. Der Persistenzdienst sorgt dann beispielsweise für die Eindeutigkeit eines Objekts (bestimmt durch sein Schlüsselattribute) innerhalb eines Programms aber nicht für eine Verbindung zur Datenbank.