Rollenmodell und vier Regeln
Wer die vier Regeln kennt, versteht jede Methode im SDK — und jede Fehlermeldung. Sie gelten für das Protokoll selbst, nicht nur für ein SDK; Java und .NET setzen sie nur in unterschiedlicher Syntax um.
Eine UUID plus Typ: A Verwaltung, B Unternehmen, C Onlinedienst. Der Typ ist bei der Anlage im Self-Service-Portal fest.
Und zwar nur an A oder B. Senden darf jede Partei — auch eine Verwaltung an eine andere Verwaltung.
Nie an einen Zustellpunkt. Antworten (reply) laufen immer A/B → C, in den
Case, den der Antrag geöffnet hat.
Nie, was man senden darf. Senden braucht kein Schlüsselmaterial — Empfangen braucht den Entschlüsselungsschlüssel des Zustellpunkts, Antworten lesen braucht den Rückkanalschlüssel des Vorgangs.
Was das für Ihren Code bedeutet
| Typ A/B · Verwaltung | Typ C · Onlinedienst | |
|---|---|---|
| Erzeugen (Java) | sdk.organisation(id, keys) | sdk.onlineService(id, replyKeys) |
| Erzeugen (.NET) | client.AsOrganisation() | client.AsOnlineService() |
| Anträge senden | ja | ja, auch vorverschlüsselt |
| Anträge empfangen | ja — mit Entschlüsselungsschlüssel | nein (Regel 2) |
| Antworten senden | ja, in Vorgänge eines Onlinedienstes | nein (Regel 3) |
| Antworten empfangen | nein (Regel 3) — kein Bug | ja — mit Rückkanalschlüssel |
Die Rollen sind zwei getrennte Typen, damit der Compiler verhindert, was das Protokoll ohnehin
verbietet. Ein OnlineService hat schlicht keine Methode, um Anträge zu empfangen — Sie können
den Fehler nicht machen. Das .NET-SDK prüft beim Host-Start zusätzlich, ob Ihre DestinationId
zum gewählten Rollen-Client passt (Client.VerifyDestinationOnStartup), und meldet einen
Rollentausch als FitConnectConfigurationException, bevor der erste Antrag unterwegs ist.
- Java
- .NET (C#)
// Typ C — Onlinedienst: sendet Anträge, liest Antworten
OnlineService svc = sdk.onlineService(MY_ONLINE_SERVICE_ID, vault::find);
// Typ A/B — Verwaltung/Unternehmen: empfängt Anträge, antwortet
Organisation amt = sdk.organisation(MY_DESTINATION_ID, keys);
// Ohne Authentifizierung: Empfänger und Schlüssel nachschlagen
Directory dir = sdk.directory();
// Zustellpunkte und Anhangspeicher verwalten (Scope manage-destinations)
Management mgmt = sdk.manage();
Beide Rollen-Accessoren haben eine Überladung ohne Schlüssel (organisation(id),
onlineService(id)) — sie senden weiterhin korrekt, und ihre Empfangsmethoden melden den
fehlenden Schlüssel statt zu scheitern.
// Typ C — Onlinedienst: sendet Anträge, liest Antworten
IOnlineServiceClient svc = client.AsOnlineService();
// Typ A/B — Verwaltung/Unternehmen: empfängt Anträge, antwortet
IOrganisationClient amt = client.AsOrganisation();
// Ohne Authentifizierung: Empfänger und Schlüssel nachschlagen
IDirectoryService dir = client.Directory;
Die eigene DestinationId und das Schlüsselmaterial stehen in der Konfiguration
(FitConnect.Client), nicht am Aufruf — der Container hält pro Anwendung genau einen
IFitConnectClient.
Vorgänge, Anträge, Antworten
Ein Antrag (submission) öffnet beim Empfänger einen Vorgang (case). Alles, was danach
passiert — Abholung, Annahme, Ablehnung, Antworten (reply) — hängt an diesem Vorgang und wird
im Ereignisprotokoll als signiertes Event festgehalten. Der Onlinedienst braucht sich nur eine
caseId zu merken; damit liest er Status und Antworten. Wie das im Detail funktioniert, zeigt
Vorgänge und Ereignisprotokoll.
Wo die Regeln zuschlagen
| Sie sehen … | Regel | Was dahintersteckt |
|---|---|---|
OnlineService hat kein awaitingSubmissions() / IOnlineServiceClient kein FetchSubmission | 2 | Ein Onlinedienst empfängt keine Anträge. |
Organisation hat kein awaitingReplies() / IOrganisationClient kein FetchAvailableReplies | 3 | Antworten gehen nur in Vorgänge eines Onlinedienstes. |
FitConnectReplyException beim Antworten | 3 | Der Antrag hat keinen FIT-Connect-Rückkanal mitgebracht — es gibt keinen Schlüssel, für den Sie verschlüsseln könnten. |
sdk.organisation(id) ohne Schlüssel sendet trotzdem | 4 | Senden braucht nur den öffentlichen Schlüssel des Empfängers, den das SDK selbst holt. |
FitConnectConfigurationException: … is a type C online service — call AsOnlineService() | 1 | Der Typ ist fest; das .NET-SDK hat ihn beim Start nachgeschlagen. |
Weiter geht's
- Der Weg eines Antrags — die sechs Stationen auf einen Blick
- Rezept: Einrichten — Rolle wählen und Client erzeugen
- Schlüssel und Rollover — Regel 4 in der Praxis