Für eine Salesforce-Integration mit SAP, einem anderen ERP oder einem eigenen Backend gilt eine einfache Faustregel: Eine direkte API reicht bei ein bis zwei Verbindungen mit klarem Prozess. Eine Middleware lohnt sich, sobald drei oder mehr Systeme Daten austauschen oder bereits eine Integrationsschicht im Haus läuft. Ein iPaaS mit fertigen Konnektoren passt, wenn wenige Cloud-Tools mit kleinen Datenmengen verbunden werden und niemand eine Schnittstelle betreiben soll.
Das Werkzeug ist aber die zweite Frage. Die erste ist fachlich: Welches System führt welches Feld, was löst den Abgleich aus und wohin geht ein Fehler? Wer das vor dem Angebot klärt, kann das Werkzeug fast frei wählen. Wer es nicht klärt, baut mit jedem Werkzeug doppelte Datensätze. Dieser Leitfaden gibt Ihnen eine Entscheidungstabelle und fünf Fragen, die vor jedem Integrationsangebot beantwortet sein müssen.
Warum Salesforce-Integrationen an Fachfragen scheitern, nicht an Technik
Eine Schnittstelle zu bauen ist heute selten das Problem. Salesforce bietet REST- und SOAP-APIs, Ereignisse und Massenschnittstellen, und jedes ERP hat eine eigene API. Schwierig wird es an einer anderen Stelle: wenn zwei Systeme dasselbe Feld pflegen und niemand festgelegt hat, welches gewinnt.
Bei einem Premium-Kamerahersteller habe ich in der Analyse der Service Cloud genau das gefunden. Die Stammdatenhoheit zwischen Salesforce und SAP war nicht geklärt, und das war die Ursache doppelter Cases. Ein schnelleres oder teureres Werkzeug ändert an so einer Ursache nichts. Es verteilt den Fehler nur schneller.
Mit KI-Agenten wird die Frage dringender. Ein Agent, der einen Kunden einordnen oder einen Auftrag nachschlagen soll, ist nur so gut wie die Daten, die aus den Umsystemen kommen. Doppelte oder veraltete Stammdaten machen aus einer guten Antwort eine falsche.
Ob API, Middleware oder iPaaS, ist die zweite Frage. Die erste lautet: Welches System führt welches Feld?
Datenhoheit je Feld: Welches System führt welche Daten?
Datenhoheit heißt: Für jedes Feld gibt es genau ein führendes System, das System of Record. Nur dort wird der Wert geändert, alle anderen Systeme lesen ihn. Das klingt selbstverständlich und wird trotzdem fast nie pro Feld festgelegt, sondern pro Objekt. Und auf Objektebene ist die Antwort meist falsch.
Ein Beispiel: Beim Kunden führt das ERP die Rechnungsanschrift, die Debitorennummer und die Zahlungsbedingungen. Salesforce führt den Ansprechpartner, die Branche und den zuständigen Vertriebsmitarbeiter. Wer sagt, SAP führt den Kunden, hat für die Hälfte der Felder die falsche Regel. Wie diese Aufteilung bei DATEV aussieht, zeige ich in DATEV und Salesforce verbinden.
Für jedes Feld, das zwischen den Systemen wandert, brauchen Sie vier Angaben:
- Führendes System: Wo wird der Wert angelegt und geändert?
- Auslöser: Was startet den Abgleich? Eine Änderung, eine Abfrage des Nutzers oder eine feste Uhrzeit?
- Richtung: Fließt der Wert nur in eine Richtung oder in beide? Beide Richtungen für dasselbe Feld sind fast immer ein Warnsignal.
- Schlüssel: Über welche Kennung finden sich die Datensätze? In Salesforce ist das ein External ID-Feld, etwa die Debitorennummer aus dem ERP.
Drei Integrationsmuster: Echtzeit-Abfrage, Ereignis oder nächtlicher Abgleich
Bevor es um Werkzeuge geht, entscheidet sich, wie die Daten fließen. Salesforce kennt drei grundlegende Muster, und jedes passt zu einer anderen Frage.
1. Abfrage in Echtzeit (REST oder SOAP). Ein System fragt, das andere antwortet sofort. Das passt, wenn ein Nutzer gerade wartet, etwa auf den aktuellen Lagerbestand oder den offenen Saldo im Kundendatensatz. Bei einem Außenwerbe-Unternehmen habe ich ein individuelles Backend-System auf diesem Weg per REST an Salesforce angebunden.
2. Ereignis (Platform Events und Change Data Capture). Ein System meldet eine Änderung, und alle Interessierten reagieren darauf. Platform Events sind selbst definierte Nachrichten, etwa Auftrag freigegeben. Change Data Capture veröffentlicht automatisch jede Änderung an ausgewählten Salesforce-Objekten. Beides ist laut Salesforce in Enterprise, Performance, Unlimited und Developer Edition verfügbar. Ohne Zusatzlizenz können Sie für Change Data Capture fünf Objekte auswählen, und eine Enterprise-Org darf in 24 Stunden 25.000 Ereignisse an externe Abonnenten ausliefern. Jeder Abonnent zählt dabei einzeln.
3. Nächtlicher Abgleich (Bulk API). Große Mengen wandern gesammelt zu einer festen Zeit, etwa Preislisten oder Umsatzhistorien. Die Bulk API verarbeitet die Daten asynchron in Paketen statt Datensatz für Datensatz.
Die Wahl des Musters hat direkte Folgen für Ihre API-Zuteilung. Eine Enterprise-Org bekommt laut Salesforce-Dokumentation zu API-Limits 100.000 Aufrufe pro 24 Stunden plus 1.000 je Salesforce-Lizenz. Bei 50 Lizenzen sind das 150.000. Angenommen, das ERP schreibt jede Nacht 40.000 geänderte Preise einzeln per REST: Dann ist mehr als ein Viertel der Tageszuteilung verbraucht, bevor der erste Nutzer sich anmeldet. Bulk-Aufrufe und die Aufrufe installierter AppExchange-Pakete zählen übrigens auf dieselbe Zuteilung.
Direkte API, Middleware oder iPaaS: Welches Werkzeug passt?
Die drei Begriffe werden unscharf verwendet, deshalb kurz, was ich damit meine:
- Direkte API: Eine Punkt-zu-Punkt-Verbindung. Salesforce ruft das andere System auf, etwa per Apex oder Flow mit Named Credentials, oder das andere System ruft die Salesforce-API auf.
- Middleware: Eine zentrale Integrationsschicht zwischen allen Systemen, die Mappings, Warteschlangen und Überwachung bündelt. Typische Vertreter sind die SAP Integration Suite oder MuleSoft. Sie wird von Ihrer IT oder einem Dienstleister betrieben.
- iPaaS: Integration Platform as a Service, eine Cloud-Plattform mit fertigen Konnektoren, die der Anbieter betreibt. Im Mittelstand sind das oft Low-Code-Werkzeuge wie Make oder Zapier.
Die Grenze ist fließend, denn auch große Middleware läuft heute als Cloud-Dienst. Für die Entscheidung zählt weniger das Etikett als die Frage, wer die Integrationsschicht betreibt und wer die Mappings pflegt, wenn sich ein Feld ändert.
| Kriterium | Direkte API | Middleware | iPaaS (Low-Code) |
|---|---|---|---|
| Zahl der Systeme | 1 bis 2 Verbindungen | 3 und mehr, die untereinander Daten tauschen | Wenige Cloud-Tools |
| Datenmenge | Klein bis mittel, eher Echtzeit | Hoch, auch Massendaten | Klein, Aufgabe für Aufgabe |
| Wer betreibt | Entwickler, intern oder extern | IT oder Integrationsdienstleister | Fachbereich oder Admin |
| Laufende Kosten | Keine Zusatzlizenz, aber Wartung des Codes | Eigene Lizenz plus Betrieb | Abo, steigt mit der Zahl der Ausführungen |
| Releases und Änderungen | Jede Änderung ist ein Deployment | Mappings zentral an einer Stelle | Schnell geändert, schwer zu versionieren |
| Fehler und Überwachung | Muss selbst gebaut werden | Wiederholung und Protokoll eingebaut | Einfach, für Kernprozesse oft zu dünn |
| Typischer Fall | Eigenes Backend, ein Prozess | SAP plus weitere Kernsysteme | Formular, Kalender, Marketing-Tool |
Daraus ergeben sich drei Regeln. Erstens: Wenn im Unternehmen schon eine Integrationsschicht läuft, etwa für SAP, nutzen Sie diese, statt daneben eine zweite aufzubauen. Zweitens: Punkt-zu-Punkt wächst schneller, als es sich anfühlt. Bei n Systemen, die alle miteinander sprechen, entstehen n mal (n minus 1) geteilt durch 2 Verbindungen: bei drei Systemen drei, bei fünf schon zehn, bei acht 28. Drittens: Low-Code-Werkzeuge sind für Randprozesse stark und für Stammdaten zwischen ERP und CRM zu dünn. Wo die Grenze zu Flow verläuft, zeigt mein Vergleich von Salesforce Flow, Zapier und Make.
Für SAP im Speziellen habe ich typische Ansätze und Fehler in SAP und Salesforce integrieren zusammengefasst. Auch dort beginnt der Fehler meist bei der Datenhoheit, nicht beim Konnektor.
Fehlerweg und Überwachung gehören in den ersten Entwurf
Jede Integration fällt irgendwann aus. Das ERP wird gewartet, ein Zertifikat läuft ab, ein Pflichtfeld kommt hinzu. Die Frage ist nicht, ob das passiert, sondern wer es merkt und was mit den Daten in der Zwischenzeit geschieht.
Im Entwurf sollte deshalb für jede Verbindung stehen:
- Wiederholung: Wie oft und in welchem Abstand wird ein fehlgeschlagener Aufruf wiederholt?
- Ablage: Wohin gehen Datensätze, die auch nach mehreren Versuchen nicht durchgehen? Ein Fehlerobjekt in Salesforce oder eine Warteschlange in der Middleware, aber nie ins Leere.
- Verantwortung: Wer bekommt die Meldung, und zwar als Rolle im Fachbereich, nicht als Sammelpostfach der IT?
- Abstimmung: Ein regelmäßiger Abgleich der Bestände, der zeigt, ob beide Systeme noch dasselbe wissen.
Für die API-Zuteilung bietet Salesforce im Setup API Usage Notifications: Eine E-Mail geht an einen festgelegten Nutzer, sobald ein bestimmter Anteil der Tageszuteilung verbraucht ist. Das kostet fünf Minuten und verhindert, dass ein Fehler in einer Schleife die Zuteilung für alle anderen Systeme aufbraucht.
Die 72 Stunden und das Nachholen verpasster Ereignisse über die Replay ID beschreibt Salesforce in der Dokumentation zur Pub/Sub API. Und denken Sie an die drei Salesforce-Releases pro Jahr: Jemand muss vor jedem Release prüfen, ob die Schnittstellen weiter laufen. Bei dem Außenwerbe-Unternehmen ist die Release-Prüfung fester Teil der laufenden Betreuung.
Fünf Fragen, die vor jedem Integrationsangebot beantwortet sein müssen
Wenn Sie diese fünf Fragen beantworten können, ist jedes Angebot vergleichbar und jede Schätzung belastbar. Wenn nicht, schätzt der Anbieter Ihre offenen Fachfragen mit, und das wird teuer.
- Welches System führt welches Feld? Als Feldliste, nicht als Satz pro Objekt.
- Was löst den Abgleich aus? Nutzeraktion, Änderung oder feste Uhrzeit, je Datenfluss.
- Wie viele Datensätze bewegen sich pro Tag? Daraus folgen Muster und API-Bedarf.
- Wohin geht ein Fehler, und wer kümmert sich? Mit Namen der Rolle, nicht der Abteilung.
- Wer betreibt die Integration nach dem Go-Live? Diese Antwort entscheidet oft mehr über das Werkzeug als jede Funktionsliste.
Häufige Fragen
Was ist der Unterschied zwischen Middleware und iPaaS?
Middleware ist eine zentrale Integrationsschicht, die Ihre IT oder ein Dienstleister betreibt und die Mappings, Warteschlangen und Überwachung bündelt. Ein iPaaS ist eine Cloud-Plattform mit fertigen Konnektoren, deren Betrieb der Anbieter übernimmt. Die Grenze ist fließend, entscheidend ist, wer die Integration im Alltag betreibt.
Wie viele API-Aufrufe hat meine Salesforce-Org?
Eine Enterprise-Org erhält laut Salesforce 100.000 Aufrufe pro 24 Stunden plus 1.000 je Salesforce-Lizenz, Unlimited und Performance 5.000 je Lizenz. Den aktuellen Verbrauch sehen Sie im Setup auf der Seite System Overview. Bulk-Aufrufe und installierte AppExchange-Pakete zählen auf dieselbe Zuteilung.
Brauche ich für eine SAP-Anbindung zwingend eine Middleware?
Nein. Läuft im Unternehmen schon eine Integrationsschicht für SAP, sollten Sie diese nutzen. Für wenige Objekte mit klarer Datenhoheit kann auch eine direkte API-Verbindung reichen, sofern Fehlerweg und Überwachung mitgebaut werden.
Echtzeit oder nächtlicher Abgleich: Was ist besser?
Echtzeit lohnt sich nur dort, wo jemand auf die Antwort wartet, etwa beim Lagerbestand im Kundengespräch. Für große Mengen wie Preislisten oder Umsatzhistorien ist ein nächtlicher Abgleich über die Bulk API günstiger und schont die API-Zuteilung.
Was passiert, wenn das ERP ausfällt?
Das hängt vom Entwurf ab. Eine gute Integration wiederholt fehlgeschlagene Aufrufe, legt dauerhafte Fehler in einer Warteschlange oder einem Fehlerobjekt ab und benachrichtigt eine zuständige Rolle. Ohne diesen Fehlerweg gehen Daten still verloren.
Wenn Sie eine Salesforce-Integration mit SAP, ERP oder eigenem Backend planen, kläre ich mit Ihnen zuerst die Datenhoheit und dann das Werkzeug. Im Assessment für komplexe Orgs bewerte ich Architektur und Integrationen, inklusive SAP, und Sie bekommen ein Zielbild mit Roadmap und eine Entscheidungsvorlage für Geschäftsführung und IT. Festpreis nach Scoping ab 9.000 Euro, bei Umsetzung voll anrechenbar. Die Schnittstelle baue ich danach auch selbst, als Berater und Entwickler in einer Person.
