Performance Optimierung von SAP-Anwendungen durch Shared Memory Objects

Beim Wechsel von SAP HCM auf HXM (Human Experience Management) Applikation sollte man Anwendungen nicht isolierten auf das Abbilden von HR-Prozessen betrachten, sondern auch das Anwendererlebnis mit einbeziehen. Wenn es eine Sache gibt, die Anwender wirklich nicht mögen, ist es das Warten. Daher möchte ich in diesem Artikel vorstellen, wie man mit ABAP Shared Memory Objects die Ladezeit von vielen SAP-Anwendungen deutlich senken kann. Dies spielt vor allem bei Anwendungen mit großen Datenmengen oder vielen Anwendern eine Rolle. Mögliche Anwendungsgebiete sind z.B. die Optimierung von Fiori- oder WebDynpro Self Services Anwendungen (ESS/MSS, LSO Lernportal oder E-Recruiting).

Was sind Shared Memory Objects?

Das Shared Memory ist ein Speicherbereich auf einem Applikationsserver, auf den alle ABAP-Programme dieses Servers gemeinsam zugreifen.
Durch Ablegen der Daten in das Shared Memory lässt sich die Anzahl der Datenbankaufrufe erheblich reduzieren, was in vielen Fällen einen enormen Performancegewinn bedeutet.

Implementierung von Shared Memory Objects

Wir möchten nun als Beispiel für das SAP LSO Lernportal die Trainingstypinformationen in ein Shared Memory Objekt schreiben. Dabei speichern wir alle Trainingstypinformationen in eine Struktur und können diese später beim Aufruf des Kurses, schneller laden.

Implementierung der Wurzelklasse

Zunächst legen wir im Class Builder die Wurzelklasse (Der Klassenname erhält üblicherweise den Suffix ROOT):

Anlage der Wurzelklasse zu Shared Memory Objects

Unter Eigenschaften weisen wir die Klasse als Shared-Memory-fähig aus.

Setzen des Flags Shared-Memory-fähig

Die Klasse erbt das Interface IF_SHM_BUILD_INSTANCE.

Einbinden des Interfaces IF_SHM_BUILD_INSTANCE

Unter Attribute können wir nun beliebig viele Instanzvariablen ablegen, die wir in das Shared Memory schreiben. In unserem Fall nehmen wir eine Tabelle mit allen verfügbaren Trainingstypinformationen.

Anlage in Shared Memory Objects Instanz-Attributen

Für die Instanz-Attribute legen wir nun noch öffentliche Getter- und Setter-Instanz-Methoden an, welche die Attribute befüllen bzw. zurückliefern.

Anlage von Getter- und Setter Methoden zu den Shared Memory Objects

In den Getter-Methoden liefern wir lediglich einen oder mehrere Werte zurück. In vielen Fällen ist es sinnvoll bereits hier die Rückgabewerte auf (strukturelle) Berechtigungen des aufrufenden Users zu prüfen, da man das Shared Memory ja in der Regel mit allen Objekten befüllt und im Falle der LSO es möglicherweise Kurse gibt, auf die ein Mitarbeiter keinen Zugriff haben darf.

Implementierung der Getter-Methode

In der Setter-Methode werden alle aufrufbaren Objekte geschrieben. Bei uns also eine Tabelle mit allen vorhanden Trainingstypinformationen:

Implementierung der Setter-Methode

Nachdem wir die Wurzelklasse soweit vorbereitet haben müssen wir erst die Gebietsklasse generieren, um die vererbte Methode IF_SHM_BUILD_INSTANCE~BUILD abschließend implementieren zu können.

Implementierung der Gebietsklasse

Die Gebietsklasse müssen wir nicht selbst implementieren, da diese über die Transaktion SHMA angelegt wird. Die Gebietsklasse erhält i.d.R. den Suffix AREA.

Anlage der Gebietsklasse für Shared Memory Objects

Für unsere Gebietsklasse können wir nun definieren, wie das Shared Memory aufgebaut wird. Man kann z.B. entscheiden, dass das Memory mandatenabhängig oder -übergreifend ist, zudem kann das Memory automatisch oder durch den Aufruf eines Users gefüllt werden. In unserem Fall möchten wir, dass die Shared Memory Objects automatisch bei einer Leseanfrage oder Invalidierung aufgebaut werden, und dass die Lebensdauer 15 Minuten beträgt.
Für eine vollständige Auflistung der Gebietsoptionen verweise ich auf die SAP-Dokumentation zu Shared Objects.

Einstellung der Gebietsklasse

Nachdem die gewünschte Auswahl getroffen wurde, wird mit dem Speichern unsere Gebietsklasse generiert. Die Gebietsklasse lässt sich nicht über den Class Builder ändern, aber einsehen. Jede Änderung am Gebiet über die Transaktion SHMA führt zur Neugenerierung der Gebietsklasse.

Erfolgsmeldung zur Generierung der Gebietsklasse

Fertigstellung der Wurzelklasse

Nachdem unsere Gebietsklasse angelegt ist, können wir nun die verbleibende Methode in der Wurzelklasse implementieren. Hervorzuheben ist bei uns Zeile 17, in welcher wir unsere Setter-Methode(n) aufrufen.

Implementierung der Build-Methode in der Wurzelklasse

Wollen wir nun auf die Shared Objects aus einem Gateway Service, WebDynpro Komponente oder Report zugreifen, können wir das wie folgt auslesen:

Verwenden des Shared Memories zum Auslesen von Shared Objects

Der Shared Objects Monitor

Über die Transaktion SHMM können wir den Shared Objects Monitor aufrufen. Dort tauchen alle Gebietsinstanzen auf. Die Gebietsinstanzen lassen sich hier auch löschen und invalidieren, wenn das Shared Memory z.B. fehlerhaft aufgebaut wurde.

Shared Objects Monitor

Wenn die Gebietsinstanz noch nicht aufgebaut wurde, können wir dies hier auch manuell vornehmen.

Manuelle Anlage der Gebietsinstanz über den Shared Memory Monitor

Fazit

Das Shared Memory lässt sich sehr einfach implementieren und kann große Vorteile bei der Anwendungsperformance bringen.
Gerade bei HR-Anwendungen muss darauf geachtet werden, dass man ggf. die gelesenen Objekte gemäß den (strukturellen) Berechtigungen im Nachhinein noch einschränkt.

Kategorie:

Tags:

Keine Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.