SDK validiert Replies fachlich falsch

Zusammenfassung

Das Java-SDK validiert eingehende Replies zu strikt, was eine fachlich sinnvolle Nutzung von Replies derzeit unmöglich macht.

Betrifft

  • Java SDK 3.1.0
  • (möglicherweise) .NET SDK

Beschreibung

Beim Empfang von Replies wird geprüft, ob reply.metadata.contentStructure.data.submissionSchema.schemaUri in destination.publicServices[].submissionSchemas[].schemaUri enthalten ist. Ist dies nicht der Fall, wird der Reply rejected. Dieser Check ist aber fachlich falsch und muss entfernt werden.

Die Validierung von reply.data gegen reply.metadata.contentStructure.data.submissionSchema.schemaUri macht aber durchaus weiterhin Sinn.

Hintergrund

An einer Destination werden unter destination.publicServices[].submissionSchemas die URLs von Schematas hinterlegt, denen Submissions genügen müssen. Beim Empfang von Submissions validiert das SDK dies korrekt.

Für Replies soll diese Einschränkung aber nicht gelten. Welches Fachdatenschema in einem Reply verwendet wird, wird seitens FIT-Connect in keiner Weise gesteuert; die Reply-empfangende Implementierung muss selbstständig feststellen, ob die Reply-Fachdaten einem erwarteten Schema entsprechen.

Das SDK kann derzeit deshalb nicht fachlich sinnvoll genutzt werden, da:

  1. Man in Replies nicht dasselbe Fachdatenschema verwenden will, wie in einer Submission. Ein Bescheid hat z.B. eine völlig andere Struktur als eine Beantragung.
  2. Man an der Destination nicht auch noch das Reply-Schema eintragen möchte. Dies würde die Beschreibung der Leistung "verschmutzen" und Register und Anbinder verwirren.

Am 14 Jan 2026 besprach ich dies mit @Andreas_Huber, der mir bestätigte, dass es sich um einen Bug handelt.

zu 2.: Das ist ein Bug. Auf eine Bauvoranfrage antwortet die Baubehörde mit einem Bauvorbescheid. Dann sendet der Bauherr einen Bauantrag, darauf antwortet die Behörde mit einer Baugenehmigung, dann kommt die Baubeginnanzeige usw. Genau das legt der Prozessstandard fest.

Eine saubere Validierung bekommen wir erst mit der Prozessunterstützung hin. Da können wir dann alle Nachrichten als Message Flows modellieren und den Zustellpunkten (die dann auf beiden Seiten existieren) zuordnen.