Für den Aufbau eines zentralen Core Data Warehouse bietet SAP BW viele Vorteile im Vergleich zu anderen Datenbanktechniken. Hier steht Datenqualität und korrekte fachliche Daten mehr im Vordergund als bei vergleichbaren Datenbanklösungen. So sind diverse Szenarien wie etwa Daten zurückrollen auf den Vorbeladungszustand beim Zurücknehmen einer ausgeführten Datenbeladung standardisiert.
Um stichtagsgerechte Berechnungen, speziell im Finance Bereich aber auch für machine learning/ AI Anwendungen zu gewährleisten, ist eine übergreifende funktionierende Historisierung in allen Datenbanktabellen über die gerechnet werden soll, maßgeblich. Eine funktionierende Historisierung besteht aus eindeutigen, lückenlosen und nicht überlappenden Zeitscheiben für jeden fachlichen Schlüssel. Reintechnische Zeitscheiben dienen eher der Nachvollzieharkeit von Korrekturen, sollten aber für fachlich richtige Ergebnisse nur mit neustem Stand verwendet werden. Daher betrachte ich im Folgenden nur die Erstellung einer richtigen Versionierung anhand von fachlichen "Gültig von" bis "Gültig bis" Zeiträumen.
Dies wird in der Regel über 2 weitere Schlüsselfelder im Datumsformat, welche den Gültigkeitsstart (GültigAb) und das Enddatum (GültigBis) festlegen erreicht. Deshalb muss für jeden neu erzeugten Datensatz die zugehörige alte Zeitscheibe geschlossen werden. Das Auslesen des richtigen Datensatz zum richtigen Zeitpunkt wird dann über die folgende Filterbedingung sichergestellt.
Da mir die Umsetzung einer Historisierung mittlerweile bei allen Kunden früher oder später begegnet, wollte ich mit diesem kleinen Hands on eine pragmatische Anleitung geben, wie die Historisierung nur einmal implementiert werden muss, um eine nachvollzieh- und pflegbare Lösung zu haben, aber dennoch noch weitestgehend dynamisch bleibt. Im Folgenden verwende ich die Info Objekte HDRVALTO und HDRVALFR. Wer eigene Info Objekte verwenden möchte, muss diese dann unten im Coding Beispiel noch anpassen. Ich habe dies als Public Static Methode (manage_hist) von überall aufrufbar implementiert. Als Input Parameter habe ich zum einen die Referenz auf das Result Package, der Ziel ADSO Name und Optional der Stichtag ab dem die neue Zeitscheibe generiert bzw. bis zu welchem Stichtag die alte Zeitscheibe nicht mehr gültig sein soll. In manchen Szenarien soll das Gültig von Datum aus den Daten heraus variabel generiert werden. Dies wird dann aus dem Result Package aus dem HDRVALR gelesen.
Im ersten Teil werden die einzelnen Variablen deklariert, die Referenz des Result Package mit dem Feld Symbol <lt_result> verknüpft und je nach Optionaler Input Datum Befüllung die where Bedingungen definiert um aktuelle Zeitscheiben im Ziel zu ermitteln.
Das dynamische Erzeugen des richtigen Tabellentypen, abhängig vom mitgegebenen iv_adso_name, wird dann über das Create Data Statemen, das eine Referenz vom Typ der aktiven ADSO Zieltabelle liefert vorgenommen. So erhält man die interne Tabelle vom Typ der aktiven Tabelle des Ziel ADSO durch Zusweisung der Referenz.
Anhand der SAP DDICT Tabelle DD031 lassen sich sämtliche Schlüsselfelder einer Tabelle auslesen. Wir schreiben dann alle Schlüssel in die Where Bedingungen lv_where und lv_keys.
Mit der generierten Where Bedingung können wir dann direkt die zu schließenden Zeitscheiben ermitteln und weisen diesen der Standard Tabelle <lt_hist> zu.
Jetzt werden in einer Schleife über alle zu schließenden Zeitscheiben die existierende Zeitscheibe gelöscht. Dies geschieht über das Setzen von 'D' des Recordmodes und Hinzufügen zum Resultpackage. Anschließend müssen wir für dieselbe Zeitscheibe das Gültig Bis Datum HDRVALTO entweder auf Stichtag - 1 setzten. Bei Nichtbefüllung des Datums Inputvariable wird im Resultpackage nach dem vorhandenen passenden gültig Ab gesucht und dieses einen Tag vordatiert übernommen.
Damit die Verbuchung und Aktivierung der Beladung im Ziel ADSO perfomanter ist sollte noch die Record Nummerierung neu gesetzt werden.
Die Fehlerbehandlung wird über die Print Ausgabe der Fehlermeldung nur angedeutet. Hier sollte man sich eventuell mit einer eigenen Fehlerklasse in das vorhandene Fehlermanagement integrieren.
Im folgenden stelle ich euch die gesamte Methode zum Wiederverwenden zur Verfügung.
Die Methode solltet ihr dann am Ende aller Experten-/ End-Routinen aufrufen.