Employee Central zu SAP HCM Integration - Unter der Haube

Von Girish Bangalore

Employee Central zu SAP HCM Integration - Unter der Haube

Von Girish Bangalore

Einführung

Wenn SAP HCM-Kunden für globale HR-Zwecke zu SuccessFactors Employee Central (EC) wechseln, können sie Pause ihren HR-Kernprozess "Hire to Pay" in zwei Systeme auf. Der Prozess wird nun zu "Hire in EC" und "Pay in SAP HCM". Ein in EC eingestellter Mitarbeiter findet seinen Weg in HCM über eine Integration, die SAP als Core Hybrid Integration bezeichnet - der HR-Kernprozess von Hire to Pay wird mit einem Hybrid aus EC und SAP HCM bereitgestellt. Dieser Blog verfolgt die Reise eines Mitarbeiters von SuccessFactors zu SAP HCM.

Mitarbeiterdaten fließen von EC zu HCM

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

Bildrechte: INTEGRTR GmbH

  1. Zu einem bestimmten Zeitpunkt des Tages wacht ein Job in SAP auf und löst eine Reihe von API-Aufrufen aus, um Änderungen in Employee Central (Mitarbeiter- und OM-Objekte) in SAP zu replizieren.
  2. Der Auftrag, der durch einen SAP-Bericht dargestellt wird, ruft eine asynchrone API auf der SAP Cloud Platform Integration (CPI) auf. Dabei übergibt er CPI alle notwendigen Parameter in Bezug auf die abzurufenden Informationen, die Where-Klausel, das Datum der letzten Ausführung usw., um einen Aufruf an SF zu tätigen.
  3. SAP Cloud Platform Integration (CPI) ist die Cloud-Middleware von SAP, die die gesamte Integration zwischen der Cloud und der On-Premise-Welt orchestriert. Der API-Aufruf aus dem vorherigen Aufruf wird von CPI bedient. An der API-Front endet ein IFlow*, der API-Aufrufe an SuccessFactors stapelt und ausgibt.
    * Es gibt verschiedene iFlows für Employee und OM. Bei SuccessFactors ist die ehrwürdige Compound Employee API 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 aus SF ab dem 1. Januar 2020 abzurufen.
    SELECT
    Adresse_Information,
    alternative_kosten_verteilung,
    Vergütung_Information,
    abhängige_Informationen,
    beschäftigung_information,
    job_information,
    nationale_id_karte,
    Lohnausgleich_einmalig,
    Lohnausgleich_wiederkehrend,
    Zahlungsinformationen,
    Person,
    persönliche_Informationen
    VON
    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
    Datum des Gültigkeitsendes >= Datum bis('2020-01-01')
    Lustige Tatsache: Die Compound Employee API ist die einzige SOAP-API im API-Arsenal von SuccessFactors. Die anderen sind, nun ja, ReSTful-artig.
  4. Die Antwort von diesen APIs wird umgewandelt, und zwar nur ein wenig*, und dann über einen On-Premise-Agenten namens SAP Cloud Connector an SAP HCM weitergeleitet.* Die Antwort von SF wird fast vollständig an SAP weitergeleitet. Nur einige Kopfparameter werden aus Prüfungs- und Sicherheitsgründen hinzugefügt.SAP Cloud Connector ist ein Reverse-Proxy-Tunnel. Er befindet sich in der DMZ des Kunden und ermöglicht sichere Verbindungen zum SAP HCM-System, ohne dass irgendwelche Ports geöffnet oder die Erlaubnisliste der Firewall ergänzt werden muss.
  5. Auf der SAP-Seite, dem empfangenden Ende dieses Aufrufs, befindet sich ein SOAP-Webdienst. Der Proxy des SOAP-Dienstes ist das Herzstück der gesamten Integration. Im Falle der Mitarbeiterreplikation erzeugt der Proxy einen Hintergrund-RFC und stellt ihn in die bgRFC-Warteschlange zur Verarbeitung 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, wenn alles nach Plan läuft, wird der Aufruf in Infotypen und Subtypen aufgeteilt.
  6. Im Falle eines OM landet der Anruf in einem Staging-Bereich. Ein nachfolgender Report bündelt ihn in den PD-Infotypen von HRP1000 und HRP1001. Die Designabweichung für OM ist auf die Art und Weise zurückzuführen, wie OM strukturiert ist - Objekte und Beziehungen. Wenn eines der Objekte fehlt, kann die DB-Aktualisierung der Beziehungen schief gehen. Daher werden alle Objekte zunächst in einer Staging-Tabelle zusammengefasst und dann in einem Rutsch in die DB gespült.

Design zum Mitnehmen

  1. In der Integrationsarchitektur ist das asynchrone Design die Norm, wobei die SF-API-Aufrufe die einzige Ausnahme bilden.
    1. SAP ruft CPI an und schläft
    2. CPI führt Batches aus und ruft die SF API im Synchronisationsmodus auf, leitet die Antwort an SAP HCM weiter und fährt mit dem nächsten Batch fort.
    3. Die Webdienste, die diese Informationen über SAP erhalten, sind ebenfalls asynchron. Im Falle des Mitarbeiters wird ein Thread mit dem bgRFC-Aufruf gestartet und im Falle des OM wird das OM-Objekt in eine Datenbanktabelle persistiert, wobei nur wenige oder gar keine Prüfungen der Geschäftslogik stattfinden.
  2. Der asynchrone Charakter der Architektur sorgt für die Ausfallsicherheit der gesamten Infrastruktur. Ein gemeinsames Merkmal einer hybriden Landschaft ist die Verschiedenartigkeit der beteiligten APIs und Infrastrukturen. Die API in der SAP HCM-Landschaft ist in Bezug auf die Ressourcen, die sie mobil zur Verfügung stellen kann, begrenzt; On-Premise-Komponenten, sei es der Cloud-Konnektor oder das SAP HCM-System, können niemals mit den unbegrenzt skalierenden Microservice-Infrastrukturen von CPI oder SuccessFactors mithalten. Das SAP HCM-System läuft in seinem eigenen Tempo und seine Cloud-Pendants in ihrem eigenen. Die asynchrone Architektur macht diesen Luxus möglich.
  3. Verwendung von SAP Cloud Connector (CC), einem maßgeschneiderten Reverse-Proxy-Tunnel. Dieser von SAP als "Reverse Invoke Proxy" bezeichnete Tunnel stellt eine sichere Verbindung zwischen On Premise Assets und der SAP Cloud Platform her. Der Begriff "On Premise Assets" ist wichtig, da der CC nicht nur für die Verbindung von SAP ERP/S4HANA-Systemen, sondern auch für die Verbindung zu On Prem. LDAP, andere http- und neuerdings sogar SQL-Datenbanken über JDBC-Verbindungen. Es gibt andere Möglichkeiten, SAP CP sicher mit der On-Premise-Welt zu verbinden - aber keine, die so einfach einzurichten und zu skalieren ist.
  4. Verwendung von CPI als Durchgangslösung: CPI ist eine großartige Middleware. Sie kann viele Dinge tun. In der EC-HCM-Architektur wird CPI jedoch in erster Linie als sicheres Daten-Pass-Through verwendet, das sich wie ein Message Broker verhält und Anrufe in eine Warteschlange stellt und stapelweise verarbeitet. Die gesamte Transformation wird auf der ABAP-Seite mit Hilfe der Business Integration Builder (BIB)-Infrastruktur durchgeführt. Für eine ABAP-lastige HCM-Beratungslandschaft ist dies eine willkommene Abkehr von der früheren Middleware-lastigen Integration (< PA_SE_IN SP18). Da der CPI-Prozess außerdem in einem "Nur-Customizing"-Modus angeboten wird und das gesamte Customizing nun auf die ABAP-Seite verlagert wird, kann SAP nun vierteljährliche Updates an die Kunden weitergeben, ohne sich Sorgen machen zu müssen, dass eine funktionierende Integration unterbrochen wird.
  5. Verwendung von CPI in einem Pub-Sub-Modus: Wenn ein neuer Mitarbeiter bei EC eingestellt wird, wird das Ereignis der Neueinstellung an den Abonnenten in CPI weitergeleitet. Dies ist die "Push"-Benachrichtigung, mit der Neueinstellungen und andere ähnliche Lebenszyklusereignisse fast sofort an SAP HCM übermittelt werden.
  6. Auf der SAP HCM-Seite bleibt es bei SOAP: Die niedrigste ECC-Version, die das Add-on PA_SE_IN unterstützt, ist ECC 6.0 (+SPxx). ECC6.0 ist mindestens 12 Jahre alt. Das BASIS/NW-Release von ECC6.0 unterstützt nicht die neueren API-Funktionen wie ODATA und das ReSTFul-Programmiermodell. SOAP ist ein fester Bestandteil der Netweaver-Kernversion und erfordert keine zusätzlichen Softwarekomponenten. Wenn man über die offensichtlichen Mängel hinwegsieht, bietet es nach der Einrichtung eine robuste Dienstkonnektivität. Die digitale Transformation sollte nicht auf Kosten der Aufrüstung der bestehenden Infrastruktur vor Ort erfolgen - vor allem nicht, wenn die Cloud der Weg in die Zukunft ist.
  7. Kunden fragen oft: Wenn EC zu EC Payroll Punkt zu Punkt durchgeführt werden kann, warum nicht EC zu SAP ERP HCM? Viele der Argumente aus dem vorherigen Punkt gelten auch hier. EC und EC Payroll werden beide in SAP-Rechenzentren gehostet, und SAP stellt sicher, dass sie auf dem neuesten Stand der Technologiekomponenten sind und somit neuere Integrationsmodelle und -architekturen unterstützen. Dies ist nicht bei allen SAP HCM-Kunden der Fall. Es stimmt zwar, dass viele Kunden mit dem neuesten und besten Stack von SAP arbeiten, aber es gibt auch immer Kunden, die noch mit einer älteren Version von SAP HCM arbeiten. Für den SAP-Anbieter, der versucht, eine Einheitslösung zu entwickeln, ist die PA_SE_IN-Add-on-Architektur ein Design-Kompromiss.

Zusammenfassend lässt sich sagen, dass die Integration von EC zu HCM eine Menge zu bieten hat. Aufgrund der Kompromisse, die bei der Entwicklung eingegangen wurden, gibt es eine ganze Reihe von Vorbehalten. Aber im Großen und Ganzen bringt sie eine Reihe von Systemen zusammen, um das versprochene Hire-to-Pay-Szenario zu verwirklichen. Es wäre nicht falsch, das Design als eine technische Meisterleistung zu bezeichnen,

Je effizienter die Digitalisierung und der Datenfluss sind, desto höher sind der Unternehmenswert und die Wettbewerbsfähigkeit.

Möchten Sie ein INTEGRTR werden?

DE