Wie bekannt ist, bietet das Unternehmen SAP ein vollständiges Spektrum an Software an, sowohl für die Durchführung von Transaktionsdaten als auch für die Verarbeitung dieser Daten in Analyse- und Berichtssystemen. Insbesondere stellt die SAP Business Warehouse-Plattform (SAP BW) ein Werkzeug zur Speicherung und Analyse von Daten dar, das über umfangreiche technische Möglichkeiten verfügt. Trotz aller objektiven Vorteile hat das System SAP BW einen erheblichen Nachteil. Dies ist die hohe Kosten für die Speicherung und Verarbeitung von Daten, die insbesondere bei der Nutzung der Cloud SAP BW on HANA auffällt.
Was wäre, wenn wir als Speichermedium ein non-SAP-Produkt, vorzugsweise OpenSource, verwenden würden? Wir bei X5 Retail Group haben uns für GreenPlum entschieden. Das löst natürlich das Kostenproblem, bringt aber sofort Fragen auf, die bei der Verwendung von SAP BW praktisch automatisch gelöst wurden.
Insbesondere, wie Daten aus den Quellsystemen abgerufen werden sollen, die überwiegend SAP-Lösungen sind?
Die "HR-Metriken" waren das erste Projekt, in dem dieses Problem gelöst werden musste. Unser Ziel war die Schaffung eines HR-Datenlagers und die Erstellung von Analyseberichten über die Arbeit mit Mitarbeitern. Dabei ist das Hauptdatenquelle das Transaktionssystem SAP HCM, in dem alle Personal-, Organisations- und Gehaltsvorgänge verwaltet werden.
Datenextraktion
In SAP BW gibt es standardisierte Datenextraktoren für SAP-Systeme. Diese Extraktoren können automatisch die erforderlichen Daten sammeln, ihre Integrität überwachen und Änderungen identifizieren. Hier ist beispielsweise die Standarddatenquelle für Mitarbeiterattribute 0EMPLOYEE_ATTR:
Das Ergebnis der Datenextraktion aus diesem für einen Mitarbeiter:
Bei Bedarf kann ein solcher Extraktor an die eigenen Anforderungen angepasst oder ein eigener Extraktor erstellt werden.
Zunächst wurde die Idee entwickelt, ihre Wiederverwendbarkeit zu prüfen. Leider stellte sich das als unerfüllbare Aufgabe heraus. Ein Großteil der Logik ist auf der Seite von SAP BW implementiert, und es war nicht möglich, den Extraktor am Quellsystem schmerzfrei von SAP BW zu trennen.
Es wurde offensichtlich, dass die Entwicklung eines eigenen Mechanismus zur Datenextraktion aus SAP-Systemen erforderlich sein würde.
Die Datenstruktur in SAP HCM
Um die Anforderungen an einen solchen Mechanismus zu verstehen, müssen zunächst die genauen Daten bestimmt werden, die wir benötigen.
Die meisten Daten in SAP HCM werden in flachen SQL-Tabellen gespeichert. Basierend auf diesen Daten visualisieren SAP-Anwendungen dem Benutzer die Organisationsstrukturen, Mitarbeiter und andere HR-Informationen. So sieht beispielsweise die Organisationsstruktur in SAP HCM aus:
Physisch wird ein solches Baumdiagramm in zwei Tabellen gespeichert – in hrp1000 die Objekte und in hrp1001 die Beziehungen zwischen diesen Objekten.
Objekte „Abteilung 1“ und „Leitung 1“:
Beziehung zwischen den Objekten:
Es kann eine immense Anzahl an Objektarten sowie Beziehungstypen zwischen ihnen geben. Sowohl Standardbeziehungen zwischen Objekten als auch angepasste für spezifische Bedürfnisse existieren. Zum Beispiel gibt die Standardbeziehung B012 zwischen der Organisationseinheit und der Stellenbeschreibung den Leiter der Abteilung an.
Darstellung des Leiters in SAP:
Speicherung in der Datenbanktabelle:
Mitarbeiterdaten werden in Tabellen pa* gespeichert. Beispielsweise werden Daten über Personalmaßnahmen für einen Mitarbeiter in der Tabelle pa0000 gespeichert.
Wir haben beschlossen, dass GreenPlum die „rohen“ Daten abruft, d.h. sie einfach aus den SAP-Tabellen kopiert. Und direkt in GreenPlum werden sie verarbeitet und in physische Objekte (z.B. Abteilung oder Mitarbeiter) und Kennzahlen (z.B. durchschnittliche Anzahl von Beschäftigten) umgewandelt.
Es wurden etwa 70 Tabellen definiert, deren Daten in GreenPlum übertragen werden müssen. Danach haben wir begonnen, einen Übertragungsweg für diese Daten zu erarbeiten.
SAP bietet eine Vielzahl von Integrationsmechanismen an. Der einfachste Weg – direkter Datenbankzugriff – ist aufgrund von Lizenzbeschränkungen nicht erlaubt. Daher müssen alle Integrationsströme auf Anwendungsebene realisiert werden. Server Anwendungen.
Ein weiteres Problem war das Fehlen von Daten über gelöschte Datensätze in der SAP-Datenbank. Beim Löschen einer Zeile in der Datenbank wird diese physisch gelöscht. Das heißt, die Bildung einer Delta-Änderung über den Zeitpunkt der Änderung war nicht möglich.
Natürlich gibt es in SAP HCM Mechanismen zur Feststellung von Datenänderungen. Beispielsweise gibt es für die anschließende Übertragung an empfangende Systeme Änderungszeiger (change pointer), die alle Änderungen erfassen und auf deren Grundlage Idocs (Objekt zur Übertragung an externe Systeme) gebildet werden.
Beispiel für die IDoc-Änderung des Infotyps 0302 für einen Mitarbeiter mit der Personalnummer 1251445:
Oder die Führung von Änderungsprotokollen in der Tabelle DBTABLOG.
Beispiel für ein Protokoll zur Löschung eines Eintrags mit dem Schlüssel QK53216375 aus der Tabelle hrp1000:
Aber diese Mechanismen sind nicht für alle benötigten Daten verfügbar, und ihre Verarbeitung auf der Ebene des Anwendungsservers kann recht ressourcenintensiv sein. Daher kann eine massenhafte Aktivierung der Protokollierung für alle erforderlichen Tabellen zu einer merklichen Leistungsverschlechterung des Systems führen.
Ein weiteres ernstes Problem waren die Cluster-Tabellen. Die Daten zur Zeitbewertung und zur Gehaltsberechnung in der RDBMS-Version SAP HCM werden als eine Reihe logischer Tabellen für jeden Mitarbeiter für jede Abrechnung gespeichert. Diese logischen Tabellen werden in Form von binären Daten in der Tabelle pcl2 gespeichert.
Gehaltsabrechnungscluster:
Die Daten aus Cluster-Tabellen können nicht mit einem SQL-Befehl gelesen werden, sondern erfordern die Verwendung von SAP HCM-Makrobefehlen oder speziellen Funktionsmodulen. Dementsprechend wird die Lesegeschwindigkeit solcher Tabellen relativ niedrig sein. Andererseits enthalten solche Cluster Daten, die nur einmal im Monat benötigt werden – die endgültige Gehaltsabrechnung und die Zeitbewertung. Daher ist die Geschwindigkeit in diesem Fall nicht so kritisch.
Bei der Bewertung der Optionen zur Bildung einer Delta-Änderung der Daten wurde auch die Option einer vollständigen Auslagerung in Betracht gezogen. Die Option, täglich Gigabytes unveränderter Daten zwischen den Systemen zu übertragen, kann nicht ansprechend wirken. Sie hat jedoch auch eine Reihe von Vorteilen – es ist weder notwendig, das Delta auf der Quellseite zu implementieren, noch es auf der Zielseite einzugliedern. Entsprechend sinken die Kosten und die Implementierungszeit, und die Zuverlässigkeit der Integration steigt. Es wurde festgestellt, dass praktisch alle Änderungen in SAP HR innerhalb eines Zeitraums von drei Monaten bis zum aktuellen Datum stattfinden. Daher wurde beschlossen, eine tägliche vollständige Auslagerung der Daten aus SAP HR für N Monate vor dem aktuellen Datum und eine monatliche vollständige Auslagerung durchzuführen. Der Parameter N hängt von der jeweiligen Tabelle ab.
und variiert zwischen 1 und 15.
Für die Datenextraktion wurde folgendes Schema vorgeschlagen:
Das externe System erstellt eine Anfrage und sendet sie an SAP HCM, wo die Anfrage auf Vollständigkeit der Daten und Berechtigungen zum Zugriff auf die Tabellen überprüft wird. Bei erfolgreicher Prüfung führt SAP HCM ein Programm aus, das die erforderlichen Daten sammelt und an die Integrationslösung Fuse überträgt. Fuse bestimmt das notwendige Thema in Kafka und überträgt die Daten dorthin. Anschließend werden die Daten aus Kafka in den Stage Area GP überführt.
Für uns in dieser Kette ist die Frage der Datenextraktion aus SAP HCM von Interesse. Lassen Sie uns näher darauf eingehen.
Schema der Interaktion zwischen SAP HCM und FUSE.
Das externe System bestimmt die Zeit der letzten erfolgreichen Anfrage in SAP.
Der Prozess kann durch einen Timer oder ein anderes Ereignis ausgelöst werden, es kann auch eine Timeout-Wartezeit für die Antwort mit den Daten von SAP festgelegt werden, gefolgt von der Initiierung einer erneuten Anfrage. Danach wird eine Delta-Anfrage erstellt und an SAP gesendet.
Die Daten der Anfrage werden im Body im JSON-Format übermittelt.
HTTP-Methode: POST.
Beispiel einer Anfrage:
Der SAP-Dienst führt eine Kontrolle der Anfrage auf Vollständigkeit, Übereinstimmung mit der aktuellen SAP-Struktur und das Vorhandensein von Zugriffsrechten auf die angeforderte Tabelle durch.
Im Fehlerfall gibt der Dienst eine Antwort mit dem entsprechenden Code und einer Beschreibung zurück. Bei erfolgreicher Kontrolle wird ein Hintergrundprozess zur Erstellung der Auswahl erstellt, ein einzigartiger Sitzungs-ID wird generiert und synchron zurückgegeben.
Im Fehlerfall registriert das externe System diesen im Protokoll. Bei erfolgreicher Antwort überträgt es die Sitzungs-ID und den Namen der Tabelle, auf die die Anfrage gerichtet war.
Das externe System registriert die aktuelle Sitzung als offen. Wenn es andere Sitzungen für diese Tabelle gibt, werden diese mit einer Warnung im Protokoll geschlossen.
Der Hintergrundjob von SAP erstellt einen Cursor basierend auf den angegebenen Parametern und ein Paket von Daten einer bestimmten Größe. Die Paketgröße entspricht der maximalen Anzahl von Datensätzen, die der Prozess aus der Datenbank liest. Standardmäßig wird sie auf 2000 festgelegt. Wenn es in der Datenbankauswahl mehr Datensätze gibt als die verwendete Paketgröße, wird nach der Übertragung des ersten Pakets der nächste Block mit dem entsprechenden Offset und der inkrementierten Paketnummer gebildet. Die Nummern werden um 1 inkrementiert und strikt nacheinander gesendet.
Dann übergibt SAP das Paket an den Eingang des Webdienstes des externen Systems. Dieses System führt Überprüfungen des eingehenden Pakets durch. Eine Sitzung mit der erhaltenen ID muss im System registriert und im offenen Status sein. Wenn die Paketnummer > 1 ist, muss im System der erfolgreiche Empfang des vorherigen Pakets (package_id-1) registriert sein.
Im Falle einer erfolgreichen Überprüfung parst und speichert das externe System die Daten aus der Tabelle.
Zusätzlich, wenn im Paket das Flag final vorhanden ist und die Serialisierung erfolgreich war, wird das Integrationsmodul über den erfolgreichen Abschluss der Sitzungsbearbeitung benachrichtigt, und das Modul aktualisiert den Status der Sitzung.
Im Falle eines Fehlers bei den Kontrollen/Parsing wird der Fehler protokolliert, und Pakete für diese Sitzung werden vom externen System abgelehnt.
Ebenso im umgekehrten Fall, wenn das externe System einen Fehler zurückgibt, wird dieser protokolliert und die Übertragung von Paketen wird eingestellt.
Für die Abfrage von Daten im SAP HCM wurde ein Integrationsdienst implementiert. Der Dienst basiert auf dem ICF-Framework (SAP Internet Communication Framework - ). Er ermöglicht die Abfrage von Daten aus dem SAP HCM-System aus bestimmten Tabellen. Bei der Bildung der Datenanfrage gibt es die Möglichkeit, eine Liste spezifischer Felder und Filterparameter festzulegen, um die benötigten Daten zu erhalten. Dabei sieht die Implementierung des Dienstes keine Geschäftslogik vor. Algorithmen zur Berechnung der Delta-Werte, der Abfrageparameter, der Integritätskontrolle usw. werden ebenfalls im externen System implementiert.
Dieser Mechanismus ermöglicht es, alle benötigten Daten innerhalb von wenigen Stunden zu sammeln und zu übertragen. Diese Geschwindigkeit ist an der Grenze des Akzeptablen, weshalb diese Lösung von uns als vorübergehend betrachtet wird, um den Bedarf an einem Extraktionstool im Projekt zu decken.
In dem Zielbild zur Lösung der Datenextraktionsaufgabe werden Optionen zur Nutzung von CDC-Systemen wie Oracle Golden Gate oder ETL-Tools wie SAP DS erarbeitet.
Quelle: habr.com
