Salesforce und SAP ECC verbinden - ohne Eingriff beim Hosting-Provider

Zwei starke Systeme, keine Verbindung

Der Kunde - ein mittelständischer deutscher Maschinenbauer mit wachsendem After-Sales-Geschäft - führt sein kaufmännisches Kerngeschäft auf SAP ECC und hatte Salesforce als Plattform für Vertrieb und Service eingeführt. Beide Systeme erfüllten ihre Aufgabe. Was fehlte, war die Verbindung dazwischen.

• Neu gewonnene Kunden aus Salesforce mussten im SAP ein zweites Mal manuell als Debitoren angelegt werden.

• Angebote wurden in beiden Systemen parallel gepflegt.

• Aufträge erreichten die Auftragsabwicklung per E-Mail und Tabellen.

• Servicetechniker erfassten Arbeitszeiten im einen System - übertragen wurden sie von Hand ins andere.

• Rechnungen lagen im SAP-Archiv, waren für das Serviceteam in Salesforce aber unsichtbar.

Jeder dieser Brüche kostete Zeit. Zusammen begrenzten sie, wie schnell das Unternehmen Auftragseingang und Ersatzteilgeschäft ausbauen konnte, ohne den Backoffice-Aufwand im gleichen Maß mitwachsen zu lassen.

Zwei Rahmenbedingungen prägten das Projekt von Anfang an. Erstens: Die SAP-Landschaft steht nicht im eigenen Rechenzentrum des Kunden, sondern wird von einem externen Provider betrieben und ist ausschließlich über einen etablierten IPsec-Tunnel erreichbar, über den produktiver Datenverkehr läuft. Zweitens: Eine S/4HANA-Migration steht perspektivisch auf der Roadmap - die Integrationsschicht darf nicht zu deren Blocker werden.

Der Auftrag

ZirkelTech wurde beauftragt, die durchgängige Integrationsplattform in zwei Arbeitspaketen zu konzipieren und umzusetzen:

• Neukunden und Aufträge - von der gewonnenen Opportunity in Salesforce bis zu Debitor, Angebot und Kundenauftrag in SAP.

• After-Sales - Ersatzteilangebote und -aufträge, Servicezeiten in das SAP-Arbeitszeitblatt (CATS) sowie der Abruf von Rechnungsbelegen aus dem SAP-Archiv (ArchiveLink) nach Salesforce.

Eine Scope-Erweiterung während der Laufzeit - die Synchronisation von Salesforce-Angeboten in SAP-SD-Angebote -s wurde durch Umpriorisierung des Sprintplans aufgefangen, ohne das Programm anzuhalten.

Lösungsarchitektur: ereignisgesteuert als Grundprinzip

Die Plattform folgt drei Prinzipien: Systeme entkoppeln, jeden Datenfluss beobachtbar und wiederholbar machen, jeden SAP-Berührungspunkt explizit und minimal halten.

• Salesforce Platform Events als Auslöseschicht. Änderungen an Kunden, Angeboten und Zeiterfassungen werden als Ereignisse publiziert – Salesforce hängt nie davon ab, dass SAP im Moment der Änderung erreichbar ist.

• MuleSoft CloudHub 2.0 (Private Space) als Integrationsschicht. Die Anwendungen abonnieren die Ereignisse, validieren und transformieren die Daten und orchestrieren die SAP-Aufrufe. Der Private Space stellt ein dediziertes Netzsegment mit kontrolliertem Ausgang bereit - der Anker für das nachfolgend beschriebene VPN-Design.

• SAP-Eingang über freigegebene, per Whitelist zugelassene BAPIs unter einem dedizierten technischen Benutzer. Schlanke kundeneigene RFC-Bausteine kommen nur dort zum Einsatz, wo die Standardbibliothek Lücken hat.

• SAP-Ausgang über ALE/IDoc. Änderungszeiger erkennen relevante Stammdaten- und Statusänderungen; IDocs werden an einen registrierten RFC-Server der Integrationsschicht übergeben und nach Salesforce weitergeleitet - Massendaten über die Bulk API 2.0.

• Resilienz per Konstruktion. Anypoint MQ entkoppelt die Verarbeitungsschritte; fehlgeschlagene Nachrichten landen in Dead-Letter-Queues mit Alarmierung, statt zu verschwinden; Upserts sind über externe Schlüssel idempotent, Wiederholungen also gefahrlos.

• Eine durchgängige dreistufige Systemlandschaft - Entwicklung, Qualitätssicherung, Produktion - über Salesforce, MuleSoft und SAP hinweg.

Die eigentliche Herausforderung: aus der Cloud in ein extern gehostetes SAP

Die meisten Integrationsprojekte gehen davon aus, dass das ERP nur ein paar Firewall-Regeln entfernt ist. Hier nicht. Die SAP-Landschaft läuft bei einem externen Hosting-Provider und ist nur über einen etablierten IPsec-Tunnel zwischen Kundenstandort und Provider erreichbar – einen Tunnel, über den produktiver Datenverkehr läuft.

Die Lehrbuchlösung - ein zweites, direktes VPN zwischen Integrations-Cloud und Hosting-Provider - schied früh aus. Sie hätte Konfigurationsänderungen, vertragliche Abstimmung und Wartungsfenster auf Providerseite bedeutet - und einen Dritten in den kritischen Pfad jeder künftigen Anpassung gestellt.

ZirkelTech entwarf stattdessen eine Transit-Architektur:

1. Ein Site-to-Site-IPsec-VPN verbindet den MuleSoft Private Space mit der Perimeter-Firewall des Kunden.

2. Die Firewall routet den Integrationsverkehr über den bereits bestehenden Tunnel zum Hosting-Provider weiter.

3. Vor Eintritt in diesen Tunnel wird der gesamte Integrationsverkehr per Source-NAT (SNAT) auf eine Adresse aus dem Kundennetz umgesetzt.

Der Effekt: Aus Sicht des Hosting-Providers ist der Integrationsverkehr vom regulären Standortverkehr des Kunden nicht zu unterscheiden. Bestehende Firewall-Richtlinien, Routing und vertragliche Regelungen auf Providerseite blieben unangetastet – nichts musste beantragt werden, und nichts auf Providerseite kann die Integration brechen.

Das Design ist bewusst eng gefasst. VPN-Selektoren und Firewall-Regeln erlauben exakt die benötigten SAP-Gateway- und Dispatcher-Ports in der benötigten Richtung – und sonst nichts. Die vorgeschlagenen IPsec-Parameter wurden vor Go-Live über die Herstellervorgaben hinaus gehärtet.

Lektion am SAP-Gateway: RFC funktioniert heißt nicht, IDocs funktionieren

Ein Muster, das sich über SAP-Integrationsprojekte hinweg wiederholt und deshalb geteilt gehört: Sobald BAPI-Aufrufe ins SAP funktionieren, wird angenommen, dass auch die Gegenrichtung - SAP versendet IDocs - über dieselbe Verbindung läuft. Das folgt daraus nicht.

Funktionierende RFC-Aufrufe ins SAP sagen nichts darüber aus, ob SAP IDocs nach außen senden kann. Der Ausgangs-Stack - Verteilungsmodell, Änderungszeiger, Partnervereinbarungen, Gateway-ACLs - ist davon unabhängig und in einer Greenfield-Umgebung ein eigenes Arbeitspaket.

Der IDoc-Ausgang basiert auf einem eigenen Konfigurationsstack: ALE-Verteilungsmodell, Aktivierung der Änderungszeiger, Partnervereinbarungen und Ports – und, am häufigsten übersehen, die Sicherheits-ACLs des SAP-Gateways (reginfo/secinfo), die überhaupt erst entscheiden, ob sich ein externes Programm als RFC-Server registrieren darf.

Im Projekt wies das Gateway den ersten Registrierungsversuch des RFC-Servers mit der klassischen Fehlermeldung ab: registration of tp … from host … not allowed.

Die Ursache hatte eine Pointe. Durch das SNAT-Transitdesign sieht das SAP-Gateway nie die Adresse der Integrationsplattform, sondern die Tunnel-Austrittsadresse im Kundennetz. Ein ACL-Eintrag auf die naheliegende Quelle hätte nie gegriffen. Die Lösung folgte einem disziplinierten Vorgehen: Gateway-Logging aktivieren, um den tatsächlich abgewiesenen Quellhost zu erfassen; eine minimal zugeschnittene Freigaberegel für genau diese Programm-ID und Quelle ergänzen; die ACLs zur Laufzeit neu laden - ohne Gateway-Neustart, ohne Downtime.

Die übergreifende Erkenntnis: In einer Greenfield-Umgebung ist die IDoc-Anbindung ein eigenes Arbeitspaket. Es gehört explizit geplant und budgetiert - es versteckt sich nicht hinter „Konnektivität steht“.

Sicherheit als Konstruktionsprinzip

• Ein dedizierter technischer Benutzer für die Integration – ohne Dialogzugang, ohne geteilte Zugangsdaten.

• Ein zweckgebundenes Berechtigungskonzept nach dem Minimalprinzip. Die RFC-Whitelist enthält exakt die aufgerufenen Funktionsbausteine – rund zwei Dutzend freigegebene BAPIs plus wenige kundeneigene Lesebausteine - und sonst nichts.

• Die Gateway-ACLs arbeiten nach Deny-by-Default; jedes registrierte Serverprogramm wird einzeln freigegeben und auf seine Quelle eingeschränkt.

• VPN-Selektoren und Firewall-Regeln folgen derselben Philosophie: konkrete Subnetze, konkrete Ports, eine Richtung.

Ein Detail aus der Designphase zeigt die angesetzte Prüftiefe: Ein frühes Schnittstelleninventar verwies auf einen „Standard“-BAPI zum Lesen von Angebotslisten, den es in SAP ECC schlicht nicht gibt. Er wurde durch einen schlanken kundeneigenen Lesebaustein auf den Vertriebsbelegtabellen ersetzt. Ein kleiner Befund mit großer Moral: Jede angenommene Standardschnittstelle wird am realen System verifiziert, bevor sie zur Abhängigkeit in einem Design wird.

Ergebnisse

Gelb markierte Werte sind Projektschätzungen – vor Veröffentlichung an Produktivdaten validieren.

• Fünf manuelle Medienbrüche entlang der Lead-to-Cash- und After-Sales-Kette eliminiert - Kundenanlage, Angebotspflege, Auftragserfassung, Servicezeit-Übertragung und Rechnungssuche.

• Sechs End-to-End-Prozesse auf einer Plattform integriert - ohne eine einzige Konfigurationsänderung auf Providerseite und ohne Unterbrechung des Produktivtunnels.

• Übertragungsfehler aus manueller Doppelerfassung per Konstruktion eliminiert: Daten werden an der Schnittstelle validiert, bevor sie SAP erreichen.

• Kunden- und Angebotsdaten stehen in unter fünf Minuten nach dem Salesforce-Ereignis in SAP bereit - zuvor ein manueller Prozess von ein bis zwei Arbeitstagen.

• Rund 15 Stunden pro Woche an Doppelerfassung und manuellen Übertragungen entfallen in Vertrieb, Auftragsabwicklung und Service.

Jenseits der Kennzahlen: Kunden- und Auftragsdaten sind über CRM und ERP hinweg konsistent; Servicezeiten fließen ohne Medienbruch ins CATS; Rechnungen aus dem SAP-Archiv sind für das Serviceteam direkt in Salesforce sichtbar; und die Plattform ist darauf ausgelegt, weitere Prozesse aufzunehmen - von der automatisierten Ticketabrechnung bis zu bidirektionalen Stammdatenflüssen - ohne Neuarchitektur.

Ausblick: gebaut für die S/4HANA-Frage

Weil jeder SAP-Berührungspunkt über explizite, versionierte Schnittstellen der Integrationsschicht läuft - nicht über Punkt-zu-Punkt-Verdrahtung -, ändert ein späterer Wechsel von ECC auf S/4HANA den Endpunkt, nicht die Architektur. Schnittstellen werden zentral neu gemappt; Salesforce und das Eventmodell bleiben unberührt. Für ein mittelständisches Unternehmen, das diese Migration in den kommenden Jahren vor sich hat, ist diese Entkopplung kein akademischer Vorteil. Sie ist der Unterschied zwischen einem Projekt und zweien.