Neu: Prozessbasierte Kommunikation

Mit dem Major Update von FIT-Connect stehen die Submission API und die Destination API in Version 3.0.0 zur Verfügung.

Informationen zu allgemeinen Konzeptänderungen und zum Migrationspfad von Version 2.x.x auf 3.0.0 finden Sie in den Migrationshinweisen zur Version 3. Hingegen dienen die folgenden Abschnitte dazu, Ihnen die (optionalen) neuen Features zur prozessbasierten Kommunikation vorzustellen.

Motivation

Bei einer Verwaltungsleistung folgt auf die initiale Einreichung (in der Regel ist das ein Antrag) ein Verwaltungsprozess. Dieser Prozess kann entweder innerhalb der zuständigen Behörde stattfinden oder auch andere Behörden sowie Unternehmen einbeziehen.

Wenn man den Digitalisierungsprozess bis zum Ende denkt, muss auch jegliche nachgelagerte Kommunikation berücksichtigt werden. Beispiele dafür sind das Einholen einer Zustimmung von einer (übergeordneten) Behörde, die Abfrage von Auskünften oder das Einholen einer Stellungnahme. Daher ist die Digitalisierung mit der Erfüllung des OZG alleine noch nicht vollständig.

FIT-Connect möchte im Vorgriff auf die zu erwartende Ende-Zu-Ende-Digitalisierung bereits heute das Angebot für die Nutzung als Basisinfrastruktur dahingehend erweitern. Das erklärte Ziel ist, "vor die Welle" zu kommen und damit den Aufwand für alle Beteiligten zu verringern.

Im Detail verfolgt FIT-Connect dabei folgende Ziele:

• Digitalisierung von den gesetzlichen Vorgaben bis hin zum ausführbaren Prozess durchdenken
• Bedürfnisse der Bürger:innen und Unternehmen in den Fokus nehmen
• Alle Akteure, direkt oder mittelbar, verbinden
• Standardisierte Prozesse einfach nachnutzbar machen
• Intuitive Prozessmodifikation und Bereitstellung ermöglichen
• Modularer Prozessaufbau und flexible Adaptierbarkeit unterstützen
• Extrem leichte Anbindung und einheitliche Rollen und Abläufe ermöglichen
• Security First gewährleisten – sowohl für den Datentransfer als auch für die Prozesssteuerung

Der Kern dieses Updates ist es daher, komplexere Prozesse mit mehr als zwei Beteiligten besser zu unterstützen. Fachlich unterstützt FIT-Connect damit nun Folgendes:

• Neben dem von Bürgern oder Unternehmen genutzten Onlinedienst und der verfahrensführenden Behörde können nun eine beliebige Anzahl weiterer Behörden innerhalb eines Vorgangs kommunizieren, sowohl untereinander als auch mit dem Onlinedienst.
• Die Integration von Unternehmen ist bereits technisch umgesetzt, aber noch nicht freigeschaltet.
• Innerhalb eines Vorgangs ist es möglich, Submissions nicht nur per Leistungsschlüssel zu adressieren, sondern alternativ auch per Prozessnachricht. Dies ermöglicht es Behörden, sich auf einen zuvor vereinbarten Prozessstandard (der zum Beispiel via BPMN abgelegt sein kann, aber nicht muss) beim Versand von Nachrichten zu beziehen.

Grundlegendes Konzept

Der Versand von Submissions oder Replies erfolgt nun immer von einer Destination zu einer anderen Destination. Dies ist nötig, um die Prozessteilnehmer besser zu identifizieren. Die verwendeten Clients dienen nur dazu, den Zugang zu diesen Destinations zu ermöglichen, spielen darüber hinaus aber keine Rolle.

Im Rahmen dieses Updates wurden zwei Typen von Destinations eingeführt und eine dritte Destination vorbereitet:

• Typ A (Verwaltungs-Zustellpunkt): raditionelle Zustellpunkte öffentlicher Verwaltungsbehörden, die neben Verwaltungsleistungen jetzt auch Prozessnachrichten unterstützen und, wie gehabt, V-PKI-Zertifikate erfordern. Alle bisherigen Zustellpunkte sind also jetzt vom Typ A.
• Typ C (Onlinedienst-Zustellpunkt): Zustellpunkte für Onlinedienste, ohne Zertifikat. Diese können weder Verwaltungsleistungen noch Prozessnachrichten spezifizieren und sind nur über Replies adressierbar. Nur eine C-Destination kann an einem Vorgang (case) teilnehmen und repräsentiert den Bürger.

Geplant: Typ B – Wirtschafts-Zustellpunkt

Der neue Typ B ist für Unternehmen vorgesehen. Er verwendet ausschließlich Prozessreferenzen, jedoch keine Verwaltungsleistungen. Typ B ist noch nicht verfügbar.

Neue Features im Detail

Erweiterungen des Destination-Schemas

An einer Destination können nun (ob programmatisch per Destination-API V3 oder per Self-Service-Portal) neben Verwaltungsleistungen (publicServices) auch Prozessnachrichten (Process Messages) angegeben werden, die diese Destination empfangen kann und möchte. Es ist also möglich, eine Destination ohne Verwaltungsleistungen zu konfigurieren oder ihr zusätzlich Prozessnachrichten zuzuordnen.

Destinations können anhand dieser Nachrichten gefunden werden (siehe unten). Statt an Verwaltungsleistungen können Submissions auch an Prozessnachrichten adressiert werden. FIT-Connect validiert bei einem solchen Versand, ob die jeweilige Ziel-Destination die Prozessnachricht unterstützt. Die Art und Weise, wie Sie mit diesen Datenfeldern umgehen und wie Sie Ihre Prozesse modellieren, pflegen und ausführen, können Sie frei gestalten. FIT-Connect gibt hierzu keine Vorgaben.

Das Destination-Schema erhält ein Feld processMessages (mit processModelId, messageId, regions, schemas) mit einer optionalen Liste der von der Destination unterstützten Prozessnachrichten. Diese steht in allen Lese- und Schreib-Endpunkten zur Verfügung. Das Konzept geht davon aus, dass sich die eindeutige ID einer Prozessnachricht aus der eindeutigen ID des Prozessmodells und der innerhalb des Prozessmodells eindeutigen ID der Nachricht ergibt. In BPMN wäre ein MessageFlow die Entsprechung einer Prozessnachricht.

Mehrere Teilnehmer an einem Case

Cases werden nach wie vor an eine A-Destination adressiert. Dazu muss (ob explizit oder implizit) eine Verwaltungsleistung angegeben werden. Ein Vorgang kann mit der API-Version 3 auch mehrere Teilnehmer haben. Dies ist möglich, wenn einer der beiden initialen Teilnehmer eine Submission an eine dritte Destination sendet und dabei die bestehende caseId referenziert wird. Damit wird der dritte Teilnehmer aufgenommen und dazu berechtigt, an die anderen beiden Destinations zu senden.

Jede Kommunikation erfolgt weiterhin nur bilateral. Auch können stets nur solche Events unter GET /v3/cases/{caseId}/events abgefragt werden, die mit den eigenen Destinations in Verbindung stehen.

Neuer Endpunkt POST /v3/cases

Ein neuer Endpunkt POST /v3/cases ermöglicht es, einen Vorgang explizit anzulegen, ohne gleichzeitig eine Einreichung zu erstellen. Voraussetzung ist die Adressierung an eine gültige A-Destination mit passender Verwaltungsleistung, um so den Bezug des Vorgangs zu einer Verwaltungsleistung zu gewährleisten. Es ist damit möglich, dass ein Onlinedienst einen Vorgang bei einer Verwaltungsbehörde anlegt, aber im Zusammenhang mit dieser soll zunächst eine andere Behörde die Einreichung bearbeiten.

Prozessbasierter Nachrichtenversand

Submissions

Submissions können in Version 3 optional ein processMessage-Objekt (bestehend aus processModelId und messageId) enthalten, um einen Prozessbezug herzustellen. Diese Einreichungsart setzt voraus, dass die Ziel-Destination die entsprechende Prozessnachricht in ihrem processMessages-Feld konfiguriert hat. Auch in Antworten (Replies) kann eine processMessage angegeben werden. Replies können dabei weiterhin nur an Destinations vom Typ C gesendet werden.

Das Feld caseId auf der Wurzelebene des POST /v3/submissions-Requests wurde entfernt und durch ein case-Objekt ersetzt. Zur Referenzierung eines bestehenden Vorgangs wird case.caseId verwendet.

Zur gleichzeitigen Eröffnung eines neuen Vorgangs können case.destinationId und case.publicService angegeben werden — dies ist jedoch ausschließlich in Kombination mit einer processMessage auf Wurzelebene erlaubt, nicht mit einem publicService auf Wurzelebene.

Verweis auf bestehenden Vorgang

{
  "case": {
    "caseId": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
  }
}

Eröffnung eines neuen Vorgangs (nur mit processMessage)

{
  "processMessage": { "processModelId": "...", "messageId": "..." },
  "case": {
    "destinationId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "publicService": {
      "identifier": "urn:de:fim:leika:leistung:99108034179000"
    }
  }
}

Replies

Mit Version 3 können Replies nun ebenfalls Prozessnachrichten referenzieren. Darüber hinaus kann im Rückkanal-Datensatz in den Metadaten spezifiziert werden, welche Prozessantworten die C-Destination empfangen kann, die eine Submission versendet.

Routing

Bisher gab es zwei Möglichkeiten, den Ziel-Zustellpunkt für das Senden eine Submission festzulegen:

• Eine beim Sender (Onlinedienst) fest konfigurierte DestinationID
• Die Ermittlung des Zustellpunktes anhand von Leistungsschlüssel und Region über den Routingdienst

In Abhängigkeit der fachlichen Rahmenbedingungen stehen nun weitere Möglichkeiten zur Verfügung, die genutzt werden können:

Neuer Such-Endpunkt

In der Submission API v3 steht ein neuer, öffentlich zugänglicher Such-Endpunkt zur Verfügung, der keine Authentifizierung erfordert:

• GET /v3/search-destinations/by-process-message: Suche von Zustellpunkten anhand von processModelId, messageId und Region. Dieser Endpunkt dient dazu, prozessbasierte Workflows zu ermöglichen.

Absender-Destination

In Version 3 der Submission-API besitzt jede Submission nun eine Absender-Destination. Der Empfänger kann diese persistieren und für die Adressierung von Submissions oder Replies verwenden, die er zu einem späteren Zeitpunkt im Prozess an diesen Teilnehmer senden muss.

Dataset process

In diesem Datensatz kann ein Sender dem Empfänger Informationen über Zustellpunkte und deren Verwendung als Adressat zukünftiger im Rahmen des Vorgangs zu sendender Prozessnachrichten mitteilen.

Beispiel

Der folgende Beispielprozess dient alleine der Veranschaulichung. Er hat keinen Bezug zu einem realen Verwaltungsprozess einer realen Verwaltungsleistung.

Senden und Empfangen der Prozessnachrichten (MessageFlows)

Für das Senden muss zuvor der Ziel-Zustellpunkt festgelegt werden. Je nach dem fachlichen Kontext gibt es dafür folgende Optionen:

• Eine fest konfigurierte ID eines Zustellpunktes, z. B. wenn es für eine Instanz bzw. einen Mandanten eines Fachverfahrens in jedem Fall nur eine Möglichkeit gibt
• Eine in den Metadaten einer zuvor zu diesem Vorgang empfangenen Prozessnachricht enthaltene Zustellpunkt-ID - im Dataset reply-channel oder im Dataset process
• Die ID des Absender-Zustellpunktes einer zuvor zu diesem Vorgang empfangenen Prozessnachricht
• Ein über den Routingdienst anhand von Leistung und Region ermittelter Zustellpunkt
• Ein über den neuen Suchendpunkt anhand von processModelId, messageId und Region ermittelter Zustellpunkt

Der Empfänger einer Prozessnachricht muss also in der Regel zum Vorgang (Case - caseId) der Nachricht die ID des Absender-Zustellpunktes und die ggf. in den Metadaten enthaltenen routing-relevanten Informationen persistieren, um diese beim Senden einer Prozessnachricht zum selben Vorgang verwenden zu können. Die caseId muss in jedem Fall gespeichert werden, da nur sie die Zuordnung später empfangener Prozessnachrichten zu dem Vorgang bzw. zur eigenen Prozessinstanz ermöglicht.

1 Anzeige

Die erste Nachricht, die zu einem Vorgang gesendet wird. Der Sender, hier ein Onlinedienst, ermittelt den Zustellpunkt der zuständigen Behörde. Einmal anhand von Leistung und Region über die klassische Routing-API, um für die Erstellung des Vorgangs (case) den Bezug zu einer Verwaltungsleistung herzustellen. Und einmal anhand von ProzessmodelID und MessageID über den neuen Suchendpunkt. Der Zustellpunkt der unteren Behörde muss also sowohl die Leistung als auch die Prozessnachricht unterstützen. Er sendet im Dataset reply-channel die Informationen zu:

• 2 Nachforderung zur Nachreichung
• 8 Empfangsbestätigung
• 4 Rückmeldung

2 Nachforderung zur Nachreichung

Der Sender hat zuvor "1 Anzeige" oder "3 Nachreichung" erhalten. Dabei wurde im Dataset reply-channel übermittelt, wie die Adressierung für "2 Nachforderung zur Nachreichung" erfolgt. Dort sind ebenfalls die Schlüssel für die Verschlüsselung der Nachricht enthalten. Da es sich beim Empfänger um einen Onlinedienst mit einer C-Destination handelt, wird hier keine Submission, sondern ein Reply gesendet.

3 Nachreichung

Der Sender kann den Absender-Zustellpunkt der zuvor empfangenen Nachricht "2 Nachforderung zur Nachreichung" für die Adressierung verwenden. Er sendet im Dataset reply-channel die Informationen zu:

• 2 Nachforderung zur Nachreichung
• 8 Empfangsbestätigung
• 4 Rückmeldung

4 Rückmeldung

Der Sender hat zuvor "1 Anzeige" oder "3 Nachreichung" erhalten. Dabei wurde im reply-channel-Dataset übermittelt, wie die Adressierung erfolgt. Dort sind ebenfalls die Schlüssel für die Verschlüsselung der Nachricht enthalten. Da es sich beim Empfänger um einen Onlinedienst mit einer C-Destination handelt, wird hier keine Submission, sondern ein Reply gesendet. Wenn der Zustellpunkt der "Fachbehörde" für den Onlinedienst zum Senden von "6 Einwendungen" nicht eindeutig per Such-Abfrage anhand von processModelId, messageId ermittelbar ist, schickt der Sender im Dataset process die nötigen Informationen mit.

5 Weitergeleitete Anzeige

Sofern es für den Sender nicht nur eine Möglichkeit gibt und deswegen die ID eines Ziel-Zustellpunktes fest konfiguriert wurde, ermittelt er den Empfänger anhand von processModelId, messageId und Region über den Suchendpunkt. Dies ist die erste Prozessnachricht, die die "Fachbehörde" erhält. Dadurch, dass das "Ordnungsamt" diese Nachricht an den Zustellpunkt der "Fachbehörde" sendet, wird dieser Zustellpunkt am Vorgang (case) beteiligt und somit dazu berechtigt, selbst weitere Prozessnachrichten zu diesem Vorgang zu senden.

6 Einwendungen

Der Sender verwendet den Suchendpunkt, um den Zustellpunkt des Empfängers zu ermitteln, sofern dieser eindeutig zu ermitteln ist. Ansonsten hat er zusammen mit "4 Rückmeldung" im Dataset process die nötigen Informationen erhalten. Er sendet im Dataset reply-channel die Informationen zu:

• 7 Rückmeldung zu Einwendungen

7 Rückmeldung zu Einwendungen

Der Sender kann den Absender-Zustellpunkt der zuvor empfangenen Nachricht "6 Einwendungen" für die Adressierung verwenden. Den Schlüssel entnimmt er dem mit "6 Einwendungen" erhaltenen Dataset reply-channel. Da es sich beim Empfänger um einen Onlinedienst mit einer C-Destination handelt, wird hier keine Submission, sondern ein Reply gesendet.

8 Empfangsbestätigung

Der Sender hat zuvor "1 Anzeige" oder "3 Nachreichung" erhalten. Dabei wurde im Dataset reply-channel übermittelt, wie die Adressierung erfolgt. Dort sind ebenfalls die Schlüssel für die Verschlüsselung der Nachricht enthalten. Da es sich beim Empfänger um einen Onlinedienst mit einer C-Destination handelt, wird hier keine Submission, sondern ein Reply gesendet.

9 Zustimmung

Der Sender kann den Absender-Zustellpunkt der zuvor empfangenen Nachricht "5 Weitergeleitete Anzeige" für die Adressierung verwenden.

10 Untersagung

Der Sender kann den Absender-Zustellpunkt der zuvor empfangenen Nachricht "5 Weitergeleitete Anzeige" für die Adressierung verwenden.

Alternative: Unternehmenssoftware statt Onlinedienst

Ein Onlinedienst wird von vielen natürlichen und/oder juristischen Personen genutzt. Um eine Ende-zu-Ende-Verschlüsselung für jeden einzelnen Nutzer zu gewährleisten, wird mit der C-Destination eine vorgangs- oder nutzerspezifische Verschlüsselung verwendet. Prozessnachrichten an den Onlinedienst werden daher als Antwort (Reply) gesendet.

Ein Antrag könnte jedoch auch direkt aus der Software eines spezifischen Unternehmens gesendet werden. Da diese Software ausschließlich von einer juristischen Person genutzt wird, kann sie eine B-Destination mit dem in der Destination hinterlegten Schlüssel verwenden. Prozessnachrichten an eine B-Destination werden als Einreichung (Submission) gesendet.

Videodemonstration

Unser Tipp

Das folgende Video zeigt Ihnen eine Demonstration mit drei verschiedenen Fachverfahren, die jeweils unterschiedliche Prozess-Engines verwenden:

Video:   Prozessunterstützung mit FIT-Connect