Im zweiten Teil dieser Blogbeitragsreihe über APIs betrachten wir die OData API und die SFAPI in SuccessFactors genauer. Dieser zweite Teil baut auf dem ersten Blogbeitrag zum Thema API-Grundlagen auf. Hast du diesen noch nicht gelesen? Kein Problem, du findest diesen hier.

OData und SFAPI

Wie bereits erwähnt, wird im SuccessFactors Umfeld zwischen der OData API und der SFAPI unterschieden. Hierbei basiert die OData API auf der Technologie einer RESTful API, während die SFAPI auf der Technologie einer SOAP API basiert. Den Unterschied zwischen SOAP und REST habe ich bereits im ersten Teil erklärt. Schauen wir uns im Folgenden die Unterschiede der OData API und SFAPI an:

SFAPI

Die SFAPI ist eine SAOP API. Der Funktionsumfang ist somit von vornherein schon deutlich eingeschränkter als der einer REST API. Die SFAPI in SuccessFactors ist auch als Compound Employee API bekannt. Hierbei umfasst die Compound Employee API eine gewisse Anzahl an SuccessFactors Entitäten, welche die meistverwendeten Mitarbeiter Stammdaten einschließen (siehe folgende Abbildung).

Eine generelle Empfehlung ist die SFAPI nur in folgenden Anwendungsfällen zu verwenden (diese können nicht durch die OData API abgedeckt werden):

• Für die Mitarbeiterreplikation – nur die SFAPI lässt ein Delta auf Feldebene zu
• Wenn ein Snapshot benötigt wird
• Falls nur geänderte Mitarbeiter ausgelesen werden sollen

OData

OData (Open Data Protocol) ist ein OASIS-Standard. Dieser sorgt dafür, dass wir uns auf die Prozesslogik konzentrieren können, während sich OData um die RESTful APIs kümmert (beispielsweise die Ansätze zur Definition von Request und Response Header, Statuscodes, URL-Konventionen, Medientypen, Nutzdatenformate und Abfrageoptionen). Hierbei bietet OData sowohl einen Standard für die Darstellung unserer Daten als auch eine Metadatenmethode zur Beschreibung der Struktur und der verfügbaren Operationen.

Das auf Standards basierende Protokoll vereinfacht die API-Unterstützung. Folgende Vorteile werden hierbei geboten:

• OData ist der Standard für SAP-APIs
• Leistungsstarke Abfragefunktionen zum Abrufen von Daten aus mehreren Entitäten in SuccessFactors (funktionieren ähnlich wie SQL JOINS)
• Die Daten können in verschachtelten Datenstrukturen zurückgegeben werden, wahlweise im XML- oder JSON-Format

Folgende Funktionalitäten bietet die OData API:

• Abfrage zur Extraktion von Daten aus dem System
• Erstellen (Einfügen) neuer Daten in das System
• Aktualisierung vorhandener Daten im System
• Daten aus dem System löschen
• Mehrere zusammenhängende Entitäten in einer einzigen Operation bearbeiten

Sie können eine OData-API für eine Vielzahl von Funktionen verwenden. Der große Vorteil von OData ist, dass Sie nicht auf spezielle Entitäten beschränkt sind, sondern das gesamte SuccessFactors Employee Central Datenmodell nutzen können. Die folgende Abbildung zeigt eine Übersicht der SuccessFactors Entitäten. Durch den roten Rahmen wird gekennzeichnet, auf welche Entitäten durch die API zugegriffen werden kann. Im Fall der OData API sind dies sowohl Person Objects, Employment Objects und Foundation Objects.

Beispielhafte Anwendungsfällle, bei denen ausschließlich OData die benötigte Funktionalität bietet:

• MDF Objekte: Sobald der Zugriff auf MDF Daten benötigt wird, muss auf die OData API gesetzt werden. Die SFAPI bietet hierfür keine Funktionalität.
• Wird ein kundeneigenes User Interface über Employee Central gelegt und die API soll Daten zwischen dieser UI und Employee Central austauschen. In diesem Fall müssen die Role-Based-Permissions beachtet werden. Die hierfür benötigte Funktionalität bietet nur die OData API.

Fazit

Wir haben sowohl die SFAPI, als auch die OData API Möglichkeiten kennengelernt. Prinzipiell ist es zu empfehlen, wenn möglich immer auf die OData API zu setzten. Nur in den genannten Ausnahmefällen sollte auf die SFAPI zurückgegriffen werden.

Haben Sie ein bevorstehendes Schnittstellen Projekt und könnten eine passende Beratung gebrauchen? Wir unterstützen sehr gerne! Sowohl bei der Identifikation der am besten passenden Schnittstelle als auch bei der Implementierung. Kontaktieren Sie uns einfach hier.

Vorschau auf die nächsten Teile dieser Blogreihe

In den folgenden Teilen dieser Blogreihe werden wir uns Tools zum Testen von APIs genauer ansehen, vergleichen und einrichten. Wir werden uns auf SAP SuccessFactors fokussieren und richten einen API User ein (User Erstellung und Berechtigungszuweisung). Mithilfe des eingerichteten Users werden wir einfache, aber auch komplexere APIs entwickeln. Trotz der Fokussierung auf SAP SuccessFactors werden diese Beispiele mit einer REST API stattfinden und somit auch für nicht SAP SuccessFactors interessierte ein guter Einstieg.

Folge uns auf LinkedIn um den nächsten Teil dieser Blogreihe nicht zu verpassen!