Status verfolgen

TL;DR – Status oder vollständiges Ereignisprotokoll einer Submission abrufen, um den Fortschritt durch das Zustandsmodell submitted → forwarded → accepted / rejected zu verfolgen. Die Hintergründe erklärt Vorgänge und Ereignisprotokoll.

Zustandsmodell einer Submission

Zustände mit ✎ schreibt der Empfänger — signiert mit seinem Signaturschlüssel. Eine ausführliche Erklärung der Zustände finden Sie im Glossar und im Konzept Vorgänge und Ereignisprotokoll.

Aktuellen Status abfragen (Sender)

Status und Eventlog stecken im TransferLog: cases().logOf(...) liefert es für eine einzelne Nachricht (Submission oder Reply), latest() den aktuellsten Eintrag als CaseEvent mit seinem EventState.

Java
.NET (C#)

SentSubmission sent = onlineService.send(submission);

// latest() wirft bei leerem Log — direkt nach dem Senden ist immer mindestens ein Event da
CaseEvent latest = onlineService.cases().logOf(sent).latest();

System.out.printf("Submission %s → %s%n",
    sent.submissionId(), latest.state());

Ein Aufruf statt zweier separater Roundtrips: logOf(...) liefert das TransferLog dieser einen Nachricht, latest() (nach issueTime) trägt den aktuellen Stand als EventState.

SentSubmission sent = await onlineService.SendSubmission(submission);

EventState state = await onlineService.GetSubmissionState(sent);

Console.WriteLine($"Submission {sent.SubmissionId} → {state}");   // Submitted, Forwarded, Accepted, Rejected …

GetSubmissionState(...) liest den neuesten Eintrag des Ereignisprotokolls dieser Submission und prüft dabei die Signatur des Events. Für gesendete Antworten gibt es analog organisation.GetReplyState(sentReply).

Auf Endstatus warten (.NET, Paket Fitko.FitConnect.Zbp)

WaitForCompletionAsync(sent, timeoutSeconds: 60) pollt, bis die Submission ihren Endstatus (Accepted oder Rejected) erreicht hat. Die Erweiterungsmethode liegt im Paket Fitko.FitConnect.Zbp (nicht im Basispaket) — installieren Sie es auch dann, wenn Sie kein ZBP nutzen, sobald Sie diese Komfortfunktion wollen.

Vollständiges Eventlog abrufen

Zwei Blickwinkel auf denselben Vorgang: logOf(nachricht) liefert das Log einer einzelnen Nachricht, events(caseId) das Log des ganzen Vorgangs — die Namen sind absichtlich verschieden.

Java
.NET (C#)

Log einer einzelnen Nachricht, samt Ausgabe aller Einträge:

TransferLog log = onlineService.cases().logOf(sent);
List<CaseEvent> entries = log.entries();

for (CaseEvent e : entries) {
    System.out.printf("[%s] %s%n", e.issueTime(), e.state());
}

Log des ganzen Vorgangs — alle Submissions und Replies dieses Case zusammen:

List<CaseEvent> caseLog = onlineService.cases().events(caseId);

// IEventLogService liefert geparste Einträge (CaseEvent) statt roher JWT-Strings.
// AddFitConnect() registriert es; injizieren Sie es neben IFitConnectClient.
List<CaseEvent> caseLog = await eventLogService.GetCaseEventLog(caseId, myDestinationId);

foreach (CaseEvent e in caseLog)
{
    Console.WriteLine($"[{e.IssueTime}] {e.EventType} von {e.Issuer}");
    if (e.Problems is { Count: > 0 })
        Console.WriteLine($"   Gründe: {string.Join("; ", e.Problems.Select(p => p.Detail))}");
}

Rohzugriff

onlineService.Cases.GetCaseEventLog(caseId) (ebenso organisation.Cases) liefert das Log als Liste roher, signierter JWT-Strings (CaseEventLogResponse.EventLogs). Für die geparste Form mit Zeitstempel, Event-Typ und Problems ist IEventLogService der richtige Einstieg.

Status auf der Empfängerseite

Empfangsseitig verwenden Sie die Organisation — das Log lässt sich direkt aus dem wartenden bzw. empfangenen Objekt abrufen, ganz ohne separates Tripel aus IDs.

Java
.NET (C#)

Organisation organisation = sdk.organisation(myDestinationId, keys);

CaseEvent latest = organisation.cases().logOf(submissionForPickup).latest();

List<CaseEvent> log =
    organisation.cases().logOf(submissionForPickup).entries();

IOrganisationClient organisation = client.AsOrganisation();

// Zustand eines noch nicht abgeholten Antrags — ohne zu entschlüsseln
EventState state = await organisation.GetSubmissionState(submission);   // Submission aus der Pickup-Liste

// Ereignisprotokoll eines empfangenen Antrags, geparst
List<CaseEvent> log = await eventLogService.GetSubmissionEventLog(received);

Abgelehnt — und warum?

Ein REJECTED-Event trägt die Problem-Liste des Empfängers. Das SDK lehnt seit 4.0.0-rc.1 nichts mehr von allein ab („Auto-Reject“ gibt es weder in Java noch in .NET); jede Ablehnung ist eine Entscheidung des Fachverfahrens auf Basis des Prüfberichts — siehe Konzept: Der Prüfbericht. Als Onlinedienst lesen Sie die Gründe aus dem letzten Event:

Java
.NET (C#)

CaseEvent latest = onlineService.cases().logOf(sent).latest();
if (latest.state() == EventState.REJECTED) {
    latest.problems().forEach(p -> log.warn("{}: {}", p.getType(), p.getDetail()));
}

List<CaseEvent> log = await eventLogService.GetSubmissionEventLog(sent.SubmissionId, sent.CaseId, myDestinationId);
CaseEvent latest = log.Last();
if (latest.EventType.State == EventState.Rejected)
    foreach (Problem p in latest.Problems ?? [])
        logger.LogWarning("{Type}: {Detail}", p.Type, p.Detail);

Häufige Stolperfallen

Polling-Intervalle: Pollen Sie nicht aggressiver als nötig. 30 Sekunden bis wenige Minuten sind in der Praxis ausreichend.
Submission verschwunden: Akzeptierte oder abgewiesene Submissions werden im Zustelldienst gelöscht. Sie erhalten dann 404-ähnliche Fehler. Persistieren Sie den Endstatus in Ihrem System, sobald er erreicht ist.
Callbacks statt Polling: Wenn Ihre Anwendung öffentlich erreichbar ist, ist Callbacks effizienter als Polling.

Zustandsmodell einer Submission​

Aktuellen Status abfragen (Sender)​

Vollständiges Eventlog abrufen​

Status auf der Empfängerseite​

Abgelehnt — und warum?​

Weiter geht's​

Zustandsmodell einer Submission

Aktuellen Status abfragen (Sender)

Vollständiges Eventlog abrufen

Status auf der Empfängerseite

Abgelehnt — und warum?

Weiter geht's