Ein Agent für ERP-Integrationsfehler: Taxonomie, Runbooks und sichere Wiederholungen

Fehlerbehandlung in ERP-Integrationen ist die Betriebsseite der Verbindung von Shop, PIM und ERP: fehlgeschlagene Nachrichten lesen, zwischen Wiederholen und Korrigieren entscheiden, herausfinden, wessen System die Korrektur verantwortet, und wissen, welche Aufträge betroffen sind. Ein Agent kann dem Integrationsteam den Großteil des Lesens und Sortierens abnehmen, solange er gegen eine echte Fehlertaxonomie klassifiziert, nur über eine kurze Liste sicherer Runbook-Aktionen handelt und jede Änderung an Geschäftsdaten Menschen überlässt.

Dieser Artikel behandelt, was zwischen Shop, PIM und ERP bricht, eine Taxonomie aus den Fehlerverträgen von SAP, die Triage-Schleife des Agenten, sichere Retries und Runbooks, Queue- und Dead-Letter-Mechanik, Leitplanken, den Business Case und wann eine Regel-Engine die bessere Antwort ist. Das Design der Synchronisation selbst beschreibt der Pimcore-ERP-Delta-Sync.

Was bricht zwischen Shop, PIM und ERP?

Fünf Fehlerfamilien decken die meisten Vorfälle ab: Mapping- und Validierungsfehler, fehlende oder gesperrte Stammdaten, Preis- und Kundensperren, Verfügbarkeits- und Zuteilungskonflikte sowie Authentifizierungs-, Timeout- und Infrastrukturfehler. Jede Triage beantwortet drei Fragen: wiederholen oder korrigieren, wessen System die Korrektur verantwortet und wie viele Aufträge betroffen sind.

Der Unterschied zwischen Wiederholen und Korrigieren zählt am meisten. Nur die letzte Familie bessert sich mit der Zeit; ein fehlendes Material oder ein gesperrter Kunde scheitert bei jedem Retry gleich, und eine Integration, die solche Fehler endlos wiederholt, macht aus einem Datenproblem hunderte laute Alarme. Bei meiner Arbeit an B2B-Commerce-Systemen mit Spryker und Pimcore habe ich gelernt, dass Teams nach einem Projekt nicht den Integrationscode behalten, sondern die Runbook-Bibliothek und das Fehler-Dashboard; planen Sie diese von Anfang an.

Wie baut man eine Taxonomie für Integrationsfehler?

Bauen Sie sie aus den Fehlerverträgen, die Ihre Systeme schon ausgeben, nicht aus erfundenen Bezeichnungen. SAP liefert zwei gute: IDoc-Statussätze und OData-Fehlerobjekte.

• IDoc-Statussätze. Laut der Statusliste von SAP, abgeglichen mit der SAP Community, bedeutet 51 „Anwendungsbeleg nicht gebucht“, 53 „Anwendungsbeleg gebucht“, 64 „IDoc bereit zur Übergabe an die Anwendung“, 66 „IDoc wartet auf Vorgänger-IDoc“ und 68 „Fehler, keine weitere Verarbeitung“. Die ALE-Dokumentation von SAP beschreibt, dass die Eingangsverarbeitung eines fehlerhaften IDocs abbricht, ein Workflow-Workitem entsteht und das IDoc nach der Korrektur erneut übergeben wird; der Report RBDMANI2 verarbeitet IDocs mit Status 51 und 63 erneut und lässt sich einplanen, um an einer Sperre gescheiterte einzusammeln (SAP Library).
• OData-Fehlerobjekte. Eine OData-V4-Fehlerantwort ist ein JSON-Objekt error mit sprachunabhängigem code, einer Meldung, einem optionalen target, das auf die fehlerhafte Eigenschaft zeigt, und einem Array details. SAP CAP ergänzt eine numerische Schwere und zieht eine klare Linie: Eine ServiceException bricht ab und rollt zurück, während über die Messages-API ergänzte Meldungen die Verarbeitung nicht stoppen (SAP CAP). Eine Warnung mit Target ist ein Bericht, kein Retry-Kandidat.

Wie funktioniert die Triage-Schleife des Agenten?

Jedes Signal in einen Datensatz normalisieren, zuerst mit Regeln klassifizieren, aus der Taxonomie entscheiden, innerhalb einer Freigabeliste handeln, das Geschehene festhalten und per Fingerabdruck deduplizieren. Das LLM ist ein Bestandteil des Klassifikators und nur für unstrukturierten Laufzeittext gedacht, auf den keine Regel passt.

// One record shape for every signal (sketch)
type IntegrationError = {
  source: 'idoc' | 'cpi' | 'odata' | 'queue' | 'shop'
  interface: string      // e.g. "ORDERS inbound", "stock sync"
  entityKey: string      // order number, material, customer
  code: string           // IDoc status + message class/number, OData error code, DLQ reason
  target?: string        // OData target path or IDoc segment/field
  text: string           // runtime message text: untrusted input for any LLM step
  retryCount: number
}

// Same class, same runbook: fingerprint without volatile values
const fingerprint = (e: IntegrationError) =>
  sha256([e.source, e.interface, e.code, e.target ?? '', stripVolatile(e.text)].join('|'))
// stripVolatile removes ids, numbers and timestamps, so
// "material 4711 not found" and "material 4712 not found" share one fingerprint

Der Fingerabdruck macht aus einer Flut eine Liste. Zweihundert fehlgeschlagene Auftrags-IDocs mit demselben fehlenden Material werden zu einem Vorfall mit Zähler und Liste betroffener Aufträge, verknüpft mit einem Ticket. Behandeln Sie den Laufzeittext als nicht vertrauenswürdige Eingabe: Er kann Zeichenketten des Kunden enthalten; der LLM-Schritt klassifiziert und fasst daher nur zusammen und entscheidet nie eine Aktion außerhalb der Taxonomie. Mein eigener jev-decide-Skill hat dieselbe Form, eine typisierte Entscheidung mit Konfidenz, bei der niedrige Konfidenz an einen Menschen geht, und der Triage-Klassifikator sollte genau das liefern: Fehlerklasse, wiederholbar, Verantwortlicher, Konfidenz.

Wann ist ein Retry sicher, und was gehört in ein Runbook?

Ein Retry ist sicher, wenn der Fehler vorübergehend und die Operation idempotent ist, und er bleibt nur sicher, wenn die Versuche begrenzt und zeitlich verteilt sind. Alles andere ist Quarantäne plus Ticket. Ein Runbook ist eine kurze Liste benannter Aktionen je Fehlerklasse: automatischer Retry, Quarantäne mit Zuständigem, Benachrichtigung, Ticket mit Kontext oder Vorschlag einer Mapping-Änderung.

Idempotenz ist ein Vertrag auf Empfängerseite. Die Stripe-API ist die saubere Referenz: Ein Idempotenzschlüssel erlaubt es, eine Anfrage zu wiederholen, ohne die Operation doppelt auszuführen, und die Wiederverwendung eines Schlüssels mit anderen Parametern liefert einen Fehler (Stripe). Jeder Aufruf, der einen Kundenauftrag, eine Lieferung oder eine Rechnung anlegt, braucht denselben Vertrag, bevor ein Agent ihn wiederholen darf; der doppelte Kundenauftrag ist der Fehler, der echtes Geld kostet, weshalb die automatisierte Auftragserfassung aus E-Mails den Schlüssel an den Anlageaufruf hängt. Backoff allein reicht auch nicht: In der AWS-Simulation mit 100 konkurrierenden Clients halbierte Full Jitter auf begrenztem exponentiellem Backoff die Zahl der Aufrufe mehr als (AWS).

// Capped exponential backoff with full jitter, for idempotent operations only
function retryDelayMs(attempt: number, baseMs = 1_000, capMs = 60_000): number {
  const ceiling = Math.min(capMs, baseMs * 2 ** attempt)
  return Math.random() * ceiling
}

const MAX_ATTEMPTS = 5   // bounded: after that, quarantine and open a ticket

Die Runbook-Bibliothek ist zugleich die Rückkopplung. Landet derselbe Fingerabdruck immer wieder in Quarantäne, schlägt der Agent dem Datenverantwortlichen per Ticket eine Mapping-Korrektur vor, mit Zähler, betroffenen Aufträgen und Beispiel-Payload. So verschwinden wiederkehrende Klassen, statt ewig bearbeitet zu werden. Retries bei LLM-API-Aufrufen folgen ähnlichen Regeln, aber einem anderen Fehlerbild, beschrieben in LLM-Rate-Limits, Retries und Provider-Fallback.

Welche Queue- und Dead-Letter-Mechanik sollte man kennen?

Wissen Sie genau, was in jeder Dead Letter Queue landet, denn die Regeln unterscheiden sich je Plattform, und ein Agent, der die falsche annimmt, übersieht Fehler. Drei Beispiele decken die meisten Stacks ab.

• JMS-Queues in SAP Cloud Integration: Bei nicht exklusiven JMS-Queues, wie SAP 2017 dokumentiert hat, beträgt das Retry-Intervall standardmäßig eine Minute, exponentielles Backoff verdoppelt es nach jedem Fehlschlag, und ein Höchstintervall von 60 Minuten oder mehr wird empfohlen (SAP Community). Die Dead Letter Queue ist dort eng gefasst: Sie nimmt Nachrichten auf, die wegen eines abgestürzten Knotens nicht verarbeitet werden konnten, zweimal wiederholt und dann für manuelle Bearbeitung geparkt; Nachrichten, die an einem Verarbeitungsfehler scheitern, landen dort nicht (SAP Community). Neuere exklusive Queues verhalten sich anders; prüfen Sie, welche Art eine Schnittstelle nutzt.
• Amazon SQS: Eine Redrive-Policy mit maxReceiveCount verschiebt Nachrichten in eine Dead Letter Queue, deren Ablauf sich nach dem ursprünglichen Einreihungszeitpunkt richtet; ihre Aufbewahrung muss daher länger sein als die der Quell-Queue (AWS).
• Azure Service Bus: Dead-Letter-Nachrichten tragen DeadLetterReason und DeadLetterDescription, etwa MaxDeliveryCountExceeded nach standardmäßig 10 Zustellungen, und Microsoft empfiehlt, Ausnahmetyp und Stacktrace in diese Felder zu schreiben (Microsoft Learn). Das ist kostenlose Eingabe für den Klassifikator.

Engines für dauerhafte Ausführung kodieren dieselben Regeln als Standard. Temporal wiederholt Activities mit exponentiellem Backoff, Faktor 2,0 von einer Sekunde Startintervall bis 100 Sekunden, behandelt maximal null Versuche als unbegrenzt und nennt in der Dokumentation fehlerhafte Eingabedaten als vernünftigen Fall für einen nicht wiederholbaren Fehler (Temporal). Laufen Ihre Auftragsabläufe darauf, liest der Agent deren Fehler wie jedes andere Signal; die Plattform selbst ist in Temporal besprochen.

Welche Leitplanken braucht ein Triage-Agent?

Standardmäßig nur lesend, Aktionen nur aus einer Freigabeliste, ein Probelaufmodus, Freigaben je Aktionsklasse und ein vollständiger Audit-Trail. Die OWASP Top 10 für LLM-Anwendungen führen übermäßige Handlungsbefugnis, also mehr Funktionen, Rechte oder Autonomie für ein LLM-gesteuertes System als die Aufgabe braucht, in der Ausgabe 2025 als LLM06 (OWASP GenAI).

Ein gutes Ticket ist der halbe Nutzen. Es enthält Schnittstelle, IDoc-Nummer oder Nachrichten-ID, Nachrichtenklasse und -nummer, Objektschlüssel, Fingerabdruck-Zähler, betroffene Aufträge und einen Link zum Runbook. Ich lege solche Tickets täglich über einen Jira-MCP-Server mit 20 Werkzeugen an, und der Unterschied zwischen einem Ticket mit und ohne Kontext lässt sich in Analystenminuten messen.

Was ist ein Triage-Agent für Integrationsfehler wert?

Er ist die Integrationszeit wert, die er freisetzt, und die fehlgeschlagenen Aufträge, die er sichtbar macht, bevor Kunden es merken. Für eingesparte Analystenstunden durch Triage-Automatisierung oder die Kosten eines fehlgeschlagenen B2B-Auftrags gibt es keine veröffentlichte Zahl; der Business Case stützt sich daher auf Kontextzahlen und Ihre eigene Basislinie.

• Integrationslast: Der Connectivity Benchmark 2026 von MuleSoft, eine Umfrage unter 1.050 IT-Verantwortlichen von Oktober bis November 2025, berichtet, dass IT-Teams 36 % ihrer Zeit mit Entwurf, Bau und Test individueller Integrationen verbringen, dass eine durchschnittliche Organisation 957 Anwendungen betreibt, von denen 27 % verbunden sind, und dass 26 % der IT-Projekte ihren Termin verfehlten (MuleSoft).
• Auftragsfehler treiben Abwanderung: In einer Studie von Sana Commerce mit 750 B2B-Einkäufern vom September 2024 berichteten 33 % von Auftragsfehlern durch ungenaue Webshop-Daten, und 75 % würden für ein besseres Erlebnis einen Lieferantenwechsel erwägen (Procurement Magazine; Anbieterumfrage).

Für eine Leitung E-Commerce-Betrieb oder ERP-Integration: Erheben Sie vor dem Pilot vier Basiswerte, fehlgeschlagene Nachrichten pro Schnittstelle und Woche, Zeit bis zur Lösung je Fehlerklasse, Anteil ohne menschlichen Eingriff und manuelle Eingriffe pro fehlgeschlagenem Auftrag. Zählen Sie dann die wiederkehrenden Klassen, die durch Mapping-Korrekturen verschwinden; diese Zahl versteht ein COO.

Wann sollte man dafür keinen Agenten bauen?

Bauen Sie keinen, wenn das Nachrichtenvolumen gering ist, wenn jedes Signal bereits strukturiert ist, wenn es keine Beobachtbarkeit gibt, aus der man lesen kann, oder wenn das eigentliche Problem ein ungelöster Designfehler weiter vorn ist. In diesen Fällen gewinnt eine Regel-Engine mit Alarmierung, und ein LLM bringt Kosten und ein neues Fehlerbild, aber kein zusätzliches Signal.

Eine Umsetzungs-Checkliste auf einer Seite

1. Für den Pilot eine Schnittstelle und eine Fehlerklasse wählen, etwa eingehende Auftrags-IDocs.
2. Die Taxonomie aus echten Statuscodes und Fehlerobjekten schreiben, mit Verantwortlichem je Klasse.
3. Alle Signale in eine Datensatzform normalisieren und ohne veränderliche Werte Fingerabdrücke bilden.
4. Zuerst mit Regeln klassifizieren; nur unpassenden Freitext mit Konfidenzschwelle an das LLM geben.
5. Aktionen per Freigabeliste festlegen, im Probelauf starten und Freigaben je Aktionsklasse verlangen.
6. Nur idempotente Aufrufe wiederholen, begrenzt, mit Backoff und Jitter.
7. Jede Entscheidung und Aktion mit Fingerabdruck, Regel- oder Modellversion und Ergebnis protokollieren.
8. Die vier Kennzahlen als Basislinie erheben und wiederkehrende Klassen monatlich mit den Datenverantwortlichen durchgehen.

Ein Triage-Pilot mit festem Umfang für eine Schnittstelle, mit schriftlicher Taxonomie, Runbook-Bibliothek, Dedup-Berichten und einem Vorher-nachher aus Ihren eigenen Logs, ist ein klar abgegrenztes Projekt. Wenn Sie Unterstützung bei der Planung möchten, sehen Sie sich meine B2B-E-Commerce-Arbeit an.

Quellen

1. SAP Library: IDoc interface and ALE exception handling
2. SAP Community: IDoc status codes
3. SAP CAP: indicating errors (Java)
4. SAP Community: Cloud Integration asynchronous messaging with retry using JMS (2017)
5. SAP Community: Cloud Integration dead-letter handling in the JMS adapter (2017)
6. Temporal: retry policies
7. Amazon SQS: dead-letter queues
8. Azure Service Bus: dead-letter queues
9. Stripe API reference: idempotent requests
10. AWS Architecture Blog: Exponential backoff and jitter
11. MuleSoft: 2026 Connectivity Benchmark Report
12. OWASP GenAI Security Project: LLM06:2025 Excessive Agency