Beim Wechsel von SAP Human Capital management (HCM) auf Human Experience Management (HXM ) Applikation sollte man Anwendungen nicht isoliert für das Abbilden von HR-Prozessen betrachten. Vielmehr sollte man auch das Anwendererlebnis mit einbeziehen. Wenn es um Ladezeiten geht, wer mag es da schon zu 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 einer Struktur und können diese später beim Aufruf des Lern-Kurses, schneller laden.

Implementierung der Wurzelklasse

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

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

Die Klasse erbt das Interface 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.

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

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

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

Nachdem wir die Wurzelklasse 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.

Für unsere Gebietsklasse können wir nun definieren, wie das Shared Memory aufgebaut wird. Man kann z.B. entscheiden, dass das Memory mandantenabhängig oder -übergreifend ist. Außerdem 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.

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.

Fertigstellung der Wurzelklasse

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

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

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.

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

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.