Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • fit-connect/docs
1 result
Show changes
Commits on Source (25)
Showing
with 236 additions and 85 deletions
......@@ -2,6 +2,24 @@
Das Format dieser Datei basiert auf [Keep a Changelog](https://keepachangelog.com/de).
## 2021-12-14
### API Spezifikation 1.0.5
- Der Content-Type für das Senden von Events wurde korrigiert.
## 2021-12-10
### Self Service Portal 1.2.2
- Bugfixes für: Statusmodell einer Destination
([Story](https://git.fitko.de/fit-connect/planning/-/issues/18))
### Zustelldienst 1.1.1
- Bugfixes für: Statusmodell einer Destination
([Story](https://git.fitko.de/fit-connect/planning/-/issues/18))
- Callback-Aufrufe können nun über einen Proxy geleitet werden.
([Story](https://git.fitko.de/fit-connect/planning/-/issues/298))
- API-Version in `1.0.4` geändert.
## 2021-12-02
### Self Service Portal 1.2.1
......
......@@ -44,7 +44,7 @@ Ein sicheres *Callback-Secret* kann über die folgenden Aufrufe erzeugt werden:
- Ruby: `ruby -rsecurerandom -e 'puts SecureRandom.hex(32)'`
- pwgen: `pwgen --secure 64 1`
Die Einrichtung von Callbacks im Self-Service-Portal wird im Artikel `TODO: Link einfügen` näher beschrieben.
Die Einrichtung von Callbacks im Self-Service-Portal wird im Artikel [Zustellpunkt anlegen](../receiving/destination.mdx) näher beschrieben.
### Konfiguration von Callbacks für Zustellpunkte
Über die API können Callbacks für Zustellpunkte wie folgt konfiguriert werden:
......@@ -58,7 +58,7 @@ Die Einrichtung von Callbacks im Self-Service-Portal wird im Artikel `TODO: Link
<TabItem value="curl">
```bash
$ SERVICE_URL=...
$ SUBMISSION_API=https://submission-api-testing.fit-connect.fitko.dev
$ JWT_TOKEN=...
$ DESTINATION_ID=...
$ CALLBACK_URL=https://fachverfahren.beispielstadt.example.org/callbacks/fit-connect
......@@ -67,7 +67,7 @@ $ curl -X PATCH \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $JWT_TOKEN" \
--data "{ \"callback\": { \"url\": \"$CALLBACK_URL\", \"secret\": \"$CALLBACK_SECRET\" }}" \
"$SERVICE_URL/v1/destinations/$DESTINATION_ID"
"$SUBMISSION_API/v1/destinations/$DESTINATION_ID"
```
</TabItem>
......
......@@ -35,7 +35,7 @@ Die Details sind der API-Spec zu entnehmen.
#### Aktualisierung des Verschlüsselungsschlüssels eines Zustellpunktes
```shell
$ SERVICE_URL=...
$ SUBMISSION_API=https://submission-api-testing.fit-connect.fitko.dev
$ JWT_TOKEN=...
$ DESTINATION_ID=...
......@@ -44,14 +44,14 @@ $ curl -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $JWT_TOKEN" \
--data '{"kty": "RSA", "kid": "new-encryption-key", "alg": "RSA-OAEP-256", "key_ops": ["wrapKey"], "x5c": ["..."], "e": "AQAB", "n": "..."}' \
"$SERVICE_URL/v1/destinations/$DESTINATION_ID/keys"
"$SUBMISSION_API/v1/destinations/$DESTINATION_ID/keys"
# Setzen der Schlüssel-ID als Verschlüsselungsschlüssel
$ curl -X PATCH \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $JWT_TOKEN" \
--data '{"encryptionKid": "new-encryption-key"}' \
"$SERVICE_URL/v1/destinations/$DESTINATION_ID"
"$SUBMISSION_API/v1/destinations/$DESTINATION_ID"
```
</TabItem>
......@@ -74,10 +74,29 @@ $ curl -X PATCH \
| --- | --- |
| created | Die Destination wurde erzeugt. Sie kann vorbereitet werden und sollte erst bei fertig aufgesetzter Fachanwendung in den Status `active` wechseln. |
| active | Die Destination ist ab jetzt aktiv und kann Anträge annehmen. |
| inactive | Wenn die Destination in den Status `inactive` versetzt wird, können keine neuen Anträge mehr angelegt werden. Alle anderen Optionen bleiben möglich. Sie kann wieder in den Status `active` versetzt werden. |
| decommissioned | Wenn eine Destination in den Status `decommissioned` versetzt wird, ist weder das Anlegen von Anträgen möglich, noch ist es möglich, neue Antworten zu versenden. Status-Updates können allerdings noch gesetzt werden. |
| inactive | Wenn die Destination in den Status `inactive` versetzt wird, können keine neuen Anträge mehr angelegt werden. Alle anderen Optionen bleiben möglich. Eine inaktive Destination kann jederzeit wieder in den Status `active` versetzt werden. Nach einer Wartefrist von 30 Tagen kann die Destination in den Status `decommissioned` versetzt werden. |
| decommissioned | Wenn eine Destination in den Status `decommissioned` versetzt wird, ist weder das Anlegen von Anträgen möglich, noch ist es möglich, neue Antworten zu versenden. Status-Updates können allerdings noch gesetzt werden. Eine Destination im Status `decommissioned` kann nicht wieder aktiviert werden. |
| (gelöscht) | Eine Destination kann im Status `created` manuell gelöscht werden. Nach zwei Jahren im Zustand `decommissioned` wird sie automatisiert gelöscht. |
### Wartefrist vor dem Wechsel von `inactive` zu `decommissioned` {#grace-period}
Wird ein Zustellpunkt in den Status `decommissioned` versetzt, so kann er nicht mehr reaktiviert werden.
Daher wurde eine Wartefrist von 30 Tagen im Status `inactive` vorgesehen.
Erst nach Ablauf dieser Zeit kann er in den Status `decommissioned` versetzt werden.
Sofern Sie den Statuswechsel zu früh versuchen, erhalten Sie über das Self-Service-Portal folgende Fehlermeldung:
![Fehlermeldung Statuswechsel](/images/status/error_destination-state-invalid.png)
Über die Submission API erhalten Sie folgende Meldung.
```json
{
"type": "https://schema.fitko.de/fit-connect/submission-api/problems/destination-state-invalid",
"title": "Destination State invalid",
"status": 422,
"detail": "Destination df7fb66a-8c25-45a7-8325-793e42822eac has the wrong state for this operation."
}
```
### Status des Zustellpunkts ändern
Der Status kann über den Endpunkt <ApiLink api="submission-api" to="/v1/destinations/{destinationId}" withMethod="patch" /> aktualisiert werden.
......@@ -95,7 +114,7 @@ Der Status kann über den Endpunkt <ApiLink api="submission-api" to="/v1/destina
#### Aktualisierung des Verschlüsselungsschlüssels eines Zustellpunktes
```shell
$ SERVICE_URL=...
$ SUBMISSION_API=https://submission-api-testing.fit-connect.fitko.dev
$ JWT_TOKEN=...
$ DESTINATION_ID=...
......@@ -104,7 +123,7 @@ $ curl -X PATCH \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $JWT_TOKEN" \
--data '{"status": "active"}' \
"$SERVICE_URL/v1/destinations/$DESTINATION_ID"
"$SUBMISSION_API/v1/destinations/$DESTINATION_ID"
```
</TabItem>
......
......@@ -28,9 +28,9 @@ Der hier beschriebene Payload des Access Tokens dient lediglich der Dokumentatio
```json
{
"sub": "lxnsidjbdd6bk",
"aud": "https://api.zustelldienst-01.example.com",
"aud": "https://submission-api-testing.fit-connect.fitko.dev",
"scope": "send:region:DE01010 send:region:DE010109990",
"iss": "https://auth.fitko.de",
"iss": "https://auth-testing.fit-connect.fitko.dev",
"exp": 1627044703,
"iat": 1627042903,
"jti": "bU9uS7fTLbQ",
......
......@@ -31,8 +31,8 @@ Token für empfangende Systeme wird beim Zugriff auf die Submission API im `Auth
**Beispiel**
```http
POST /applications HTTP/1.1
Host: api.zustelldienst-01.example.com
POST /v1/submissions HTTP/1.1
Host: submission-api-testing.fit-connect.fitko.dev
Authorization: Bearer ey...
```
......@@ -78,9 +78,9 @@ folgenden [standardisierten Felder](https://www.iana.org/assignments/jwt/jwt.xht
```json
{
"sub": "epie1quee7eeR",
"aud": "https://api.zustelldienst-01.example.com",
"aud": "https://submission-api-testing.fit-connect.fitko.dev",
"scope": "subscribe:destination:36141427-d405-40a4-8f8b-3592d544e85b manage:destination:36141427-d405-40a4-8f8b-3592d544e85b",
"iss": "https://auth.fitko.de",
"iss": "https://auth-testing.fit-connect.fitko.dev",
"exp": 1627045703,
"iat": 1627043903,
"jti": "aeveeSa3ohl",
......
......@@ -59,13 +59,13 @@ Wenn keine spezifischer Scope angefragt wird (siehe nächster Abschnitt), enthä
<TabItem value="curl">
```bash
$ export OAUTH_URL=<URL>
$ export OAUTH_URL=https://auth-testing.fit-connect.fitko.dev/token
$ export CLIENT_ID=<client_id>
$ export CLIENT_SECRET=<client_secret>
$ curl \
-H "Content-Type: application/x-www-form-urlencoded" \
--data "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET" \
-X POST $OAUTH_URL
-X POST "$OAUTH_URL"
{
"access_token": "eyJraWQi...",
"expires_in": 1800,
......@@ -84,13 +84,13 @@ Hier im Beispiel hat der angelegte OAuth Client weitreichende Berechtigungen: `s
Wir beschränken allerdings diesen konkreten Access Token auf `send:region:DE01010`.
```bash
$ export OAUTH_URL=<URL>
$ export OAUTH_URL=https://auth-testing.fit-connect.fitko.dev/token
$ export CLIENT_ID=<client_id>
$ export CLIENT_SECRET=<client_secret>
$ curl \
-H "Content-Type: application/x-www-form-urlencoded" \
--data "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&scope=send:region:DE01010" \
-X POST $OAUTH_URL
-X POST "$OAUTH_URL"
{
"access_token": "eyJraWQi...",
"expires_in": 1800,
......@@ -109,14 +109,14 @@ Weiterführende Details zu den Scopes finden sich hier:
## Zugriff auf die API mittels Access Token
Access Tokens werden vom OAuth-Dienst erzeugt und DÜRFEN NIEMALS an dritte Systeme (mit Außnahme des Zustelldienstes zum Zwecke der Authentifizierung) weitergegeben werden.
Access Tokens werden vom OAuth-Dienst erzeugt und DÜRFEN NIEMALS an dritte Systeme (mit Ausnahme des Zustelldienstes zum Zwecke der Authentifizierung) weitergegeben werden.
Beim Zugriff auf die Submission API wird muss ein Access Token im `Authorization`-Header mit `Bearer`-Authentifizierungsschema gemäß [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750) an den Zustelldienst übermittelt werden:
**Beispiel**
```http
POST /applications HTTP/1.1
Host: api.zustelldienst-01.example.com
POST /v1/submissions HTTP/1.1
Host: submission-api-testing.fit-connect.fitko.dev
Authorization: Bearer ey...
```
......
......@@ -196,10 +196,10 @@ Dann kann man mit diesem und einer entsprechenden Bibliothek eine Signaturprüfu
Im folgenden Beispiel wird die Bibliothek [nimbus-jose-jwt](https://connect2id.com/products/nimbus-jose-jwt) für die Prüfung genutzt.
```java
static final ZUSTELLDIENST_BASE_URL = "https://zustelldienst.example.com";
static final SUBMISSION_API = "https://submission-api-testing.fit-connect.fitko.dev";
boolean verifyZustelldienstSignature(SignedJWT securityEventToken, String keyId) {
JWKSet jwks = JWKSet.load(ZUSTELLDIENST_BASE_URL + "/.well-known/jwks.json");
JWKSet jwks = JWKSet.load(SUBMISSION_API + "/.well-known/jwks.json");
JWK publicKey = jwks.getKeyByKeyId(keyId)
if (publicKey.getAlgorithm() != JWSAlgorithm.PS512) {
......@@ -252,7 +252,7 @@ Mit der `submissionId` kann über den Endpunkt <ApiLink api="submission-api" to=
Hier ist das konkret der Wert `92f2f581-c89d-44a5-b834-1fe3f6fa48d5`.
```http title="Abfrage der destinationId einer Submission"
GET /submissions/F65FEAB2-4883-4DFF-85FB-169448545D9F
GET /v1/submissions/F65FEAB2-4883-4DFF-85FB-169448545D9F
{
"destinationId": "92f2f581-c89d-44a5-b834-1fe3f6fa48d5",
// ...
......@@ -263,10 +263,10 @@ Mit den zwei Informationen `kid` und `destinationid` kann nun der JWK zur Signat
```shell title="Beispiel: Abruf des JWK eines Zustellpunktes"
$ KID=...
$ SERVICE_URL=...
$ SUBMISSION_API=https://submission-api-testing.fit-connect.fitko.dev
$ DESTINATION_ID=...
$ curl -X GET \
"$SERVICE_URL/v1/destinations/$DESTINATION_ID/keys/$KID"
"$SUBMISSION_API/v1/destinations/$DESTINATION_ID/keys/$KID"
---
{
"kty": "RSA",
......@@ -299,4 +299,3 @@ boolean verifyClientSignature(SignedJWT securityEventToken, String keyId) {
return securityEventToken.verify(jwsVerifier);
}
```
......@@ -20,3 +20,4 @@ Für Anbindungstests in der Testumgebung können Sie die folgenden Links & Infos
- Self-Service-Portal der Testumgebung: siehe [Accountregistrierung und Client-Verwaltung](./account.mdx)
- OAuth Token URL: `https://auth-testing.fit-connect.fitko.dev/token`
- Submission API: `https://submission-api-testing.fit-connect.fitko.dev`
- Routing API: `https://routing-api-testing.fit-connect.fitko.dev`
......@@ -39,5 +39,5 @@ hide_table_of_contents: true
| Zuständige Fachbehörde | Die für die Bearbeitung der Einreichung zuständige Stelle. Die zuständige Fachbehörde betreibt zum Empfang von Einreichungen ein empfangendes System. |
| Zustellberechtigungs-Scope | Beschreibt die Scopes aus den OAuth-Tokens (JWT), die im Zustelldienst dazu dienen, um zu überprüfen, ob ein Onlinedienst Einreichungen bei einer Destination vornehmen darf. |
| Zustelldienst | Zentrale Komponente der FIT-Connect-Infrastruktur. Der Zustelldienst implementiert die Submission API und ermöglicht die Übermittlung und den Abruf von Einreichungen von sendenden Systemen an empfangende Systeme. |
| Zustellpunkt (Destination) | Technisch eindeutig adressierbarer Endpunkt zur Einreichung von Anträgen oder Berichten an die Verwaltung über die FIT-Connect Übermittlungsinfrastruktur. Ein Zustellpunkt repräsentiert typischerweise ein konkretes empfangendes System (Fachverfahren oder virtuelle Poststelle). Für ein empfangendes System können jedoch multiple Zustellpunkte angelegt werden. In der Konfiguration eines Zustellpunkts sind interne und öffentliche Teile hinterlegt. Interne Angaben sind solche, die zu Administrationszwecken dienen. Öffentliche Angaben legen z.B. fest, in welcher Form der Empfänger Einreichungen akzeptiert. Zustellpunkte werden über die sogenannte Destination-ID eindeutig identifiziert. Weitere Informationen finden sich in den Artikeln [Zustellpunkt anlegen](receiving/destination.mdx) und [Zustellpunkt ermitteln](responsibilities/get-destination.mdx). |
| Zustellpunkt (Destination) | Technisch eindeutig adressierbarer Endpunkt zur Einreichung von Anträgen oder Berichten an die Verwaltung über die FIT-Connect Übermittlungsinfrastruktur. Ein Zustellpunkt beschreibt die Konfiguration eines konkreten empfangenden Systems (Fachverfahren oder virtuelle Poststelle). Für ein empfangendes System können (z.B. für unterschiedliche Fachlichkeiten) multiple Zustellpunkte angelegt werden. In der Konfiguration eines Zustellpunkts sind interne und öffentliche Teile hinterlegt. Interne Angaben sind solche, die zu Administrationszwecken dienen. Öffentliche Angaben legen z.B. fest, in welcher Form der Empfänger Einreichungen akzeptiert. Zustellpunkte werden über die sogenannte Destination-ID eindeutig identifiziert. Weitere Informationen finden sich in den Artikeln [Zustellpunkt anlegen](receiving/destination.mdx) und [Zustellpunkt ermitteln](responsibilities/get-destination.mdx). |
| Zuständigkeitsverzeichnis | Dienst, der eine Abfrage der *Adressierungsinformationen* anhand eines Leistungsschlüssels und eines geographischen Merkmals (z.B. ARS oder PLZ) ermöglicht; z.B. Portalverbund Online-Gateway oder Behördenfinder Deutschland |
---
slug: /
---
import {Redirect} from '@docusaurus/router'
<Redirect to=".." />
---
hide_table_of_contents: true
slug: /
---
# Einführung in FIT-Connect
Willkommen im FIT-Connect-Dokumentationsportal der [Föderalen IT-Kooperation (FITKO)](https://www.fitko.de/).
Auf den folgenden Seiten möchten wir einen Überblick über die föderale Antragsdatenübermittlungsinfrastruktur FIT-Connect geben und die nötigen Schritte zur Anbindung von Onlinediensten und Fachverfahren an FIT-Connect beschreiben.
## Was leistet FIT-Connect?
Bei der Implementierung von Online-Diensten müssen derzeit heterogene Antragsarchitekturen berücksichtigt werden, um die medienbruchfreie Übermittlung von Antragsdaten in die Fachverfahren der zuständigen Behörde sicherzustellen.
Dabei muss zudem auf Basiskomponenten unterschiedlicher Verwaltungsebenen und Behörden zugegriffen werden (bspw. auf Payment- oder Nutzerkontenkomponenten).
Zur Unterstützung von Verfahrensverantwortlichen bei der Umsetzung von Onlinediensten und der Anbindung von Fachverfahren steht mit FIT-Connect eine Infrastruktur zur Unterstützung der technischen Realisierung von Antragsprozessen zur Verfügung.
Die entwickelte Lösung vereinfacht nicht nur den Datentransport von Onlinediensten zu Fachverfahren, sondern unterstützt auch bei Umsetzung weiterer, verfahrensunabhängiger Anforderungen wie z.B. der Zuständigkeitsermittlung, der Aushandlung von Fachdatenschemata und Rückkanaloptionen und der Übermittlung von Bezahlinformationen.
FIT-Connect schafft dazu eine einheitliche Schnittstelle zur Anbindung von Onlinediensten an die zuständigen Fachverfahren aller föderalen Ebenen und bietet Lösungsverantwortlichen für Fachverfahren eine einfache Möglichkeit, ihre Software schnell und wirtschaftlich in länder- und ebenenübergreifende Antragsprozesse zu integrieren.
Zur Etablierung eines einheitlich hohen Sicherheitsniveaus für alle angebundenen Systeme wurde eine verschlüsselte Übertragung von Antragsdaten bereits in der Konzeptionsphase des Projekts nach dem Prinzip Security by Design vorgesehen und ist ein integraler Bestandteil von FIT-Connect.
Bei der Übertragung von Antragsdaten über FIT-Connect kommt neben einer obligatorischen Transportverschlüsselung immer auch zwingend eine über Zertifikate aus der Verwaltungs-PKI (V-PKI) abgesicherte Inhaltsdatenverschlüsselung zum Einsatz.
Dadurch wird ein Zugriff auf Inhaltsdaten durch die FIT-Connect-Infrastruktur technisch unmöglich.
Werden Inhaltsdaten dabei bereits auf dem Endgerät der Verwaltungskunden verschlüsselt, kann im Antragskontext von einer Ende-zu-Ende-Verschlüsselung gesprochen werden.
Ziel von FIT-Connect ist, die bestehende föderale IT-Landschaft effektiver zu vernetzen.
FIT-Connect kombiniert dazu bestehende Produkte und Standards des IT-Planungsrates bedarfsgerecht und zielt auf die ganzheitliche Betrachtung
aller Schritte der Antragstellung im Rahmen des Onlinezugangsgesetzes.
Durch die Vereinheitlichung und Dokumentation von Prozessschritten der Antragsstellung senkt FIT-Connect die Umsetzungsaufwände für zukünftige
Digitalisierungsvorhaben.
Herausfordernde Problemstellungen wie z.B. das Antragsrouting werden einmal bearbeitet; entwickelte Lösungen werden allen Verfahrensverantwortlichen zur Verfügung gestellt.
Weitere Informationen zum Projekt FIT-Connect finden sich [auf der Webseite der FITKO](https://www.fitko.de/projektmanagement/fit-connect).
## Wie kann FIT-Connect genutzt werden?
Die FIT-Connect-Schnittstellen sind als ein universelles Eingangstor für digitale Einreichungen an die Verwaltung ausgelegt.
Die FIT-Connect-Infrastruktur bedient dabei 4 Hauptanwendungsfälle, die in der folgenden Grafik dargestellt sind:
![Darstellung der Anwendungsfälle von FIT-Connect](/images/api_overview/fitconnect-use-cases.png "Darstellung der Anwendungsfälle von FIT-Connect")
### Anwendungsfall 1: Konfiguration von API-Clients und Zustellpunkten
Eine [Registrierung von technischen Benutzern](./getting-started/account.mdx) (API-Clients) und die [Eröffnung von sogenannten Zustellpunkten](./receiving/destination.mdx) für den Empfang von Anträgen oder Bescheiden ist über das **FIT-Connect Self-Service-Portal** möglich.
- Sendende Systeme (bspw. Online-Antragsdienste) können nach der Konfiguration eines technischen Benutzers (API-Clients) Einreichungen an alle existierenden Zustellpunkte senden.
- Empfangende Systeme (bspw. Fachverfahren) in den fachlich zuständigen Behörden können einen digitalen Zugang (Zustellpunkt) eröffnen und hierüber beliebige Einreichungen (Anträge, Berichtsmeldung, etc. ) erhalten.
Für diese Zustellpunkte legen die zuständigen Stellen alle fachlichen Vorgaben (zulässige Fachstandards, Verschlüsselung, Datenformate, etc.) fest, damit eine medienbruchfreie Weiterverarbeitung in ihren Systemen gewährleistet ist.
Jeder Zustellpunkt ist über eine sogenannte **Destination-ID** eindeutig identifizierbar.
### Anwendungsfall 2: Abruf von Zuständigkeiten und Parametrisierungs-Informationen
Über den **FIT-Connect Routingdienst** können sendende Systeme auf Basis des Leistungs- und Ortsbezugs der Einreichung die [fachlich zuständige Behörde und alle technischen Verbindungsparameter ermitteln](./responsibilities/get-destination.mdx).
Um die richtigen Zustellpunkte für den jeweiligen Leistungskontext und die jeweilige Zuständigkeit zu finden, wird sendenden Systemen mit der **Routing API** hierzu eine entsprechende Schnittstelle bereitgestellt.
Um die Auffindbarkeit eines Zustellpunktes skalierbar auf allen föderalen Ebenen zu ermöglichen, werden die konfigurierten Zuständigkeitsinformationen zuvor durch die fachlich zuständige Behörde [in einem an den Portalverbund angeschlossenen Landes- oder Bundes-Redaktionssystem des FIM-Bausteins Leistungen hinterlegt](./responsibilities/routing.mdx).
Diese dezentral gepflegten Zuständigkeiten werden durch das [Online-Gateway des Portalverbunds](https://servicesuche.bund.de/) gebündelt.
Fragt nun ein sendendes System über die Routing API an, ermittelt der FIT-Connect Routingdienst die Destination-ID des korrekten Zustellpunktes im Onlinegateway, ruft auf Basis dieser ID die technischen Verbindungsparameter im DVDV ab und gibt diese Informationen an das sendende System zurück (siehe [Zusammenspiel der Infrastruktur bei der Übermittlung von Einreichungen​](#architecture)).
### Anwendungsfall 3: Übermittlung von Einreichungen (Anträge oder Berichtsmeldungen)
Über den **FIT-Connect Zustelldienst** können sendende Systeme Einreichungen [an die zuvor ermittelte fachlich zuständige Behörde senden](./sending/overview.mdx).
Der Zustelldienst stellt hierfür die **Submission API** bereit. Sendende Systeme können sich über eine erfolgreiche Zustellung über ein [Ereignisprotokoll (Event Log)](./getting-started/event-log.mdx) informieren.
Die Vertraulichkeit der Übermittlung ist dank der [obligatorischen Ende-zu-Ende-Verschlüsselung](./getting-started/encryption.mdx) für alle übermittelten Daten jederzeit gewährleistet. Die eingesetzte Ende-zu-Ende-Verschlüsselung stellt sicher, dass auch die Betreiber der FIT-Connect-Infrastruktur zu keinem Zeitpunkt Zugriff auf die Inhalte der übermittelten Einreichungen erlangen können. Mit FIT-Connect ist eine Realisierung einer Ende-zu-Ende-Verschlüsselung bis in den Browser oder das Endgerät der Antrag- oder Berichtssteller:in möglich.
### Anwendungsfall 4: Abruf von Einreichungen (Anträge oder Berichtsmeldungen)
Empfangende Systeme werden durch den **FIT-Connect Zustelldienst** [über eingegangene Einreichungen informiert](./receiving/notification.mdx). Anschließend können empfangende Systeme diese Einreichungen über die **Submission API** [abrufen](./receiving/overview.mdx).
Nach dem Abruf ist der Versand einer Empfangsbestätigung über das [Ereignisprotokoll](./getting-started/event-log.mdx) möglich. So können empfangende Systeme den Eingang von Einreichungen nachweisbar bestätigen.
## Für wen ist die föderale Antragsdatenübermittlungsinfrastruktur FIT-Connect gedacht und warum sollte ich sie nutzen?
Die FIT-Connect Submission API ist für alle Hersteller, Entwickler:innen und Verfahrensverantwortliche von sendenden und empfangenden Systemen gedacht.
Insbesondere folgende Systeme mit bundesweiten Nutzungsszenarien sollen mit der FIT-Connect Submission API unterstützt werden:
- **Einer für alle (EfA)-Verfahren**: Länderübergreifend entwickelte Antragsverfahren für eine bestimmte Verwaltungsleistung oder ein Leistungsbündel, die entweder in verschiedenen Ländern nachnutzbar oder länderübergreifend als gemeinsamer Antragsdienst für alle zuständigen Stellen betrieben werden.
- **Antragsgeneratoren / Antragsmanagementsysteme**: Standardsoftware zur Umsetzung von direkt nutzbaren Online-Antragsdiensten, die im ganzen Bundesgebiet bei einzelnen Stellen oder Gebietskörperschaften (bspw. als Basiskomponente) im Einsatz sind.
- **Als Standardsoftware bereitgestellte Fachverfahrenssoftware, Prozessplattformen oder Dokumentenmanagementsysteme**: Bundesweit angebotene und eingesetzte Standardsoftware, die von den zuständigen Stellen für die Antragsbearbeitung eingesetzt wird.
Für diese Systeme bietet die FIT-Connect bei der schnellen und wirtschaftlichen Realisierung medienbruchfreier Antragsprozesse eine Reihe von Mehrwerten:
- **Plug and Play Anbindung an die föderale Antragsübermittlung**: Durch die zentral bereitgestellten Schnittstellen (APIs) und die Nutzung der bestehenden Zuständigkeitsfinderinfrastruktur des Portalverbunds können Systeme schnell an eine föderale Antragsübermittlungsinfrastruktur angebunden werden, ohne eigene Infrastrukturen hierfür zu beauftragen oder aufzubauen.
- **Leichgewichtige APIs und Industriestandards**: Die FIT-Connect-Schnittstellen bauen auf leichgewichtigen RESTful API-Ansätzen auf und nutzen verbreitete Industriestandards wie den OpenAPI-Spezifikationsstandard und das OAuth-2.0-Autorisierungsframework, sodass kein spezialisiertes Know-How oder proprietäre Softwarekomponenten für die Anbindung erforderlich sind.
- **Flexibilität in der Antragsübermittlung**: Die FIT-Connect-Schnittstellen verbinden Flexibilität und Standardisierung. Während die FIT-Connect Submission API eine einheitliche Metadatenstruktur festlegt, um Einreichungen strukturiert zu verarbeiten, können beliebige Fachstandards und Anlagen übertragen werden. Auch die Übertragung von Einreichungen im PDF-Format ist möglich, solange für die Antragsdaten noch kein FIM-Schema vorhanden ist.
- **Nutzung bestehender Prozesse und Strukturen für die Pflege von Adressierungsinformationen**: Langjährig erprobte Prozesse und Strukturen zur Pflege der Zuständigkeitsinformationen, können in den zuständigen Stellen beibehalten werden. Technische Adressierungsparameter werden über die gleichen Systeme und Prozesse gepflegt, die schon heute bei Informationen zu Anschriften, Rufnummern, E-Mail-Adressen oder Ansprechpartnern für Verwaltungsleistungen genutzt werden.
- **Machine2Machine Ready**: Die FIT-Connect Submission API und die FIT-Connect Antragsübermittlungsarchitektur sind von Grund auf als offene API-Plattform konzipiert. Dadurch können auch verwaltungsexterne Antrags- und Berichtssysteme wie Drittsoftware oder Unternehmenssysteme direkt eingebunden werden, ohne das hierfür eine gesonderte Infrastruktur notwendig ist.
## Wie unterscheidet sich FIT-Connect vom bisherigen XFall-Standard?
Die FIT-Connect Submission API baut auf den bisherigen Konzepten und Erfahrungen des bestehenden IT-Planungsrat-Standards XFall auf.
> Die übergreifende Zielstellung des Standards XFall besteht darin, Anträge und Berichte, die aus vorgelagerten Systemen (bspw. Onlineantragsdienste, Fachportale oder Berichtssysteme) erstellt werden, in die unterschiedlichen Systeme der elektronischen Verfahrensbearbeitung (bspw. Fachverfahren, Dokumentenmanagementsystem oder Prozessplattformen) zu übergeben.
Bei der Entwicklung der Submission API wurden viele Konzepte des Moduls XFall-Container mit Hinblick auf die neuen Erfordernisse des Onlinezugangsgesetzes, der SDG-Verordnung sowie den Anforderungen digitaler Geschäftsmodelle weiterentwickelt.
Technisch setzt die FIT-Connect Submission API auf einen leichtgewichtigen RESTful-Architekturstil und baut auf der föderalen Antragsübertragungsarchitektur von FIT-Connect auf.
Bereitgestellt wird diese API durch einen zentral gemanagten Intermediär (FIT-Connect Zustelldienst), der für Nutzer:innen der API einen Aufbau eigener Infrastruktur unnötig macht.
Die Bausteinsammlung und systematische Vorgabe für die Übertragung von Fachdaten (Formularfelder und weiterer antragsspezifischer Inhalt) des Moduls XFall-Container wurde durch den [FIM-Baustein Datenfelder](https://fimportal.de/) aufgegriffen.
## Ist die FIT-Connect Submission API nur für länder- und behördenübergreifende Antragskontexte gedacht?
Durch die einfache Anbindung und Nutzung bietet sich die Submission API auch dort an, wo das behördeneigene Antragsverfahren mit dem behördeneigenen Fachverfahren verbunden wird.
Durch die Nutzung der Submission API werden diese Systeme standardisiert verbunden, ohne das die Behörde in Abhängigkeiten zu proprietären Technologien und Schnittstellen gerät.
Dies ermöglicht es der Behörde, ihre Systeme auf beiden Seiten flexibel auszutauschen und weiterzuentwickeln, um somit auf neue technische Trends und Möglichkeit schnell zu reagieren.
![Interoperabilität mit FIT-Connect](/images/api_overview/fitconnect-middleware.png "Interoperabilität mit FIT-Connect")
## In welchem Stand befindet sich FIT-Connect Submission API und wann kann man diese nutzen?
Ein Zugang für interessierte Enwickler zur einer Testinfrastruktur ist seit August 2021 möglich.
Um auf diese Testumgebung zuzugreifen, können interessierte Entwickler ihre Anwendungen das Self-Service-Portal vorab registrieren.
Eine produktive Nutzung der FIT-Connect-Infrastruktur ist aktuell einem geschlossenen Kreis von Projektbeteiligten vorbehalten.
Bei Interesse an der produktiven Nutzung von FIT-Connect, freuen wir uns über Ihre [Kontaktaufnahme](./contact).
## Zusammenspiel der Infrastruktur bei der Übermittlung von Einreichungen {#architecture}
Das Zusammenspiel der Infrastruktur-Komponenten, die bei FIT-Connect zum Einsatz kommen, ist in der folgenden Gesamtdarstellung der Architekturbausteine abgebildet:
![Überblick über die FIT-Connect-Architektur](/images/api_overview/fitconnect-architecture.png "Antragsübertragungsarchitektur FIT-Connect")
......@@ -9,7 +9,7 @@ Fachdaten, beschrieben.
"contentStructure": {
"data": {
"schema": {
"schemaUri": "urn:de:fim:leika:leistung:99015004037000",
"schemaUri": "https://schema.fitko.de/fim/s00000143_1.0.schema.json",
"mimeType": "application/json"
}
},
......
......@@ -12,14 +12,14 @@ Die URL der Submission API findet sich im Artikel [Erste Schritte](../getting-st
:::
```bash title="Abfrage der Einreichung inkl. Fachdaten und Metadaten"
$ export SERVICE_URL=<URL>
$ export SUBMISSION_API=https://submission-api-testing.fit-connect.fitko.dev
$ export JWT_TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA
$ export SUBMISSION_ID=9d618546-0ff7-4e93-9f15-714e5dd1bf12
$ curl \
-H "Authorization: Bearer $JWT_TOKEN" \
-H "Content-Type: application/json" \
-X GET $SERVICE_URL/submissions/$SUBMISSION_ID
> {
-X GET "$SUBMISSION_API/v1/submissions/$SUBMISSION_ID"
{
"destinationId": "879ee109-a690-4db8-ab32-424284184d7d",
"submissionId": "ce75a6b8-d72f-4b94-b09e-af6be35bc2ae",
"caseId": "e89e107e-ed79-40e6-ad34-4e770f9df26d",
......@@ -43,13 +43,13 @@ Anlagen können über den Endpunkt <ApiLink api="submission-api" to="/v1/submiss
```bash title="Herunterladen einer Anlage"
$ export SERVICE_URL=<URL>
$ export SUBMISSION_API=https://submission-api-testing.fit-connect.fitko.dev
$ export JWT_TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA
$ export SUBMISSION_ID=9d618546-0ff7-4e93-9f15-714e5dd1bf12
$ export ATTACHMENT_ID=122668ad-3081-497c-9358-7ce4b6144b02
$ curl \
-H "Authorization: Bearer $JWT_TOKEN" \
-H "Content-Type: application/jose" \
-X GET $SERVICE_URL/submissions/$SUBMISSION_ID/attachments/$ATTACHMENT_ID
-X GET "$SUBMISSION_API/v1/submissions/$SUBMISSION_ID/attachments/$ATTACHMENT_ID"
> 6r4H2H_WIzCv8Pd-uetmcbK...iVBKF3ylHRUahmZ
```
......@@ -38,13 +38,13 @@ In diesem Fall werden nur die Submissions zurückgegeben, die zum angegebenen Zu
Anzahl an Submissions in einer Teilliste (`limit`) sind 500 Submissions.
```bash
$ export SERVICE_URL=<URL>
$ export SUBMISSION_API=https://submission-api-testing.fit-connect.fitko.dev
$ export JWT_TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA
$ curl \
-H "Authorization: Bearer $JWT_TOKEN" \
-H "Content-Type: application/json" \
-X GET $SERVICE_URL/submissions
> {
-X GET "$SUBMISSION_API/v1/submissions"
{
offset: 0,
count: 3,
totalCount: 3,
......
......@@ -37,24 +37,24 @@ Beispiele für das Ermitteln der benötigten Daten:
<TabItem value="curl">
```bash
$ export SERVICE_URL=...
$ export ROUTING_API=https://routing-api-testing.fit-connect.fitko.dev
$ curl \
-H "Content-Type: application/json" \
-X GET $SERVICE_URL/v1/routes?leikaKey=99010003001006&ags=15085055
-X GET "$ROUTING_API/v1/routes?leikaKey=99010003001006&ags=15085055"
```
```bash
$ export SERVICE_URL=...
$ export ROUTING_API=https://routing-api-testing.fit-connect.fitko.dev
$ curl \
-H "Content-Type: application/json" \
-X GET $SERVICE_URL/v1/routes?leikaKey=99010003001006&ars=150850055055
-X GET "$ROUTING_API/v1/routes?leikaKey=99010003001006&ars=150850055055"
```
```bash
$ export SERVICE_URL=...
$ export ROUTING_API=https://routing-api-testing.fit-connect.fitko.dev
$ curl \
-H "Content-Type: application/json" \
-X GET $SERVICE_URL/v1/routes?leikaKey=99010003001006&areaId=15529
-X GET "$ROUTING_API/v1/routes?leikaKey=99010003001006&areaId=15529"
```
</TabItem>
......@@ -256,7 +256,7 @@ Im folgenden Beispiel wird die Bibliothek [nimbus-jose-jwt](https://connect2id.c
```
```java
static final String SSP_BASE_URL = "https://portal.auth-dev.fit-connect.fitko.dev";
static final String SSP_BASE_URL = "https://portal.auth-testing.fit-connect.fitko.dev";
static boolean verifySSPSignature(SignedJWT signedJWT, String keyId) throws IOException, ParseException, JOSEException {
......@@ -302,28 +302,28 @@ Beispiele für die Suche:
Suche mit Postleitzahlanfang
```bash
$ export SERVICE_URL=...
$ export ROUTING_API=https://routing-api-testing.fit-connect.fitko.dev
$ curl \
-H "Content-Type: application/json" \
-X GET $SERVICE_URL/v1/areas?areaSearchexpression=061*
-X GET "$ROUTING_API/v1/areas?areaSearchexpression=061*"
```
Suche mit Name
```bash
$ export SERVICE_URL=...
$ export ROUTING_API=https://routing-api-testing.fit-connect.fitko.dev
$ curl \
-H "Content-Type: application/json" \
-X GET $SERVICE_URL/v1/areas?areaSearchexpression=Halle
-X GET "$ROUTING_API/v1/areas?areaSearchexpression=Halle"
```
Suche mit Name und Postleitzahl
```bash
$ export SERVICE_URL=...
$ export ROUTING_API=https://routing-api-testing.fit-connect.fitko.dev
$ curl \
-H "Content-Type: application/json" \
-X GET $SERVICE_URL/v1/areas?areaSearchexpression=06108&areaSearchexpression=Halle
-X GET "$ROUTING_API/v1/areas?areaSearchexpression=06108&areaSearchexpression=Halle"
```
</TabItem>
......@@ -375,13 +375,13 @@ Die URL der Submission API findet sich im Artikel [Erste Schritte](../getting-st
Über `curl` können diese Information mit dem folgenden Aufruf abgerufen werden.
```bash
$ export SERVICE_URL=...
$ export SUBMISSION_API=https://submission-api-testing.fit-connect.fitko.dev
$ export JWT_TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA
$ export DESTINATION_ID=13ad2349-975c-4167-bcd8-da606b4e1d84
$ curl \
-H "Authorization: Bearer $JWT_TOKEN" \
-H "Content-Type: application/json" \
-X GET $SERVICE_URL/v1/destinations/$DESTINATION_ID
-X GET "$SUBMISSION_API/v1/destinations/$DESTINATION_ID"
{
"destinationId": "13ad2349-975c-4167-bcd8-da606b4e1d84",
......
......@@ -6,7 +6,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl';
import Tabs from '@theme/Tabs'
import TabItem from '@theme/TabItem'
Um die Auffindbarkeit eines Zustellpunktes [über die Routing API zu ermöglichen](./get-destination.mdx), müssen die im Self-Service-Portal konfigurierten Zuständigkeitsinformationen zunächst in einem an den Portalverbund angeschlossenen Landes-Redaktionssystem des FIM-Bausteins Leistungen hinterlegt werden.
Um die Auffindbarkeit eines Zustellpunktes [über die Routing API zu ermöglichen](./get-destination.mdx), müssen die im Self-Service-Portal konfigurierten Zuständigkeitsinformationen zunächst in einem an den Portalverbund angeschlossenen Landes- oder Bundes-Redaktionssystem des FIM-Bausteins Leistungen hinterlegt werden.
Die zu einem Zustellpunkt gehörigen signierten Zuständigkeits-/Adressierungsinformationen (`destinationSignature`) können im Self-Service-Portal über einen Button in der Zustellpunkt-Übersichtsliste in die Zwischenablage kopiert werden.
Von der Zwischenablage können diese Informationen dann in das zuständige Redaktionssystem kopiert/import werden.
......@@ -17,3 +17,10 @@ Von der Zwischenablage können diese Informationen dann in das zuständige Redak
</div>
Nach der Übernahme der Adressierungsinformationen in das Redaktionssystem werden diese im Format XZuFi an das [Onlinegateway des Portalverbund (PVOG)](https://servicesuche.bund.de/) übermittelt und sind anschließend [über die Routing API abrufbar](./get-destination.mdx).
Die notwendige Pflege der FIT-Connect Adressierungsinformationen in einem Landes- oder Bundes-Redaktionssystem des FIM Baustein Leistungen und die Zuständigkeitsermittlung im Portalverbund ist in folgendem Schaubild dargestellt:
<div class="center">
<img width="550" alt="FIT-Connect Routing-Architektur"
src={useBaseUrl('/images/routing/routing-architecture-overview.png')}/>
</div>
......@@ -2,13 +2,14 @@
title: Anlagen
---
import ApiLink from '@site/src/components/ApiLink'
import Tabs from '@theme/Tabs'
import TabItem from '@theme/TabItem'
Anlagen sind Bestandteil einer Einreichung, die nicht zwingend maschinenlesbar oder an Standards geknüpft sind.
Sie können beim Anlegen einer Einreichung mit angekündigt und dann im weiteren Verlauf hochgeladen werden.
Anlagen sind Bestandteil einer Einreichung und müssen nicht zwingend maschinenlesbar sein.
Anlagen können [beim Anlegen einer Einreichung angekündigt werden](start-submission.mdx) und anschließend über den Endpunkt <ApiLink api="submission-api" to="/v1/submissions/{submissionId}/attachments/{attachmentId}" withMethod="put" /> hochgeladen werden.
In dem folgenden Ausschnitt wird dargestellt, wie eine bereits verschlüsselte Datei an eine Einreichung angehängt und hochgeladen werden kann.
In dem folgenden Ausschnitt wird dargestellt, wie eine bereits verschlüsselte Datei über den Endpunkt <ApiLink api="submission-api" to="/v1/submissions/{submissionId}/attachments/{attachmentId}" withMethod="put" /> hochgeladen werden kann:
<Tabs
defaultValue="curl"
......@@ -22,7 +23,7 @@ In dem folgenden Ausschnitt wird dargestellt, wie eine bereits verschlüsselte D
<TabItem value="curl">
```bash
$ export SERVICE_URL=...
$ export SUBMISSION_API=https://submission-api-testing.fit-connect.fitko.dev
$ export JWT_TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA
$ export SUBMISSION_ID=63f0c991-0635-4e18-8a4b-fb0c01de9f5c
$ export ATTACHMENT_ID=90ae8309-2102-4e81-a325-ceda480d0e9d
......@@ -31,7 +32,7 @@ In dem folgenden Ausschnitt wird dargestellt, wie eine bereits verschlüsselte D
-H "Authorization: Bearer $JWT_TOKEN" \
-H "Content-Type: application/jose" \
--data "$ENC_FILE_CONTENT" \
-X PUT $SERVICE_URL/submissions/$SUBMISSION_ID/attachments/$ATTACHMENT_ID
-X PUT "$SUBMISSION_API/v1/submissions/$SUBMISSION_ID/attachments/$ATTACHMENT_ID"
```
</TabItem>
......@@ -40,17 +41,17 @@ In dem folgenden Ausschnitt wird dargestellt, wie eine bereits verschlüsselte D
```js
import axios from 'axios'
const baseUrl=...
const token="eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA"
const submissionId="63f0c991-0635-4e18-8a4b-fb0c01de9f5c"
const attachmentId="90ae8309-2102-4e81-a325-ceda480d0e9d"
const data="6r4H2H_WIzCv8Pd-uetmcbK...iVBKF3ylHRUahmZ"
const SUBMISSION_API = "https://submission-api-testing.fit-connect.fitko.dev"
const token = "eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA"
const submissionId = "63f0c991-0635-4e18-8a4b-fb0c01de9f5c"
const attachmentId = "90ae8309-2102-4e81-a325-ceda480d0e9d"
const data = "6r4H2H_WIzCv8Pd-uetmcbK...iVBKF3ylHRUahmZ"
axios.put(
`/submissions/${submissionId}/attachments/${attachmentId}`,
`/v1/submissions/${submissionId}/attachments/${attachmentId}`,
data
{
baseURL,
SUBMISSION_API,
timeout: 2000,
headers: {
'Content-Type': 'application/jose',
......
......@@ -21,11 +21,9 @@ Damit können wir den JWK des Zustellpunktes abrufen um Daten zu verschlüsseln.
```shell title="Beispiel: Abruf des JWK eines Zustellpunktes"
$ KID=... # Wert des Feldes `encryptionKid`
$ SERVICE_URL=...
$ SUBMISSION_API=https://submission-api-testing.fit-connect.fitko.dev
$ DESTINATION_ID=...
$ curl -X GET \
"$SERVICE_URL/v1/destinations/$DESTINATION_ID/keys/$KID"
---
$ curl -X GET "$SUBMISSION_API/v1/destinations/$DESTINATION_ID/keys/$KID"
{
"kty": "RSA",
"keyops": ["wrapKey"],
......
......@@ -47,7 +47,7 @@ Das letzte Security Event Token (SET) aus obigem Beispiel hat folgenden Payload:
```json
{
"iss": "https://api.fitko.de/fit-connect/",
"iss": "https://submission-api-testing.fit-connect.fitko.dev",
"iat": 1622796532,
"jti": "0BF6DBF6-CE7E-44A3-889F-82FE74C3E715",
"sub": "submission:F65FEAB2-4883-4DFF-85FB-169448545D9F",
......@@ -59,7 +59,7 @@ Das letzte Security Event Token (SET) aus obigem Beispiel hat folgenden Payload:
```
In dem SET ist folgende Information abgelegt:
- Er wurde vom Zustelldienst https://api.fitko.de/fit-connect/ ausgestellt (iss = issuer)
- Er wurde vom Zustelldienst https://submission-api-testing.fit-connect.fitko.dev ausgestellt (iss = issuer)
- Er wurde am 04.06.2021 um 08:48:52 GMT+0 (Unixzeit 1622796532) aufgezeichnet (iat = issued at)
- Er hat die eindeutige ID `0BF6DBF6-CE7E-44A3-889F-82FE74C3E715` (jti = JWT ID)
- Er betrifft die Einreichung `F65FEAB2-4883-4DFF-85FB-169448545D9F` (sub = subject)
......
......@@ -33,14 +33,14 @@ Die URL der Submission API findet sich im Artikel [Erste Schritte](../getting-st
<TabItem value="curl">
```bash
$ export SERVICE_URL=...
$ export SUBMISSION_API=https://submission-api-testing.fit-connect.fitko.dev
$ export JWT_TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA
$ export DESTINATION_ID=7a2668ad-3081-407c-9358-7ce4b6144b02
$ curl \
-H "Authorization: Bearer $JWT_TOKEN" \
-H "Content-Type: application/json" \
--data "{ \"destinationId\": \"$DESTINATION_ID\", \"announcedAttachments\": [\"1da99641-2067-4e8b-b049-91b2a6c90544\", \"538a1365-092e-4d80-93b9-90eb8c1f5982\"], \"serviceType\": { \"name\": \"Bauantrag\", \"identifier\": \"urn:de:fim:leika:leistung:99010003001006\" } }" \
-X POST $SERVICE_URL/submissions
-X POST "$SUBMISSION_API/v1/submissions"
> {
"destinationId": "7a2668ad-3081-407c-9358-7ce4b6144b02",
......@@ -61,7 +61,7 @@ $ curl \
```js
import axios from 'axios'
const url = '/submissions'
const SUBMISSION_API = "https://submission-api-testing.fit-connect.fitko.dev"
const data = {
"destinationId": "879ee109-a690-4db8-ab32-424284184d7d",
"announcedAttachments": [
......@@ -76,10 +76,10 @@ const data = {
const token = 'eyJhbGciOiJIUzI1NiJ9.eyJyYW5kb20iOiJyYW5kb20ifQ.lXckRWoWCUBGM4ACZ6wIhYqplJeSw0HMEfE91jD1JPU'
axios.post(
url,
'/v1/submissions',
data
{
baseURL,
SUBMISSION_API,
timeout: 2000,
headers: {
'Authorization': `Bearer ${token}`
......