Anfang des Inhaltsbereichs

Contexte puffern Dokument im Navigationsbaum lokalisieren

Das Hauptziel von Contexten ist es, die Systembelastung dadurch zu verringern, daß 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, daß 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

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.

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.

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:

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.

Hinweis

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 Einfluß aufeinander.

Puffer löschen

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

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

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

Beispiel

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 Datenbankänderungen programmieren.

 

 

 

Ende des Inhaltsbereichs