Wiki - Chris Seyboth

Der ACK-Vertrag - was eine Quittung zusichert

5 Min. Lesezeit

Konzept: Der ACK-Vertrag

Ein ACK ist keine Erfolgsmeldung, sondern die Erfüllung eines Vertrags, den der Sender pro Nachricht selbst festlegt — über MSH-15 (Accept Acknowledgment Type) und MSH-16 (Application Acknowledgment Type).

Beide Felder sind Anforderungen an den Empfänger, keine Zusagen des Senders: Der Standard beschreibt sie als „the conditions under which acknowledgments are required to be returned in response to this message”. Wer MSH-16 setzt, sagt nicht „ich quittiere so”, sondern „so hast du mir zu quittieren”. Die Richtung zu verwechseln, führt im Gespräch mit einer Gegenstelle regelmäßig zur falschen Zuständigkeitsfrage.

Sind beide leer oder nicht vorhanden, gilt der Original Mode; ist mindestens eines gefüllt, der Enhanced Mode. Beide tragen Werte aus HL7-Tabelle 0155:

WertBedeutung
ALalways — immer quittieren
NEnever — nie quittieren
ERnur bei Fehler/Reject
SUnur bei Erfolg

Zwei getrennte Zusagen

  • Accept (CA / CE / CR in MSA-1, nur Enhanced Mode) — „Ich habe die Nachricht angenommen und sicher verwahrt.” Eine Aussage über Zuständigkeit, nicht über Verarbeitung. CR gilt, wenn MSH-9, MSH-11 oder MSH-12 nicht akzeptabel sind, CE bei jedem anderen Annahmehindernis.
  • Application (AA / AE / AR) — „Meine Anwendung hat die Nachricht verarbeitet.”

Keine der beiden Zusagen sagt etwas darüber, ob der Inhalt zutrifft. Ein ACK bewertet die Nachricht, nie ihren Wahrheitsgehalt.

Daraus folgt der praktisch wichtigste Satz: Steht MSH-16 auf NE, hat der Sender ausdrücklich erklärt, keine Aussage über die Verarbeitung zu wollen. Dann existiert kein Kanal, über den ein Verarbeitungsfehler je gemeldet werden könnte — und eine Quittungsquote von 100 % ist eine Tautologie, kein Nachweis. „Null NACKs” ist dort keine Beobachtung, sondern eine Definitionsfolge.

Ebenso häufig: ein mit MSH-15 = AL angeforderter Accept-ACK wird mit MSA-1 = AA beantwortet, also einem Original-Mode-Code. Die meisten Kommunikationsserver akzeptieren das tolerant. Das ACK geht damit nicht verloren — es kommt an und wird fehlgelesen, und das ist der schlechtere Fall: eine verlorene Quittung fällt irgendwann auf, eine fehlgelesene nie.

Wo der Fehler im Sichtbarkeitsraster steht

Ein abbestellter Rückkanal ist nicht „der Empfänger rät”. Niemand rät hier; der Empfänger verarbeitet, und niemand fragt nach dem Ergebnis. Sauber ausgedrückt über das Raster

Sichtbarkeit = Fehlerklasse × ACK-Vertrag × Strenge der Gegenstelle

hat der Sender den mittleren Faktor auf null gesetzt. Dann ist jede Fehlerklasse still, gleichgültig wie streng die Gegenstelle prüft.

Daraus folgt eine Gegenprobe, die schärfer ist als „kann dieser Defekt das Symptom erzeugen”: Ersetze den Befund gedanklich durch die korrekte Variante — verschwindet das Symptom? Ein korrektes CA statt des falschen AA erzeugt dasselbe Protokoll und denselben Verlust. Der auffällige Befund ist damit nicht die Ursache.

AE und AR verlangen gegenläufige Retry-Logik

  • AE — Fehler in Inhalt oder Format. Dieselbe Nachricht liefert beliebig oft dasselbe Ergebnis; Wiederholung vergiftet die Queue.
  • AR — Ablehnung aus inhaltsunabhängigen Gründen (Anwendung nicht verfügbar, Sequenzproblem). Hier ist ein späterer Versuch sinnvoll.

Eine Retry-Schleife, die beide gleich behandelt, ist entweder ein Endlosläufer oder ein stiller Datenverlust.

Warum NACKs selten automatisierbar sind

Die maschinenlesbare Begründung steht im ERR-Segment: ERR-2 (Datentyp ERL) lokalisiert die Fundstelle als Segment ^ Segmentwiederholung ^ Feld ^ Feldwiederholung ^ Komponente ^ Subkomponente, ERR-3 trägt einen generischen Code aus Tabelle 0357, ERR-4 die Severity. ERR-1 ist ab v2.4 deprecated und ab v2.7 zurückgezogen.

Tabelle 0357 kennt nur Klassen; die konkrete Diagnose landet in den nicht standardisierten Feldern ERR-5 und ERR-7. Jede Automatik, die darauf aufsetzt, ist damit faktisch eine Herstellerbindung. Belastbar automatisierbar ist genau eines: dass ein NACK kam.

Portalbezug

„Alle Nachrichten wurden quittiert” ist die häufigste Aussage in der Fehlersuche zwischen KIS und Portal — und je nach MSH-15/MSH-16 bedeutet sie alles zwischen „verarbeitet” und „gar nichts”. Vor jeder Diskussion über fehlende Daten gehört geklärt, welcher Quittungsmodus auf der Strecke tatsächlich vereinbart ist.

Beispiel: NACK mit lokalisierter Fundstelle (synthetisch)

MSA|AE|MSGID000123
ERR||PID^1^3^1^4|101^Required field missing^HL70357|E|||Assigning Authority in PID-3.4 nicht gesetzt

Transfer

Der ACK-Vertrag ist die zweite Schicht der Sichtbarkeit: Ob ein Fehler überhaupt sichtbar werden kann, entscheidet sich nicht am Fehler, sondern am vereinbarten Rückkanal. Wo MSH-16 = NE gilt, braucht es zwingend einen ausdrücklich benannten zweiten Nachweisweg. In der Regel den Abgleich Quelle↔Ziel. Ohne einen davon ist die Strecke nicht bloß unbeobachtet, sondern unbelegbar.

Vollständige Mechanik zum Nachschlagen: ACK und NACK im Detail

Siehe auch: Framing · Update-Semantik

Fragen an die Kunden-IT

  • Welche Werte stehen in MSH-15 und MSH-16 auf dieser Strecke — und hat sie jemand bewusst gesetzt, oder sind es Defaults?
  • Falls MSH-16 = NE: Über welchen Weg erfahrt ihr dann von Verarbeitungsfehlern? (Es gibt keinen — außer ihr benennt einen zweiten.)
  • Unterscheidet eure Retry-Logik zwischen AE und AR? Falls nein: bei welchem der beiden entsteht die Endlosschleife?
  • Was passiert mit einer Nachricht nach dem letzten fehlgeschlagenen Versuch — Queue, Dead Letter, oder still verworfen?
  • Wertet ihr ERR-3/ERR-4 maschinell aus, oder nur die Tatsache „es kam ein NACK”?
  • Was genau belegt euer Sendeprotokoll — Zustellung oder Verarbeitung? Und woran lässt sich das im Protokoll unterscheiden?

Lektüre & Belege

Graphansicht

Backlinks