Exkurs: OT und Datengetriebene Fertigung

Konzept

Live Demo

Features

FAQ

Status Quo & Ausblick

Optional: Deep Dive

Aktuell: alles über Workflow Ereignisse lösbar

• Im ELF werden Events harmonisiert:
  • Ereignisquelle
  • Objekttyp
  • Objekt ID
  • Event
• Ausbruch aus der SAP Welt möglich
  • Objekttypen in Anlehnung an SAP (z.B. "Vendor", "PurchaseOrder")
  • zusätzlich sind eigene Objekttypen möglich (z.B. "StorageLocation")
  • nicht an ereignisauslösende Technologie gebunden
• Unterschiedliche Event-Typen:
  • Workflow Events
  • Change Documents (CDHDR)
  • Custom Code, BADIs
  • RAP Events
  • Externe Ereignisse (Event-Driven-Architecture inbound)

• Oberpaket ZX_EVENT_LISTENER_FRAMEWORK

• Wunsch, dass ELF nicht nur eine Projektlösung bleibt

• Mit dem Erfolg steigt die Komplexität und das Projekt wird zum Produkt

• verschiedene Unterpakete mit unterschiedlichen Aufgaben

• Weitreichene Nutzung von ABAP Objects:

  • Factory, Interfaces, Vererbung
  • Konfiguration von ABAP Objects Handlern

• Rückblick:

  • ELF Version 1 setzte auf Change Documents und manuelle Prozesse via RAP Anwendung
  • Mehrfach-Events, hoher manueller Aufwand, Dumps
  • Umstellung auf Workflow Events und Queues
  • Rückbau weitestgehend abgeschlossen

• Herausforderung 1:
  • Der SAP Standard löst ein Event nicht aus
  • Beispiel: Bestellung ändert Einkaufsinfosatz, erzeugt aber kein Ereignis
  • Lösungsansatz:
    • Ereignis der Bestellung wird durch ELF verarbeitet
    • in den Positionen stehen ggf. die Infosätze
    • das ELF Framework leitet das Event intern weiter
• Herausforderung 2:
  • Der SAP schenkt benötigten Objekten nicht die "gewünschte Aufmerksamkeit"
  • Beispiel: Lagerort und Bestand des Lagerortes
  • Lösungsansatz:
    • Änderung der Lagerort-Stammdaten lassen sich abgreifen
    • Ein Materialbeleg (mit Ereignis) ändert den Bestand
    • ELF Objekttyp StorageLocation ist möglich

{
    "LIFNR": "0000012345",
    "NAME1": "Irgendein Lieferant",
    "ORT01": "Hamburg",
    "PSTLZ": "22222",
    "STRAS": "Irgendeine Straße 100",
    "LAND1": "DE",
    "ADRNR": "3000099999",
    "TELF1": "040 123456-78",
    "SMTP_ADDR": "noemail@nodomain.xx"
}

Herausforderungen:

• Der Partner erhält die Werte in abweichenden Feldern als im "ELF Standard"
• Der Partner erhält nur eine Teilmenge aller Daten
• Der Partner soll das Ereignis nur bekommen, wenn sich für seine Sicht tatsächlich etwas geändert hat

[
    {
        "PATH": "/SMTP_ADDR",
        "TAB_INDEX": 0,
        "ROW_KEY": "",
        "ELEMENT": "SMTP_ADDR",
        "CHG_IND": "U",
        "VAL_OLD": "noemail@nodomain.abc.xx",
        "VAL_NEW": "noemail@nodomain.xx"
    }
]

Lösungsansatz:

• ELF1 Receiver bekommt das Ereignis und prüft für die Sicht des Partners, ob das Ereignis wirklich relevant ist
• Wenn ja, dann wird das Ereignis an ELF3 weitergeleitet, sonst stoppt der Flow

• in ELF Level 3 geht es um den Transport der Daten
• Bisher verwendete Technologien: RFC, IDoc, WebService
• Wiederverwendbare Komponenten können in Konnektoren ausgelagert werden
• Es ist durchaus üblich, eine "Autobahn" zu Partnern zu bauen und dann nur verschiedene "Autos" loszuschicken: z.B. Konnektoren für Integration Suite, Azure, ...
• Ziel: konfigurierbare Konnektoren (Low-Code)

• Dokumentation als Knowledge Transfer Document
• Direkt am Entwicklungspaket, wird transportiert

• Vorgaben von zentraler IT wünschenswert
• im Markdown-Format und damit KI-tauglich

Status Quo

• Produktivstart am 18.01.2026 mit Version 0.9.0
• inzwischen bereits 0.9.1 - 0.9.2 produktiv mit kleineren Optimierungen und neuen Funktionen
• Release 0.9.3 für EWM: ChangeMaster über IDoc
• derzeit im Test, Produktivstart geplant für April 2026

Ausblick

• Mögliche neue Partner
  • Integration Suite
  • Kafka
  • Power BI
  • Simplifier
• Mögliche neue ELF Objekttypen
  • MaterialDocument
  • StorageLocation

Backlog

• weitere Use Cases und Partner
• Konfiguration für ABAP Objects basierende ELF-Handler
• Umstellung SM30 auf Custom Business Configuration
• Tools für Key User und Administration

Anregungen & Wunschliste

• Synchronisation mit der "Datenplattform"
• Engere Zusammenarbeit mit Dräger IT
• Zusammenarbeit mit Dräger OT
• Know-how-Transfer
• Qualitätssicherung
• Pair Programming
• Hackathons (2 Tage für PoC)