Checkliste für performante WDA-Programmierung
Beachten Sie bei der Programmierung von Web-Dynpro-ABAP-Anwendungen die folgenden grundlegenden Aspekte.
|
|
Designen Sie Ihre Anwendung für gute Performance und achten Sie auf geringen Speicherverbrauch |
|
|
Überprüfen Sie zuerst Ihr eigenes Coding auf Performance- und Speicherengpässe hin, bevor Sie eine Meldung unter BC-WD-ABA anlegen |
|
|
Führen Sie entwicklungsbegleitend Performance- und Memory-Tests durch |
|
|
Lesen Sie die Web-Dynpro-ABAP-Dokumentation |
Tools
Dos and Dont's: Web-Dynpro-Components
Achten Sie darauf, Web-Dynpro-Entitäten nur für die UI-Programmierung zu verwenden.
|
|
Schreiben Sie nicht Ihr gesamtes Anwendungscoding in Web-Dynpro-Components. Weitere Informationen: Anzahl, Größe und Generik von Components |
|
|
Schreiben Sie Ihr Anwendungscoding in ABAP-OO-Klassen. Verwenden Sie beispielsweise die Assistance-Klasse. |
|
|
Verwenden Sie Web-Dynpro-Components nur dazu, die Views und den Context zu verwalten Hinweis
Beachten Sie, dass Web-Dynpro-Components keine "Leichtgewichte" sind... |
|
|
Erstellen Sie keine Web-Dynpro-Component nur für eine einzigen View |
|
|
Fassen Sie möglichst alle Views, die zu einem Anwendungsteil gehören, in einer Web-Dynpro-Component zusammen. Wenn jedoch die ABAP-Load zu groß wird, splitten Sie die Component auf. |
|
|
Löschen Sie alle Web-Dynpro-Component-Instanzen, sobald sie nicht mehr benötigt werden. Verwenden Sie dazu IF_WD_COMPONENT_USAGE=>DELETE_COMPONENT |
|
|
Verwenden Sie dynamische Navigation oder dynamische Component-Usages nur dann, wenn es sich absolut nicht vermeiden lässt |
|
|
Setzen Sie die Lebensdauer einer View auf when visible, wenn die View nur einmal in der Anwendung angezeigt wird, d.h. wenn die View nicht ein zweites Mal verwendet wird |
|
|
Setzen Sie möglichst immer die Lebensdauer auf when visible. Hinweis
Durch die Lebensdauer when visible wird zwar der Speicherverbrauch reduziert, aber when visible kann Auswirkungen auf die Performance haben, weil in diesem Fall die View jedes Mal, wenn sie angezeigt wird, initialisiert werden muss. Siehe auch Auf- und Abbauen von Components und Views. |
Dos and Dont's: Web-Dynpro-Context
Im Web-Dynpro-Context werden die UI-Daten abgelegt und verwaltet.
|
|
Stellen Sie nicht alle Ihre Daten in den Context. Erstellen Sie also keinen Mega-Context für alle Daten einer Anwendung |
|
|
Stellen Sie nur die Daten in den Context, die für das UI-Element-Binding notwendig sind |
|
|
Verwenden Sie die Assistance-Klasse oder andere ABAP-OO-Klassen für den Datenaustausch |
|
|
Erstellen Sie je nach Bedarf lokale Contexte, beispielsweise in Views |
|
|
Erstellen Sie keine tief verschachtelten Contexte |
|
|
Verwenden Sie Singleton-Knoten, wenn Verschachtelungen (Master-Detail) benötigt werden |
|
|
Verwenden Sie keine dynamischen Attribute ( IF_WD_CONTEXT_NODE_INFO->ADD_ATTRIBUTE) |
|
|
Verwenden Sie Daten mit der Context-Struktur für BIND_TABLE |
|
|
Aktualisieren Sie den Context nur dann, wenn die Daten auch tatsächlich aktualisiert werden müssen |
|
|
Erstellen Sie keine langen Context-Mapping-Ketten |
Weitere Informationen: Context
Dos and Dont's: Web-Dynpro UI-Elemente
Die Größe Ihres Anwendungsbildschirms hat enorme Auswirkungen auf die Performance.
|
|
Verwenden Sie kein Container-Scrolling ( scrollingMode<>none) |
|
|
Verwenden Sie nicht die Scrolling-Funktionalität des Browser-Fensters. Hinweis
Beachten Sie die folgende Ausnahme: Wenn der Anwendungsbildschirm nur zum Anzeige und nicht für Benutzereingaben dienen soll, können Sie ausnahmsweise das Browser-Scrolling verwenden, um unnötige Server-Roundtrips zu vermeiden. |
|
|
Erstellen Sie Anwendungsbildschirme, die in ein typisches Browser-Fenster passen |
|
|
Verwenden Sie die Scrolling-Features der Table, der MultiPane und des RowRepeaters |
|
|
Vermeiden Sie tiefe Verschachtelungen von Containern, Group s und TabStrip s. Hinweis
Durch Verschachtelungen werden Server- und Client-Performance stark beeinflusst. Es kann auch aufgrund von Browser-Einschränkungen, die nicht vom Web-Dynpro-ABAP-Framework beeinflusst werden können, vorkommen, dass tief verschachtelte Inhalte am Frontend nicht angezeigt werden. |
|
|
Fügen Sie keine TransparentContainer UI-Elemente in Container-UI-Elemente, wie Group s, ein. |
|
|
Tauschen Sie, wenn möglich, das RootUIElementContainer UI-Element ( TransparentContainer) durch andere Container-UI-Elemente wie Table, TabStrip oder Group, aus, um Verschachtelungstiefen zu minimieren. Siehe auch Root-Elemente von Views |
|
|
Ordnen Sie logisch ineinander verschachtelte Inhalte am besten in Zeilen an |
|
|
Verwenden Sie möglichst nicht das UI-Element Tree |
|
|
Für die Darstellung von Baumstrukturen verwenden Sie eine Table mit entweder TreeByKeyTableColumn oder TreeByNestingTableColumn |
|
|
Verwenden Sie nicht dynamische UI-Element-Programmierung und/oder multiple Components für sich wiederholende Layouts |
|
|
Verwenden Sie den RowRepeater oder die MultiPane für sich wiederholende Layouts |
|
|
Modifizieren Sie Ihre UI-Elemente nur dann, wenn sie tatsächlich geändert werden müssen |
|
|
Verwenden Sie, wenn möglich, das Delta-Rendering |
|
|
Beachten Sie spezielle Performance-Aspekte bei der Verwendung des InteractiveForm-Oberflächenelements. |
Weitere Informationen: User Interface