Verwendung von Controls im WAN 

Die Verwendung von Controls zur Oberflächengestaltung führt in der Regel zu einer Belastung des Kommunikationskanals zwischen Frontend und Backend.  Dies kann schon im LAN-, aber insbesondere im WAN-Umfeld ein performance-kritischer Aspekt sein. 

Puffermechanismen helfen diese Problematik zu entschärfen (siehe auch Automation Queue). Die aufgeführten Punkte sollen als Richtlinien bei der Verwendung von Controls im WAN dienen.

Control-spezifische Hinweise zur Verwendung im WAN finden Sie in der Dokumentation zu dem jeweiligen Control.

Verwendung von CL_GUI_CFW=>FLUSH

Der Aufruf CL_GUI_CFW=>FLUSH dient zum Synchronisieren der Automation Queue und der in der Queue enthaltenen ABAP-Variablen.  Dieser Aufruf erzeugt in vielen Fällen einen synchronen RFC vom Applikationsserver zum Frontend.  Um eine optimale Performance zu erreichen, sollten die Aufrufe dieser Methode minimiert werden. 

Es ist in vielen Fällen zu empfehlen, alle Eigenschaften von allen Controls zentral an einer Stelle (z.B. am Anfang des PAI) in einer Automation Queue zu lesen und dann über eine einmalige Synchronisation zu besorgen.  Diese Variante ist auch dann zu bevorzugen, wenn dabei Eigenschaften gelesen werden, die nicht immer für den Ablauf des Ereignisbehandlers bzw. des PAI – PBO-Zyklus notwendig sind.

Es ist nicht notwendig, einen Sicherheits-Flush am Ende von PBO zu codieren, damit Methodenaufrufe der Controls garantiert an das Frontend transportiert werden.  Diese Funktionalität wird systemseitig garantiert, wenn das nächste Dynpro gesendet wird.  Damit ist es auch nicht möglich, eine Automation Queue über mehrere Bildwechsel hinweg aufzubauen.

Es ist nicht garantiert, dass eine Automation Queue durch den Aufruf CL_GUI_CFW=>FLUSH gesendet wird. Die Queue erkennt, ob Returnwerte enthalten sind. Ist dies nicht der Fall, wird das Senden unterdrückt!

Für alle Fälle, in denen auch bei einer Queue ohne Returnwert gewünscht wird, dass die Automation Queue synchron versendet wird, gibt es im Control Framework die Methode CL_GUI_CFW=>UPDATE_VIEW. Diese Methode darf nur dann verwendet werden, wenn es zwingend notwendig, ist ein Update des SAP GUI zu erreichen.  Beispiele hierfür sind sehr lange laufende Anwendungen, die in regelmäßigen Abständen dem Benutzer ein Feedback über den Fortschritt der Aktion anzeigen möchten. 

Nach dem Lesen von Eigenschaften ist der Inhalt der entsprechenden ABAP-Variable erst nach dem nächsten FLUSH garantiert.  Solange dieser Aufruf nicht erfolgt ist, ist der Inhalt der entsprechenden ABAP-Variablen nicht definiert.  In Zukunft wird es Fälle gegeben, in denen dieser FLUSH unnötig sein wird.  Diese Fälle werden von der Automation Queue erkannt; der entsprechende FLUSH-Call wird dann ignoriert. 

Erzeugen von Controls, Datenversorgung

Das Erzeugen eines Controls und seine Datenversorgung ist in den meisten Fällen ein einmaliger Vorgang und im Vergleich zu Dynproelementen sehr teuer. Deshalb sollten Controls nicht unnötig erzeugt bzw. nicht unnötig mit Daten versorgt werden. 

Ein typisches Beispiel hierfür sind TabStrips mit mehreren Seiten.  Wenn diese Seiten Controls tragen, ist immer abzuwägen, ob man auf lokale Seiten verzichten sollte und die Controls erst dann erzeugt, wenn der Benutzer die Seite aktiviert.  Das gleiche trifft für die Datenversorgung dieser Controls auf TabStrip-Seiten zu.

Muss bei der Datenversorgung eine Unterscheidung zwischen einer WAN - und einer LAN - Anmeldung vorgenommen werden, steht der Funktionsbaustein  SAPGUI_GET_WAN_FLAG zur Verfügung. In manchen Fällen kann es notwendig werden, dass eine Anwendung andere Datenmengen oder ganze Fallbacks für die WAN-Anmeldung zur Verfügung stellen sollte.  Ein Beispiel, wann die WAN- bzw. LAN- Anmeldung einen Einfluss haben kann, ist die Anzahl von Geschwistern in einem Tree Control, die ohne künstliche Zwischenebenen übertragen werden können.

Im Gegensatz zu Dynproelementen werden die Controls nur einmalig erzeugt und mit Daten versorgt.  Controls werden unter Performance-Aspekten immer preiswerter, je länger sie leben.  In Anwendungen, die ständig neu aufgerufen und damit neu initialisiert werden, kann dies zu einem erhebliche Performance-Nachteil werden; in Anwendungen, die sehr lange auf den gleichen Bildern arbeiten, kann daraus sogar ein Performance-Vorteil entstehen. 

Im Einzelfall kann über entsprechende Performancewerkzeuge überprüft werden, welche Nachteile oder Vorteile die Verwendung eines Controls unter dem Aspekt der Netzwerkauslastung bringt.