Daten aus Cornerstone herausbekommen: REST, Reporting API oder Data Exporter?

Frag fünf Cornerstone OnDemand (CSOD)-Administratoren, wie man Daten aus der Plattform bekommt, und Du bekommst fünf verschiedene Antworten – die meisten davon richtig, aber alle nur die halbe Wahrheit. Cornerstone hat mehr Wege nach draußen als fast jedes HR-System, mit dem wir arbeiten, und genau das ist das Problem: Die Schwierigkeit liegt nicht darin, eine API zu finden, sondern die richtige auszuwählen, bevor Du das Falsche gebaut hast.

Wir haben auf den meisten von ihnen aufgebaut, aus den unterschiedlichsten Gründen. Hier ist die komplette Landkarte an einem Ort – und eine einfache Methode, um die richtige Wahl zu treffen.

Die vier(einhalb) Wege nach draußen

In der Praxis gibt es vier Wege, auf denen Deine Daten Cornerstone verlassen können – plus einen weiteren, den Du nur innerhalb der eigenen Webseiten der Plattform nutzen kannst.

• REST API – Echtzeit, lesen und schreiben, jeweils ein Datensatz. Reich verschachtelte Objekte für einen einzelnen User, ein Transcript oder ein Learning Object. Das ist der Weg, wenn Du etwas tun musst (Training zuweisen, einen User aktualisieren) oder die Daten einer Person in dem Moment zeigen willst, in dem sie sich ändern.
• Reporting API (RAPI) – programmatisch, nur lesend, OData, gespeist aus Cornerstones Real-Time Data Warehouse. Breite Reporting-Sichten. Gibt es noch, ist noch nützlich, aber nicht mehr dort, wo Cornerstone investiert.
• Data Exporter API (DEAPI) – das moderne Bulk-Arbeitstier. Nur lesend, OData, Delta-Sync, gebaut, um tausende Datensätze effizient abzuholen. Cornerstone nennt sie „den geistigen Nachfolger von RAPI" und schreibt, dass sie „im Laufe der Zeit beginnen wird, RAPI-Endpunkte abzukündigen, wenn dieselben Daten über die DEAPI abgerufen werden können."
• Bulk API – zum Laden von Daten hinein (und für ein paar schwergewichtige Export-Jobs), mit eigenen engen Throttle-Limits pro Endpoint und Datenlimits. Anderes Werkzeug, andere Aufgabe.
• Die Reporting-Bildschirme – Reporting 2.0 und die älteren Standard Reports, die In-Platform-Tools, die ein Mensch bedient, um einen Report zu bauen, auszuführen, zu planen und nach CSV oder Excel zu exportieren. Großartig für jemanden, der einen Report erstellt; keine Integrationsfläche. Die Grenzen davon haben wir in unserem Beitrag zu Reporting 2.0 beschrieben.

Eine Entscheidung in drei Fragen

Du musst so gut wie nie alle gegeneinander abwägen. Drei Fragen reichen.

Schreibst Du, oder liest Du nur? Wenn Du etwas anlegen oder aktualisieren musst, ist das die REST API, Punkt. Die DEAPI und die RAPI sind nur lesend.

Ein Datensatz jetzt, oder viele über die Zeit? Wenn die Daten einer Person eine Änderung in dieser Sekunde widerspiegeln müssen – jemand hat gerade einen Kurs abgeschlossen und erwartet, das sofort zu sehen –, ist das REST, weil die Reporting-APIs über ein Data Warehouse mit Verzögerung laufen. Wenn Du breite, historische oder große Datenmengen brauchst, um ein Dashboard, ein Warehouse oder ein BI-Tool zu füttern, ist das die DEAPI.

Nutzt Du heute RAPI? Dann plane den Umzug zur DEAPI. Es funktioniert noch, aber Du baust auf einer API auf, von der sich Cornerstone verabschiedet. Neue Arbeit sollte direkt mit dem Data Exporter starten.

Das ist das ganze Framework. Schreiben → REST. Ein Live-Datensatz → REST. Breit/Bulk/historisch → DEAPI. Auf RAPI → Migration zur DEAPI.

Die Verzögerung, die keiner auf die Folie schreibt

Beide Reporting-APIs – RAPI und die DEAPI – lesen aus dem Real-Time Data Warehouse, und „Real-Time" kommt dort mit einem Sternchen: Rechne in Produktion mit einer Verzögerung von rund fünfzehn Minuten zwischen einem Ereignis im Portal und seinem Erscheinen in einer Abfrage. Für Dashboards, Trends und alles Aggregierte ist diese Verzögerung unsichtbar. Für „zeig mir diese eine Person jetzt sofort" ist sie ein Support-Ticket, das nur auf seinen Auftritt wartet. Der Fehler liegt nicht in der Verzögerung; der Fehler liegt darin, eine warehouse-gespeiste API für eine Echtzeit-Frage zu benutzen. Mehr dazu – und zu den Throttle-Limits, die jeden irgendwann erwischen – findest Du in unserem Guide zur Data Exporter API.

Rate Limits gelten für alles

Egal, welchen Weg Du wählst, Cornerstone zählt mit. Die Foundational APIs teilen sich ein Budget von 417 Requests pro Minute, 25.000 pro Stunde und 600.000 pro Tag, gezählt pro Umgebung und pro Endpoint – nicht pro User oder pro Token, weshalb Du Dir mit zusätzlichen Credentials keinen Spielraum erkaufen kannst. Die DEAPI läuft mit einem deutlich engeren Minutenbudget. Die Job-Endpoints der Bulk API werden noch härter gedrosselt. Baust Du das alles ohne Back-off-Strategie, triffst Du im ungünstigsten Moment auf einen 429.

Der ehrliche Teil

Worauf das alles hinausläuft: Die richtige Cornerstone-API zu wählen, ist eine echte Architekturentscheidung, und damit zu leben – die Rate Limits, die Warehouse-Verzögerung, der Deprecation-Pfad, die Retries, die Schema-Übersetzung – ist fortlaufende Ingenieursarbeit. Die meisten Teams wollen keine Integrationsschicht besitzen. Sie wollen ihre Daten.

Die Entwicklungsrichtung macht das eher wichtiger als unwichtiger. Cornerstone brandet die Plattform inzwischen als Cornerstone Workforce AI und verkauft sie als interoperabel, gebaut, um sich „sauber … mit jedem System of Record oder Datastore" zu verbinden. Sauberes, verlässliches Data-out ist die Hälfte dieses Versprechens, die Du tatsächlich selbst bauen musst.

Was Du auf diesen APIs baust, ist ein Spektrum. Am leichten Ende rollenbewusste MicroApps, die Live-Cornerstone-Daten direkt im Portal zeigen – der Mittelweg zwischen der nativen Plattform und einem vollen Warehouse. Am anderen Ende eine Plattform, die alles heraussynchronisiert und aktuell hält.

Genau das ist octo.taxi. Wir haben die Entscheidungen oben einmal richtig getroffen und übernehmen den Sync, damit Du es nicht musst. Deine Cornerstone-Daten landen an einem Ort mit Dashboards, einem Organigramm, Antworten in normaler Sprache, herunterladbaren Reports, einem Live-BI-Feed und einer eigenen, sauberen REST API – einer Tür in beide Richtungen, die sich öffnet, wohin auch immer Du Deine Daten als Nächstes brauchst.

Wähl das richtige Werkzeug, wenn Du es selbst baust – wir hoffen, diese Landkarte hat Dir eine falsche Abzweigung erspart. Oder überspring die Landkarte, und lass Deine Daten einfach dort ankommen, wo sie hinsollen.

So oder so: Deine Daten sollten sich frei bewegen – von A nach B, mit Stil.

---

Quellen. Cornerstones Entwicklerdokumentation: API-Throttling-Limits & Header · Reporting-API-Überlegungen (DEAPI als Nachfolger von RAPI) · Bulk-API-Throttling-Limits · Bulk-API-Datenlimits.