Aktualisierung der SAP SuccessFactors ECP/EC-Testumgebung

Diesen Monat haben wir bei PostNL daran gearbeitet, die Employee Central Payroll (ECP)- und Employee Central (EC)-Testumgebung zu aktualisieren. PostNL verwaltet fast 200.000 „Central Person“-Datensätze, mit mehr als einer Viertelmillion verknüpfter Employee-Datensätze – einige davon ausschließlich in ECP, die Mehrheit jedoch auch in EC.

Die Aktualisierung der EC-Instanz ist ein Service von SAP SuccessFactors, der üblicherweise im Vertrag enthalten ist. Dabei werden sämtliche Daten und Konfigurationen aus der Produktionsumgebung in die QA- oder Testumgebung übernommen. Die Herausforderung dabei ist der Umgang mit dem verknüpften Payroll-System. Eine vollständige Systemkopie kann einen erheblichen Nachbereitungsaufwand verursachen und erfordert zudem den gleichen Speicherplatz wie das Produktivsystem. Ohne eine solche Kopie entsteht jedoch eine Diskrepanz zwischen der aktualisierten EC-Instanz und den älteren Daten in ECP. Genau hier kommt EPI-USE ins Spiel – mit verschiedenen technologischen Ansätzen zur Lösung dieses Problems.

Vor vier Jahren haben wir diesen Prozess zuletzt durchgeführt und dabei den Data Sync Manager™ (DSM) Object Sync™ for SuccessFactors Add-on genutzt. So konnten wir gleichzeitig die ECP-Daten importieren und die SuccessFactors-Daten maskieren.

Dieses Mal sind wir einen anderen Weg gegangen: Statt Object Sync haben wir den Client Sync™-Engine (ebenfalls Teil der DSM Suite) verwendet, gefolgt von DSM Data Secure™ for SuccessFactors Add-on. Client Sync ist eher eine Lösung für das Basis-Team, da sie für groß angelegte Systemänderungen gedacht ist – als Alternative zu einer vollständigen Systemkopie.

Es gab zwei wesentliche Gründe für diesen neuen Ansatz:

1. Effizienz bei großen Datenmengen
   Beim Umgang mit hohen Datenvolumen ist die Client Sync-Engine auf dem ABAP-Stack die leistungsfähigere Lösung. Object Sync kann zwar ebenfalls große Datenmengen verarbeiten, arbeitet jedoch sequenziell: Es wählt einen Eintrag aus PA0003 aus, sucht dann alle zugehörigen Datensätze in anderen Tabellen und wechselt anschließend zum nächsten. Client Sync hingegen verarbeitet Tabellen blockweise, was deutlich schneller ist. Zudem kann man gezielt bestimmte Daten ausschließen – z. B. die vollständige Cluster-Historie, was bei diesem Projekt aufgrund der umfangreichen Payroll-Historie notwendig war.

2. Optimierung durch die SuccessFactors-Instanzaktualisierung
   Da SuccessFactors bereits eine Instanzaktualisierung durchlaufen hat, waren die meisten Daten bereits in der gewünschten Form vorhanden. Object Sync arbeitet mit dem vollständigen OData-Modell und beginnt bei den User-Daten, um dann alle verknüpften Entitäten wie EmpEmployment, PerPerson, PerPersonal usw. einzubeziehen. In der Praxis wurden dadurch viele Daten lediglich überschrieben, was jedoch dennoch Business Rules und andere Validierungen auslöste. Beim letzten Mal mussten wir erheblichen Aufwand betreiben, um sicherzustellen, dass die maskierten Daten korrekt übernommen wurden. Selbst wenn Validierungen kein Problem darstellen, bleibt der Performance-Aspekt: 95 % der Bearbeitungszeit entfielen auf OData API-Calls. Eine Reduzierung dieser Aufrufe verbessert somit direkt die Laufzeit.

Natürlich gibt es weiterhin zahlreiche Vorbereitungen für eine Instanzaktualisierung. Ziel dieses neuen Ansatzes ist es jedoch, den Prozess einfach wiederholbar zu machen. Nach einer initialen Implementierung und Prozessdefinition durch unser Consulting-Team könnten Kunden diesen Prozess selbst durchführen – oder alternativ unseren Managed Service in Anspruch nehmen.

Technischer Prozess: Datenaktualisierung

Wir haben den Client Sync-Export so terminiert, dass er genau zum selben Zeitpunkt lief, an dem SAP SuccessFactors das Instanz-Refresh-Image aus der Produktionsumgebung erstellte. Im Client Sync-Produkt gibt es ein spezielles „HCM only“-Profil, das es ermöglicht, ausschließlich HCM-Daten zu aktualisieren, ohne andere SAP-Bereiche zu beeinflussen. Optional könnte auch das HCM-bezogene Customizing übernommen werden, doch in diesem Fall war das nicht nötig, da das Transport Management System in ECP bereits effizient genutzt wurde.

In diesem Projekt war es entscheidend, die „Time-Slice“-Funktionalität von Client Sync zu nutzen, um nur die letzten zwei Jahre der Payroll-Cluster-Daten zu übernehmen. Ohne diese Einschränkung wäre die Datenmenge für das vorhandene QA-System zu groß gewesen.

Nach Abschluss des Exports starteten wir den Import in die QA ECP-Instanz. Idealerweise sollte das SAP Operations-Team die Datenbank-Redo-Logs deaktivieren, um die Performance zu verbessern. Falls dies nicht möglich ist, kann Client Sync durch eine reduzierte Anzahl an parallelen Prozessen gedrosselt werden. Wir haben mit vier Prozessen gearbeitet – allerdings gab es einen Punkt, an dem die Datenbank-Logs volllief. Glücklicherweise hat sich das System eigenständig erholt. Im schlimmsten Fall hätten wir auf das Operations-Team warten müssen, um die Logs zu bereinigen. Dennoch wäre die Performance deutlich besser, wenn die Logs von Beginn an deaktiviert worden wären – eine Empfehlung, die wir für Client Sync schon lange aussprechen. In diesem speziellen Anwendungsfall war jedoch mehr Flexibilität möglich, da die HCM-Datenmenge (gefiltert auf die letzten zwei Jahre) in der Regel überschaubar bleibt.

Nach Abschluss des Imports baten wir den Kunden, die Replikation zu aktivieren und zu validieren. Damit war bestätigt, dass der „Copy-Back“-Prozess erfolgreich war. Nun folgte der entscheidende Schritt: die Anonymisierung sensibler personenbezogener Daten, damit in der Testumgebung keine echten Daten vorhanden sind.

Wusstest du, dass das SAP Data Processing Agreement ausdrücklich vorschreibt, dass keine Echtdaten in einem Testsystem vorhanden sein dürfen? Paul hat dazu vor ein paar Jahren einen Blogbeitrag verfasst. SuccessFactors bietet zwar einige Maskierungsfunktionen, aber diese decken nicht die komplexen Payroll-Daten in ECP ab – insbesondere die Cluster-Daten. Deshalb benötigten wir für diesen Schritt ein weiteres Modul aus der DSM Suite.

Technischer Prozess: Datenmaskierung

Die DSM Data Secure™ for SuccessFactors Add-on-Funktionalität wurde erst einige Jahre nach Object Sync for SuccessFactors eingeführt und erweitert die ABAP-Stack Data Secure Scrambling Engine um die Möglichkeit, anonymisierte Werte über die OData API an Employee Central (EC) zurückzusenden. In diesem Prozess haben wir diese Lösung erstmals genutzt.

1. Erstellung einer Worklist für die Maskierung

Aus dem aktualisierten Client haben wir eine Worklist mit Central Person-Nummern erstellt. Die Maskierung basiert auf dieser Liste, um sicherzustellen, dass alle mit einer Person verknüpften Beschäftigungsverhältnisse (mehrere Pernrs für eine Person) gemeinsam verarbeitet werden und identische Werte erhalten.

2. Testen der Maskierungsrichtlinie

Bevor wir große Datenmengen verarbeitet haben, haben wir die Maskierung zunächst mit einer kleinen Gruppe von Mitarbeitern getestet. Dabei wurde sichergestellt, dass:

• Die gewünschten Änderungen korrekt angewendet wurden
• ECP-Daten vollständig aktualisiert wurden (Infotypen, Namen, Adressen etc.)
• Die geänderten Daten auch in die Payroll-Cluster und de-geclusterten Payroll-Ergebnisse übernommen wurden

Ein weiterer Vorteil der Begrenzung auf die letzten zwei Jahre der Payroll-Historie war, dass es insgesamt weniger Daten zu maskieren gab.

3. Verarbeitung und Skalierung

Die Maskierung wurde über mehrere Hintergrundprozesse verteilt und konnte bei OData-API-Fehlern jederzeit fortgesetzt werden. Optimale Ergebnisse wurden erzielt, indem die Daten in Gruppen von 5000 bis 10.000 Mitarbeitern aufgeteilt und mit 4 bis 6 parallelen Prozessen pro Durchgang verarbeitet wurden.

4. Umgang mit OData-API-Fehlern und Dateninkonsistenzen

In der Praxis treten bei der OData API gelegentlich Fehler auf, was dazu führen kann, dass Daten in ECP korrekt maskiert werden, aber nicht vollständig in EC – insbesondere Namen.

Die Data Secure-Engine verwendet ein „If same – keep same“-Prinzip. Das bedeutet, dass Inkonsistenzen beibehalten werden, wenn eine Abweichung zwischen den beiden Systemen entsteht. Um das zu vermeiden, haben wir eine zweistufige Maskierungsmethode entwickelt:

1. Zunächst wurden alle betroffenen Mitarbeiter auf einen festen Wert (z. B. „John Doe“) maskiert, um die Daten abzugleichen.
2. Danach wurde eine erneute Maskierung mit zufällig generierten Namen durchgeführt.

Zusätzlich haben wir ein Utility-Tool entwickelt, das alle betroffenen Datensätze identifiziert. Dieses wird in Kürze als Standardfunktion in DSM integriert.

Mit diesem Ansatz konnten wir eine vollständig synchronisierte und anonymisierte Testumgebung sicherstellen, ohne gegen Datenschutzrichtlinien zu verstoßen.

Die Extras

Die Extras

Bei unserem letzten Durchlauf haben wir einige zusätzliche Utility-Tools entwickelt, um verbleibende Herausforderungen nach dem Instance Refresh zu bewältigen.

Ein wichtiges Beispiel sind Links zu Dokumenten. Die eigentlichen Dokumente werden durch ein Dummy-Dokument ersetzt, aber die Dokumenttitel bleiben bestehen. Mithilfe der EPI-USE Labs Library Code zur Erstellung gezielter OData-Requests konnten wir bestimmte Dokumenttypen löschen, die sensible Daten im Namen enthalten könnten – z. B. „Jane Does Arztbescheinigung“ oder disziplinarische Dokumente.

Ein weiteres Utility wurde für die Löschung von Profilbildern benötigt. Während SAP die Option bietet, Profilfotos während des Instance Refresh zu entfernen, hatten einige Mitarbeitende nicht nur ihr Profilbild, sondern auch ihren gesamten Hintergrund als persönliches Foto hinterlegt. Ein generationelles Phänomen…

Mein persönliches Lieblings-Extra: Vor unserem ersten Instance Refresh nutzte die Organisation einen speziellen Payroll-Bereich, der Daten aus dem ursprünglichen Datenimport enthielt. Diese Daten wurden manuell gepflegt und dienten als leicht unterscheidbares Testset. Da jedoch reale Schlüsselwerte verwendet wurden, kam es zu Konflikten mit den echten Daten, die wir per Object Sync übertrugen.

Anstatt diese alten Testdaten beizubehalten, entwickelten wir eine individuelle Konvertierung, mit der beliebige Mitarbeiter diesem speziellen Payroll-Bereich zugeordnet werden können – so entsteht ein separates Testset. Falls erforderlich, lassen sich die Mitarbeiter jederzeit aus der Produktion erneut kopieren, wobei die Data Secure-Maskierungsrichtlinie angewendet wird, um sie aus dem Testbereich zurück in den realen Payroll-Bereich zu überführen.

Das war unsere Geschichte. Wie gehst du damit um?

Wenn du EC und ECP (oder sogar eine On-Premise-Payroll, die mit EC verbunden ist) nutzt, wie gehst du dann mit der Aktualisierung des ABAP-Systems um, wenn du ein Instance Refresh auf EC durchführst? Für kleinere Organisationen mit nur ein paar tausend Mitarbeitenden könnte ein SAP-Client-Kopie ausreichen. Wenn jedoch deine Payroll in einem System mit vollständigen FI/LO-Daten betrieben wird, könnte es sein, dass du auf eine vollständige Systemkopie zurückgreifen musst.

Mit DSM (Data Sync Manager) könnten wir eine Systemkopie vermeiden und nur die für HCM relevanten Daten übertragen. Außerdem könnten wir die Payroll- und Zeitdaten filtern, sodass nur die letzten zwei Jahre der Daten übertragen werden. Aber nachdem du die Daten hast, was ist mit dem Datenschutz? Oder behältst du immer produktionsähnliche Berechtigungen in den Testsystemen bei?