Wer SAP Cloud Integration produktiv betreibt, kennt das Muster: Die ersten Integration Flows laufen, die Fachabteilungen sind zufrieden, das Projekt wird als Erfolg verbucht. Dann wächst die Landschaft. Zwanzig Flows werden fünfzig, fünfzig werden zweihundert – und plötzlich häufen sich OutOfMemory-Fehler, Nachrichten verschwinden ohne Fehlermeldung, und ein einzelner fehlerhafter Flow legt den gesamten Tenant lahm.
Die Ursache ist fast immer dieselbe: Die offiziellen Design Guidelines von SAP wurden nicht konsequent angewandt. SAP stellt auf dem Business Accelerator Hub neun Guideline-Pakete bereit, die zusammen ein vollständiges Qualitätsframework für Integration Flows bilden. In der Praxis werden sie zu selten genutzt – sei es aus Zeitdruck, mangelnder Kenntnis oder der Annahme, dass sie nur für komplexe Szenarien relevant seien.
Dieser Beitrag greift die vier Bereiche heraus, die in unseren Projekten den größten Unterschied zwischen einer stabilen und einer fragilen Integrationslandschaft ausmachen: Ressourcenmanagement, Fehlerbehandlung, Scripting-Disziplin und Governance.
1. Ressourcengrenzen kennen – bevor der Tenant sie durchsetzt
SAP Cloud Integration läuft nicht auf dedizierter Infrastruktur. Jeder Tenant teilt sich feste Ressourcen zwischen allen deployten Integration Flows. Die Grenzen sind eng (Angaben beziehen sich auf den Standard Plan): 4 GB RAM pro Runtime Node, 8 gleichzeitige Datenbankverbindungen, 200 HTTP-Threads und 32 GB Datenbankspeicher für Data Stores, Variablen und Locks zusammen. Wer diese Zahlen nicht kennt, entwirft Flows, die einzeln funktionieren, aber im Zusammenspiel den Tenant destabilisieren.
Das häufigste Problem ist der Umgang mit großen Nachrichten. Wird eine XML-Payload als String in den Speicher geladen, belegt sie ein Vielfaches ihrer Dateigröße – bei einer 50-MB-Nachricht können das schnell mehrere hundert Megabyte werden. Laufen zwei solcher Flows parallel, stürzt der Worker Node mit einem OutOfMemory-Error ab. Die Lösung ist Streaming: Nachrichten als InputStream oder Reader verarbeiten, Splitter-Steps für Batch-Verarbeitung nutzen und die Streaming-Option bei XML-zu-JSON-Konvertierungen aktivieren.
Ebenso kritisch ist der Umgang mit Datenbankverbindungen. Acht Connections klingt nach wenig und genau das ist der Punkt. Lange laufende Transaktionen, die Verbindungen unnötig offen halten, können den gesamten Connection Pool blockieren. Das betrifft dann nicht nur den verursachenden Flow, sondern alle Flows auf dem Tenant, die Datenbankzugriff benötigen. Die Empfehlung: JDBC-Transaktionen nur dort aktivieren, wo Datenkonsistenz es erfordert, Datenbankoperationen in Local Integration Processes bündeln und für High-Throughput-Szenarien JMS Queues statt Data Stores verwenden.
SAP bietet mit dem Inspect-Resource-Usage-Dashboard ein Werkzeug, um den Ressourcenverbrauch zu überwachen. Es ist erstaunlich, wie selten dieses Dashboard in Projekten tatsächlich genutzt wird.
2. Fehlerbehandlung: Warum HTTP 200 nicht „alles in Ordnung“ bedeutet
Jeder Integration Flow braucht einen Exception Subprocess. Das klingt nach einer Selbstverständlichkeit, ist es aber in der Praxis nicht. Flows ohne Exception Subprocess scheitern stillschweigend – kein Alert, kein verwertbarer Log-Eintrag, kein Hinweis darauf, dass Geschäftsdaten verloren gegangen sind. Der Mindeststandard ist: Jeder Exception Subprocess loggt die Fehlerdetails inklusive der ursprünglichen Payload und löst eine Benachrichtigung aus.
Ein subtileres Problem sind APIs, die bei fachlichen Fehlern trotzdem HTTP 200 zurückgeben. Wer nur den HTTP-Statuscode prüft, hält die Verarbeitung für erfolgreich, obwohl die Zielanwendung die Daten abgelehnt hat. Integration Flows müssen den Response Body nach jedem Outbound-Call auf Business-Level-Errors parsen und bei einem Fehler gezielt in einen separaten Verarbeitungspfad routen.
Für größere Landschaften empfiehlt sich ein zentraler Error-Handler-Flow. Statt in jedem einzelnen Flow die Fehlerlogik zu duplizieren, leiten alle Flows ihre Exceptions über ProcessDirect an einen dedizierten Handler weiter. Dieser implementiert ein einheitliches Fehlerformat mit Correlation ID, Zeitstempel, Quell-Flow und Fehlerklassifikation. Die Alerts werden nach Schweregrad differenziert: Kritische Fehler erzeugen sofortige Benachrichtigungen, Warnungen erscheinen im täglichen Digest, Informationen nur im Dashboard.
Der oft vernachlässigte letzte Baustein ist Idempotenz. Wenn ein Flow nach einem Fehler erneut ausgeführt wird, darf er keine doppelten Datensätze erzeugen. SAP stellt dafür den Idempotent Process Call Step bereit. Wer ihn nicht nutzt, riskiert bei jedem Retry Dateninkonsistenzen in den angebundenen Systemen.
3. Groovy-Scripting: Die mächtigste und gefährlichste Waffe im Werkzeugkasten
Groovy-Scripts sind der häufigste Verursacher von Memory Leaks, Performance-Problemen und Wartungsalbträumen in SAP Cloud Integration. Nicht weil Groovy schlecht wäre, sondern weil es zu leicht ist, damit die falsche Entscheidung zu treffen.
Die wichtigste Regel: Standard-Flow-Steps haben Vorrang. SAP Cloud Integration bietet dedizierte Steps für Message Mapping, Content Modification, Routing und Formatkonvertierung. Nur wenn keiner dieser Steps das gewünschte Ergebnis liefern kann, ist ein Groovy-Script gerechtfertigt. In der Praxis sehen wir regelmäßig Scripts, die nichts anderes tun als einen Header zu setzen – etwas, das ein Content Modifier in Sekunden erledigt, ohne jedes Wartungsrisiko.
Wenn Scripts unvermeidlich sind, entscheidet ein einziger Architekturentscheid über die Stabilität: Wird die Payload als String oder als InputStream gelesen? String bedeutet, dass die gesamte Nachricht im Speicher liegt. Bei kleinen Nachrichten kein Problem, bei großen der direkte Weg zum OutOfMemory-Error. Dasselbe Prinzip gilt für XML-Verarbeitung: XmlSlurper ist speichereffizienter als XmlParser – er erzeugt eine leichtgewichtigere GPathResult-Struktur statt eines vollständigen Node-Baums. Beide laden das Dokument jedoch vollständig in den Speicher. Wer wirklich große Payloads streamen muss, kommt an SAX oder StAX nicht vorbei – XmlSlurper ist dafür kein Ersatz.
Darüber hinaus gelten Grundregeln, die in jedem Softwareprojekt gelten sollten, aber in Integration Flows besonders häufig verletzt werden: Streams in finally-Blöcken schließen, keine Thread.sleep()-Aufrufe verwenden, keine manuellen Threads erstellen, aussagekräftige Variablennamen nutzen und jedes Script mit einem Header-Kommentar versehen, der Zweck, Input und Output beschreibt.
4. Governance: Aus Empfehlungen werden verbindliche Standards
Design Guidelines ohne Governance sind Empfehlungen. Empfehlungen werden unter Zeitdruck ignoriert. Das Ergebnis ist eine Landschaft, in der die Qualität der Integration Flows direkt davon abhängt, welche Entwickler:innen sie gebaut haben.
SAP Cloud Integration bietet eine eingebaute Design-Guidelines-Funktion, die Integration Flows automatisiert gegen definierte Regeln prüft. Die Guideline-Pakete stehen auf dem SAP Business Accelerator Hub bereit und lassen sich direkt über Discover → Integrations auf den eigenen Tenant kopieren. Die Aktivierung der gewünschten Regeln erfolgt anschließend unter Settings → Integrations → Design Guidelines. Entwickler:innen führen die Prüfung direkt im Integration Flow Editor aus und erhalten einen Compliance-Report, der Verstöße nach Severity klassifiziert: High (blockiert Produktivgang), Medium (sollte behoben werden, Ausnahmen dokumentieren) und Low (Empfehlung, kein Blocker).
Der entscheidende Schritt ist die Integration in den Deployment-Prozess. SAP stellt Remote APIs für Design-Guideline-Operationen bereit, die in CI/CD-Pipelines eingebunden werden können – ob Jenkins, SAP CI/CD Service oder ein Custom-Setup. Eine Pipeline-Gate-Regel, die bei High-Severity-Verstößen den Deploy blockiert, verhindert, dass nicht-konforme Flows überhaupt in die Produktion gelangen.
Das Rollenmodell dahinter ist klar: Die Tenant-Administrator:innen konfigurieren die Guidelines, der Integration Lead definiert, welche mandatory und welche recommended sind, und die Entwickler:innen führt die Prüfung vor jedem Deployment-Request durch. Der Compliance-Report wird Teil der Go-Live-Entscheidung.
Qualität ist kein Zufall
Die Design Guidelines von SAP sind kein theoretisches Framework. Sie sind die destillierte Erfahrung aus Tausenden von produktiven Integrationsszenarien. Wer sie konsequent anwendet, reduziert Produktionsausfälle, beschleunigt das Onboarding neuer Entwickler:innen und schafft eine Landschaft, die auch bei hunderten von Integration Flows wartbar bleibt.
Der einfachste erste Schritt: Aktivieren Sie die Design-Guidelines-Prüfung auf Ihrem Tenant und lassen Sie einen Compliance-Report über Ihre bestehenden Flows laufen. Das Ergebnis wird deutlich machen, wo der größte Handlungsbedarf liegt.
Sie möchten Ihre Integration-Landschaft auf den Prüfstand stellen? Wir als adesso SAP Architects unterstützen Sie dabei. Melden Sie sich gerne bei uns!
