Contexte puffern 

 

 Contexte sind obsolet und sollten nicht verwendet werden. Contexte wurden zu Release 4.0 für performante Zugriffe auf häufig benötigte abgeleitete Daten eingeführt. Seit der Einführung von ABAP Objects zu Release 4.5 werden Contexte nicht weiterentwickelt. Seit Release 6.40 können Contexte durch Shared Objects ersetzt werden.

 

Das Hauptziel von Contexten ist es, die Systembelastung dadurch zu verringern, dass bei häufig benötigten Daten, die aus Beziehungen zwischen Schlüsseldaten abgeleitet werden, die Ableitung so wenig wie möglich ausgeführt wird. Hierfür dient die Pufferung der abgeleiteten Daten im Context-Puffer. Dabei werden die abgeleiteten Daten pro Modul gespeichert.

Der Context-Puffer unterscheidet sich von den Datenbankpuffern der Datenbankschnittstelle und dem SAP-Tabellenpuffer vor allem dadurch, dass er sich nur zu bestimmten Zeitpunkten erneuert (jeweils zur vollen Stunde), aber nicht versucht, laufende Änderungen synchron oder nahezu synchron nachzuvollziehen. Er kann daher nicht für jeden Context oder für jedes Modul eines Contexts verwendet werden, sondern nur für Daten mit langlebigem Charakter.

Sie können in der Spalte Puffertyp der Tabelle Module einzeln für jedes Modul einstellen, ob Sie den eigentlichen Context-Puffer verwenden wollen (P), nur einen temporären Puffer (T) oder gar keinen (N).

Die Pufferungsarten im Einzelnen

·        Permanent (P)

Diese Pufferungsart ist die Standardeinstellung und verwendet den transaktionsübergreifenden Anwendungspuffer. Mehr zu diesem Puffer finden Sie in der Schlüsselwortdokumentation zu der Anweisung EXPORT/IMPORT TO/FROM SHARED BUFFER. Der transaktionsübergreifende Anwendungspuffer kann maximal 128 Context-Einträge enthalten. Diese Einträge werden in einem dem LRU (Least Recently Used) ähnlichen Verfahren aufgebaut.

Der Context-Pufferinhalt eines Applikationsservers läßt sich im Context Builder über die Auswahl von Springen → Puffer anzeigen darstellen. Der Puffer wird zu jeder vollen Stunde zurückgesetzt. Ein manuelles Rücksetzen des Context-Puffers ist im Context Builder über die Auswahl von Bearbeiten → Puffer zurücksetzen möglich und wirkt sich auf alle Applikationsserver aus.

·        Temporär (T)

Bei dieser Pufferungsart werden die Ergebnisse von Ableitungen nur innerhalb einer Transaktion gepuffert. Innerhalb einer Transaktion kann der Puffer 1024 Einträge enthalten. Diese Einträge werden paketweise in den transaktionsübergreifenden Anwendungspuffer exportiert. Die Ergebnisse von verschiedenen Instanzen eines Contexts werden programmintern im gleichen Puffer abgelegt.

·        Keine Pufferung (N)

Bei dieser Einstellung werden die Ergebnisse der Ableitung überhaupt nicht gepuffert. Wenn Sie alle Module eines Contexts mit der Pufferungsart N anlegen, dient der Context somit der reinen Wiederverwendung von Programmlogik, bringt aber keine Performance-Verbesserungen.

Beim Test von Customizing-Einstellungen kann die permanente Pufferung stören. Der Context Builder bietet daher die Möglichkeit, den Context-Puffer (Pufferungsart P) für die laufende Benutzersitzung zu deaktivieren. Hierfür wählen Sie Einstellung →Pufferung und im folgenden Dialogfenster Inaktiv. In der Benutzerpflege aktivieren oder deaktivieren Sie den Context-Puffer durch Setzen des Benutzerparameters BUF auf Y oder space (Standardeinstellung) bzw. auf N als dauerhafte Voreinstellung für einen Benutzer.

Aufbau des Puffers

Der Context-Puffer enthält für jedes Modul zwei Puffertabellen:

·        Der I-Puffer (interner Puffer) speichert während der Lebensdauer des Context-Puffers jede abgefragte Kombination von Modul-Eingabeparametern mit den zugehörigen abgeleiteten Werten genau einmal.

·        Der E-Puffer (externer Puffer) ordnet den Schlüsselwerten des Contexts die abgeleiteten Werte des Moduls zu. Der E-Puffer wird in Abhängigkeit von der Abfragehäufigkeit gefüllt. Bei der ersten Abfrage einer bestimmten Kombinationen von Modul-Eingabeparametern werden diese ohne Bezug zu den Schlüsselwerten des Contexts in den I-Puffer geschrieben. Werden Kombination von Modul-Eingabeparametern mehrmals abgefragt (sie sind also bei der Abfrage schon im I-Puffer vorhanden), schreibt das System die Ergebnisse mit den Context-Schlüsselwerten in den E-Puffer. Dadurch kann es vorkommen, dass die Ergebnisse zu einer bestimmten Kombination von Modul-Eingabeparametern mehrmals im E-Puffer vorkommen, da verschiedene Context-Schlüsselfelder zu gleichen Modul-Eingabeparametern führen können.

Die verschiedenen Module eines Contexts sind durch das Ableitungsschema miteinander verknüpft. Die Eingabeparameter eines Moduls sind entweder Schlüsselfelder oder Ausgabeparameter anderer Module. Die Einträge in E-Puffern von Modulen, die von vorgelagerten Modulen abhängen, stellen somit eine Schnittmenge von Einträgen in I-Puffern der vorgelagerten Module dar. Die Pufferungsart des E-Puffers von abhängigen Modulen bestimmt sich aus der kürzesten Pufferungsart eines der vorgelagerten Module. Falls also nur eines der vorgelagerten Module die Pufferungsart N hat, werden keine Einträge im E-Puffer des abhängigen Moduls gespeichert.

Beim Zugriff des Systems auf den Context-Puffer während des Testens oder der DEMAND-Anweisung, durchsucht das System für jedes Modul zuerst den E-Puffer und dann den I-Puffer. Der Zugriff auf den E-Puffer ist direkter und damit schneller während über den I-Puffer in der Regel mehrere Zugriffe nötig sind.

Beim Eintrag mehrfach abgefragter Einträge aus dem I- in den E-Puffer wird Datenredundanz für eine schnellere Zugriffszeit in Kauf genommen. Der I-Puffer dient somit als Filter für den E-Puffer, um Datenredundanz nur in den wirklich benötigten Fällen zuzulassen. Die Verwendung von I- und E-Puffer stellt somit eine Zusammenführung von schneller Zugriffszeit und hoher Trefferwahrscheinlichkeit dar.

Beachten Sie die Vorteile dieses Pufferungskonzept beim Erstellen von Contexten für Ihre Anwendungsprogramme. Versuchen Sie möglichst viele Beziehungen zwischen Daten in einem Context pro Programm zu definieren, statt in einem Programm verschiedene Contexte einzusetzen. Sie können auch verschiedene Contexte als Module eines Contexts zusammenfassen. Bei einem Context puffert das System alle Zwischenergebnisse in einer optimalen Form. Bei verschiedenen Contexten haben die einzelnen Puffer keinen Einfluss aufeinander.

Puffer löschen

Sie können die Pufferinhalte eines Contexts wie folgt löschen:

·        im Context Builder (Transaktion SE33) löschen Sie über Bearbeiten →Löschen der Puffer → Auf lokalem Server oder Bearbeiten → Löschen der Puffer →Auf allen Servern die Pufferinhalte eines Contexts auf dem aktuellen bzw. auf allen Anwendungsservern.

Diese Funktionen können Sie beim Testen von Contexten und der Pufferung von Contexten einsetzen.

·        in ABAP-Programmen löschen Sie mit den Funktionsbausteinen CONTEXT_BUFFER_DELETE_LOCAL und CONTEXT_BUFFER_DELETE die Pufferinhalte eines Contexts auf dem aktuellen bzw. auf allen Anwendungsservern.

Diese Funktionsbausteine können Sie im Zusammenhang mit Änderungen von Datenbankinhalten einsetzen, wenn Sie sicherstellen wollen, dass der Inhalt der Context-Puffer immer aktuell ist.

Beispiel zum Einsatz bei der asynchronen Verbuchung:

DATA context_name LIKE rs33f-frmid.

context_name = 'DOCU_TEST1'.

...

CALL FUNCTION 'CONTEXT_BUFFER_DELETE' IN UPDATE TASK
     EXPORTING
          context_id = context_name
     EXCEPTIONS
          others     = 0.

....

COMMIT WORK.

In diesem Beispiel wird CONTEXT_BUFFER_DELETE als Verbuchungsbaustein aufgerufen. Dieser Aufruf kann z.B. nach den Datenbankänderungen als letzter Verbuchungsaufruf vor dem COMMIT WORK erfolgen.
Mehr zur asynchronen Verbuchung finden Sie unter Datenkonsistenz.