Der Prüfbericht

Typ A/B · Verwaltung

Beim Abholen validiert das SDK eine Submission (oder Reply) in drei Stufen — Metadaten, Fachdaten, Anhänge: Schema, Hashes, Authentifizierungs-Tags, optional der Virenscan. In älteren SDK-Generationen konnte ein Fehler zur automatischen Ablehnung führen („Auto-Reject“). Seit 4.0.0-rc.1 kommt die Nachricht immer entschlüsselt zurück — zusammen mit einem Bericht. Ob angenommen oder abgelehnt wird, entscheidet ausschließlich Ihr Fachverfahren.

So sieht ein Bericht aus

describe() für eine Submission, deren Metadaten das Schema vergessen haben und deren Datenhash nicht stimmt:

ERROR METADATA    $.contentStructure.data.submissionSchema.schemaUri: is missing but it is required
      Fix: Ask the sender to correct the metadata and resubmit, or reject with the attached problem.
ERROR DATA        Invalid data hash - the metadata declares ab3f...91c2, the transmitted data hashes to 77de...04ff
      Fix: Ask the sender to correct the submission data and resubmit, or reject with the attached problem.

Nichts wurde abgelehnt, um diesen Bericht zu erzeugen: Die Submission ist entschlüsselt und lesbar.

Was drinsteht

Element	Bedeutung
`ReceiveIssue` · Schwere	`ERROR` blockiert die Annahme; `WARNING` nie.
`ReceiveIssue` · Stufe	`METADATA`, `DATA` oder `ATTACHMENTS` — wo der Fund liegt.
`ReceiveIssue` · Lösung	Der „Fix:“-Vorschlag — für Log und Sachbearbeitung gedacht, nicht wegoptimieren.
`acceptable()`	`true`, wenn der Bericht keine Fehler enthält. Warnungen zählen nicht.
`errors()` / `warnings()`	Die Funde nach Schwere getrennt.
`asProblems()`	Ein `Problem` pro Fehler — genau die Liste, die `reject(…)` erwartet und die der Absender im Ereignisprotokoll liest.
`describe()`	Alle Funde menschenlesbar, eine Zeile pro Fund plus Lösungsvorschlag.

Das Muster im Code

Java
.NET (C#)

ReceivedSubmission received = organisation.receive(waiting);

if (!received.acceptable()) {                 // report().acceptable() — false nur bei Fehlern
    log.warn(received.report().describe());
    organisation.reject(received, received.report().asProblems());
    return;
}

organisation.accept(received);

Ein accept(…)-Aufruf trotz acceptable() == false wirft SubmissionNotAcceptableException — mit dem Bericht im Gepäck — statt das Accept-Event zu senden. Die Submission bleibt unbestätigt und lässt sich weiterhin ablehnen. Warnungen sind erlaubt: accept(received) funktioniert auch dann, wenn report().warnings() nicht leer ist.

IncomingSubmission received = await organisation.FetchSubmission(submissionId, caseId);

if (!received.Acceptable())                   // Report.Acceptable() — false nur bei Fehlern
{
    logger.LogWarning(received.Report.Describe());
    await organisation.RejectSubmission(received, received.Report.AsProblems().ToList());
    return;
}

await organisation.AcceptSubmission(received);

Jede IncomingSubmission trägt ihren Report (ReceiveReport). AcceptSubmission(…) verweigert mit SubmissionNotAcceptableException, solange Fehler im Bericht stehen; Report.AsProblems() liefert die Liste für RejectSubmission(…). Welche der drei Stufen geprüft werden, steuern Validation.Metadata, Validation.Data und Validation.Attachments in der Konfiguration — alle drei stehen standardmäßig auf true.

Vielleicht wollen Sie einen Antrag mit fehlendem Schema trotzdem sichten, bevor Sie ihn ablehnen. Vielleicht ist eine Warnung für Ihr Verfahren ein Fehler. Beides geht nur, wenn die Entscheidung bei Ihnen liegt und der Antrag lesbar bleibt. Und weil reject(…) die Gründe als Problem-Liste ins Ereignisprotokoll schreibt, sieht der Onlinedienst genau, was er korrigieren muss — nicht nur „abgelehnt“.

Eigene Gründe ergänzen

Der Bericht deckt die technische Prüfung ab. Fachliche Gründe („Geburtsdatum liegt in der Zukunft“) fügen Sie als eigene Problem-Objekte hinzu — neben oder statt der Berichtsfehler:

Java
.NET (C#)

organisation.reject(received, List.of(
    new DataSchemaViolation("$.geburtsdatum: Datum liegt in der Zukunft"),
    new MyCustomProblem("Stadtname existiert nicht")));

// Annahme mit informativem Hinweis — trotz acceptable() == true
organisation.accept(received, new MyCustomProblem("Anhang wird nachgereicht"));

Die mitgelieferten Problem-Typen (DataSchemaViolation, UnsupportedService, …) liegen in dev.fitko.fitconnect.rest.model.event.problems; eigene leiten Sie von Problem ab.

await organisation.RejectSubmission(received,
[
    new DataJsonSyntaxViolation(),
    new MyCustomProblem("Stadtname existiert nicht"),
]);

// Annahme mit informativem Hinweis — trotz Acceptable() == true
await organisation.AcceptSubmission(received, [new MyCustomProblem("Anhang wird nachgereicht")]);

Die mitgelieferten Problem-Typen liegen unter Fitko.FitConnect.Client.Validation.*.Problems; eigene leiten Sie von Problem (Fitko.FitConnect.Core.Validation) ab.

Was der Absender davon sieht

Nur den Zustand REJECTED und die Problem-Liste im Ereignisprotokoll — nie den Bericht selbst. Deshalb lohnt sich beim Ablehnen ein sprechendes Problem: Es ist die einzige Information, die beim Onlinedienst ankommt. Wie der Absender sie liest, zeigt Status verfolgen.

Veraltet: „Auto-Reject“

Frühere Vorab-Versionen des Java-SDKs (bis 4.0.0-alpha.3) kannten einen konfigurierbaren Auto-Reject; mit 4.0.0-rc.1 wurde er ersatzlos entfernt (Story planning#5261, „Empfangsdiagnose“). Auch im .NET-SDK gibt es kein Validation.AutoReject mehr. Wer noch Code oder Doku mit enableAutoReject kennt, sieht einen älteren Stand.

Weiter geht's

Rezept: Anträge abholen und prüfen
Rezept: Antworten senden und lesen — derselbe Bericht für Replies
Referenz: Exceptions — SubmissionNotAcceptableException und Verwandte

So sieht ein Bericht aus​

Was drinsteht​

Das Muster im Code​

Eigene Gründe ergänzen​

Was der Absender davon sieht​

Weiter geht's​