Enterprise Integration Patterns: SAP, Oracle & Microservices

Enterprise Integration ist das Rückgrat moderner IT-Landschaften. Nach 13 Jahren Erfahrung mit der Integration von SAP, Oracle, Salesforce und Custom-Systemen bei internationalen Konzernen teile ich hier bewährte Patterns und Anti-Patterns.

Warum Integration so komplex ist

Die Herausforderung: Heterogene Systeme müssen miteinander sprechen - unterschiedliche Technologien, Datenformate, Protokolle und zeitliche Verfügbarkeiten. Und das alles bei hohen Anforderungen an Verfügbarkeit, Performance und Datenkonsistenz.

Typische Integrations-Szenarien:

• SAP ERP ↔ E-Commerce Platform
• Legacy System ↔ Cloud Services
• Warehouse Management ↔ Transport Management
• CRM ↔ ERP ↔ Marketing Automation

Die Evolution der Integration

1. Point-to-Point: Der Anfang

Beschreibung: Direkte Verbindungen zwischen Systemen.

Wann es funktioniert:

• Wenige Systeme (2-3)
• Klare, stabile Schnittstellen
• Geringe Komplexität

Das Problem: Mit n Systemen entstehen potenziell n×(n-1)/2 Verbindungen. Bei 10 Systemen sind das bereits 45 Verbindungen - nicht mehr wartbar!

Mein Einsatz: Nur für sehr einfache Szenarien oder als Übergangslösung.

2. Hub-and-Spoke (ESB): Der Klassiker

Beschreibung: Ein zentraler Hub (Enterprise Service Bus) vermittelt zwischen allen Systemen.

Vorteile:

• Zentrale Verwaltung
• Wiederverwendbare Adapter
• Transformation & Orchestration an einem Ort

Nachteile:

• Single Point of Failure
• Kann zum Monolithen werden
• Performance-Bottleneck bei hohem Durchsatz

🔧 Praxis-Tipp:
Bei einem Retail-Kunden haben wir Oracle SOA Suite als ESB eingesetzt. Funktioniert gut für komplexe BPMN-Workflows, ist aber wartungsintensiv. Heute würde ich für neue Projekte auf Event-Driven setzen.

3. Event-Driven Architecture: Die moderne Lösung

Beschreibung: Systeme kommunizieren über asynchrone Events via Message Broker (Kafka, RabbitMQ).

Vorteile:

• Entkopplung: Producer kennt Consumer nicht
• Skalierbarkeit: Parallelverarbeitung möglich
• Resilienz: Retry-Mechanismen, Dead Letter Queues
• Audit-Trail: Alle Events sind protokolliert

Herausforderungen:

• Eventual Consistency (nicht immer sofort konsistent)
• Komplexität im Debugging
• Event-Schema-Evolution

Mein bevorzugter Stack:

• Kafka für High-Throughput, Event-Sourcing
• RabbitMQ für klassische Message Queues mit Routing
• CloudEvents Standard für Event-Schemas

Konkrete Integrations-Patterns

Pattern 1: Request-Reply (Synchron)

Use Case: Verfügbarkeitsprüfung, Preisabfragen, Kundensuche

Client → REST API → Service → Response

Best Practices:

• Timeout konfigurieren (z.B. 3 Sekunden)
• Circuit Breaker implementieren
• Idempotenz sicherstellen

Technologie: REST, gRPC, GraphQL

Pattern 2: Fire-and-Forget (Asynchron)

Use Case: Bestellbestätigung versenden, Lagerbuchung, Logging

Producer → Message Queue → Consumer (später)

Best Practices:

• At-least-once Delivery garantieren
• Consumer müssen idempotent sein
• Dead Letter Queue für Fehler

Technologie: RabbitMQ, AWS SQS, Azure Service Bus

Pattern 3: Publish-Subscribe

Use Case: Order-Events an multiple Systeme (Warehouse, Shipping, Billing)

Publisher → Topic/Exchange → [Subscriber1, Subscriber2, ...]

Best Practices:

• Event-Schema versionieren (Avro, JSON Schema)
• Consumer Groups für Skalierung
• Replay-Fähigkeit für neue Consumer

Technologie: Kafka, AWS SNS, Redis Pub/Sub

Pattern 4: Saga Pattern

Use Case: Verteilte Transaktionen (Order → Payment → Shipping → Invoicing)

Step1 → Success → Step2 → Success → Step3
         ↓ Fail          ↓ Fail
    Compensate     Compensate

Best Practices:

• Choreography (events) vs. Orchestration (coordinator)
• Compensation-Logik für jedes Step
• Monitoring & Alerting für Saga-State

⚠️ Häufiger Fehler:
Sagas ohne Compensation-Logik implementieren. Wenn Step 3 fehlschlägt, müssen Step 1 und 2 rückgängig gemacht werden - das muss explizit implementiert werden!

SAP Integration: Der Elefant im Raum

SAP ist in vielen Enterprise-Landschaften das Kern-System. Integration ist oft komplex, aber mit dem richtigen Ansatz gut machbar.

SAP Integrations-Optionen

1. RFC/BAPI: Synchrone Function Calls
   • ✅ Direkter Zugriff auf Business Logic
   • ❌ Tight Coupling, Performance-Limits
2. IDoc: Asynchrone Dokumente
   • ✅ SAP-native, robust
   • ❌ Komplexe Konfiguration, eigenes Format
3. OData Services: RESTful API
   • ✅ Modern, JSON-basiert
   • ❌ Nicht alle SAP-Module unterstützen OData
4. SAP PI/PO: SAPs eigener ESB
   • ✅ SAP-optimiert
   • ❌ Teuer, komplex, Legacy

Meine Empfehlung:
Für neue Integrationen: OData wenn verfügbar, sonst RFC/BAPI mit Wrapper-Service als Anti-Corruption Layer. IDocs nur wenn unumgänglich.

API Gateway Pattern

Für Microservices-Architekturen unverzichtbar:

Client → API Gateway → [Service1, Service2, Service3, ...]

Funktionen:

• Routing: Requests an richtigen Service
• Authentication/Authorization: Zentral verwaltet
• Rate Limiting: Schutz vor Überlast
• Transformation: Request/Response-Mapping
• Aggregation: Mehrere Service-Calls kombinieren

Tools:

• Kong: Open Source, Lua-basiert
• NGINX: Bewährt, performant
• AWS API Gateway: Managed Service
• Spring Cloud Gateway: Java-Stack

Integration Testing

Das größte Problem: Wie testet man ein verteiltes System?

Mein Ansatz:

1. Contract Tests: Pact, Spring Cloud Contract
   → Sicherstellen, dass Producer/Consumer kompatibel sind
2. Integration Tests: Testcontainers
   → Echte Dependencies (DB, Kafka) in Docker
3. End-to-End Tests: Minimal!
   → Nur kritische Happy Paths, zu langsam für CI/CD
4. Chaos Engineering: Production!
   → Resilienz testen mit Chaos Monkey

Monitoring & Observability

In verteilten Systemen ist Monitoring Pflicht:

Das 3-Säulen-Modell:

1. Metrics: Prometheus + Grafana
   → Latency, Throughput, Error Rate
2. Logging: ELK Stack oder Loki
   → Strukturierte Logs mit Correlation IDs
3. Tracing: Jaeger oder Zipkin
   → Request-Flow über alle Services

💡 Erfolgsrezept:
Correlation IDs sind der Schlüssel! Jeder Request bekommt eine eindeutige ID, die durch alle Services propagiert wird. Debugging wird dadurch 100x einfacher.

Häufige Anti-Patterns vermeiden

• ❌ Distributed Monolith: Microservices mit synchronen Calls überall
• ❌ Chatty Services: 100 API-Calls für eine Geschäftslogik
• ❌ Shared Database: Mehrere Services auf eine DB - tight coupling!
• ❌ Fehlende Timeouts: Ein hängender Service blockt alle
• ❌ Keine Idempotenz: Retry führt zu Duplicate-Orders

Fazit

Enterprise Integration ist komplex, aber mit den richtigen Patterns beherrschbar. Meine wichtigsten Learnings:

1. Async first: Event-Driven wo möglich, synchron nur wenn nötig
2. Anti-Corruption Layer: Schützt vor Legacy-Komplexität
3. Observability: Von Anfang an einbauen, nicht nachträglich
4. Start simple: Point-to-Point ist ok für 2-3 Systeme
5. Idempotenz: Macht Retry sicher und Leben einfacher

Die Wahl des richtigen Patterns hängt von Ihrem Kontext ab: Gibt es bereits einen ESB? Cloud oder On-Premise? Batch oder Real-time? Lassen Sie sich beraten - es spart Zeit und Geld.