Integrating with SuccessFactors

The company was bought by SAP in 2011 and is sold as a replacement for the SAP HR module on premise.
The first meeting we had about integrating it with other applications, the consultants told us everything is very easy. Being a SaaS tool I was expecting some kind or REST API or at least a web service we could use to do the basic CRUD operations.
I was quite surprised when the consultant (which was an expert in SuccessFactors integration) started talking about CSV and SFTP. The first impression I had after that meeting was "Is this really the only way we can integrate with a modern SaaS tool?"
Since we were on a really short timeline and had no experience ourselves, we trusted the consultants and went ahead with the implementation.
My colleague and I couldn't believe that this really was the only way to do this and we started doing our own research. It took us some time, a few conference calls and a whole bunch of documentation. But after a while we found out there are actually 2 other (and better) ways to integrate with SuccessFactors.
- SFAPI : a SOAP webservice
- ODATA REST API
At this point we already integrated with a few other applications that we use inside our company and we started with reworking a few them to get more familiar with these 2.
I will go into detail on these in later posts but I already want to give you a general overview of the options.
SFAPI
The official documentation describes it as :
The SFAPI is SuccessFactors Data API. It is a SOAP Web Service designed for importing and exporting data to and from your SuccessFactors instance. It provides generic CRUD (Create, Read, Update, Delete) operations to access data, as well as meta-data operations to allow runtime discovery of the data.
Data are exposed as entities called SFObjects, which are conceptually analogous to database tables. Using the meta-data operations, you can list the SFObjects available to the API, and describe the fields in these entities. Using the CRUD operations you can query or edit the data.
The combination of CRUD style data access operations along with meta-data driven operations for data discovery provides a generic API that offers the following benefits
- Provide a consistent mechanism for accessing data in the SuccessFactors platform.
- Provide a mechanism to describe the data schema configuration, including the entities that are available and fields that appear in these entities.
- Avoid WSDL changes with each release.
It provides methods like query, insert, update, upsert (combination of insert and update), delete, ... in a quite generic way. We mostly use it to "upsert" data from other sources like Active Directory (profile pictures, telephone numbers, ...)
The SFAPI also provides what is called a "Compound Employee" object you can query through their own SFQL syntax. SFQL is actually used for all query operations and is an SQL like language.
The compound employee returns a hierarchical XML structure of an employee. It's the advised way of querying for data if you would like to integrate with your payroll system since it can provide you with a delta that goes up to the field level.
ODATA
The official documentation describes it as :
The HCM Suite OData API is SuccessFactors Web Services API based on OData protocol intended to enable
access to data in the SuccessFactors system. The API is data oriented. This API provides methods for CRUD style
access (Create, Read, Update and Delete). The API is best used for frequent or real time requests for small
amounts of data. Large data requests are better handled by batch FTP processes. This OData API is used to
configure entities. Each SuccessFactors module can be accessed using its own set of entities.
With the ODATA API, you can query the entire data model of SuccessFactors in an easy way. We use it to get large data sets and it's actually quite performant.
It should also work to upload data but we haven't used it for that yet since we first started with SFAPI and we don't want to redo everything again.
The HCM Suite OData API is SuccessFactors Web Services API based on OData protocol intended to enable
access to data in the SuccessFactors system. The API is data oriented. This API provides methods for CRUD style
access (Create, Read, Update and Delete). The API is best used for frequent or real time requests for small
amounts of data. Large data requests are better handled by batch FTP processes. This OData API is used to
configure entities. Each SuccessFactors module can be accessed using its own set of entities.
With the ODATA API, you can query the entire data model of SuccessFactors in an easy way. We use it to get large data sets and it's actually quite performant.
It should also work to upload data but we haven't used it for that yet since we first started with SFAPI and we don't want to redo everything again.
Future steps
I have seen that SuccessFactors also provides some ways to send data to a webservice when some events happen in the application. But I'm waiting for the next version to start playing with this.
For now we mostly do big extracts on a timely basis to synchronise our systems. So you can expect some more blogposts about this when we discover new possibilities.
I've also launched the question to Microsoft if they plan to create a connector for Logic Apps in the future. Being an SAP company they already provide something in HCI (HANA Cloud Integration) to integrate with it, but since we have no expertise there we didn't go that way. There was also a connector in Dell Boomi but I'm not sure if it is still maintained at the moment.
Conclusion
If you have to integrate with SuccessFactors, it's really worth downloading the documentation for SFAPI and ODATA. It's actually pretty good.
In later posts I will try to give some samples of both options to give you a start.
If you have some questions or need some help, I would be happy to give you a hand in getting started with this. Just contact me through twitter (you can follow me at the top of the page) and I'll take some time to try and help.
Comments
Post a Comment