Analysieren der EC-OData-API-Performance

OData-API unterstützt einige HTTP-Operationen wie GET, POST, PUT, PATCH und DELETE. Wir verwenden die grundlegenden Operationen, um Entitäten wie Benutzer, PerPerson, Auswahlliste usw. in EC abzurufen oder zu bearbeiten.

HTTP-Operationen

• GET: Query
• POST: Anlegen
• PUT: Aktualisieren
• PATCH: Teilaktualisierung
• DELETE: Löschen

HTTP-Ressourcen oder -Services

• Benutzer, PerPerson, Auswahlliste, Planstelle

HTTP-Parameter

• Getrennt durch "?" (erste nach Ressource) und Zeichen "&"
• OData-Standardparameter beginnen mit einem "$"-Zeichen, z.B. $filter oder $select.

XML-Definition von API-Metadaten

• Kann über den OData-API- $metadata-Aufruf abgerufen werden, kann ein Ergebnis nach dem Download in Excel importiert werden:

Um zusätzliche Informationen wie Sprachbezeichner und Auswahllisten zu erhalten, die über die standardmäßigen OData-Metadaten hinausgehen, stellt SAP SuccessFactors OData Metadaten als Entität bereit. Das SAP-SuccessFactors-OData-API exponiert eine Entität namens 'Entität'. Seine Eigenschaften werden als komplexer Typwert exponiert, der in den Antworttext von 'Entity' eingebettet ist. Verschiedene Formen von Metadaten können somit exponiert werden, ohne das Standard-OData-Metadatenformat zu ändern. Sie können auf die neuen Metadaten wie auf eine reguläre Entität zugreifen. Darüber hinaus unterstützt sie einen einfachen Filter, um Metadaten einer bestimmten Entität auszugeben.

Die Metadaten können über das OData-API durch $metadata im HTTPS-Aufruf erreicht werden. Sie können die Metadaten über den Firefox-REST-Client anfordern. Da die Daten für die Metadaten etwas groß sind, kann der Request mehr Zeit in Anspruch nehmen.

Wählen Sie die Wiedergabetaste, um mehr über den Parameter $format zu erfahren.

Filteroptionen und -parameter

Das folgende Beispiel zeigt ein Beispiel für eine OData-API-Abfrage mit Filter und Select. Für den Filter kann ein angegebener Wert für ein Feld angegeben werden, um die entsprechende Entität abzufragen. Für die Auswahl können wir auch die Felder definieren, die die Antwort zurückgeben sollen.

• $filter=personIdExternal%20eq%20’greinhard’

  • %20 ist ein spezielles Escape-Zeichen für Leerzeichen; wie %28 und %29 für Klammern wie "(" und ")"

  • Verfügbare Operatoren sind EQ,NE,GT,GE,LT,GT und können mit NOT, AND und OR kombiniert werden.

• $select=firstName definiert Felder, die durch Leerzeichen getrennt zurückgegeben werden sollen

Das folgende Beispiel zeigt, wie Sie den Parameter von expand verwenden. Expandieren wird immer verwendet, um zu einer anderen Entität zu navigieren.

Expandieren der Daten – Navigieren im Datenmodell

• $expand=personNav
• $select=firstName,personNav

  • Erweitert firstName in Wurzelressource und alle Felder in navigierter Ressourcenperson

• $select=firstName,personNav/dateOfBirth

  • Erweitert firstName in Wurzelressource und alle Felder in navigierter Ressourcenperson

Das obige Beispiel zeigt, wie Sie die Parameter $expand und $filter verwenden.

Die Antwort identifiziert eine Reihe von Benutzerentitäten, deren Eigenschaft personNav/emailNav emailAddress ist, die gleich gerald.reinhard@sap.com ist. Nachdem die Entitäten abgerufen wurden, entfernt die Antwort nicht ausgewählte Spalten. Anschließend expandiert die Option $expand die ausgewählten Spalten, bei denen es sich um eine Navigationseigenschaft handelt.

Tiefe Filterung mit $filter und $expand

• $expand nach Filter unabhängig voneinander ausgeführt (siehe Ergebnis nächste Folie)
• $select für gefilterte Attribute nicht erforderlich

Filtern+Aufklappen

• Filter auf Wurzelressource angewendet
• Auf gefilterte Wurzelressource angewendete Erweiterung
• Ergebnis: Erweiterte E-Mail stimmt nicht mit Filter überein

Der folgende Inhalt beschreibt, wie Sie Entitäten mit Gültigkeitsdatum abfragen. Um fromDate und toDate zu verwenden, werden alle historischen Daten der Wurzelentität in der Antwort zurückgegeben. Wenn die Wurzelentität jedoch kein Gültigkeitsdatum ist, werden fromDate und toDate auf die nächste Entität mit Gültigkeitsdatum in der Navigationshierarchie angewendet, und alle Datensätze mit Gültigkeitsdatum, die in das Zeitintervall zwischen fromDate und toDate fallen, werden zurückgegeben.

Wenn auch historische Daten eines Datensatzes mit Gültigkeitsdatum zurückgegeben werden und eine Navigation/Expansion von diesen Datensätzen zu einem anderen Datensatz mit Gültigkeitsdatum erfolgt, wird das Startdatum der ersten Entität mit Gültigkeitsdatum verwendet, um die zweite Entität zu filtern.

• Für Entitäten mit Stichtag, um das API anzuweisen, alle historischen Daten der Wurzelentität in der Antwort zurückzugeben.
• Wenn die Wurzelentität kein Gültigkeitsdatum toDate ist und fromDate auf die nächste Entität mit Gültigkeitsdatum in der Navigationshierarchie angewendet wird:
  • https://salesdemo4.successfactors.com:443/odata/v2/PerPerson? $filter=EmploymentNav/jobInfoNav/userId%20eq%20'greinhard' &fromDate=1900-01-01 &$select=EmploymentNav/jobInfoNav/startDate,EmploymentNav/jobInfoNav/departmentNav/externalCode &$expand=arbeitsplymentNav/jobInfoNav/departmentNav
• Alle Datensätze mit Stichtag, die in das Zeitintervall zwischen fromDate und toDate fallen, werden zurückgegeben.

• Wenn historische Daten eines Datensatzes mit Gültigkeitsdatum zurückgegeben werden und eine Navigation/Expansion von diesen Datensätzen zu einem anderen Datensatz mit Gültigkeitsdatum erfolgt, wird das Startdatum der ersten Entität mit Gültigkeitsdatum verwendet, um die zweite Entität zu filtern.
  • https://salesdemo4.successfactors.com:443/odata/v2/EmpJob? $filter=userId%20eq%20'greinhard'&fromDate=1900-01-01 &$select=startDate,departmentNav/externalCode &$expand=departmentNav

Hier wird beschrieben, wie Sie Entitäten mit Gültigkeitsdatum abfragen. Wenn Sie fromDate und toDate verwenden, werden alle historischen Daten der Wurzelentität in der Antwort zurückgegeben. Wenn die Wurzelentität jedoch kein Gültigkeitsdatum ist, werden fromDate und toDate auf die nächste Entität mit Gültigkeitsdatum in der Navigationshierarchie angewendet, und alle Datensätze mit Gültigkeitsdatum, die in das Zeitintervall zwischen fromDate und toDate fallen, werden zurückgegeben.

Wenn auch historische Daten eines Datensatzes mit Gültigkeitsdatum zurückgegeben werden und eine Navigation/Expansion von diesen Datensätzen zu einem anderen Datensatz mit Gültigkeitsdatum erfolgt, wird das Startdatum der ersten Entität mit Gültigkeitsdatum verwendet, um die zweite Entität zu filtern.

• Teilweise Löschungen werden für Entitäten ohne Gültigkeitsdatum wie PerEmail, PerPhone nicht unterstützt.
• Vollständige Löschung wird noch von keinem API unterstützt
• lastModifiedOn (Server-Zeitzone) lastModifiedDateTime (UTC)

• Das OData-API bietet mehrere Paginierungsoptionen für Abfrageergebnisse.
• Ein einzelner OData-HTTP-GET-Request kann maximal 1.000 Datensätze zurückgeben. Dies ist sinnvoll, da die meisten HTTP-Clients ein Timeout-Limit von 2 bis 5 Minuten haben.
• Ein Request, der länger als das Limit läuft, erhält einen HTTP-Timeout-Fehler. Daher ist es häufig erforderlich, komplexe Abfragen zu optimieren und die Datengröße zu verringern, damit sie innerhalb der Timeout-Einschränkung abgeschlossen werden können.

Der Kunde kann zwischen zwei Arten der Paginierung wählen:

• Client-Paginierung
• Serverpaginierung

• Die Client-Paginierung ist der grundlegendste Paginierungsmechanismus. Sie verwendet Abfrageoptionen auf Client-Seite, um einen "Offset" zu erstellen, der die vom Server zurückgegebene Datenmenge einschränkt. Ein Client verwendet den folgenden URI-Parameter.
• Ein Client verwendet den folgenden URI-Parameter:
  • Der Parameter $top gibt die Anzahl der Datensätze an, die im Batch zurückgegeben werden sollen. Der Standardwert und die maximale Anzahl sind 1.000 Datensätze.
  • Der Parameter $skip gibt die Anzahl der Datensätze im vollständigen Datensatz an, die vor dem Abrufen der Daten übersprungen werden sollen.
• Beispiel: Eine Abfrage mit $skip=2000&$top=500 gibt die 5. Seite der Daten zurück, wobei die Seitengröße 500 beträgt.

• Im Gegensatz zur Client-Paginierung, bei der die Paginierung durch vom Client angegebene Parameter gesteuert wird, wird die Serverpaginierung serverseitig gesteuert.
• Es gibt zwei Arten der Serverpaginierung: Cursor-basierte Paginierung und Snapshot-basierte Paginierung. Beide Arten der Paginierung geben einen „__next"-Parameter am Ende jeder Abfrageantwort zurück, der einen $skiptoken-Wert enthält, der die nächste Datenseite angibt.
• Die Cursor-basierte Paginierung pflegt einen Datenbank-"Cursor" auf dem Server während der Paginierungs-HTTP-Anforderungen. Der Cursor stellt einen Zeiger auf den Anfang der nächsten Seite im gesamten Datensatz dar. Dies wird mit dem Parameter &paging=cursor URI aktiviert.
• Die Snapshot-Paginierung funktioniert, indem eine Liste aller Geschäftsschlüssel des Datensets auf dem Server persistiert wird. Dies wird über den URI-Parameter &paging=snapshot aktiviert.

Wann Sie die verschiedenen Arten der Paginierung verwenden sollten:

• Verwenden Sie für die UI-Nutzung die Client-Offset-Paginierung. Dies ist die einzige unterstützte Methode auf der Benutzungsoberfläche.
• Für Integrationsanwendungsfälle werden eine Cursor-basierte Paginierung und eine Snapshot-basierte Paginierung empfohlen.
• Wir empfehlen Ihnen, Ihre Abfragen zu optimieren, wenn Sie die Snapshot-basierte Paginierung verwenden. Wenn Sie bei sehr großen Datensätzen Probleme mit der Performance der ersten Seite haben, wechseln Sie ggf. zur cursorbasierten Paginierung.

Zu guter Letzt haben wir die OData-Entitäten FOLocation und FOPayGrade für die Snapshot-basierte Paginierung optimiert, um die Performance zu verbessern.