Die wichtigsten Salesforce Limits, wie API Calls, im Überblick – Teil 1
Integrationsprojekte, wie das Schieben von SAP SD Daten nach Salesforce, sind oftmals komplex genug. Selbst wenn Sie an alles gedacht haben, der Projektplan vermeintlich lückenlos ist und alle Risiken abdeckt sind, passiert es: Die Schnittstelle wird zum ersten Mal voll benutzt und nichts geht mehr. Ein Horrorszenario, was allerdings schon viele erlebt haben. Sie fragen sich, was könnte hierfür die Ursache sein? Eine mögliche Ursache: Die Limits von Salesforce wurden bei der Architektur nicht berücksichtigt und nun sprengen die Datenmengen eines dieser Limits. Die Folge: Salesforce blockt ab, die Schnittstelle ist und bleibt für Stunden funktionslos. In dieser Blogreihe möchte ich daher Aufmerksamkeit schaffen, für die gängigen Salesforce Limits und wie Sie diese einhalten können.
API Calls und warum Salesforce so strikt limitiert ist
Grund für die strikte Limitierung ist primär die sogenannte Multi-Tenant-Architektur. Multi–Tenancy ist die grundlegende Technologie, die Salesforce nutzt, um IT-Ressourcen kosteneffizient und sicher gemeinsam zu nutzen. Vergleichen können Sie dies mit einer Bank, in der viele Mieter eine versteckte gemeinsame Infrastruktur kosteneffizient gemeinsam nutzen. Dabei nutzen diese eine definierte Reihe hochsicherer Dienste, wo die Privatsphäre anderer Mieter vollständig geschützt ist.
Auch die Salesforce Clouds verwenden eine Multi–Tenancy-Technologie. Damit IT-Ressourcen sicher zwischen mehreren Anwendungen und Mietern – also den Unternehmen und ihren Organisationen, die die Cloud nutzen – geteilt werden.
Der Vorteil hierbei ist, dass Ressourcen gemeinsam genutzt werden und kleinere Kunden dieselben Vorteile in Sachen Updates, Sicherheit und Co. nutzen können, wie riesige Konzerne.
Der Nachteil ist, dass gewisse „Regeln“ für die gemeinsame Nutzung existieren müssen. Damit die nicht von einem Unternehmen verbraucht werden und einem anderen nicht mehr zur Verfügung stehen, falls sich beide auf demselben Server befinden.
Limit 1: Die berüchtigten API Calls
Die API-Beschränkungen werden gegen die Summe aller API Calls der Organisation innerhalb von 24 Stunden gerechnet. Wenn also eine Organisation ein Limit überschreitet, können alle Benutzer in dieser Organisation vorübergehend für weitere Anfragen gesperrt werden. Aufrufe werden so lange blockiert, bis die Nutzung in den vorangegangen 24 Stunden unter das Limit fällt. Es handelt sich hierbei also um ein rollierendes Limit innerhalb von 24 Stunden. Im schlimmsten Fall bedeutet es also, dass Ihre Schnittstelle für 24 Stunden lahmgelegt ist, falls ein einzelnes Event so viele API Calls erzeugt hat.
Wie hoch ist mein API Limit?
Für Salesforce Professional und Enterprise erhält jede Organisation insgesamt 1.000 API-Calls pro Benutzer innerhalb eines Zeitraums von 24 Stunden, bis zu einem Maximum von 1.000.000 API-Calls (für Organisationen mit mehr als 15.000 Salesforce-Lizenzen). Salesforce Unlimited verfügt über ein Limit von 5.000 API-Calls pro Benutzer. Damit kleinere Organisationen mit wenigen Usern nicht zu schnell in ein Limit laufen, gibt es ein Grundlimit von 100.000 Calls, die grundsätzlich zur Verfügung stehen.
Bei einem Unternehmen mit 155 Professional Lizenzen ergibt sich also bspw. ein rollierendes Limit von 100.000+150*1000=250.000 API Calls.
Damit Sie auf Sandboxes mehr experimentieren können, gilt hier grundsätzlich ein API Limit von 5.000.000. Das ist wichtig zu berücksichtigen, denn das bedeutet, dass eine Schnittstelle, die auf einem Testsystem die Limits nicht überschreitet, dies auf einem Produktivsystem durchaus tun kann. Dies ist außerdem atypisch, da beispielsweise bei den meisten on premises Systemen das Produktivsystem über mehr Leistung verfügt als die Testsysteme.
Wie können Sie das überwachen?
Um zu sehen, wo Ihre API-Calls im Moment liegen, gehen Sie einfach folgendermaßen vor:
Unternehmensprofil > Unternehmensinformationen – Die Zahlen werden im Feld API-Anforderungen, letzte 24 Stunden gespeichert. Der Wert in diesem Feld zeigt an, was Sie innerhalb der Letzten 24 Stunden verbraucht haben.
Darstellung der API Nutzung in einer Salesforce Sales Cloud
Was verursacht bzw. benötigt API Calls?
Grundsätzlich gibt es sehr viele Ereignisse, die API Calls „verbrauchen“:
- Datenanfragen, z. B. SOAP Calls
- System-Anmeldungen, bspw. von Schnittstellenusern
- SOQL Aufrufe: Add, Update, and delete data
- Manche Administrator-Utilities
- U. v. m.
- Mehr Details finden Sie hier
Am wichtigsten bei Schnittstellenprojekten sind hier allerdings meist die SOAP-Calls, die Sie auf der Datenbank schreiben oder lesen. Zu beachten ist auch, dass viele Middlewares nicht gerade sparsam mit API Calls umgehen. So kann das Lesen mit Kontextinformationen oder Senden eines einzelnen Datensatzes schon mal zahlreiche API Calls verursachen.
Wie können Sie verhindern, dass Ihr API ans Limit stößt?
Dies ist alles eine Frage der Architektur:
-
Bulkification:
Der Begriff „Bulkifying Apex-Code“ bezieht sich darauf sicherzustellen, dass der Code mehr als einen Datensatz auf einmal korrekt behandelt. Wenn ein Stapel von Datensätzen Apex initiiert, wird eine einzelne Instanz dieses Apex-Codes ausgeführt. Diese muss jedoch alle Datensätze in diesem Stapel verarbeiten. Ein Auslöser könnte bspw. durch einen Force.com-Webservices-API-Call aufgerufen werden, der einen Stapel von Datensätzen einfügt oder durch einen benutzerdefinierten Apex-Webdienst. Wenn also ein Stapel von Datensätzen denselben Apex-Code aufruft, müssen alle diese Datensätze als Bulk verarbeitet werden. So können Sie einen skalierbaren Code schreiben und das Erreichen von Limits vermeiden. Um Ihnen hier ein Beispiel zu liefern: Nicht bulkified Code bedeutet, Sie laufen für eine Bestellung von 12 Eiern 12 mal zum Supermarkt und kehren jeweils mit einem Ei zurück. Das verbraucht dann 12 API Calls. Bulkified Code bedeutet, Sie laufen nur einmal zum Laden, nehmen alle 12 Eier auf einmal, und gleichzeitig noch alles was Sie brauchen, was im selben Regal steht.
-
Bulk API:
Die Bulk-API von Salesforce bietet eine programmatische Option zum schnell Laden von großen Datenmengen in Salesforce. Für die Verwendung der API sind grundlegende Kenntnisse der Softwareentwicklung, der Webservices und der Salesforce-Benutzeroberfläche erforderlich.
Die Bulk-API basiert auf den REST-Prinzipien und ist für das Laden oder Löschen großer Datenmengen optimiert. Die können Sie verwenden, um viele Datensätze asynchron abzufragen, einzufügen, zu aktualisieren und vieles weitere, indem Sie komplette Datenstapel verwenden. Salesforce verarbeitet diese Stapel dann im Hintergrund. Z. B. kann die Bulk-API 50.000 Datensätze mit nur einem einzigen API Call auf die Datenbank schreiben. Diese wird daher auch vom Salesforce Dataloader verwendet.
Wichtiger Unterschied zur Standard SOAP-API, die häufig bei Schnittstellen Anwendung findet: Die SOAP-API ist für Echtzeit-Client-Anwendungen optimiert, die nur wenige Datensätze gleichzeitig aktualisiert. Beispiel: Wenn Sie 1 Millionen Eier brauchen, dann müssen Sie mit Ihrem PKW ziemlich oft hin und herfahren, da in diesen nur maximal 50.000 Eier passen. Stattdessen können Sie aber auch einen LKW verwenden (die BULK API), in den mehr als 50.000 Eier auf einmal passen. Dieser ist zwar etwas sperriger im Handling und braucht mehr Erfahrung, liefert Ihnen aber pünktlich alle Eier.
-
Einschub: Entscheidungshilfe SOAP vs. Bulk API
Die SOAP API kann auch große Datenmengen verarbeiten. Aber wenn die Datenmenge Hunderttausende von Datensätzen enthält, ist die SOAP-API ungeeignet – nicht nur aufgrund der Limits. Die Bulk-API hingegen ist schon so konzipiert, dass die Verarbeitung von Daten von einigen Tausend bis zu Millionen von Datensätzen leicht bewerkstelligt werden kann.
-
Middleware-Buffering:
Wenn eine Middleware jeden einzelnen Datensatz direkt weiterreicht, bspw. wie bei Echtzeit-Schnittstellen, dann erreichen Sie die Limits schnell. Eine Möglichkeit kann es hier sein, die Datensätze erst in der Middleware zu puffern. Somit verfügt das SAP PI PO Modul über Möglichkeiten, Datensätze bis zu einer gewissen Anzahl oder bis zu einer gewissen vergangenen Zeit zu puffern und dann gesammelt nach Salesforce zu schicken:
- Z. B. immer, wenn 10 Datensätze gepuffert sind, werden diese gesammelt rübergeschickt.
- Wenn die 10 Datensätze noch nicht erreicht sind, diese allerdings schon seit 10 Minuten auf den Versand warten, werden diese trotzdem schon verschickt. Damit der Endnutzer nicht zu lange auf die Aktualisierung warten muss.
Sind API Limits also eine Gefahr?
Meist ist das API Limit ein unterschätztes Risiko, das am häufigsten in der Praxis zu Problemen führt. Sie benötigen gute Entwickler, die einen qualitativen Code erzeugen müssen, damit dies kein Problem ist. Aus diesem Grund sollten Sie genau das bei initialen Überlegungen berücksichtigen, was die Integrationsprozesse angeht.
Ich hoffe ich konnte Ihnen im ersten Teil einen guten und verständlichen Überblick über die Limits von Salesforce geben. Falls Sie Fragen haben sollten bezüglich der Salesforce Limits, dann kontaktieren Sie mich gerne.
Automatischer Datenaustausch zwischen SAP und Salesforce
Unsere Lösung sorgt für eine einfache, automatische Synchronisierung zwischen den Systemen. So sehen Sie Ihre Kundendaten in beiden Systemen!
