Performance-Aspekte (SAP-Bibliothek)

Performance-Aspekte

Verwendung

Um die Performance eines BAPIs zu verbessern, sollten Sie die Programmierrichtlinien einhalten, die allgemein für die ABAP-Programmierung gelten, zum Beispiel:

Geben Sie WHERE-Bedingungen vollständig an, um die zu transportierende Datenmenge zu minimieren.
Vermeiden Sie unnötige Datenbankzugriffe.
Verwenden Sie verstärkt die ARRAY-Technik.
Puffern Sie Daten, zum Beispiel über den lokalen Funktionsbaustein-Speicher. Beachten Sie jedoch, daß ein Puffern von Daten im globalen Memory nicht erlaubt ist.
Die Sperrgranularität muß der Instanzgranularität aus dem Objekt-Modell entsprechen.
Vermeiden Sie das dynamische Generieren von Programmen.

Weitere Hinweise zum performanten Programmieren im R/3-Umfeld finden Sie SAP-intern im SAPnet.

Zusätzliche Richtlinien für BAPI-Programmierung

Da der Funktionsbaustein, der einem BAPI zugrundeliegt, über RFC von externen Programmen aufgerufen werden kann, gelten für die BAPIs weitere Richtlinien:

Große Datenmengen

Die Behandlung von Massendaten wird in der ABAP-Programmierung, bei der ein SAPgui (Graphical User Interface) als Frontend dient, und bei der Programmierung auf externen Entwicklungsplattformen wie beispielsweise Visual Basic, unterschiedlich gehandhabt.

Wenn innerhalb des Systems R/3 Massendaten gelesen werden, z.B. eine Liste mit sehr vielen Einträgen, so bleibt ein Großteil dieser Daten auf dem Anwendungs-Server. Es werden nur die Daten an das Frontend geschickt, die dort auch tatsächlich angezeigt werden. Bei der Programmierung mit Visual Basic dagegen werden in dieser Situation alle Daten vom Anwendungs-Server an das Client-System übertragen. Dies hat eine stärkere Netzbelastung und höheren Speicherbedarf beim Client-System zur Folge.

Für den Fall, daß von Ihrem BAPI große Datenmengen gelesen werden sollen, geben Sie dem BAPI möglichst eine Begrenzung mit, so daß beispielsweise nur die ersten n Sätze gelesen werden. Alternativ oder zusätzlich hierzu könnte das BAPI dem aufrufenden Programm auch über eine Rückmeldung mitteilen, daß die Datenmenge zu groß ist und eine Nachselektion erfolgen sollte.

Definieren Sie keine parallelen Prozesse.
Erfolgt nach einem BAPI-Aufruf kein "COMMIT WORK", muß eine gesetzte Sperre explizit gelöscht werden.
Um die Dauer von Sperren zu reduzieren, sollten Sie Nummern nicht einzeln vergeben. Nutzen Sie stattdessen die gepufferte Vergabe, d.h. lesen Sie die Nummern in einen Puffer und vergeben Sie diese direkt aus dem Puffer.
Sperrzeiten können auch vermindert werden, indem Sie Verbuchungen möglichst nahe am Aufruf des "COMMIT WORK"-Kommandos durchführen. Dadurch verhindern Sie, daß die Sperre zu lange steht und eventuell andere Prozesse blockiert.
Je weniger selektiv oder spezifisch der (Teil-)Schlüssel eines geänderten Datensatzes ist, umso wahrscheinlicher ist es, daß viele BAPIs diesen Satz verändern und damit sperren. Zum Beispiel wird sich eine Statistik auf Werksebene sehr schlecht auf die Performance auswirken, wogegen eine Statistik auf Werks-/Materialebene für weitaus weniger BAPIs relevant sein wird und somit weniger Sperren hervorruft.
Seien Sie sparsam mit lesenden Transaktionen, die von einem Datenbank-Commit abhängig sind (Committed Read), da eine lesende Transaktion auf die Abarbeitung des "COMMIT WORK"-Kommandos der ändernden Transaktion warten muß.
Bei allen Tabellen, die nicht über SAP-Sperren geschützt werden, muß die Reihenfolge der Fortschreibung immer gleich sein, um ein gegenseitiges Sperren (Deadlock) zu verhindern.