Context
Der Context einer Web-Dynpro-ABAP-Anwendung ist ein komplexes Gebilde, das Ihnen enorm viele Gestaltungsmöglichkeiten bietet. Da der Umgang mit Datenmengen in der Regel großen Einfluss auf die Performance einer Anwendung hat, bieten sich hier sowohl Risiken als auch Chancen, den zeitlichen Ablauf Ihrer Anwendung zu beeinflussen. Die Optimierung der Performance ist für viele, insbesondere für jede komplexere Anwendung ein wichtiger Aspekt, der bereits beim Entwurf einer neuen Anwendung oder Anwendungsgruppe auf jeden Fall beachtet werden sollte. In den folgenden Abschnitten finden Sie eine Reihe von nützlichen Hinweisen über den sinnvollen Einsatz verschiedener Context-Eigenschaften und -Features.
Wenn Sie ein Element in mehreren Contexten verwenden wollen, sich dieses Element jedoch selten oder nie ändert, legen Sie am besten eine Kopie des Elementes im jeweiligen Context an. Sie müssen in diesem Fall allerdings sicherstellen können, dass die Daten immer konsistent gehalten werden. Eine weitere Möglichkeit besteht darin, den Inhalt eines Context-Knotens zunächst als interne Tabelle vorzuhalten und nur innerhalb der jeweiligen View tatsächlich auch als Context-Knoten.
Definieren Sie nur in Ausnahmefällen ein Mapping auf Context-Knoten verwendeter Components. Zum einen ergeben sich dadurch Performance-Einbußen, zum anderen ergibt sich logischerweise die Gefahr, dass innerhalb der verwendeten Component Änderungen vorgenommen werden, die dann zu Fehlern in der Haupt-Component führen können.
Eine mögliche Alternative hierzu stellt die gemeinsame Nutzung einer Assistance-Klassen-Instanz dar. Lesen Sie hierzu die Beschreibung der Beispiel-Anwendung DEMO_COMMON_ASSISTANCE1 und schauen Sie sich deren Implementierung in Ihrem System im Paket SWDP_DEMO an.
Umgang mit Context-Mapping
Das Context-Mapping ist ein Mechanismus, mit dessen Hilfe Sie die verschiedenen Contexte verschiedener Controller statisch miteinander verbinden können. Wenn Sie also ein Set an bestimmten Daten in exakt der selben Struktur parallel in zwei verschiedenen Views benötigen, bietet es sich an, einen geeigneten Context-Knoten am Component-Controller einzurichten. Mit einem einzigen Vorgang lässt sich im View-Editor der Workbench für jeden einzelnen View-Controller eine Kopie des Component-Controller-Knotens anlegen, für welche dann gleichzeitig ein Mapping auf den Original-Knoten eingerichtet wird. Diese Vorgehensweise ist sehr komfortabel und bietet einen hohen Grad an Sicherheit. Sie verleitet aber dazu, die Gestaltung der Contexte innerhalb einer Component immer mit der Gestaltung des Component-Controller-Contextes zu beginnen und für die View-Contexte anschließend nur noch die benötigten Mappings zu definieren. Je nach Größe des Context-Knotens (Anzahl und Struktur der Unterknoten, absolute Datenmengen) kann dies jedoch teilweise erheblichen Einfluss auf die Performance der Anwendung haben. Sie sollten daher sehr genau planen, welche Context-Knoten Sie unbedingt an mehreren Contexten benötigen und welche Sie ausschließlich lokal verwenden. Vermeiden Sie unnötige Mappings innerhalb Ihrer Component.
Ein Context-Knoten wird erst dann befüllt, wenn der entsprechende Context zum ersten Mal gerufen wird. Im Gegensatz zu einem auf einen zentralen Knoten gemappten Context-Knoten ist ein rein lokal angelegter Context-Knoten daher leer, so lange die entsprechende View noch nicht angesprungen wurde. Zur Vermeidung von fehlerhaften Dialogen kann es sinnvoll sein, die Daten für den Context der Folge-View bereits vor dem Auslösen der eigentlichen Navigation bereitzustellen. Da die Folge-View zu diesem Zeitpunkt noch nicht instanziiert ist, muss dann an dieser Stelle entschieden werden, ob man entweder einen Component-Controller-Context mit dazugehörigem Mapping einrichtet oder ob die Daten zunächst in einer Hilfsklasse geholt und geprüft werden und erst nach der vollzogenen Navigation an den Context der Folge-View übergeben werden. Der Weg über ein Context-Mapping ist aus Sicht der Anwendungsentwicklung natürlich der deutlich komfortablere, die Verwendung einer Hilfsklasse kann dagegen eine deutliche Performance-Optimierungen zur Folge haben.
Dynamisch erzeugte Attribute vs. dynamisch erzeugt Knoten
Wie in Dynamische Context-Manipulation beschrieben, erlaubt das Web-Dynpro-ABAP-Framework die dynamische Erzeugung sowohl von Context-Knoten als auch von Context-Attributen. Die dynamische Erzeugung an sich ist ein Performance-relevanter Vorgang, der bei der Erzeugung eines einzelnen Attributes noch keinen großen Einfluss hat. Wenn jedoch mehrere Attribute für einen Context-Knoten gleichzeitig dynamisch erzeugt werden müssen, ist es wesentlich sinnvoller, zunächst eine Struktur anzulegen, aus der dann anschließend der ganze neue Knoten in einem Schritt erzeugt wird. Sie finden ein Beispiel für die dynamische Erzeugung eines Knotens aus einer Struktur in der Web-Dynpro-Anwendung DEMODYNAMIC im Paket SWDP_DEMO Ihres Systems. In der View DYNAMIC_NODE_TYPE wird in der Methode WDDOINIT erst eine Struktur und anschließend daraus die benötigte Node-Info erzeugt.
Singleton-Knoten
Die Eigenschaft Singleton eines Context-Knotens ist unter Context-Knoten: Eigenschaften beschrieben. Beim Anlegen eines Context-Knotens unterhalb des Wurzelknotens wird durch Voreinstellung die Option Singleton markiert. Prinzipiell ist die Überlegung nicht verkehrt, bei tieferen Datenstrukturen mit großen Datenmengen zunächst nur die Daten zum ausgewählten Element des Hauptknotens in den Speicher zu laden. Dem gegenüber steht jedoch ein nicht verschwindender Performance-Verbrauch durch die nötige Invalidierung und Neu-Befüllung des oder der entsprechenden Context-Knoten. Es gilt daher an dieser Stelle gut abzuwägen, ob eine Belastung des Speichers durch große Datenmengen oder eher die Belastung der Laufzeit durch Invalidierungs- und Füllvorgänge zu minimieren sind. Nutzen Sie Singleton-Knoten nur dann, wenn die Datenmengen im Speicher ansonsten wirklich zu groß würden. Ansonsten kann es auch durchaus sinnvoll sein, mit Nicht-Singleton-Knoten zu arbeiten und solche Daten, die Sie von vornherein oder auch zu einem späteren Zeitpunkt nicht oder nicht mehr benötigen, explizit aus dem Speicher zu löschen.
Befüllen des Contexts: Supply-Funktion
Die Supply-Funktion bietet Ihnen die Möglichkeit, den Inhalt eines Knotens gezielt nur bei Bedarf zu beschaffen. Die Supply-Funktion wird immer erst (und auch nur) dann aufgerufen, wenn der Inhalt des Knotens tatsächlich benötigt wird, das heißt, wenn die Laufzeit auf die Inhalte des Knotens zugreifen muss. Da der konkrete Aufruf der Supply-Funktion von der Laufzeit kontrolliert wird und nicht durch das vom Anwendungsentwickler erzeugte Coding, ist es besonders wichtig, dass während des Ausführens, also während der Datenbeschaffung, keine Fehler auftreten. Nutzen Sie die Supply-Funktion daher nur, wenn die korrekte Verfügbarkeit der Daten im Backend gewährleistet ist.
Supply-Funktionen eignen sich üblicherweise für das Befüllen von Unterknoten, unabhängig davon, ob es sich um Singleton- oder um nicht-Singleton-Knoten handelt. Grundsätzlich muss jedoch folgendes beachtet werden: Der benötigte Inhalt eines Unterknotens darf nur von einem Element des zugehörigen Oberknotens abhängig sein. Nur dann ist sichergestellt, dass alle benötigten Knoten instanziiert und die Werte vorhanden sind. Die folgende Grafik verdeutlicht diesen Zusammenhang:
Der Unterknoten s1 des Knotens node1 kann auf jeden Fall genau dann mit Hilfe einer Supply-Funktion gefüllt werden, wenn die benötigten Daten ausschließlich vom Wert eines Elementes des Knotens node1 abhängen. In diesem Fall ist implizit sichergestellt, dass dieser Wert bereits vorhanden ist, da der Knoten node1 bereits instanziiert ist. Prinzipiell könnte es jedoch auch sein, dass die Auswahl der Daten für s1 vom Wert eines Elements des Knotens node2 abhängig ist. Der Knoten node2 ist aber zum Zeitpunkt des Befüllens von s1 unter Umständen noch gar nicht instanziiert. Wenn der Knoten node2 ebenfalls über eine Supply-Funktion gefüllt wird, träte nun der Fall ein, dass die Supply-Funktion von s1 ihrerseits zunächst die Supply-Funktion vom Knoten node2 aufrufen müsste. Dieser kaskadierende Aufruf zweier oder mehrerer Supply-Funktionen ist jedoch nicht zulässig und führt zu einem Laufzeitfehler. Wenn Sie also zum Befüllen eines Context-Knotens auf Daten eines anderen als dem direkten Oberknoten zugreifen müssen, verzichten Sie sicherheitshalber auf die Nutzung der Supply-Funktion und programmieren Sie stattdessen die nötige Datenbeschaffungsfunktion in einer geeigneten Ereignisbehandlermethode. Ansonsten sollten Sie auf jeden Fall dafür sorgen, dass eventuell auftretende Laufzeitfehler abgefangen und behandelt werden
Wenn Sie den Aufruf einer Supply-Funktion explizit antriggern wollen, bevor der Inhalt des Knotens selbst erstmalig gebraucht wird, können Sie dies mittels der Methode get_element () erreichen.
Eine Supply-Funktion kennt immer automatisch die beiden Parameter PARENT_ELEMENT und NODE. Der Parameter PARENT_ELEMENT ist eine Referenz auf das Element des Oberknotens (im obigen Beispiel also ein Element des Knotens node1), dessen Wert zur Datenbeschaffung ausgelesen werden soll, NODE wiederum ist eine Referenz auf den Knoten, der von der Supply-Funktion gefüllt werden soll (im Beispiel hier s1). Nutzen Sie unbedingt diese beiden eingebauten Parameter. Der generische Weg über die allgemeinen Context-Methoden ist wesentlich aufwändiger und dadurch nicht zuletzt fehleranfälliger und bringt ansonsten keinerlei Vorteile.
Achten Sie darauf, dass Sie innerhalb einer Supply-Funktion niemals die CONTEXT_NODE_INFO eines Context-Knotens ändern. Genauso darf in einer Supply-Funktion das Value-Set eines Knotens nicht geändert werden. Dies kann zu Komplikationen führen, da die Reihenfolge der von der Laufzeit abzuarbeitenden Schritte unter Umständen nicht mehr zu den dann jeweils gültigen Werten passt.
Context-Change-Log
Verwenden Sie die Context-Change-Log-Funktionalität zur Erkennung von Benutzereingaben. Dies hat insbesondere dann Performance-Vorteile, wenn ein Benutzer der Anwendung nur wenige Daten in einer View ändert, andererseits aber viele unterschiedliche Daten angezeigt werden.
Eigenschaften von Context-Attributen
Jedes Context-Attribut verfügt über die vier vordefinierten Eigenschaften readOnly, visible, state und enabled. Die Werte dieser Eigenschaften können mit Hilfe des Interfaces IF_WD_CONTEXT_ATTR gesetzt werden. Das Web-Dynpro-Framework erlaubt die Bindung der gleichnamigen UI-Element-Eigenschaften an die jeweilige Attribut-Eigenschaft, so dass die Zahl der anzulegenden Knoten im Context deutlich reduziert werden kann. Dies führt zu Verbesserungen der Performance sowie zur Reduzierung des Speicherbedarfs.
Weitere Informationen: Eigenschaften von Context-Attributen
Verwendung von Objekt-Referenzen
Wir empfehlen nachdrücklich, keinerlei Referenzen auf Context-Knoten und Elemente zu halten, da diese in der Zwischenzeit invalidiert werden könnten. Holen Sie stattdessen die Referenzen immer nur bei Bedarf ab. Wenn Sie tatsächlich eine Referenz länger halten müssen, verwenden Sie die Methode IS_ALIVE auf der Referenz und kontrollieren Sie das Ergebnis, bevor Sie damit weiter arbeiten.