EDUCAÇÃO E TECNOLOGIA

Integration Design Concepts between SAP SuccessFactors & Third Party Systems

Introduction

In this blog post, I will be sharing my past experiences and some design concepts on 3rd party system data replications/database maintenance and user management/maintenance integrations. Please do consider that both SAP SuccessFactors and SAP Cloud Integration (CPI) functionalities are used in the below examples.


One of the implementations we have done with an external digital learning content/solution provider (Enocta) had an integration for user account maintenance and a reverse integration for learning content.

High%20Level%20Cross-Platform%20Data%20Flow

High-Level, Cross-Platform Data Flow


User Account Maintenance

User maintenance is controlled by the SuccessFactors operations.

  • Employee Hire/Recruit (User Create)
  • Employee Data Changes (User Update)
  • Employee Termination (User Disable)
  • Employee Rehire (User Update)

After every (except the “Employee Data Changes”) data operation (above) an event-based integration is getting triggered via “Intelligent Services Centre”.

  • Trigger Type: Intelligent Services
  • Destination Type: REST
  • Source Type: SuccessFactors
  • Format: XML

A few reasons why we chose “REST” over the “SOAP” are;

  • Even though we chose the “XML” format over “JSON”, we still wanted to select “REST” as the main operation because it is faster to process the data through the CPI
  • It is more dynamic when it comes to building up the framework of the integration if any customization is required

Reverse Data Integration – Matching Unique Identifiers between Platforms

Sometimes, your system and the external system do not contain the same identifiers for their user accounts. In the above example, the external system was using SuccessFactors’ “username” as their unique identifier but with a different format. This made it impossible to write back their user-based content into the SuccessFactors, because we used a custom user-based MDF object (externalCode = user), we needed to import data records with the SuccessFactors’ “User ID”.

So, to match their unique identifier with the user IDs, we created a lookup table to support CPI. This lookup table is getting updated daily via the integration centre. (SF User table to SF custom lookup table internal integration)

While the integration centre creates the lookup tables for every SuccessFactors user account, the username value gets reformatted to match the external username format.

Whenever the CPI tries to write any user-based learning content from the external system, the CPI integration looks up the respective “User ID” from the lookup table and sends the record into the SuccessFactors.


Integration Monitoring & Processing Logs

When we were working with the CPI integration logs, we had a bad experience while trying to monitor them. Mainly because it was deleting the integration logs after it reached a certain storage capacity and this made it a difficult task to backtrack any integration-related incidents.

After that, we tried to extend and utilize the monitoring capabilities of the SuccessFactors for such integrations.

  1. Using “Intelligent Services Centre” (ISC) and “Integration Centre” made monitoring possible from “Execution Manager Dashboard” to identify if one of the processes has failed or not
  2. Furthermore, to catch and monitor individual data flow, we created a custom data table in the SuccessFactors’ Metadata Framework

An%20example%20record%20from%20the%20table%20mentioned%20above

An example record from the table mentioned above

Note: “S1” means “Successful” in the above example.


After CPI sends out the user information from SuccessFactors to the 3rd party system, it also writes back the response coming from the external system back to the custom table. This makes monitoring much easier even for the generic administrators. (they can run a report or export data from the table)

Also, with the help of “Admin Alerts”, we created a rule which generates alerts to certain responses.

  • Alert notifies responsible people via the alert notification
  • Creates a to-do task on their “Home Page”

Business%20Rule%20which%20Creates%20the%20Alerts

Business Rule which Creates the Alerts


In conclusion, there are always various and endless alternatives to make multiple systems talk with each other but in long term, it is always helpful to consider lessening the maintenance and monitoring duties for both consultants & administrators and I hope the above design concepts can help you to achieve that.

Thank you for taking the time to read and leave your comments below!


You can also refer to the official SAP documentation below on how to accomplish some of the mentioned points above;

Integrating SAP SuccessFactors Employee Central with Microsoft Active Directory (SAP Cloud Integration)

SAP SuccessFactors Employee Central OData API: Reference Guide

SAP SuccessFactors HXM Suite OData API: Reference Guide (V2)

Implementing Employee Central Core

Implementing the Metadata Framework (MDF)

Intelligent Services Center

Integration Center

SAP Cloud Integration