Snapshot-Erzeugung im HR-Reporting mit ADSOs

Gerade im Umfeld von HCM und den Infotyp-Tabellen werden häufig Fullloads für eine Versorgung eines SAP BW genutzt, da eine eindeutige Erkennung von Änderungen (CRUD – Create, Read, Update und Delete) im Quellsystem nicht möglich ist. Zum Beispiel sind Termine (Infotyp 0019) nicht mit einer vollständigen Gültigkeit versehen, sodass bei einer Löschung kein neuer Datensatz erstellt wird, der diesen Zeitraum überschreibt. Im Quellsystem könnte der Einsatz vom SLT/RS (SAP Landscape Transformation/Replication Server) mit seiner Trigger-basierten Erkennung von Änderungen auf Datenbankebene jede einzelne Anpassung an den Daten überwachen. Allerdings ist ein Einsatz aufgrund der verhältnismäßig geringen Datenmenge nicht unbedingt notwendig und auch eine Änderungsverfolgung wäre an dieser Stelle „übertrieben“. (Bitte beachten Sie, dass der SLT/RS zum Teil in aktuellen SAP-BW-Lizenzpaketen mit enthalten ist und somit häufig genutzt werden kann, jedoch eine Installation auf dem Quellsystem benötigt.)

Von den Datenintegrationsmöglichkeiten bleiben somit normale Fullloads von den HR-Infotypen in den Data Acquisition Layer des SAP BW als adäquates Mittel übrig, wie es auch sehr häufig bei HR-Reporting-Projekten realisiert wird. Mit dem Einsatz von HANA für ein SAP BW (ab 7.5 SP4) ergibt sich eine neue Möglichkeit: nämlich ein ADSO mit Snapshot-Funktion zu nutzen. Analog zum SLT/RS oder einem HANA-basierten Change Data Capture füllt diese ADSO-Einstellung basierend auf einem Fullload die Changelog-Tabelle und ermöglicht es, auch Löschungen in der weiteren Delta-Verarbeitung zu berücksichtigen. Auf diese Weise können Änderungen an den Daten eindeutig erkannt und im Corporate Memory Layer für spätere Auswertungen persistiert werden. Zusätzlich kann auch die Befüllung der zeitabhängigen Attribute von InfoObjects beschleunigt werden, da dieser Prozess weiterhin ganz oder zum Teil im ABAP Stack ausgeführt wird und somit nicht die schnellste Beladungsart darstellt.

Aktivierung der Snapshot-Funktion

Der folgende Screenshot zeigt, wie in den Modellierungseigenschaften die Snapshot-Unterstützung aktiviert werden kann (Achtung dabei, das ADSO muss dann immer komplett beladen werden!).

Deltaverhalten (RECORDMODE) im Changelog

Das entsprechend eingestellte ADSO mit Snapshot-Unterstützung generiert dabei Einträge im Changelog. Das Problem dabei ist jedoch, dass nach dem Löschen eines Datensatzes im Changelog kein Eintrag mit dem RECORDMODE ‚D‘ für Delete erzeugt wird, sondern ein Reverseimage mit dem RECORDMODE ‚R‘. Dieses enthält sämtliche Informationen des originären Datensatzes und würde somit die Attribute eines InfoObjects nicht zurücksetzen. Daher muss bei dem Befüllen eines InfoObjects der Datensatz mit dem Reverseimage zu einem Delete geändert werden. Dafür müssen sämtliche Nicht-Schlüsselspalten – mit Ausnahme des Startdatums der Gültigkeit – gelöscht werden. Dies ist notwendig, damit der korrekte Zeitbereich aus dem InfoObject überschrieben werden kann. Denn wenn Bewegungsdaten vorhanden sind, kann man keine Stammdaten mehr löschen. Man muss sie „leeren“.
 

Fallbeispiel: Zeitabhängige Stammdatenbuchung mit Snapshot-Unterstützung

Hier ein Beispiel, welche Datensätze ein ADSO mit Snapshot-Unterstützung erzeugt und wie man die Reverseimages für ein InfoObject anpassen muss.
 

1. Neuer Mitarbeiter wird angelegt

2. Mitarbeiter erhält eine neue E-Mail-Adresse

Ein InfoObject würde nun das Reverseimage als normalen Datensatz ansehen und nicht rauslöschen. Da in diesem Fall jedoch der komplette zeitliche Gültigkeitszeitraum beschrieben ist, würde es letztendlich zum korrekten Ergebnis führen. Allerdings ist dies nicht bei allen Infotypen gewährleistet, wie zum Beispiel bei Terminen. Anlehnend an das Beispiel würde es sich dort wie folgt verhalten:
 

1. Neuer Mitarbeiter wird angelegt

2. Mitarbeiter erhält eine neue E-Mail-Adresse mit begrenztem Ende

 Ergebnis in den zeitabhängigen Attributen des InfoObjects

Da das InfoObject die zeitliche Abhängigkeit auswertet, würde mit der Verarbeitung dieser Datensätze ab dem 01.01.2019 weiterhin die E-Mail-Adresse Mitarbeiter@remove-this.btelligent.com gelten, da dieser Zeitraum nicht ausgebucht wurde. Daher muss für eine korrekte Verarbeitung jedes Reverseimage in ein Delete umgewandelt werden. Die Attribute des ursprünglich gebuchten Zeitraums werden auf „leer“ gesetzt, was einer Löschung entspricht. Über eine spätere Reorganisation des InfoObjects, die auch mit dem Einsatz von HANA notwendig ist, können unnötige Einträge in den zeitabhängigen Tabellen des InfoObjects wieder bereinigt werden.
 

3. Korrekte Deltaverarbeitung aus einem Snapshot-ADSO mit Startroutine

Ergebnis in den zeitabhängigen Attributen des InfoObjects
 

Der bis zum 31.12.9999 gültige Datensatz ist zwar noch vorhanden, wurde aber korrekt auf „leer“ gesetzt. Somit entsprechen die zeitabhängigen Stammdaten wieder dem korrekten Zustand. Auch nicht zeitabhängige Stammdaten würden über diesen Weg korrekt ausgebucht, da diese wieder mit einem „leeren“ Datensatz überschrieben werden.