Vorgänge und Ereignisprotokoll
Ein Antrag (submission) öffnet beim Empfänger einen Vorgang (case). Der Vorgang ist
die Klammer um alles, was zwischen Onlinedienst und Verwaltung zu diesem Anliegen passiert:
weitere Submissions (Nachreichungen), Antworten (reply), und für jede Nachricht ihre
Zustandswechsel. Festgehalten wird das im Ereignisprotokoll des Vorgangs — als Kette von
Events, von denen die fachlich entscheidenden vom Empfänger signiert sind.
Jeder dieser Schritte hinterlässt einen Eintrag im Ereignisprotokoll des Vorgangs — Transport-Events schreibt die Plattform, die fachlichen Entscheidungen (✎) signiert der jeweilige Empfänger:
Der Onlinedienst merkt sich nur die caseId. Mit ihr liest er Status und Antworten; die
Verwaltung antwortet in denselben Vorgang. Events mit ✎ sind vom Empfänger signierte
Security Event Tokens — die Plattform kann sie nicht fälschen, und das SDK prüft die Signatur
beim Lesen.
Die Zustände einer Nachricht
| Zustand | Schreibt | Bedeutung |
|---|---|---|
SUBMITTED | Plattform | Angekommen, noch nicht abgeholt. |
NOTIFIED | Plattform | Der Empfänger wurde per Callback benachrichtigt. |
FORWARDED | Plattform | Der Empfänger hat abgeholt (entschlüsselt), aber noch nicht entschieden. |
ACCEPTED | Empfänger ✎ | Fachlich angenommen. Der Onlinedienst kann „eingegangen“ anzeigen. |
REJECTED | Empfänger ✎ | Abgelehnt — die Problem-Liste im Event sagt, warum. |
DELETED | Plattform | Nach Annahme/Ablehnung oder Ablauf der Löschfrist entfernt. |
INCOMPLETE | Plattform | Angekündigt, aber nicht vollständig eingereicht (Anhänge fehlen). |
Die Plattform ist ein Vermittler, kein Sachbearbeiter. Deshalb schreibt sie nur die Transport-Zustände; ob ein Antrag fachlich in Ordnung ist, kann nur der Empfänger wissen — und nur er kann es mit seinem Signaturschlüssel beglaubigen. So hat der Onlinedienst einen belastbaren Nachweis, dass diese Behörde diesen Antrag angenommen hat.
Eine Nachricht oder der ganze Vorgang?
Zwei Blickwinkel auf dasselbe Protokoll:
- Java
- .NET (C#)
// Das Protokoll einer einzelnen Nachricht (Submission oder Reply) — als TransferLog
TransferLog log = svc.cases().logOf(sent);
EventState status = log.latest().state(); // aktuellster Eintrag
List<CaseEvent> entries = log.entries();
// Der ganze Vorgang — alle Submissions und Replies, beide Richtungen
List<CaseEvent> wholeCase = svc.cases().events(sent.caseId());
logOf(…) ist pro Client für das überladen, was er legitim in der Hand halten kann: ein
OnlineService für gesendete Submissions und wartende Replies, eine Organisation für wartende
Submissions und gesendete Replies. Ein CaseEvent trägt state(), issueTime(), issuer() und
bei Ablehnungen problems().
// Der aktuelle Zustand einer Nachricht
EventState status = await svc.GetSubmissionState(sent); // gesendete Submission
EventState replyStatus = await amt.GetReplyState(sentReply); // gesendete Reply
// Das rohe Protokoll des ganzen Vorgangs — signierte Event-Tokens
CaseEventLogResponse? raw = await svc.Cases.GetCaseEventLog(caseId);
GetSubmissionState(…) nimmt auch eine noch nicht abgeholte Submission aus der Pickup-Liste —
so prüft eine Verwaltung den Zustand, ohne zu entschlüsseln. Die geparsten Einträge (CaseEvent
mit EventType, IssueTime, Issuer, Problems) liefert IEventLogService, das
AddFitConnect() registriert und das Sie neben IFitConnectClient injizieren können.
Nachreichungen und Vorgänge selbst öffnen
Ein zweiter Antrag zum selben Anliegen gehört in denselben Vorgang: Java inCase(caseId), .NET
WithCaseId(caseId). Ohne Angabe entscheidet der Empfänger, ob ein neuer Vorgang entsteht. Für
prozessbasierte Kommunikation (API v3) kann ein Onlinedienst einen Vorgang auch explizit anlegen
(cases().open(…) / Cases.CreateCase(…)) und dann darin senden.
Weiter geht's
- Rezept: Status verfolgen — die Aufrufe im Detail
- Rezept: Callbacks prüfen — benachrichtigt werden statt pollen
- Konzept: Der Prüfbericht — woher die
Problem-Liste imREJECTED-Event kommt