SAP-IDocs validieren: Wiederholung und Zielbeleg prüfen

Die fachliche Nachricht ist mehr als ein IDoc

Ein IDoc strukturiert den Austausch von Daten. Für die Validierung ist zusätzlich entscheidend, welche fachliche Handlung die Übertragung auslöst. Wird ein Prüfauftrag erzeugt, eine Charge gesperrt oder eine Warenbewegung gebucht? Beschreiben Sie Quellereignis, erwartete Zielwirkung und benötigte Rückmeldung. Eine formal richtige Nachricht kann auf das falsche Material, Werk oder die falsche Charge wirken. Ein erfolgreicher technischer Empfang lässt diese Zuordnungsfrage offen.

Erfassen Sie Nachrichtentyp, Basistyp, Erweiterungen, Partnervereinbarungen und relevante Verarbeitungskomponenten passend zur tatsächlichen Architektur. Middleware, Quellsystem und kundenspezifische Verarbeitung gehören in die Betrachtung, soweit sie das Ergebnis beeinflussen. Nicht jede SAP-Edition verwendet denselben Integrationsweg. Diese Arbeitshilfe richtet sich an Landschaften, in denen IDoc-Verarbeitung tatsächlich eingesetzt wird. Sie behauptet keine allgemeine IDoc-Verfügbarkeit oder Konfiguration für jedes SAP-Produkt.

Quellen: [1]

Transportidentität und Geschäftsidentität unterscheiden

SAP beschreibt für tRFC eine einmalige Ausführung innerhalb seines Transaktionsmechanismus und für qRFC zusätzlich eine festgelegte Reihenfolge innerhalb der entsprechenden Queue. Die Transaktions-ID, TID, hat dabei eine konkrete technische Rolle. Diese Eigenschaft darf nicht ohne Prüfung auf eine beliebige End-to-End-Kette übertragen werden. Ein vorgelagertes System kann dieselbe Geschäftsaktion unter einer neuen Identität erneut senden. Dann ist die technische Nachricht neu, obwohl die beabsichtigte Buchung bereits existiert.

Definieren Sie deshalb auch eine geeignete fachliche Identität, beispielsweise die Verbindung aus Quellsystem, Belegnummer, Position und Ereignisversion. Welche Wiederholungen sollen denselben Vorgang betreffen? Wann ist ein späteres Ereignis eine legitime Korrektur? Ein Dublettenkriterium nur aus Material und Menge wäre oft zu grob: Zwei gleiche Lieferungen können beide berechtigt sein. Ein Kriterium aus einer jedes Mal neu erzeugten Nachrichtennummer kann dagegen dieselbe Lieferung mehrfach zulassen. Die Regel wird aus dem Prozess abgeleitet.

Quellen: [2]

Der Zielbeleg trägt den eigentlichen Nachweis

Der Abgleich prüft nicht nur IDoc-Anzahl und Übertragungsstatus. Verfolgen Sie den betroffenen Zielbeleg und seine fachlichen Attribute: Identität, Menge, Einheit, Charge, Status, Datum und Referenzen. Prüfen Sie, ob ein Beleg tatsächlich gebucht wurde oder nur ein Zwischenschritt existiert. Eine technische Verarbeitung kann abgeschlossen sein, während eine nachgelagerte fachliche Aktion noch fehlt. Die erforderliche Schlussfolgerung muss den tatsächlichen Prozesszustand benennen.

Auch Rückmeldungen brauchen einen klaren Bezug. Eine Nachricht „erfolgreich“ ohne eindeutige Verbindung zum Quellereignis hilft bei mehreren parallelen Vorgängen wenig. Legen Sie fest, welche Information der Sender zur Entscheidung über Wiederholung erhält. Beschreiben Sie, ob eine fachliche Ablehnung, ein Transportfehler und ein noch offener Verarbeitungszustand unterscheidbar sind. Ein Timeout bedeutet zunächst nur, dass die erwartete Antwort nicht rechtzeitig vorlag; er beweist weder das Ausbleiben noch den Erfolg der Zielaktion.

Konstruiertes Beispiel: Bestätigung verloren, Buchung vorhanden

Im eigenen Prüfszenario sendet ein Lager einen Zugang über 20 kg für Charge A. SAP erzeugt den zugehörigen Zielbeleg. Anschließend wird in der kontrollierten Teststrecke die Bestätigung unterbrochen. Der Sender sieht keinen Erfolg. Der Test prüft nun die freigegebene Wiederholungsregel: Eine technische Wiederaufnahme desselben Vorgangs darf nicht unbemerkt einen zusätzlichen Zugang über weitere 20 kg erzeugen. Der erwartete Bestand und die Beleganzahl werden unabhängig vom Schnittstellenprotokoll bestimmt.

Erzeugen Sie außerdem denselben Geschäftsinhalt mit einer neuen Nachrichtenidentität. Damit prüfen Sie eine andere Fehlerklasse als die Wiederholung derselben Transporttransaktion. Die gewünschte Reaktion kann eine erkannte Dublette, eine gezielte Nachbearbeitung oder eine andere spezifizierte Behandlung sein. Behaupten Sie nicht, dass SAP jede fachliche Dublette automatisch verhindert. Die folgende Matrix zeigt eigene Prüfvorschläge. Ausführung und Eingriff erfolgen in einer dafür freigegebenen Testumgebung, nicht durch Manipulation realer Produktionsbuchungen.

Reihenfolge nach fachlicher Abhängigkeit prüfen

Nicht jede Nachricht benötigt eine globale Reihenfolge. Fachlich abhängige Ereignisse können sie jedoch benötigen: Charge anlegen, prüfen, sperren und später freigeben. Beschreiben Sie die Abhängigkeit und prüfen Sie den verwendeten Queue- oder Ordnungsmechanismus. Die qRFC-Eigenschaft gilt innerhalb ihres konkreten Mechanismus. Unterschiedliche Queues, Middlewarepfade oder parallel ausgelöste Geschäftsereignisse werden dadurch nicht automatisch zu einer einzigen fachlich sortierten Folge.

Testen Sie Verzögerung, Stau und Wiederanlauf. Kann ein älteres Ereignis nach einem neueren Zustand eintreffen und diesen unzulässig überschreiben? Ist eine Versions- oder Zustandsprüfung erforderlich? Wenn mehrere Systeme beteiligt sind, braucht der Nachweis den wirksamen Zustand an jeder relevanten Stelle. Eine Charge, die im ERP gesperrt erscheint, aber im Lager noch ausgegeben werden kann, ist kein ausreichend belegter End-to-End-Sperrprozess. Der Test muss auch den Zeitraum bis zur vollständigen Wirksamkeit betrachten.

Quellen: [2]

Teilverarbeitung und Änderungen gezielt behandeln

Ein Nachrichtenpaket kann mehrere Positionen enthalten. Legen Sie fest, ob ein Fehler die gesamte Verarbeitung zurücksetzt oder zulässige Teilwirkungen bestehen bleiben. Prüfen Sie diese Entscheidung konkret. Nach einer Wiederholung dürfen bereits verarbeitete Positionen nicht doppelt wirken und zuvor fehlerhafte Positionen nicht verloren gehen. Ein Abschlussstatus für das Gesamtpaket braucht einen nachvollziehbaren Bezug zu allen benötigten Teilaktionen. Eine summarische Meldung kann offene Positionen andernfalls verdecken.

Bei Änderungen an Mapping, Stammdaten oder Verarbeitungslogik betrachten Sie bestehende offene Nachrichten. Werden sie nach der neuen oder der alten Regel verarbeitet? Kann eine neue Feldbelegung die Bedeutung historisch wartender Nachrichten verändern? Beschreiben Sie, wie Versionen und Nachbearbeitung zugeordnet werden. Ein neuer erfolgreicher Test mit frisch erzeugten Nachrichten deckt die Behandlung eines alten Rückstands nicht automatisch ab. Der kontrollierte Übergang gehört zum Änderungskonzept, wenn solche Rückstände vorhanden sind.

Nachbearbeitung und Betrieb mit einbeziehen

Manuelle Nachbearbeitung kann fachlich nötig sein. Definieren Sie Zuständigkeit, erlaubte Korrekturen und Freigabegrenzen. Welche Änderungen bleiben nachvollziehbar? Wird eine geänderte Nachricht erneut verarbeitet oder ein Ersatzvorgang angelegt? Prüfen Sie, ob der ursprüngliche Inhalt und der Zusammenhang mit der Korrektur im erforderlichen Umfang erhalten bleiben. Ein administrativer Zugriff, der beliebige Wiederholungen ohne erkennbare fachliche Entscheidung ermöglicht, braucht eine passende Bewertung und Kontrolle.

Ein brauchbares Monitoring unterscheidet offene, abgelehnte, verarbeitete und nicht zuordenbare Vorgänge. Verantwortliche sollten erkennen können, welche fachlichen Entscheidungen betroffen sind. Eine grüne Verbindungsanzeige ersetzt diese Information nicht. Legen Sie Eskalation und Reaktion nach Prozesswirkung fest. Für einen zeitkritischen Sperrprozess kann die zulässige Reaktionszeit anders sein als für eine spätere statistische Auswertung. Die Frist wird fachlich begründet und nicht aus einer pauschalen technischen Standardzahl übernommen.

Quellen: [1] [3]

Ein nachvollziehbares Abschlussbild erstellen

Das Abschlussbild verbindet Quellereignis, Transportidentität, Verarbeitung, Zielbeleg und Rückmeldung. Halten Sie fest, welche Fehlerpfade geprüft wurden und welche Grenzen verbleiben. Dazu gehören das Verhalten bei verlorener Bestätigung, fachlicher Dublette, vertauschter Reihenfolge, Teilverarbeitung und Wiederanlauf. Dokumentieren Sie zulässige Unterschiede und deren Begründung. Ein reiner Vergleich „100 gesendet, 100 empfangen“ beantwortet diese Fragen nicht, wenn eine Nachricht doppelt und eine andere gar nicht verarbeitet wurde.

Übergeben Sie dem Betrieb konkrete Such- und Entscheidungswege. Das Team muss einen unklaren Zustand auflösen können, ohne blind erneut zu senden. Eine Arbeitsanweisung kann zeigen, welche Referenzen zu vergleichen sind und wann fachliche Unterstützung erforderlich ist. Änderungen an Schnittstelle, Identitätsregel oder Betriebsverfahren lösen eine passende Auswirkungsbewertung aus. So bleibt der ursprüngliche Nachweis auch nach Updates verwendbar, soweit seine Voraussetzungen noch zutreffen.