Integration von Employee Central nach SAP HCM - ein Blick unter die Haube

Einführung

Wenn SAP-HCM-Kunden für globale HR-Zwecke zu SuccessFactors Employee Central (EC) wechseln, zerlegen sie ihren zentralen HR-Prozess Hire to Pay in zwei Systeme. Der Prozess wird nun zu "Hire in EC" und "Pay in SAP HCM". Eine in EC eingestellte Person findet ihren Weg nach HCM über eine Integration, die SAP als Core-Hybrid-Integration bezeichnet: Der zentrale HR-Prozess Hire to Pay wird als Hybrid aus EC und SAP HCM bereitgestellt. Dieser Blogbeitrag folgt der Reise eines Mitarbeiters von SuccessFactors nach SAP HCM.

Mitarbeiterdaten fließen von EC nach HCM

Der Fluss der Mitarbeiterdaten von EC nach HCM wird durch die folgende Architektur ermöglicht.

Bildrechte: INTEGRTR GmbH

1. Zu einer eingeplanten Tageszeit erwacht ein Job auf SAP und stößt eine Reihe von API-Aufrufen an, um Änderungen aus Employee Central (Mitarbeiter- und OM-Objekte) nach SAP zu replizieren.
2. Der Job, repräsentiert durch einen SAP-Report, ruft eine asynchrone API auf SAP Cloud Platform Integration (CPI) auf. Dabei übergibt er CPI alle notwendigen Parameter für den Aufruf an SF: welche Informationen zu holen sind, die Where-Bedingung, das Datum des letzten Laufs usw.
3. SAP Cloud Platform Integration (CPI) ist die Cloud-Middleware von SAP, die die gesamte Integration zwischen Cloud- und On-Premise-Welt orchestriert. Der im vorherigen Schritt getätigte API-Aufruf wird von CPI bedient. Die API stellt einen IFlow* voran, der API-Aufrufe an SuccessFactors bündelt und absetzt.
   * Es gibt unterschiedliche iFlows für Employee und OM. Auf SuccessFactors-Seite kommt die altbewährte Compound Employee API zum Einsatz, die Quell-API für alle Mitarbeiterdaten und -änderungen. Auf der OM-Seite wird sie durch OData-APIs ersetzt. Ein Beispielaufruf gegen die Compound Employee API, um alle deutschen Mitarbeiter ab dem 1. Januar 2020 aus SF zu holen.
   SELECT
address_information,
alternative_cost_distribution,
compensation_information,
dependent_information,
employment_information,
job_information,
national_id_card,
paycompensation_non_recurring,
paycompensation_recurring,
payment_information,
person,
personal_information
FROM
CompoundEmployee
WHERE
replicationTargetSystem = 'ERPCLNT200' AND replicationContentType = 'EMPLOYEE_MASTER_DATA' AND company_territory_code IN ('DEU') AND
selectFromDate = to_date('2020-01-01','yyyy-MM-dd') AND isContingentWorker IN ('0') AND
effective_end_date >= to_date('2020-01-01') ​
   Kurioses am Rande: Die Compound Employee API ist die einzige SOAP-API im API-Arsenal von SuccessFactors. Alle übrigen sind, nun ja, ReSTful.
4. Die Antworten dieser APIs werden transformiert, tatsächlich nur ein klein wenig*, und dann über einen On-Premise-Agenten namens SAP Cloud Connector an SAP HCM weitergereicht.* Die Antwort aus SF wird nahezu vollständig an SAP übergeben. Lediglich einige wenige Header-Parameter werden aus Audit- und Sicherheitsgründen ergänzt. SAP Cloud Connector ist ein Reverse-Proxy-Tunnel. Er sitzt in der DMZ des Kunden und erlaubt sichere Verbindungen zum SAP-HCM-System, ohne dass Ports geöffnet oder Einträge in der Allow-List der Firewall ergänzt werden müssen.
5. Auf SAP-Seite steht am empfangenden Ende dieses Aufrufs ein SOAP Web Service. Der Proxy des SOAP-Service ist das schlagende Herz der gesamten Integration. Im Fall der Mitarbeiterreplikation stößt der Proxy einen Background-RFC an und stellt ihn zur Verarbeitung in die bgRFC-Queue ein. Wenn der bgRFC verarbeitet wird, kommt die gesamte Maschinerie des Business Integration Builder (BIB, Teil des SAP-Add-ons PA_SE_IN) zum Tragen und legt den Aufruf, wenn alles nach Plan läuft, in Infotypen und Subtypen ab.
6. Im Fall von OM landet der Aufruf in einem Staging-Bereich. Ein nachgelagerter Report schreibt ihn in die PD-Infotypen HRP1000 und HRP1001. Die abweichende Auslegung für OM ergibt sich aus der Struktur von OM: Objekte und Beziehungen. Fehlt eines der Objekte, kann das DB-Update der Beziehungen fehlschlagen. Deshalb werden zunächst alle Objekte in einer Staging-Tabelle gesammelt und dann in einem Rutsch in die Datenbank geschrieben.

Design-Erkenntnisse

1. Die Integrationsarchitektur macht das asynchrone Design zur Norm, wobei die SF-API-Aufrufe die einzige Ausnahme bilden.
   1. SAP ruft CPI auf und legt sich schlafen.
   2. CPI bündelt die Aufrufe, ruft die SF-API im Sync-Modus auf, leitet die Antwort an SAP HCM weiter und macht mit dem nächsten Batch weiter.
   3. Die Web Services, die diese Informationen auf SAP-Seite entgegennehmen, sind ebenfalls asynchron. Im Fall von Employee wird ein Thread mit dem bgRFC-Aufruf gestartet, im Fall von OM wird das OM-Objekt mit sehr wenigen oder gar keinen fachlichen Prüfungen in einer Datenbanktabelle persistiert.
2. Die asynchrone Natur der Architektur baut Resilienz in die gesamte Infrastruktur ein. Ein typisches Merkmal einer hybriden Landschaft ist die Heterogenität der beteiligten APIs und Infrastrukturen. Die API in der SAP-HCM-Landschaft ist in den Ressourcen begrenzt, die sie ad hoc mobilisieren kann. On-Premise-Komponenten, sei es der Cloud Connector oder das SAP-HCM-System, können mit den unendlich skalierenden Microservice-Infrastrukturen von CPI oder SuccessFactors niemals mithalten. Das SAP-HCM-System läuft in seinem eigenen Tempo, seine Cloud-Gegenstücke in ihrem. Die asynchrone Architektur erlaubt genau diesen Luxus.
3. Einsatz des SAP Cloud Connector (CC), eines maßgeschneiderten Reverse-Proxy-Tunnels. Von SAP als "Reverse Invoke Proxy" bezeichnet, verbindet er On-Premise-Assets sicher mit der SAP Cloud Platform. Der Begriff On-Premise-Assets ist dabei wichtig, denn der CC lässt sich nicht nur zur Anbindung von SAP-ERP-/S4HANA-Systemen nutzen, sondern auch für On-Premise-LDAP, andere HTTP-Dienste und seit Kurzem sogar für SQL-Datenbanken über JDBC-Verbindungen. Es gibt weitere Wege, SAP CP sicher mit der On-Premise-Welt zu verbinden, aber keinen, der so einfach einzurichten und zu skalieren ist.
4. Nutzung von CPI als Pass-through: CPI ist eine großartige Middleware. Sie kann vieles: Prozessorchestrierung, Datentransformation, Integration und mehr. Die EC-zu-HCM-Architektur nutzt CPI jedoch geschickt vor allem als sichere Daten-Pass-through-Pipe, die sich wie ein Message Broker verhält und Aufrufe in Queues stellt und bündelt. Die gesamte Transformation erfolgt auf der ABAP-Seite über die Infrastruktur des Business Integration Builder (BIB). Für eine ABAP-lastige HCM-Beratungslandschaft ist das eine willkommene Abkehr von der früheren, middleware-lastigen Integration (< PA_SE_IN SP18). Da der CPI-Prozess zudem in einem reinen "Customizing"-Modus angeboten wird und sämtliches Customizing inzwischen auf die ABAP-Seite gewandert ist, kann SAP quartalsweise Updates an Kunden ausliefern, ohne befürchten zu müssen, eine funktionierende Integration zu zerstören.
5. Nutzung von CPI im Pub-Sub-Modus: Wird auf EC eine neue Person eingestellt, wird das New-Hire-Event an den Subscriber in CPI übergeben. Das ist die "Push"-Benachrichtigung, die Neueinstellungen und ähnliche Lifecycle-Events nahezu in Echtzeit nach SAP HCM bringt.
6. Festhalten an SOAP auf der SAP-HCM-Seite: Das niedrigste ECC-Release, das das Add-on PA_SE_IN unterstützt, ist ECC 6.0 (+SPxx). ECC 6.0 ist mindestens 12 Jahre alt. Das BASIS/NW-Release von ECC 6.0 unterstützt die neueren API-Fähigkeiten wie OData und das ReSTful Programming Model nicht. SOAP ist seit jeher fester Bestandteil des Netweaver-Kerns und benötigt keine zusätzlichen Softwarekomponenten. Wer bereit ist, über die offensichtlichen Schönheitsfehler hinwegzusehen, erhält nach der Einrichtung eine robuste Service-Konnektivität. Digitale Transformation sollte nicht den Preis eines Upgrades der bestehenden On-Premise-Infrastruktur haben, gerade wenn die Cloud der Weg nach vorn ist.
7. Kunden fragen oft: Wenn EC zu EC Payroll Punkt-zu-Punkt möglich ist, warum dann nicht EC zu SAP ERP HCM? Vieles aus dem vorherigen Punkt gilt auch hier. EC und EC Payroll werden beide in SAP-Rechenzentren betrieben, und SAP stellt sicher, dass sie stets auf dem neuesten Stand der Technologiekomponenten sind, was neuere Integrationsmodelle und -architekturen ermöglicht. Für SAP-HCM-Kunden gilt das nicht durchgängig. Es stimmt, dass viele Kunden auf den neuesten von SAP ausgelieferten Stacks unterwegs sind, aber es gibt immer Kunden, die noch auf genau jenem älteren SAP-HCM-Release sitzen. Für SAP als Anbieter, der eine Lösung für alle bauen will, ist die Architektur des PA_SE_IN-Add-ons ein Design-Trade-off.

Zusammenfassend lässt sich sagen: In den EC-zu-HCM-Integrationen passiert eine Menge. Aufgrund ihrer Design-Trade-offs hat sie ihren gerechten Anteil an Einschränkungen. Insgesamt bringt sie jedoch eine heterogene Systemwelt zusammen, um das versprochene Hire-to-Pay-Szenario zu liefern. Es wäre nicht falsch, dieses Design ein Meisterwerk der Ingenieurskunst zu nennen,