Problem

Business Challenge

Ein Automobilhersteller betrieb eine komplexe Manufacturing Landscape mit S/4HANA als Core und drei kritischen Subsystemen:

• MES (Manufacturing Execution System): Shopfloor-Steuerung
• QMS (Quality Management System): Qualitätsprüfungen
• WMS (Warehouse Management System): Materialverwaltung

Bei Änderungen an Production Orders (Mengenänderung, Terminverschiebung, Status-Updates) mussten alle drei Systeme sofort aktualisiert werden, um Produktionsausfälle zu vermeiden.

Technical Pain Points

• Point-to-Point Hell: 12 separate RFC-Interfaces (S/4HANA → 3 Systeme, bidirektional)
• Synchronous Coupling: RFC-Calls blockierten S/4HANA User-Transaktionen (3-5 Sekunden)
• Brittle Integration: Wenn ein Subsystem offline war, schlug die gesamte Transaktion fehl
• No Retry Logic: Fehlgeschlagene Updates mussten manuell nachbearbeitet werden
• Tight Coupling: Neues Subsystem erforderte Änderungen an S/4HANA Code

Business Impact

• Production Delays: Durchschnittlich 2h/Tag durch Interface-Probleme
• Manual Rework: 3 FTE für manuelle Nachbearbeitung fehlgeschlagener Interfaces
• System Downtime: Wartungsfenster für ein Subsystem blockierte alle anderen
• Innovation Blocked: Integration eines neuen Planungssystems auf 6 Monate geschätzt

Solution

Strategic Architecture: Event-Driven Integration

Wir ersetzten die synchronen Point-to-Point-Interfaces durch eine Event-Driven Architecture mit SAP Event Mesh als zentralem Message Broker.

Architecture Overview

S/4HANA
   ↓ (Event Publication)
SAP Event Mesh (BTP)
   ├─ Queue: production-orders
   ├─ Queue: quality-events
   └─ Queue: material-movements
        ↓ (Subscription)
   ┌────┴─────┬─────────┬─────────┐
  MES       QMS       WMS    (Future Systems)

Technical Implementation

1. Event Publisher (S/4HANA)

Custom ABAP Event Emitter via Enterprise Messaging:

CLASS zcl_production_order_publisher DEFINITION.
  PUBLIC SECTION.
    METHODS publish_change
      IMPORTING
        iv_order_id TYPE aufnr
        iv_event_type TYPE string.
ENDCLASS.
 
CLASS zcl_production_order_publisher IMPLEMENTATION.
  METHOD publish_change.
    DATA(lo_em) = cl_em_api=>get_instance( ).
 
    " CloudEvents Format
    DATA(ls_event) = VALUE zevent_payload(
      specversion = '1.0'
      type = |com.sap.s4.ProductionOrder.{ iv_event_type }|
      source = '/sap/s4hana/prod'
      id = cl_uuid_factory=>create_system_uuid( )->create_uuid_x16( )
      time = sy-datum && sy-uzeit
      data = VALUE #(
        orderID = iv_order_id
        plant = ...
        material = ...
        quantity = ...
      )
    ).
 
    lo_em->publish(
      iv_topic = '/production/orders'
      is_data = ls_event
    ).
  ENDMETHOD.
ENDCLASS.

2. Message Broker (SAP Event Mesh)

• Topics: Hierarchical structure (/production/orders, /quality/inspections)
• Queues: Persistent storage mit Dead Letter Queue
• Subscriptions: Rule-based routing (z.B. nur Status-Changes für MES)
• QoS: At-least-once delivery mit Acknowledgment

3. Event Consumer (CAP on BTP)

CAP Service als intelligenter Subscriber:

// srv/production-consumer.ts
export default (srv: ApplicationService) => {
  const messaging = await cds.connect.to('messaging')
 
  messaging.on('production-orders', async (msg: CloudEvent) => {
    const { orderID, eventType } = msg.data
 
    try {
      // Transform & Route
      switch (eventType) {
        case 'StatusChanged':
          await callMES({ orderID, status: msg.data.status })
          await callQMS({ orderID, inspectionNeeded: true })
          break
        case 'QuantityChanged':
          await callWMS({ orderID, newQuantity: msg.data.quantity })
          break
      }
 
      // Acknowledge
      await msg.ack()
    } catch (error) {
      // Retry Logic (3x mit Exponential Backoff)
      await msg.nack()
    }
  })
}

Key Features

Resilience Patterns

• Retry with Exponential Backoff: 3 Versuche (1s, 5s, 25s Pause)
• Dead Letter Queue: Nach 3 Fehlversuchen in DLQ mit Alert
• Circuit Breaker: Subsystem-Ausfall bricht nicht gesamten Flow ab

Event Schema Governance

• CloudEvents Standard: Einheitliches Event-Format
• Schema Registry: Versionierte Event-Schemas mit Backward Compatibility
• Validation: Automatische Payload-Validierung vor Processing

Result

Business Outcomes

• Zero Production Delays: Keine Interface-bedingten Stopps seit Go-Live (12 Monate)
• 80% Reduktion der Integration-Efforts für neues Subsystem (6 Monate → 5 Tage)
• Elimination of Manual Rework: Von 3 FTE auf 0 FTE für Interface-Nachbearbeitung
• Maintenance Window Flexibility: Subsysteme können unabhängig gewartet werden
• Business Agility: 4. System (Advanced Planning) in 1 Woche integriert

Technical Achievements

• < 2 Sekunden End-to-End Event Processing (S/4HANA → Subsystem)
• 99.95% Delivery Rate über 12 Monate (SLA: 99.9%)
• Zero Data Loss: Dank At-Least-Once Semantics + DLQ
• Asynchronous: S/4HANA User-Transaktionen nicht mehr blockiert (0 sec statt 3-5 sec)
• Scalable: Event Mesh verarbeitet Spitzen von 1000 Events/min problemlos

Quantifiable Impact

Architectural Benefits

Loose Coupling Realized

Example: Wartungsfenster für QMS

• Before: Alle S/4HANA Production Order Changes blockiert (3h Downtime)
• After: Events werden in Queue gespeichert, QMS holt nach Wartung auf (0h Downtime)

Scalability Unlocked

Black Friday Scenario: 3x normale Event-Last

• Before: RFC-Timeouts, System-Überlastung
• After: Event Mesh buffert automatisch, Consumer skalieren auf 5 Instanzen

Future System Integration

4th System (Advanced Planning) Integration:

• Before: Geschätzt 6 Monate für 12 neue P2P-Interfaces
• After: 5 Tage - Subscription auf bestehende Topics, fertig

Key Success Factors

CloudEvents Standard

Verwendung des Industry-Standards ermöglichte:

• Vendor-unabhängiges Event-Format
• Einfache Integration mit Non-SAP-Systemen
• Wiederverwendbare Tooling (Validators, Visualizers)

Event Schema Evolution

Schema Registry mit Versionierung:

• Breaking Changes werden frühzeitig erkannt
• Backward Compatibility erzwungen
• Consumer können in eigenem Tempo upgraden

Monitoring & Observability

• Grafana Dashboards: Real-time Event-Throughput, Error Rates
• Alert auf DLQ: Slack-Notification bei fehlgeschlagenen Events
• End-to-End Tracing: Correlation-IDs über alle Systeme

Lessons Learned

Async ist nicht immer besser

Für kritische Validierungen (z.B. Credit Check) behielten wir synchrone APIs. Events sind für "Fire & Forget" Szenarien optimal.

Dead Letter Queue ist essentiell

Ohne DLQ hätten wir Events verloren. DLQ + Alerting ermöglicht proaktive Fehlerbehandlung.

Schema Governance unterschätzt

Anfangs hatten wir freie Event-Formate. Nach 3 Monaten war Chaos perfekt. Schema Registry war Gamechanger.

CAP als Smart Consumer

CAP-Service als Subscriber (statt direkter Subsystem-Anbindung) ermöglichte:

• Transformation-Logik zentral
• Retry-Logic wiederverwendbar
• Monitoring & Logging einheitlich

Diese Case Study zeigt, wie Event-Driven Architecture echten Business Value liefert: Zero Production Delays, 80% schnellere Integration neuer Systeme und vollständige Entkopplung für flexible Wartungsfenster.