Wie der Inhalt des SF Felds “Vollzeitmitarbeiter” in das Feld “Teilzeitkraft” im Infotypen 7 transferiert wird

Dies ist der dritte Teil der Beitragsreihe „Integration SuccessFactors zu SAP HXM“. Im vergangenen Beitrag haben wir uns mit der Architektur und der Systemlandschaft beschäftigt. In diesem Zusammenhang haben wir uns ebenfalls die SAP Cloud Plattform als Middleware-Lösung angeschaut. Neben dem detaillierten technischen Ablauf, wurden die einzelnen vordefinierten Integrationspakete vorgestellt.

In diesem Beitrag erfahren Sie, wie aus dem SF Feld „Vollzeitmitarbeiter“ das HXM Feld „Teilzeitkraft“ wird.


Abbildung 1 – Veranschaulichung Feld „Teilzeitkraft“ im SAP HXM und „Vollzeitmitarbeiter“ im SF EC

Die Grafik veranschaulicht die beiden Felder der verschiedenen Systeme. Auf der linken Seite ist das SF-System mit der Job Information aus Employee Central abgebildet. Entsprechend wird dort die Information über den Vollzeitmitarbeiter-Status als „Is Fulltime Employee“ abgebildet. In dem Kontext bedeutet „Yes“, dass der Mitarbeiter eine Vollzeitbeschäftigung ausübt. Das Pendant, im SAP HXM, dazu ist der Infotyp 0007 (Sollarbeitszeit). Hier wird die Information über das Feld Teilzeitkraft abgebildet. Entsprechend bedeutet in diesem Kontext „Yes“, dass der Mitarbeiter eine Teilzeitkraft ausübt. Dies verdeutlicht die Notwendigkeit eines durchdachten Mapping-Konzeptes. Die folgende Grafik verdeutlicht einen solchen Konflikt.


Abbildung 2 – Veranschaulichung 1:1 Feldmapping

Im Rahmen der Standardintegration zwischen SAP HXM und SF EC, gibt es verschiedene Möglichkeiten die Datenmodelle zu harmonisieren. Aufgrund der Verschiedenheit der Datenmodelle ergibt sich folgende Problemstellung, die bei der Erstellung eines Konzeptes zu beachten sind. Zum einen die unterschiedliche Struktur der Datenspeicherung zwischen den SAP HXM-Infotypen und der objektorientierten Speicherung in Portlets im SF EC. Hiermit ergibt sich die Konstellation, dass ein Speicherobjekt im SuccessFactors EC auf zwei oder mehrere Infotypen harmonisiert werden muss. Weiterhin ist aus diesem Grund meist kein eins-zu-eins Mapping zwischen Infotyp und Speicherobjekt möglich. Zum anderen stellt die Differenz in der Zeitlogik zwischen SAP HXM-Zeitbindungskonzept und SF EC-effective dating die Herausforderung dar, eben diese zu harmonisieren.

Für jedes Feld aus dem SF EC-System kann eine primäre Zuordnung definiert werden. In diesem Kontext bedeutet das primär, dass es sich hierbei um die eigentliche Zuordnung handelt. Eine sekundäre Zuordnung bedeutet, dass z.B. länderspezifisch eine unterschiedliche Feldzuordnung definiert werden kann. Unabhängig von der primären oder sekundären Zuordnung, verläuft die Implementierung wie folgt: Zunächst muss das Quellfeld aus dem SF EC-System angegeben werden. Basierend auf der konzeptionierten Wertzuordnung muss ein Zuordnungsmodus gewählt werden. Hierbei gibt es drei Optionen: BAdI-Zuordnung, Infotypzuordnung oder vorkonfigurierte Zuordnung. Bei der BAdI-Zuordnung wird eine kundenindividuelle Zuordnungslogik implementiert, die mittels der SAP-eigenen Programmiersprache ABAP realisiert werden muss. Im Gegensatz dazu wird bei der Infotypzuordnung der Infotyp, ggf. der Subtyp sowie das technische Infotypfeld angegeben. Die vorkonfigurierte Zuordnung ist durch die SAP definiert und bildet bestimmte Logiken ab. Auf die vorkonfigurierten Zuordnungen wird im Rahmen des Beitrags nicht näher eingegangen, da diese für das gegebene Beispiel nicht benötigt wird. Weitergehend kann noch eine Wertzuordnungsentität angegeben werden, wenn für die jeweiligen Felder eine Auswahlliste vorliegt oder der Wert anhand konstanter Werte konvertiert werden soll.


Abbildung 3 – Customizing des Feldmappings

Die Abbildung zeigt die technische Konfiguration des Mappings im Customizing. Für das Mapping der Vollzeitmitarbeiter-Information, wird zunächst eine Infotypzuordnung vorgenommen. Hierdurch zeigt sich der bereits erwähnte Konflikt, sodass ein eins-zu-eins Mapping nicht möglich ist. Zusätzlich zu der Feldzuordnung wird eine Verarbeitungslogik benötigt, die den Informationsgehalt invertiert.


Abbildung 4 – Feldmapping mit BadI-Verarbeitung

Durch die zusätzliche BadI-Verarbeitung wird nun der Wert aus dem SF-System invertiert, sodass aus „Yes“ -> „No“ wird und umgekehrt. Neben der gezeigten BadI-Verarbeitung, gibt es noch weitere Möglichkeiten, um ein eins-zu-eins Feldmapping mit Logik zu ergänzen. Hierzu wird keine ABAP-Programmierung benötigt. Insgesamt gibt es zwölf vordefinierte Konvertierungsregeln, um die konzeptionellen Anforderungen an die Datenharmonisierung zu realisieren. Beispielsweise können konstante Prä-/Suffixe angehangen werden oder der empfangene Wert mit einer definierten Zahl multipliziert werden. Auch können Werte durch andere anhand eines Musters ersetzt werden.

Unter Verwendung der genannten Boardmittel, die die vordefinierte Standardintegration zur Verfügung stellt, können komplexe Datenharmonisierungen vorgenommen werden. Mit einem durchdachten Konzept helfen wir Ihnen, die Systeme erfolgreich zu integrieren.

Im Rahmen dieses Beitrags haben Sie anhand eines Beispiels erfahren, wie Datenfelder zwischen SAP HXM und SF EC harmonisiert werden können. Es wurden die Möglichkeiten zur Datenharmonisierung der Standardintegration vorgestellt. In dem nächsten Beitrag dieser Reihe zeigen wir Ihnen, wie Sie im Betrieb der Schnittstelle Stammdatenfehler identifizieren können und welche Protokolle in den jeweiligen Systemen zur Verfügung stehen.

Haben Sie bereits Fragen, Anregungen oder Feedback bezüglich der Integration, so
adressieren Sie diese bitte unter dem Betreff „Beitragsreihe Integration“ an

PDF als Download

 

Hier geht es zu Teil 2
Vielen Dank für deine Nachricht, sie wurde versandt.
Es gab einen Fehler, bitte versuche es noch einmal.
Diesen Beitrag teilen