Die wichtigsten Salesforce Limits „Logins per Hour‘‘ und „Code Limits‘‘ im Überblick – Teil 2
Wichtige Integrationsprojekte, wie bspw. große Datenmengen aus einem SAP ERP nach Salesforce zu schieben sind meist schon kompliziert genug. Wenn dann unerwartete und schwer zu entziffernde Fehler auftreten, muss manchmal die gesamte Architektur der Schnittstelle umgestellt werden. Noch schlimmer ist es, wenn dies erst nach dem Go-Live unter vollem Betrieb auffällt. Um dies zu verhindern, möchte ich Ihnen diese Blogreihe vorstellen. Denn oftmals liegt genau dieses Problem an den Salesforce Limits, die gern vergessen werden. Hier erfahren Sie alles rundum die Logins per Hour und den Code Limits, die Salesforce aus bestimmten Gründen gesetzt hat.
API-Calls und Ihre Problematik – Teil 1
Falls Sie unseren ersten Teil Die wichtigsten Salesforce Limits, wie API Calls, im Überblick noch nicht gelesen haben, empfehle ich Ihnen dazu, das erst zu tun. Somit erhalten Sie einen vollständigen Überblick, warum Salesforce überhaupt so strikt limitiert ist und was es mit einem der Limits, dem API-Call-Limit, alles auf sich hat.
Limit 2: Logins per Hour – deswegen können Ihre Schnittstellen-User blockiert werden
Um die Performance weiter abzusichern, sind auch die Login-Versuche in die Salesforce Cloud limitiert.
Dafür gibt es die Login-Rate. Diese Rate gibt an, wie oft ein Benutzer innerhalb eines bestimmten Zeitraums versuchen darf, sich bei Salesforce anzumelden. Durch die Begrenzung der Login-Rate kann Salesforce die Anzahl der Anmeldeanforderungen pro Benutzer begrenzen. So vermeiden Sie Leistungseinbußen bei Salesforce-Diensten und verbessern die Sicherheit bei der Anmeldung bei Salesforce. Dies ist insbesondere wichtig bei DDOS Angriffen (eine Systemüberlastung durch die schiere Anzahl an Anfragen) oder den klassischen Brute Force Attacken (Passwörter erraten, indem einfach alle möglichen Kombinationen ausprobiert werden) auf Ihre Systemlandschaft.
Wie hoch ist das Limit hier?
Das Limit besteht meist aus 3.600 Anfragen pro Stunde. Wenn Sie es überschreiten sollten, wird der User blockiert und es gibt einen Fehler: LOGIN_RATE_EXCEEDED. Dieser Fehler ist auch sichtbar auf der Setup Seite.
Wodurch kann dieser Fehler in der Praxis entstehen?
Oft ist schwer nachvollziehbar, wodurch dieser Fehler verursacht wird, daher hier ein paar Beispiele:
-
Incorrect username(s) and password(s):
Normalerweise werden bei Schnittstellen sogenannte Integration-User verwendet – also ein dedizierter User, der nur dafür da ist, , durch eine Schnittstelle zur Authentifizierung genutzt zu werden. Je nachdem wie die Schnittstelle programmiert ist, kann nach einem unerfolgreichen Login, bspw. durch ein falsches Passwort, einfach ein neuer Versuch gestartet werden. Wenn hier kein maximales Limit an Versuchen eingebaut wurde, kommt es schnell zu einer Schleife von Logins und somit ist das Limit innerhalb kurzer Zeit erreicht.
-
Inperformante Programmierung:
Wenn die Schnittstellenprogrammierung nicht bulkified programmiert ist oder die Session ID jedes Mal neu angefordert wird, kann bei großen Datenübertragungsaufkommen auch das Limit gesprengt werden.
Beispiel: Es sollen 4.000 Preise von Materialien in SAP geupdated werden. Über die Middleware wird bspw. die Salesforce SOAP API angesprochen. Jede Änderung triggert die Schnittstelle. Somit wird jedes Mal eine neue Session erstellt, indem ein Login request mit dem Schnittstellen-User erstellt wird. In diesem Fall bricht die Schnittstelle nach 3.600 Anfragen schon ab, selbst wenn das API Limit noch bei weitem nicht erreicht ist. Als Lösung sollten Sie hier als Best Practice immer die ursprünglich angefragte Session wiederverwenden. Hierzu eignet sich z. B. der standardisierter SAP PI Salesforce Adapter, der das für Sie übernimmt. Mehr Infos dazu erhalten Sie auch im SOAP API Developer Guide.
-
Bei automatisierten Jobs:
Automatisierte Jobs benötigen ebenfalls einen Login request und zählen damit zu den 3.600 Calls. Kommt es hier zu einem zu häufigen Aufruf, wird das Limit ebenfalls gesprengt.
-
Mehrfachbenutzungdesselben Users für Integrationen und andere externe Dienste:
Multiple Client Applications können sich mit demselben User anmelden. Dies spart die wertvollen Salesforce Lizenzen, indem nur eine Lizenz für einen User verwendet wird. Dieser Ansatz erhöht jedoch das Risiko von Fehlern aufgrund von Abfragegrenzen. Ein Benutzer kann bis zu 10 Abfragecursor gleichzeitig öffnen. Wenn 10 QueryLocator-Cursor geöffnet sind, die als derselbe Benutzer angemeldet ist versucht, eine neue zu öffnen, wird der älteste der 10 Cursor freigegeben. Wenn die Clientanwendung versucht, den freigegebenen Abfragecursor zu öffnen, tritt ein Fehler auf. Dazu erfahren Sie mehr an dieser Stelle unter: proxy all requests im SOAP API devoleper guide.
Quintessenz der Login Limit für Sie:
Das Login-Limit kommt seltener vor als das Limit bei den API Calls. Dennoch: Wenn es zu einem Problem wird, werden oft umfangreiche Anpassungen notwendig. Hier empfiehlt es sich also, das vorab initial in die Überlegungen miteinzubeziehen oder einen fertigen Adapter mit dazu kaufen, wie z. B. unseren standardisierten SAP PI Connector.
Limit 3: Code Limits – das sollten Sie beachten, bevor es unübersichtlich wird
Hier fasse ich Ihnen verschiedene Code Limits zusammen. Eine vollständige Übersicht finden Sie hier:
Die wichtigsten Limits kurz angerissen:
- Anzahl an SOQL Abfragen – d. h. Abfragen an die Datenbank innerhalb von Salesforce
- Beispiel: Wenn Sie 300 Kundenstammdatensätze einfügen und die alle bspw. über die Verkäufergruppen (SAP VKGRP) einem User zuordnen möchten und jedes Mal eine einzelne SOQL Abfrage starten: SELECT Id from User where SAP_VKGRP = <mein Wert> dann bricht diese Ausführung ab. Wie eingangs schon erwähnt, ist es hier ein bulkified Code sehr wichtig.
- Auch die Gesamtzahl an Records, die Sie mit SOQL lesen ist beschränkt, nämlich auf 50.000 pro Aufruf
- Maximale CPU-Zeit auf den Salesforce-Servern: Für synchrone Aufrufe 10s für asynchrone 60s
- Maximale Anzahl an Callouts (HTTP Anfragen oder Web Service Aufrufe) in einer Transaktion: 100
Sie sehen, hier gilt es einiges zu beachten. Das kann schnell unübersichtlich werden. Deswegen lohnt es sich hier zur generellen Architektur einen zertifizierten Architekten ins Haus zu holen – wir ziehen auch bei jedem unserer Projekte einen Architekten hinzu.
Grundsätzlich gilt aber auch: Wenn die Architektur gut durchdacht ist, sind Limits selten ein Problem. Erfahrung bringt Sie hier also viel weiter.
Kleiner Tipp am Ende
Falls es doch mal dazu kommt, dass Sie ein Limit vorrübergehend überschreiten, z. B. wenn Sie initial sehr sehr viele Daten vor dem GoLive laden oder wenn es temporär zu vielen Datenänderungen kommt und Sie diese über die Schnittstelle schieben müssen, dann kann sich ein schneller Case beim Salesforce-Support lohnen. Begründen Sie das einfach mit der Bitte, ein spezielles Limit temporär erhöhen zu wollen und einer kurzen Beschreibung des Anwendungsfalls.
Wichtig: Das sollte proaktiv passieren. Ansonsten wirft die Schnittstelle Fehler und manche Daten kommen nicht mehr an. Machen Sie sich also vorab Gedanken dazu, um den Limitüberschreitungen vorzubeugen.
Ich hoffe natürlich, dass ich Ihnen mit diesem Einblick über die wichtigsten Salesforce Limits behilflich sein konnte. Wenn Sie aber dennoch Fragen haben sollten oder Sie Unterstützung bei dem Thema wünschen, 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!
