SAP- und Oracle-Systeme stehen im Mittelpunkt der meisten großen Enterprise-Architekturen in Europa. Sie sind die System of Record für Finanzen, HR, Beschaffung, Logistik und Fertigung. Alles andere — Analytics-Plattformen, Kundenportale, mobile Anwendungen, Drittanbieter-Dienste — muss Daten aus diesen Systemen beziehen oder in sie schreiben. Das Integrationsmuster ist genauso wichtig wie die Technologie — und die im ersten Jahr getroffene Musterwahl bestimmt die Wartungslast für das nächste Jahrzehnt.
Drei Integrationsmuster: Kompromisse, die zählen
Die Enterprise-Integrationsliteratur beschreibt Dutzende von Mustern. In der Praxis dominieren drei SAP- und Oracle-Integrationsprojekte:
Punkt-zu-Punkt-Integration
Direkte Verbindungen zwischen Quell- und Zielsystemen — SAP-RFC-Aufrufe aus einer benutzerdefinierten Anwendung, direkte Oracle-DB-Verbindungen, JDBC zu einer EBS-Tabelle. Punkt-zu-Punkt ist schnell zu implementieren und angemessen, wenn der Integrationsumfang wirklich klein und stabil ist (eine Quelle, ein Ziel, seltene Änderungen). Es wird zur Haftung in dem Moment, wenn ein drittes System hinzukommt: Sie haben jetzt drei Verbindungen zu pflegen, drei Orte, an denen Credentials gespeichert sind, und keine zentrale Überwachung der Datenflüsse.
Enterprise Service Bus (ESB)
Ein ESB — MuleSoft, IBM Integration Bus, WSO2 — führt eine zentrale Vermittlungsschicht ein, die alle Systemnachrichten transformiert, routet und überwacht. ESBs sind das richtige Muster, wenn: Nachrichtentransformation komplex ist, mehrere Systeme denselben Datenfeed konsumieren oder regulatorische Compliance einen einzigen Audit-Punkt für alle Datenflüsse erfordert. Der Preis ist architektonische Komplexität und der Bedarf an spezialisierten ESB-Kenntnissen.
API-Gateway-Muster
Das API-Gateway-Muster exponiert SAP- und Oracle-Funktionalitäten als verwaltete REST- oder GraphQL-APIs, wobei das Gateway Authentifizierung, Rate Limiting, Versionierung und Observability übernimmt. Das ist das Muster, das wir für neue Projekte mit DACH-Enterprise-Kunden empfehlen. Es entspricht API-First-Design-Prinzipien, skaliert für externe Entwicklerkonsumption und integriert sich natürlich in moderne cloud-native Architekturen.
Unsere Empfehlung: Beginnen Sie mit dem API-Gateway-Muster für neue Integrationen, verwenden Sie ESB bei einer komplexen bestehenden Landschaft mit Many-to-Many-Datenflüssen, und vermeiden Sie Punkt-zu-Punkt für alles jenseits eines Drei-Systeme-Perimeters.
SAP-Integration: RFC, BAPI und IDocs
SAP stellt drei primäre Integrationsschnittstellen bereit. RFC (Remote Function Call) und BAPI (Business Application Programming Interface) sind synchrone Schnittstellen, die für Echtzeit-Lookups und Transaktionsoperationen geeignet sind — Lagerbestände prüfen, Verkaufsaufträge anlegen, Finanzdokumente buchen. Wir implementieren RFC/BAPI-Integrationen mit dem SAP Java Connector (JCo) oder dem SAP .NET Connector, verpackt in einer Service-Schicht, die Connection Pooling, Retry-Logik und strukturiertes Fehler-Mapping übernimmt.
IDocs (Intermediate Documents) sind SAPs asynchrones Dokumentformat für den hochvolumigen Austausch von Geschäftsdokumenten — Bestellungen, Rechnungen, Lieferscheine. IDoc-basierte Integrationen sind zuverlässig und hochdurchsatzfähig, erfordern aber sorgfältiges Monitoring: Ein fehlgeschlagenes IDoc ist nicht immer sofort sichtbar, und Wiederverarbeitungslogik muss von Anfang an konzipiert werden.
Oracle EBS-Integration via REST-APIs
Oracle E-Business Suite (EBS) hat seine REST-API-Oberfläche erheblich weiterentwickelt. Moderne EBS-Versionen exponieren REST-APIs für Kerngeschäftsobjekte — Kunden, Aufträge, Rechnungen, Inventar — über Oracle Integration Cloud (OIC) oder direkt via EBS Integrated SOA Gateway. Für Legacy-EBS-Deployments ohne REST-Abdeckung verwenden wir Oracle-Datenbankviews und geplante Extrakte als pragmatischen Zwischenschritt, mit klarer Migrationspfad-Dokumentation in Richtung REST beim nächsten Client-Upgrade.
Message-Queue-Muster und Fehlerbehandlung
Enterprise-Integration schlägt lautlos fehl, wenn man sie lässt. Jedes Integrationsmuster, das wir implementieren, umfasst: Dead-Letter-Queues für fehlgeschlagene Nachrichten (RabbitMQ, Azure Service Bus oder AWS SQS je nach Client-Infrastruktur), strukturiertes Fehler-Logging mit genug Kontext zur Reproduktion und Wiedergabe, Idempotenz-Keys bei Schreiboperationen zur Vermeidung doppelter Verarbeitung und Alerting, das den On-Call-Ingenieur innerhalb von 5 Minuten benachrichtigt, wenn sich eine Nachricht in der Dead-Letter-Queue ansammelt.
Unsere Middleware-Referenzarchitektur
Eine bewährte Referenzarchitektur für Enterprise-Integration konvergiert auf: ein API-Gateway (Kong oder Azure API Management) als öffentlich sichtbare Vertragsschicht, einen internen Event-Bus (Kafka für hohen Durchsatz, Azure Service Bus für Microsoft-Stack-Clients) für asynchrone Flows, Adapter-Services pro System (SAP-Adapter, Oracle-Adapter), die systemspezifische Komplexität kapseln, und einen zentralen Observability-Stack (Prometheus, Grafana, Distributed Tracing via Jaeger oder Tempo). Die Adapter sind die einzigen Komponenten, die SAP- oder Oracle-Interna kennen — alles darüber kommuniziert via REST und CloudEvents.
Mehr zu diesem Thema erfahren?
Erstberatung ist kostenlos — unverbindlich.