Skip to content
Snippets Groups Projects
Commit 2db64f6c authored by Alexander Hoose's avatar Alexander Hoose
Browse files

Arbeiten an den Artikel. Löschung des Ressourcen Artikels.

parent 372b579a
No related branches found
No related tags found
2 merge requests!4Documentation integriert,!5Version 0.2
assets/images/api_overview/FIEP_strategic_vision.png

97.7 KiB

......@@ -2,9 +2,9 @@
## Der XFall Antrag
![application_structure]( "Struktur des XFall Antrags")
![application_structure](https://raw.githubusercontent.com/fiep-poc/fiep-poc/documentation/assets/images/quick_reference/application_structure.png?token=AOHBJROKKDX4MECV4WW6IKC6Q4ZYS "Struktur des XFall Antrags")
Der XFall Antrag ist das zentrale Element in der XFall API. Dieser besteht aus den Fachdaten (`Data`) und den beigefügten Anhängen (`document`). Der Antrag selbst wird über Metadaten beschrieben.
Der XFall Antrag (`application`) ist das zentrale Geschäftsobjekt in der XFall API. Dieser besteht aus den Fachdaten (`data`) und den beigefügten Anhängen (`document`) und wird über Metadaten beschrieben.
Die Metadaten des Antrags ([Application Metadata](../models/application/metadata.json)) entsprechen dem früheren XFall-Container und enthalten allgemeine Informationen über den Antrag, die enthaltenen Fachdaten und die enthaltenen Anhänge:
......@@ -15,16 +15,16 @@ Die Metadaten des Antrags ([Application Metadata](../models/application/metadata
Fachdaten bezeichnen in XFall im einen strukturieren Datensatz in XML oder JSON und können über ein externes Schema (bspw. aus FIM) beschrieben werden. Anhänge können entweder klassische Anhänge (bspw. Nachweise) sein oder oder eine PDF Representation des Fachantrags, falls dies aus rechtlichen oder technischen Gründen notwendig ist.
## IDs in den XFall Endpunkten
## Identifikatoren der XFall Ressourcen
Um Ressourcen eindeutig zu identifizieren, werden in den URLs der REST Endpunkt eine oder mehrere Identifikatoren benutzt.
Um Ressourcen eindeutig zu identifizieren, werden in den URLs der REST Endpunkt eine oder mehrere Identifikatoren (IDs) benutzt.
### Durch die API bereitgestellte IDs
#### application-id
Der Zustelldienst weist jeder Übertragung (Application) eine global eindeutige `application-id` zu.
Der Zustelldienst weist jedem übertragenen Antrag (`Application`) eine global eindeutige `application-id` zu, die diesen Antrag dauerhaft über den gesamten Bearbeitungsverlauf eindeutig identifiziert.
#### destination-id
Für jeden vom Subscriber angelegtes Übertragungsziel vergibt der Zustelldienst eine global eindeutige `destination-id`.
Die `destination-id` ist eine vom Zustelldienst vergebene ID für einen durch den Subscriber angelegten Zustellpunkt (`destination`). Diese ID wird dem Sender über externe Systeme (bspw. Zuständigkeitsfinder) oder bilaterale Absprachen zwischen beiden Seiten mitgeteilt.
### Extern vergebene IDs
#### source-id
......@@ -33,16 +33,17 @@ Die `source-id` ist die ID des Accounts, der die Übertragung absendet. Sie wird
#### subscriber-id
Die `subscriber-id` ist die ID des Accounts, der die Übertragung empfängt. Sie wird vom genutzten Identitätssystem vergeben und muss global eindeutig sein.
### Vom Sender vergebene IDs
### Vom Sender vergebene Identifikatoren
#### doc-id
Der Sender vergibt für jedes Antragsformular und jede Anlage in einer Übertragung eine `doc-id`. Diese muss für alle Dokumente (Antragsformulare und Anlagen) in der Übertragung eindeutig sein. Es wird empfohlen, die IDs `1`, `2` etc. zu verwenden.
Der Sender vergibt für jedes Antragsformular und jede Anlage in einer Übertragung eine `doc-id`. Diese muss für alle Dokumente (PDF-Antragsformulare und beliebige Anlagen) in der Übertragung eindeutig sein. Es wird empfohlen, die IDs `1`, `2` etc. zu verwenden.
## Application Sender API
### Verwendete IDs
Es werden folgende Pfadparameter in der URL verwendet:
- `source-id`: Wird mit dem Source Account zugewiesen.
- `destination-id`: Über externes System (Zuständigkeitsfinder) dem Onlineantragsdienst bekannt.
- `application-id`: Vom Zustelldienst vergebene ID für die Übertragung.
- `source-id`
- `destination-id`
- `application-id`
- `doc-id`
### Operationen
Mit folgenden Operationen kann der Sender eine Application übertragen und die Übertragung verwalten:
......@@ -60,21 +61,22 @@ Ruft den Status der Uploads der Teile der Übertragung ab. Für die Fachdaten un
Darüber hinaus stehen dem Sender folgende weitere Operationen zur Verfügung:
-
- [Get Destination](../reference/sender.json/paths/~1{source-id}~1{destination-id}/get): Ruft übertIagungsrelevante nformationen über den Zustellpunkt (bspw. zulässige Schemata oder Datentypen) ab.
- [Get Status](../reference/sender.json/paths/~1{source-id}~1{application-id}~1status/get): Ruft den Status sowie die Statushistorie der Zustellung des Antrags ab.
## Application Subscriber API
### Verwendete IDs
...
**Noch in Arbeit**
...
Es werden folgende Pfadparameter in der URL verwendet:
- `subscriber-id`
- `destination-id`
- `application-id`
- `doc-id`
### Operationen
Mit diesen Operationen werden die Abonnements (im Sinne von Destinations) des Backends/Subscribers verwaltet:
Mit diesen Operationen kann der Subscriber Zustellpunkte (`Destinations`) verwalten:
- [Create Destination](../reference/subscriber.json/paths/~1{subscriber-id}~1destinations/post)
Legt ein neues Übertragungsziel (Destination) an.
- [List Destinations](../reference/subscriber.json/paths/~1{subscriber-id}~1destinations/get)
......
......@@ -2,7 +2,7 @@
## Überblick über die Anwendungsfälle
![Application_Transfer](https://raw.githubusercontent.com/fiep-poc/fiep-poc/documentation/assets/images/use_case_documentation/Use_Case_Diagramm.png?token=AOHBJRKJHOP6P3QZ4BKPMXK6QNDHU "Use Case Diagramm der XFall APIs")
![Application_Transfer](https://raw.githubusercontent.com/fiep-poc/fiep-poc/documentation/assets/images/use_case_documentation/use_case_diagramm.png?token=AOHBJRMAJDMF7CQFPV476CK6Q5JGQ "Use Case Diagramm der XFall APIs")
### Legende der verwendeten BPMN Symbole bei Anwendungsfallabläufen
......
......@@ -6,7 +6,7 @@ Um diese übergreifende Zielstellung zur erfüllen, werden dem Sender eines Antr
Das XFall API-Gateway ist ein Teilbereich der zukünftigen föderalen Integrations- und Entwicklungsplattform und wird aktuell als Proof of Concept umgesetzt.
### Welches Problem löst das XFall-Gateway bzw. die dahinliegende Integrationsinfrastruktur?
### Welches Problem löst das XFall API-Gateway bzw. die dahinliegende Integrationsinfrastruktur?
...
......@@ -29,6 +29,7 @@ Beide Säulen folgen der Philosophie einer offenen Plattform und leiten einen Ku
- Dies ermöglicht es allen gesellschaftlichen Akteuren (Behörden, Unternehmen, Non-Profit Organisationen, Bürger) neue digitale Lösungen und Innovationen frei erstellen.
- Die Lösungen können durch den Staat eingebunden, beauftragt oder eingekauft werden oder abseits des Staats im Rahmen neuer kommerzieller oder gesellschaftlicher Geschäftsmodelle eingebunden werden.
![FIEP_Strategic_Vision](https://raw.githubusercontent.com/fiep-poc/fiep-poc/documentation/assets/images/quick_reference/application_structure.png?token=AOHBJROKKDX4MECV4WW6IKC6Q4ZYS "Vision der föderalen Integrations- und Entwicklungsplattform")
#### Zielstellung des Proof of Concepts
......
# Resourcen
![REST Resourcen](../assets/images/REST_Resourcen.svg)
## Primärresourcen
### [Application Metadata](../models/application/metadata.json)
Die Metadaten des Antrags (Application Metadata) entsprechen dem früheren XFall-Container und tragen allgemeine Informationen zu der Übertragung, wie
- Nachgefragte behördliche Leistung (Public Service Type)
- Antragsteller
- Hinweis auf Fachdaten und das dazugehörige Schema
- Struktur des Antrags (Liste der enthaltenen Dokumente)
### [Destination](../models/destination.json)
Die Destination beschreibt einen technischen Übergabepunkt für Anträge. Dies kann ein Fachverfahren sein, aber auch ein zwischengeschaltetes System wie eine virtuelle Poststelle oder ein Kommunal-Gateway.
Die Destination enthält folgende Informationen:
- Behörde
- technischen Ansprechpartner
- empfangbare Schemata
- technische Benachrichtigungsadresse (siehe [Callback](callback.md))
In Zukunft soll die Destination noch um Schlüssel für eine Ende-zu-Ende-Übertragung erweitert werden.
## Subresourcen
### Application Data
Die Übertragung kann einen Fachdatensatz (Application Data) enthalten. Dieser darf im JSON oder XML Format vorliegen.
### [Application Document](../models/application/document.json)
Einer Übertragung sind Dokumente zugeordnet. Dies sind z.B. Antragsformulare oder Anlagen.
### [Application Schema](../models/application/schema.json)
Die Destination kann Schemata benennen, die empfangen werden können. Eine Übertragung referenziert dann eines dieser Schemata um festzulegen, welche Struktur die Fachdaten haben.
## Datentypen
### [ID-String](../models/common/id-string.json)
Der ID-String ist ein String, der nur die Zeichen A-Z, a-z, 0-9 sowie Bindestrich (-), Unterstrich (_) und Punkt (.) enthält.
- Regex: `^[-_.A-Za-z0-9]+$`
### [MIME-Type](../models/common/mime-type.json)
Der MIME-Type ist ein String, der dem Format der MIME-Typen entspricht.
- Regex: `^[-\w.]+/[-\w.+]+$`
### [Phonenr](../models/common/phonenr.json)
Eine Telefonnummer im internationalen Format, z.B. "+49 89 32168-42". Muss mit einem Plus beginnen und darf danach außer Ziffern nur Leerzeichen ( ) und Bindestriche (-) enthalten.
Regex: `^\+[1-9]([ -]?[0-9]){1,14}$`
### [Status](../models/status.json)
Der Status beschreibt den Fortschritt der Übertragung. Hierzu sind folgende Werte definiert:
- `incomplete`: Die Einlieferung von der Source hat begonnen
- `queued`: Die Übertragung wurde vollständig eingeliefert und akzeptiert
- `forwarded`: Die Übertragung an die direkt angebundene Destination wurde abgeschlossen
- `delivered`: Die Übertragung hat den vorgesehen Endpunkt erreicht
<!-- theme: info -->
> **Hinweis:** Bei diesem Status handelt es sich um den Übermittlungsstatus vom Sender an den Subscriber. Die Statusmeldungen der Zuständigen Stelle an den Antragsteller sind davon unabhängig.
## Modelle
### [Error](../models/error.json)
Die Klasse "Error" dient der Rückmeldung zu einer nicht erfolgreichen Operation.
Sie enthält drei Propertys:
- code: integer - Fehlercode
- msg: string - Fehlermeldung
- ref: string - Referenz auf fehlerhafte Stelle
### [FIM-ID](../models/common/fim-id.json)
Die FIM ID besteht aus einer ID und einer Versionsnummmer.
Beispiel für Stammdatenschema "S99000001V1.0":
```json
{"id":"S99000001","version":"1.0"}
```
- Regex für "id": `^[DFGS]\d{8}$`
- Regex für "version": `^\d+\.\d+$`
### [Identifier](../models/common/identifier.json)
Der Identifier ist nach dem "IdentifierType" aus der "Universal Business Language" der OASIS nachempfunden. Die eigentliche ID ist im Unterelement "id" enthalten. Die weiteren Elemente dienen der Definition des Namensraums, aus dem die ID kommt. Hier ind vor allem die `schemeID` und `schemeVersionID` interessant.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment