Wie Sie wissen, bietet SAP eine umfassende Softwarepalette sowohl für die Pflege von Transaktionsdaten als auch für die Verarbeitung dieser Daten in Analyse- und Reportingsystemen an. Insbesondere die Plattform SAP Business Warehouse (SAP BW) ist ein Toolkit zur Speicherung und Analyse von Daten mit umfangreichen technischen Möglichkeiten. Trotz all seiner objektiven Vorteile hat das SAP BW-System einen wesentlichen Nachteil. Dies stellt einen hohen Aufwand für die Speicherung und Verarbeitung von Daten dar, der sich insbesondere bei der Verwendung von cloudbasiertem SAP BW auf Hana bemerkbar macht.
Was wäre, wenn Sie ein Nicht-SAP-Produkt und vorzugsweise ein OpenSource-Produkt als Speicher verwenden würden? Wir von der X5 Retail Group haben uns für GreenPlum entschieden. Dies löst natürlich das Kostenproblem, aber gleichzeitig treten sofort Probleme auf, die bei der Verwendung von SAP BW fast standardmäßig gelöst wurden.
Wie kann man insbesondere Daten aus Quellsystemen abrufen, bei denen es sich zumeist um SAP-Lösungen handelt?
HR Metrics war das erste Projekt, bei dem es notwendig war, dieses Problem zu lösen. Unser Ziel war es, ein Repository für HR-Daten zu erstellen und analytische Berichte im Bereich der Arbeit mit Mitarbeitern zu erstellen. Die Hauptdatenquelle ist in diesem Fall das Transaktionssystem SAP HCM, in dem alle Personal-, Organisations- und Gehaltsaktivitäten abgewickelt werden.
Datenextraktion
Im SAP BW gibt es Standard-Datenextraktoren für SAP-Systeme. Diese Extraktoren können automatisch die erforderlichen Daten sammeln, deren Integrität überwachen und Änderungsdeltas ermitteln. Hier ist beispielsweise die Standarddatenquelle für Mitarbeiterattribute 0EMPLOYEE_ATTR:
Das Ergebnis der Datenextraktion daraus für einen Mitarbeiter:
Bei Bedarf kann ein solcher Extraktor an die eigenen Anforderungen angepasst oder ein eigener Extraktor erstellt werden.
Die erste Idee, die entstand, war die Möglichkeit einer Wiederverwendung. Leider stellte sich heraus, dass dies eine unmögliche Aufgabe war. Der größte Teil der Logik ist auf der Seite von SAP BW implementiert und es war nicht möglich, den Extraktor an der Quelle problemlos von SAP BW zu trennen.
Es wurde klar, dass wir einen eigenen Mechanismus zum Extrahieren von Daten aus SAP-Systemen entwickeln mussten.
Datenspeicherstruktur in SAP HCM
Um die Anforderungen an einen solchen Mechanismus zu verstehen, müssen wir zunächst bestimmen, welche Daten wir benötigen.
Die meisten Daten in SAP HCM werden in flachen SQL-Tabellen gespeichert. Basierend auf diesen Daten visualisieren SAP-Anwendungen dem Benutzer Organisationsstrukturen, Mitarbeiter und andere HR-Informationen. So sieht beispielsweise die Organisationsstruktur in SAP HCM aus:
Physisch wird ein solcher Baum in zwei Tabellen gespeichert – in hrp1000-Objekten und in hrp1001 den Verbindungen zwischen diesen Objekten.
Objekte „Abteilung 1“ und „Büro 1“:
Beziehung zwischen Objekten:
Es kann eine große Anzahl beider Arten von Objekten und Arten von Verbindungen zwischen ihnen geben. Es gibt sowohl Standardverbindungen zwischen Objekten als auch maßgeschneiderte Verbindungen für Ihre spezifischen Anforderungen. Beispielsweise weist die Standardbeziehung B012 zwischen einer Organisationseinheit und einer Vollzeitstelle auf den Leiter einer Abteilung hin.
Manageranzeige in SAP:
Speicherung in einer Datenbanktabelle:
Mitarbeiterdaten werden in pa*-Tabellen gespeichert. In der Tabelle pa0000 werden beispielsweise Daten zu Personalveranstaltungen eines Mitarbeiters abgelegt
Wir haben beschlossen, dass GreenPlum „Rohdaten“ verwenden wird, d. h. Kopieren Sie sie einfach aus SAP-Tabellen. Und direkt in GreenPlum werden sie verarbeitet und in physische Objekte (z. B. Abteilung oder Mitarbeiter) und Kennzahlen (z. B. durchschnittliche Mitarbeiterzahl) umgewandelt.
Es wurden etwa 70 Tabellen definiert, deren Daten an GreenPlum übertragen werden müssen. Anschließend begannen wir mit der Ausarbeitung einer Methode zur Übermittlung dieser Daten.
SAP bietet eine recht große Anzahl an Integrationsmechanismen. Der einfachste Weg besteht jedoch darin, dass der direkte Zugriff auf die Datenbank aufgrund von Lizenzbeschränkungen verboten ist. Daher müssen alle Integrationsflüsse auf der Ebene des Anwendungsservers implementiert werden.
Das nächste Problem war der Mangel an Daten über gelöschte Datensätze in der SAP-Datenbank. Wenn Sie eine Zeile in der Datenbank löschen, wird diese physisch gelöscht. Diese. die Bildung eines Änderungsdeltas basierend auf dem Änderungszeitpunkt war nicht möglich.
Natürlich verfügt SAP HCM über Mechanismen zur Aufzeichnung von Datenänderungen. Für die spätere Übermittlung an Empfängersysteme gibt es beispielsweise Änderungszeiger, die etwaige Änderungen aufzeichnen und auf deren Grundlage ein IDoc (ein Objekt zur Übermittlung an externe Systeme) gebildet wird.
Beispiel-IDoc zur Änderung des Infotyps 0302 für einen Mitarbeiter mit der Personalnummer 1251445:
Oder Protokolle von Datenänderungen in der DBTABLOG-Tabelle führen.
Ein Beispiel für ein Protokoll zum Löschen eines Datensatzes mit dem Schlüssel QK53216375 aus der Tabelle hrp1000:
Allerdings stehen diese Mechanismen nicht für alle notwendigen Daten zur Verfügung und ihre Verarbeitung auf der Ebene des Anwendungsservers kann recht viele Ressourcen verbrauchen. Daher kann die massive Aktivierung der Protokollierung aller erforderlichen Tabellen zu einer spürbaren Verschlechterung der Systemleistung führen.
Das nächste große Problem waren Cluster-Tabellen. Zeitschätzungs- und Lohnabrechnungsdaten werden in der RDBMS-Version von SAP HCM als Satz logischer Tabellen für jeden Mitarbeiter und für jede Berechnung gespeichert. Diese logischen Tabellen werden als Binärdaten in der Tabelle pcl2 gespeichert.
Gehaltsabrechnungscluster:
Daten aus geclusterten Tabellen können nicht als SQL-Befehl betrachtet werden, sondern erfordern die Verwendung von SAP HCM-Makros oder speziellen Funktionsmodulen. Dementsprechend wird die Lesegeschwindigkeit solcher Tabellen recht gering sein. Andererseits speichern solche Cluster Daten, die nur einmal im Monat benötigt werden – die endgültige Gehaltsabrechnung und die Zeitschätzung. Geschwindigkeit ist in diesem Fall also nicht so entscheidend.
Bei der Prüfung der Optionen zur Bildung eines Deltas von Datenänderungen haben wir beschlossen, auch die Option einer vollständigen Entladung in Betracht zu ziehen. Die Möglichkeit, jeden Tag Gigabytes unveränderter Daten zwischen Systemen zu übertragen, sieht möglicherweise nicht gut aus. Es bietet jedoch auch eine Reihe von Vorteilen: Es ist nicht erforderlich, sowohl das Delta auf der Quellseite als auch die Einbettung dieses Deltas auf der Empfängerseite zu implementieren. Dementsprechend werden Kosten und Implementierungszeit reduziert und die Zuverlässigkeit der Integration erhöht. Gleichzeitig wurde festgestellt, dass nahezu alle Änderungen im SAP HR innerhalb eines Horizonts von drei Monaten vor dem aktuellen Datum erfolgen. Daher entschied man sich für einen täglichen Volldownload der Daten aus SAP HR N Monate vor dem aktuellen Datum und einen monatlichen Volldownload. Der N-Parameter hängt von der jeweiligen Tabelle ab
und reicht von 1 bis 15.
Für die Datenextraktion wurde folgendes Schema vorgeschlagen:
Das externe System generiert eine Anfrage und sendet diese an SAP HCM, wo diese Anfrage auf Vollständigkeit der Daten und Berechtigungen zum Zugriff auf Tabellen überprüft wird. Bei erfolgreicher Prüfung führt SAP HCM ein Programm aus, das die notwendigen Daten sammelt und an die Fuse-Integrationslösung übergibt. Fuse ermittelt das benötigte Topic in Kafka und überträgt die Daten dorthin. Anschließend werden die Daten von Kafka an Stage Area GP übertragen.
In dieser Kette interessiert uns die Frage der Datenextraktion aus SAP HCM. Schauen wir es uns genauer an.
SAP HCM-FUSE-Interaktionsdiagramm.
Das externe System ermittelt den Zeitpunkt der letzten erfolgreichen Anfrage an SAP.
Der Prozess kann durch einen Timer oder ein anderes Ereignis gestartet werden, einschließlich der Festlegung eines Timeouts, um auf eine Antwort mit Daten von SAP zu warten und eine Wiederholungsanfrage zu initiieren. Anschließend generiert es eine Delta-Anfrage und sendet diese an SAP.
Die Anforderungsdaten werden im JSON-Format an den Body gesendet.
Methode http: POST.
Anfragebeispiel:
Der SAP-Service überwacht die Anfrage auf Vollständigkeit, Einhaltung der aktuellen SAP-Struktur und Verfügbarkeit der Zugriffsberechtigung auf die angeforderte Tabelle.
Im Fehlerfall gibt der Dienst eine Antwort mit dem entsprechenden Code und der entsprechenden Beschreibung zurück. Wenn die Steuerung erfolgreich ist, wird ein Hintergrundprozess zum Generieren eines Beispiels erstellt, eine eindeutige Sitzungs-ID generiert und synchron zurückgegeben.
Tritt ein Fehler auf, zeichnet das externe System diesen im Protokoll auf. Im Falle einer erfolgreichen Antwort übermittelt es die Session-ID und den Namen der Tabelle, für die die Anfrage gestellt wurde.
Das externe System registriert die aktuelle Sitzung als geöffnet. Wenn für diese Tabelle andere Sitzungen vorhanden sind, werden diese mit einer protokollierten Warnung geschlossen.
Der SAP-Hintergrundjob generiert einen Cursor basierend auf den angegebenen Parametern und einem Datenpaket der angegebenen Größe. Die Stapelgröße ist die maximale Anzahl von Datensätzen, die ein Prozess aus der Datenbank liest. Standardmäßig wird ein Wert von 2000 angenommen. Wenn die Datenbankstichprobe mehr Datensätze enthält 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 Zahlen werden um 1 erhöht und streng sequentiell gesendet.
Anschließend übergibt SAP das Paket als Eingabe an den Webservice des externen Systems. Und das System führt Kontrollen für das eingehende Paket durch. Eine Sitzung mit der empfangenen ID muss im System registriert sein und sich im offenen Status befinden. Wenn die Paketnummer > 1 ist, sollte das System den erfolgreichen Empfang des vorherigen Pakets (Paket_ID-1) protokollieren.
Bei erfolgreicher Steuerung analysiert und speichert das externe System die Tabellendaten.
Wenn außerdem das Flag „final“ im Paket vorhanden ist und die Serialisierung erfolgreich war, wird das Integrationsmodul über den erfolgreichen Abschluss der Sitzungsverarbeitung benachrichtigt und das Modul aktualisiert den Sitzungsstatus.
Im Falle eines Kontroll-/Parsing-Fehlers wird der Fehler protokolliert und Pakete für diese Sitzung werden vom externen System abgelehnt.
Ebenso wird im umgekehrten Fall, wenn das externe System einen Fehler zurückgibt, dieser protokolliert und die Paketübertragung gestoppt.
Um Daten auf der SAP HСM-Seite anzufordern, wurde ein Integrationsdienst implementiert. Der Dienst ist auf dem ICF-Framework (SAP Internet Communication Framework - ). Es ermöglicht die Abfrage von Daten aus dem SAP HCM-System anhand spezifischer Tabellen. Beim Erstellen einer Datenanfrage besteht die Möglichkeit, eine Liste spezifischer Felder und Filterparameter anzugeben, um die erforderlichen Daten zu erhalten. Gleichzeitig impliziert die Implementierung des Dienstes keine Geschäftslogik. Auch Algorithmen zur Deltaberechnung, Abfrageparameter, Integritätsüberwachung etc. sind auf der Seite des externen Systems implementiert.
Dieser Mechanismus ermöglicht es Ihnen, alle notwendigen Daten in wenigen Stunden zu sammeln und zu übertragen. Da diese Geschwindigkeit nahezu akzeptabel ist, betrachten wir diese Lösung als vorübergehende Lösung, die es ermöglichte, den Bedarf an einem Extraktionstool für das Projekt zu decken.
Im Zielbild werden zur Lösung des Problems der Datenextraktion Optionen für den Einsatz von CDC-Systemen wie Oracle Golden Gate oder ETL-Tools wie SAP DS untersucht.
Source: habr.com