Warum eine Middleware allein für die Salesforce-Integration nicht ausreicht

Salesforce ist Ihr digitaler Front-Tier-Kern für Ihren Kundenerfolg. Sie integrieren ERP-Systeme wie SAP, Webshops wie Amazon oder eBay, Zahlungssysteme wie PayPal, soziale Medien wie Facebook oder LinkedIn und Legacy-Datenspeicher wie Datenbanken, Dateien oder FTP – zu und von Ihrem Salesforce – um ein verbundenes, unterbrechungsfreies Kundenerlebnis über eine Middleware zu schaffen.

Es funktioniert wie geplant. Aber eines Tages stellen Sie fest, dass einige Daten fehlen – Daten, die angeblich von der Middleware gesendet wurden. Sie sind nicht sicher, welche Daten tatsächlich auf der Salesforce-Seite angekommen sind, und fragen sich: „Wo kann ich die Daten sehen, die von der Middleware gesendet wurden?" – denn die Middleware bietet eine Monitoring-Funktion, um Daten zu sehen, die die Middleware verlassen, aber nichts darüber, was auf der Salesforce-Seite passiert ist.

Sie haben ein HR- und Abrechnungssystem mit Ihrem Salesforce verbunden und müssen den Datenverlauf für Ihre Prüfungsabteilung führen – um Nachweise für eine behördliche Sicherheits- und Prüfungsüberprüfung zu erbringen. Für einen solchen Prüfungsprozess reichen Daten auf einer Seite (Absender / Middleware) nicht aus und erfüllen nicht den behördlichen Prüfungsstandard. Sie werden aufgefordert, auch die andere Seite bereitzustellen – d.h. die Daten, die auf der Salesforce-Seite angekommen sind. Wie werden Sie solche Protokollierungs- und Nachverfolgungsdaten auf der Salesforce-Seite bereitstellen?

Da Sie eine Middleware verwenden, haben Sie eine nützliche Alarmierungsfunktion für den Fall, dass eine Nachricht beim Senden an Salesforce fehlschlägt. Aber eines Tages stellen Sie fest, dass einige Alarme seltsame technische Fehlertexte enthalten wie:

„java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.AbstractStringBuilder.substring(AbstractStringBuilder.java:868)"

Dabei würden Sie eine klare Geschäftsfehlermeldung erwarten, die Ihnen etwas sagt wie: „Angebot XX kann aufgrund eines ungültigen Verkaufsbereichscodes nicht gebucht werden." Welchen der beiden Fehlertexte würden Sie lieber sehen?

Wie Middleware-Integration funktioniert

Lassen Sie uns verstehen, wie die Salesforce-Integration über Middleware tatsächlich funktioniert. Um eine Verbindung zu Salesforce herzustellen, stellt die Middleware einen technischen Connector bereit, der die SOAP- oder REST-API der Salesforce-Standard-API aufruft und verwendet. Es nutzt das Request/Response-Muster – jeder Aufruf wartet, bis der Vorgang auf der Salesforce-Seite abgeschlossen ist. Dies ist die Art eines synchronen API-Aufrufs, der dem Tight-Coupling-Architekturmuster folgt.

Mit der Salesforce-Standard-API können Sie die vier grundlegenden CRUD-Operationen durchführen – Create, Read, Update und Delete eines sObjects. Aber über diese vier Grundoperationen hinaus stehen auf der Salesforce-Seite standardmäßig keine weiteren Funktionen zur Verfügung.

Betrachten Sie dieses Beispiel: Ihre Integration muss einen Kontakt aktualisieren, wenn er in Ihrem ERP-System (z.B. SAP) geändert wurde. Aber vor der Aktualisierung müssen Sie die Zuweisungsregel prüfen – ob der Kontakt den Status „Freigegeben" hat und von der Vertriebsgruppe „Innendienst" betreut wird. Nach der Aktualisierung des Kontakts möchten Sie den Status auf „Synchronisiert" ändern. Das bedeutet, Sie benötigen Vor- und Nachverarbeitungslogik neben der eigentlichen Integration – aber wie soll das mit der Standard-API allein funktionieren?

Was fehlt?

Da Salesforce – mit all den Apps von Drittanbietern und Ihren eigenen Anwendungen – zu einer so wichtigen digitalen Front-Tier-Schicht für Ihren Kundenerfolg geworden ist, benötigen Sie eine Integration der Enterprise-Klasse, die über den einfachen API-vernetzten Ansatz hinausgeht.

Sie müssen möglicherweise Ihrer einfachen API-Integration Geschäftslogik hinzufügen. Sie benötigen vielleicht Monitoring, Alerting und eine einfache Möglichkeit, Fehler auf Ihrer Salesforce-Seite zu behandeln. Möglicherweise stehen Sie in dringenden Situationen, in denen die Middleware nicht verfügbar ist und die Nachricht nicht rechtzeitig erneut senden kann – in diesem Fall wäre es eine große Hilfe, wenn Sie Daten auf der Salesforce-Seite korrigieren und eine Neuverarbeitung auslösen könnten. Außerdem benötigen Sie aus technisch-architektonischer Sicht ein Loose-Coupling-Muster für die Massenübertragung von Daten, was nur durch die Verwendung asynchroner APIs erreicht werden kann.

Warum eine Entkopplungsschicht benötigt wird

Die oben genannten zusätzlichen Mehrwertdienste werden für eine Integration der Enterprise-Klasse benötigt – aber sie sind weder auf der Salesforce-Plattform verfügbar noch kann die Middleware sie anbieten. Um solche Dienste bereitzustellen, wird eine Entkopplungsschicht auf der Salesforce-Plattform benötigt, die eingehende Daten als Nachrichten für die Verarbeitung zu einem geeigneten Zeitpunkt zwischenspeichern kann. Da eine solche Schicht zuvor nicht auf der Salesforce-Plattform existierte, hat SKYVVA eine solche Schicht entwickelt.

Der Service Layer ist die technische Grundlage für alle Funktionen, die eine asynchrone Ausführung der API-Verarbeitung ermöglichen. Das asynchrone Muster ist ein entscheidender Faktor in der Integrationsarchitektur, da es Entkopplungsfähigkeit und Betriebsunabhängigkeit bietet – es ist lose gekoppelt. Lose Kopplung gibt den Client sofort frei, sodass er nicht warten muss, bis der aufgerufene Vorgang abgeschlossen ist.

Ein weiterer wichtiger Vorteil ist die Möglichkeit, die Nachrichtenverarbeitung auf einen späteren Zeitpunkt zu verschieben. Stellen Sie sich vor, Sie haben einen Webshop und müssen täglich Millionen von Produktpreisen aktualisieren. Dies in Echtzeit zu tun würde Salesforce-Governor-Limits, verfügbare Threads und die Performance während der Geschäftszeiten belasten. In solchen Situationen genügt es, die aktualisierten Preise morgens bereitzuhaben – mit Batches von z.B. 10.000 Preisaktualisierungen, die ab 22:00 Uhr verarbeitet werden. Ohne einen Service Layer wie SKYVVA ist ein solcher Anwendungsfall mit der Standard-API schlicht nicht handhabbar.

Zusätzliche Services, die Sie einfach brauchen

Die folgenden sechs Mehrwertfunktionen helfen dabei, Wartung und Betrieb Ihrer täglichen Salesforce-Integration zu vereinfachen. Natürlich könnten Sie sagen, Sie brauchen sie nicht, weil alles reibungslos läuft. Aber vergessen Sie nicht: Der Tag, an dem Probleme auftauchen, kommt früher als Sie denken – und in diesem Moment werden Sie diese Funktionen nicht missen wollen.

#1 — Monitoring	End-to-End-Transparenz	Ein zweites Auge auf der Salesforce-Seite. Echtes End-to-End-Monitoring mit 100% Sichtbarkeit auf beiden Seiten der verbundenen Plattform.
#2 — Reprocessing	Notfall-Selbsthilfe	Fehlgeschlagene Nachrichten eigenständig neu verarbeiten, wenn die Middleware ausgefallen ist. Daten direkt in Salesforce korrigieren und erneut verarbeiten.
#3 — Alerting	Authentische Geschäftsalarme	Echte Salesforce-seitige Alarme mit dem originalen Fehlertext – nicht die internen technischen Ausnahmen der Middleware. Direkt und in Echtzeit gesendet.
#4 — Workflow	Regelbasierte Verarbeitung	Vorbedingungen und Regeln definieren, bevor Daten gebucht werden. Falsche oder inkonsistente Daten blockieren, bevor sie Schaden anrichten.
#5 — Business-Logik	Apex, Flows & mehr	Apex-Klassen, Process Builder oder autolaunched Flows direkt mit der SKYVVA-Schnittstelle verknüpfen – für leistungsstarke Nach-Verarbeitungslogik.
#6 — Batch & Scheduling	Massenverarbeitung	Massenverarbeitungen in ein nächtliches Zeitfenster verschieben. Salesforce-Performance während der Geschäftszeiten schützen.

Mehrwert #1 — Monitoring

Um die Monitoring-Funktion zu veranschaulichen, betrachten wir ein reales Schnittstellenbeispiel: die verbundenen Systeme sind SAP ERP (Absender), SAP PI (Middleware) und Salesforce (Empfänger). Das Szenario: Kundendaten ändern sich in SAP und sollen sofort zurück zu Salesforce synchronisiert werden.

Betrachten Sie nun das Monitoring in den verbundenen Systemen. Mit dem Standard-API-Ansatz sehen Sie Monitoring auf SAP ERP und SAP PI – aber auf der Salesforce-Seite gibt es keine Monitoring-Möglichkeit. Die Daten scheinen erfolgreich gesendet worden zu sein (grüne Markierung bei SAP PI), aber der Salesforce-Datensatz wurde nicht aktualisiert. Was ist passiert?

Ohne eine native Monitoring-Schicht haben Sie keine einfache Möglichkeit, die Ursache zu finden. Sie müssten Ihr erfahrenes Apex-Entwickler-Team hinzuziehen – und Stunden mit einem Problem verbringen, das ein Monitoring-Dashboard in Minuten sichtbar gemacht hätte.

Betrachten wir nun dasselbe Szenario, neu aufgebaut mit SKYVVA. Sie verwenden den SKYVVA-Connector auf der SAP PI-Seite und den SKYVVA Service Layer auf der Salesforce-Seite:

Mehrwert #2 — Reprocessing

Bleiben wir beim obigen Beispiel. Sie sehen die rote Nachricht im SKYVVA-Monitoring. Sie verstehen den Geschäftsfehler und müssen die Adresse noch heute aktualisieren – denn Sie müssen vor Geschäftsschluss ein Angebot an diesen Kunden senden. Sie rufen Ihren SAP-ERP-Kollegen an, um die Nachricht erneut zu senden, aber er hat das Büro bereits verlassen. Die erneute Übertragung erfolgt erst morgen früh – zu spät für Ihren Notfall. Was können Sie tun?

Mit SKYVVA verwenden Sie einfach die Reprocessing-Funktion. Öffnen Sie die Nachricht, korrigieren Sie die Daten, speichern Sie und klicken Sie auf Reprocess:

Es gibt auch einen geplanten automatischen Reprocessing-Job für Fehler, die keine manuelle Datenkorrektur erfordern – zum Beispiel vorübergehende Fehler, die einfach einen erneuten Versuch benötigen:

Mehrwert #3 — Alerting

Monitoring ist großartig, aber es erfordert, dass Sie es aktiv überprüfen. Wäre es nicht besser, eine Alarm-E-Mail zu erhalten, sobald etwas fehlschlägt?

SAP ERP hat Alerting, SAP PI hat Alerting – aber auf Salesforce gibt es keinen Alarm aus der Standard-API. Das Problem bei ausschließlicher Nutzung des Middleware-Alertings: Die Middleware kann ihre eigenen internen Fehler melden – nicht den tatsächlichen Fehler, der auf Salesforce aufgetreten ist. Zum Beispiel:

„java.lang.StringIndexOutOfBoundsException: String index out of range: -1"

Dies hat nichts mit der eigentlichen Ursache auf Salesforce zu tun. Middleware-basierte Alarme sind:

• Ungenau – manchmal schlicht der falsche Alarm
• Nicht echtzeitfähig genug – wenn die Middleware hängt oder ihre Performance nachlässt
• Indirekt – über die Middleware weitergeleitet statt direkt von Salesforce gesendet

SKYVVA fügt der Salesforce-Plattform eine native Alarmierungskomponente hinzu. Alarme werden direkt und in Echtzeit von Salesforce gesendet – Sie sehen immer den wahren, originalen Fehlertext. Das Alerting kann auf Integrations- oder Schnittstellenebene definiert und auf vier Wegen zugestellt werden:

• Externe E-Mail
• Interne E-Mail, verknüpft mit einem Salesforce-Benutzer
• Salesforce Task
• Chatter-Gruppen-Benachrichtigung

Mehrwert #4 — Workflow

Bei der Verwendung der Salesforce-Standard-API zum CRUD eines sObjects gibt es keine Validierung oder Prüfung vor der Ausführung – es wird einfach ausgeführt und der Datensatz sofort geändert. In den meisten Integrationsszenarien benötigen Sie jedoch eine Validierung vor der Änderung Ihrer Geschäftsdatensätze, sonst riskieren Sie Dateninkonsistenzen.

Mit dem SKYVVA Workflow können Sie auch eine Kette von Verarbeitungsschritten definieren, die mehrere Schnittstellen umfassen. Sie möchten beispielsweise sowohl einen Account als auch einen Kontakt in einem einzigen API-Aufruf ändern – der Workflow empfängt die Daten in einer Nachricht und leitet sie durch beide Verarbeitungsschritte. So lassen sich komplexe Operationen in einem einzigen Aufruf bewältigen.

Mehrwert #5 — Business-Logik

Eine Nachricht wird als Payload von der Middleware zu Salesforce übertragen, und über die Standard-API können Sie ein sObject mittels CRUD bearbeiten. Manchmal reicht das aus. Aber viele Integrationsszenarien erfordern Geschäftslogik, die über einfache CRUD-Operationen hinausgeht.

Mit SKYVVA können Sie eine Apex-Klasse direkt mit einer Schnittstelle verknüpfen. Wenn die Nachricht die SKYVVA-Schicht erreicht, wird Ihre Apex-Logik ausgeführt, in der Sie beliebige Geschäftsanforderungen implementieren können. Sie können auch das gesamte deklarative Werkzeug von Salesforce nutzen:

• Entwickler: Apex-Trigger und Apex-Klassen
• Admins (ohne Code): Process Builder und autolaunched Flows

So können Sie komplexe Geschäftslogik zu Ihrer Datenintegration hinzufügen – ohne die Komplexität auf die Middleware-Seite zu verlagern, wo sie nicht hingehört.

Mehrwert #6 — Batch und Scheduling

Middleware-basierte Integration wird hauptsächlich in Anwendung-zu-Anwendung-Szenarien eingesetzt, bei denen kein Endbenutzer direkt auf der anderen Seite wartet. Für Massen- und Hochvolumen-Dateninitegrationen ist Batch- und Hintergrundverarbeitung der richtige Ansatz, um Ressourcen und Performance zu optimieren.

Das Problem mit der Standard-API ist, dass es nicht möglich ist, die Verarbeitung zu verzögern oder als Hintergrundprozess zu einem späteren Zeitpunkt auszuführen. SKYVVA fügt der Salesforce-Plattform einen Scheduler und eine Job-Verarbeitungskomponente hinzu:

Sie können den Zeitplan flexibel definieren: alle 15 Minuten ausführen, einmalig zu einem bestimmten Zeitpunkt (z.B. 1:00 Uhr), oder stündlich innerhalb eines Zeitfensters (z.B. 22:00 bis 4:00 Uhr). Sie können auch auswählen, welche Wochentage oder Monate von der Verarbeitung ausgeschlossen werden sollen.

Mit Batch-Verarbeitung und Scheduling können Sie Pakete von 10.000 Nachrichten täglich von 22:00 bis 6:00 Uhr verarbeiten, stündlich. Das verteilt die Last und hält die Salesforce-Performance für Endbenutzer während der Geschäftszeiten reibungslos aufrecht.

Zusammenfassung

Alle sechs Mehrwertfunktionen heben Ihre Integrationsqualität auf das nächste Level und geben Ihnen die operativen Instrumente, um den täglichen Betrieb zu vereinfachen. Dieser Ansatz geht weit über die einfache API-Integration hinaus, bei der nur pure Konnektivität möglich ist. Wenn Sie eine Enterprise-Integration wollen, ist der reine Middleware-Ansatz definitiv nicht ausreichend.

End-to-End-Monitoring und Alerting erhöhen die Qualität und verbessern Fehlerbehandlung und den täglichen Betrieb erheblich. Nachrichten-Reprocessing gibt Ihnen ein mächtiges Werkzeug, um Notfälle zu bewältigen, wenn das Sendersystem vorübergehend nicht verfügbar ist. Workflow und Business-Logik überwinden die Einfachheit und Einschränkungen der grundlegenden CRUD-Operationen und ermöglichen komplexe Geschäftsszenarien ohne Überfrachtung der falschen Seite. Und Batch und Scheduling entkoppeln Sender und Empfänger, schaffen weniger Abhängigkeiten und optimieren die Performance für die Massenverarbeitung von Daten.

← Zurück zum Blog