Integration Design Concepts between SAP SuccessFactors & Third Party Systems
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.
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.
- 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
- Furthermore, to catch and monitor individual data flow, we created a custom data table in the SuccessFactors’ Metadata Framework
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”
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)
Nice description of what you built!
What was the driver in using a custom MDF object to log runs rather than using execution manager?
Thank you for asking!
We couldn't be able to utilize the "Execution Manager Dashboard" in a way to monitor individual data flows. Let me explain further what I am trying to say;
For example, we hired an employee in SuccessFactors and through the Intelligent Services Centre "Employee Hire/Recruit" event has been triggered and the integration definition within the Integration Centre has been completed successfully.
This means that the authentication method was successful and Integration Centre did connect to the Cloud Integration. After this point, we really cannot monitor the data flow between the CPI and the 3rd party system within the SuccessFactors. (we can monitor it through CPI logs but it has a disadvantage like I mentioned in the blog)
Also one other point, most of the administrators in SuccessFactors do not have the user to monitor Cloud Integrations due to the licensing and all.
I hope this clarifies the "why we choose MDF" question a bit more.
Have a great day!
Hi Murat, have a read of this blog post and it's follow up by my friend Gurdev. Then I think you'll understand...
You can use Execution manager to monitor SAP Integration Suite flows....