Änderungen von Dokument Submission-API

Zuletzt geändert von MACH formsolutions am 14.04.2026

Von 5.1 nach 4.1

Von Version 20.1

bearbeitet von MACH formsolutions
am 14.04.2026

Änderungskommentar: Es gibt keinen Kommentar für diese Version

Auf Version 5.1

bearbeitet von MACH formsolutions
am 15.02.2021

Änderungskommentar: Es gibt keinen Kommentar für diese Version

Rohform
Im Layout

Zusammenfassung

Seiteneigenschaften (1 geändert, 0 hinzugefügt, 0 gelöscht)

Details

Seiteneigenschaften

Inhalt

@@ -1,53 +1,207 @@
--## Allgemeines
++## Authentifizierung
--MACH formsolutions stellt eine Schnittstelle zur Verfügung, die die Daten aller im System hinterlegten Einreichungen ausliest. Die Architektur beruht auf dem REST-Standard. Wie bei allen von MACH formsolutions angebotenen Schnittstellen unterliegt auch diese einem Authentifizierungskonzept.
--Die ausgelesenen Ergebnisdaten werden im JSON-Format zurückgeliefert.
++Um die Schnittstelle verwenden zu können, muss eine Authentifizierung vorgenommen werden. Für diese ist die Mandantennummer und der dafür hinterlegte API-Schlüssel notwendig, wobei die Mandantennummer als Benutzername und der API-Schlüssel als Passwort gilt. Sollte noch kein passender API-Schlüssel vorliegen, kann dieser beim Administrator des Fomularservers beantragt werden.
--## Voraussetzungen
++Mit dem folgenden Link wird auf eine Oberfläche weitergeleitet, bei der die Schnittstelle auf ihre Funktionalität getestet werden kann.
++Die erforderlichen Authentifizierungsdaten dienen zu Demonstrationszwecken und lauten wie folgt:
--Um die Submission-API nutzen zu können, sind folgende Voraussetzungen zu erfüllen:
++*Beispiel: [https://vertrieb.form-solutions.de/submission/swagger-ui/index.html](https://vertrieb.form-solutions.de/submission/swagger-ui/index.html)*
++<br>
++*Mandantennummer: 88888888-8888*
++<br>
++*API-Schlüssel: npcnqwpefwAFWFAFAFqwcqcqwc23rf23rzhbnerg*
--* Es muss für die Authentifizierung die Mandantennummer und der API-Key vorhanden sein.
++> ***Hinweis:***
++> Die verwendete Authentifizierungsart ist eine [Basis-Authentifizierung](https://de.wikipedia.org/wiki/HTTP-Authentifizierung#Basic_Authentication).
--## Verwendung der Schnittstelle
++___
--Die API wurde nicht für den Browsergebrauch konzipiert. Um die Anbindung zu testen, werden externe Tools wie beispielsweise [Insomnia](https://insomnia.rest/) oder [Postman](https://www.postman.com/) empfohlen.
++## Base-URL
--Unter dem "Submission"-Endpunkt lassen sich Informationen zu eingegangenen Formularen abrufen. Zusätzlich kann ein Bearbeitungsstatus zurückgemeldet werden.
--Mittels der Mandantennummer und der Formularnummer lässt sich eine Übersicht der eingegangenen Formulare abrufen. Dabei sind nur Metadaten enthalten. Wird beim Assistentenstart eine Ordnungsziffer mitgegeben enthält das Attribut "Payload" die übergebene Ordnungsziffer als eingebettetes JSON Element.
--Die Anzeige kann eingeschränkt werden, indem als Abfrage-Parameter der gewünschte Status mit angegeben wird. So kann z. B. mittels "?status=NEW" auf neue Anträge eingeschränkt werden. Ebenso ist es möglich mehrere Status gleichzeitig für die Filterung anzugeben.
--Zusätzlich kann der Abfragezeitraum über die Angabe eines "Last-Modified-Headers" eingeschränkt werden. Dabei handelt es sich um den Zeitpunkt der Einreichung, nicht um den Zeitpunkt der letzten Statusänderung.
--Weitere Verwendungsmöglichkeiten finden Sie in unserer Swagger-Dokumentation.
++Für alle URL-Endpunkte ist ein Prefix im folgenden Stil zu verwenden:\
++`https://<Server-Name>/submission/api/v2/`
--## Authentifizierung
++___
--Um die Schnittstelle verwenden zu können, muss eine Authentifizierung vorgenommen werden. Für diese sind die Mandantennummer und ein API-Key notwendig, wobei die Mandantennummer als Benutzername und der API-Key als Passwort gilt. Die verwendete Authentifizierungsart ist eine Basis-Authentifizierung.
++## Einreichungen
--Einen API-Key können Sie beim Betreiber des Formularservers beantragen.
++Unter dem `submission`-Endpunkt lassen sich Informationen zu eingegangenen Formularen abrufen. Zusätzlich kann Bearbeitungsstatus zurückgemeldet werden.
--## Beispielanwendung (Swagger-Dokumentation)
++### Übersicht
--Auf dem Formularserver ist mit der Swagger-Anwendung eine übersichtliche Darstellung und technische Dokumentation der Schnittstelle verfügbar. Mit dieser Anwendung kann die Funktionalität auch getestet werden.
++`/submission/<Mandant>/<Formularnummer>`\
++Mittels der Mandantennummer und der Formularnummer lässt sich eine Übersicht an eingegangenen Formularen abrufen. Dabei sind nur Metadaten enthalten, z. B.
--Die Adresse der Swagger-Anwendung der Submission-API lautet  `< Formularserveradresse >/submission/api/swagger-ui/index.html`
--Um die Anwendung aufzurufen, setzen Sie die Adresse des jeweiligen Formularservers ein.
++```
++[{
++  "transID":"AS_940000-gsh7ntqS",
++  "userID":"22222222-2222-0126",
++  "identifier":"AS_940000",
++  "applicantName":"Mustermann",
++  "applicantEMail":null,
++  "status":"NEW",
++  "options": {
++    "submissionType":"REGULAR",
++    "paymentType":"NONE",
++    "npa":false
++  },
++  "payload":null,
++  "pdf":null,
++  "xml":null,
++  "attachments":null,
++  "submissionDate":1455801335305
++}]
++```
--Für Funktionstests sind gültige Authentifizierungsdaten für den jeweiligen Server erforderlich (Mandantennummer und API-Key).
++Wird beim Assistentenstart eine Ordnungsziffer mitgegeben enthält das Attribut payload die übergebene Ordnungsziffer als eingebettetes JSON Element.
--## Datenabholung durch (mehrere) Systeme koordinieren mit verschiedenen Status
++Die Anzeige kann eingeschränkt werden, indem als Abfrage-Parameter der gewünschte Status mit angegeben wird. So kann z. B. mittels `?status=NEW` auf neue Anträge eingeschränkt werden. Ebenso ist es möglich mehrere Stati gleichzeitig für die Filterung anzugeben. Hierzu stehen zwei Möglichkeiten zur Verfügung:
--### Beispiel 1: Abholung eines Detaildatensatzes durch ein einzelnes externes System
++1. `?status=NEW&status=READ`
++2. `?status=NEW,READ`
--Greift ein einzelnes externes System (beispielsweise eine Portalsoftware) auf einen Detaildatensatz für die weitere Verarbeitung zu, ist nach erfolgreicher Übermittlung der Status des entsprechenden Datensatzes von "NEW" auf "DELETED" zu setzen.
++Gültige Statuswerte sind:
--### Beispiel 2: Einsicht und Abholung von Detaildatensätzen durch ein externes System
++- NEW
++- READ
++- CLOSED
++- PRELIMINARY
++- HIDDEN
++- DELETED
--Greift ein externes System (beispielsweise eine Portalsoftware) auf die Übersicht aller Einreichungen eines spezifischen Assistenten zu, ist der Status der ermittelten Datensätze von "NEW" auf "READ" zu setzen. Wird ein Detaildatensatz für die weitere Verarbeitung im externen System abgerufen, ist nach erfolgreicher Übermittlung der Status des entsprechenden Datensatzes von "READ" auf "DELETED" zu setzen.
++Zusätzlich kann der Abfragezeitraum über die Angabe eines `Last-Modified`-Headers eingeschränkt werden. Dabei handelt es sich um den Einreichezeitpunkt, nicht die letzte Statusänderung.
--### Beispiel 3: Abholung von Detaildatensätzen durch zwei externe Systeme
++### Detailauskunft
--Wird ein Detaildatensatz für die weitere Verarbeitung in der Portalsoftware abgerufen, ist nach erfolgreicher Übermittlung der Status des entsprechenden Datensatzes von "NEW" auf "READ" zu setzen. Greift ein weiteres System (beispielsweise ein Fachverfahren) auf die Detaildatensätze zu, sollte stets eine Filterung auf Einreichungen mit dem Status „READ“ erfolgen. Nach erfolgreicher Übermittlung ist der Status des entsprechenden Datensatzes von „READ“ auf „DELETED“ zu setzen.
++Sollen alle Daten eines einzelnen Formulareingangs abgerufen werden, ist die URL um die Transaktions-ID zu ergänzen:\
++`/submission/<Mandant>/<Formularnummer>/<Transaktions-ID>/metadata`
++Das Ergebnis besitzt dieselbe Struktur wie bei der Übersichtsabfrage. Allerdings enthält das Attribut `payload` die kompletten Assistentendaten als eingebettetes JSON-Element und die Attribute pdf, xml und attachments enthalten die entsprechenden Einreichedaten.
--### Beispiel 4: Abholung von Detaildatensätzen durch drei externe Systeme
++Der bis zum Release 4.60.0 gültige Aufruf mittels:\
++`/submission/<Mandant>/<Formularnummer>/<Transaktions-ID>`
++sollte mit der obige aufgeführten Endung ergänzt werden. Der damalige Aufruf behält bis auf Weiteres seine Gültigkeit.
--Wird ein Detaildatensatz für die weitere Verarbeitung in der Portalsoftware abgerufen, ist nach erfolgreicher Übermittlung der Status des entsprechenden Datensatzes von "NEW" auf "READ" zu setzen. Greift ein zweites System (beispielsweise ein Fachverfahren) auf die Detaildatensätze zu, sollte stets eine Filterung auf Einreichungen mit dem Status „READ“ erfolgen. Nach erfolgreicher Übermittlung ist der Status des entsprechenden Datensatzes von „READ“ auf „PRELIMINARY“ zu setzen. Greift ein drittes System (beispielsweise eine Software zur Benachrichtigung des Antragstellers über das Ergebnis) auf die Detaildatensätze zu, sollte stets eine Filterung auf Einreichungen mit dem Status „PRELIMINARY“ erfolgen. Nach erfolgreicher Übermittlung ist der Status des entsprechenden Datensatzes von „PRELIMINARY“ auf „DELETED“ zu setzen.
++#### PDF
++
++Um ausschließlich die generierte oder befüllte PDF-Datei abzurufen, wird der Pfad mit der Endung `pdf` verwendet:\
++`/submission/<Mandant>/<Formularnummer>/<Transaktions-ID>/pdf`
++
++
++#### XML
++
++Um ausschließlich die generierte XML-Datei abzurufen, wird der Pfad mit der Endung `xml` verwendet:\
++`/submission/<Mandant>/<Formularnummer>/<Transaktions-ID>/xml`
++
++```
++<?xml version="1.0" encoding="UTF-8"?>
++<!--Sonderzeichen in Feldnamen wurden ersetzt bzw. entfernt!-->
++<form template="AS_940000">
++...
++</form>
++```
++
++#### Anhänge
++
++Um alle Dateianhänge in einem Zip-Archiv abzurufen, wird der Pfad mit der Endung `zip` verwendet:\
++`/submission/<Mandant>/<Formularnummer>/<Transaktions-ID>/zip`
++
++### Statusänderung
++
++Um den Bearbeitungsstatus eines Vorgangs kenntlich zu machen, kann der Status einer Transaktion geändert werden. Dazu wird an die Detail-URL ein POST gesendet mit dem zusätzlichen Parameter `setStatus`. Gültige Statuswerte sind:
++
++- NEW
++- READ
++- CLOSED
++- PRELIMINARY
++- HIDDEN
++- DELETED
++
++> ***Hinweis:***
++> Wird der Status auf `DELETED` gesetzt, werden die Inhaltsdaten (payload, pdf, xml, attachments) unwiderruflich gelöscht.
++
++___
++
++## Nachricht
++
++Unter dem `message`-Endpunkt lassen sich Nachrichten zu einzelnen Transaktionen austauschen.
++
++### Neue Nachricht erzeugen
++
++Eine Nachricht kann über einen POST an eine Url mit folgendem Muster erzeugt werden:\
++`/message/<Mandant>/<Transaktions-ID>/create`\
++Als Rückgabewert erhält man lediglich die Nachrichten-ID des neuen Eintrags. Enthält der POST einen Body, so wird dieser als Nachrichtentext verwendet.
++
++### Übersicht
++
++Eine Übersicht der Nachrichten zu einem einzelnen Vorgang können über `/message/<Mandant>/<Transaktions-ID>` abgerufen werden. Als Antwort erhält man ein JSON-Array in folgender Form:
++
++```
++[{
++  "id":"581754a5bf962e5318d90f7b",
++  "transID":"AS_940000-gsh7ntqS",
++  "changedDate":1477924005742,
++  "status":"NEW",
++  "text":null,
++  "size":0,
++  "files":[]
++}]
++```
++
++### Details
++
++Die Details zu einer einzelnen Nachricht inkl. Nachrichtentext und Verweisen auf hinterlegte Dateien können über eine URL der folgenden Form abgerufen werden: `/message/<Mandant>/<Transaktions-ID>/<Nachrichten-ID>`
++
++### Text
++
++Soll der Text einer Nachricht nachträglich hinzugefügt oder geändert werden, kann dies über einen Post an die Detail-URL bewerkstelligt werden. Der neue Text ist dabei als POST-Body zu übergeben.
++
++### Status
++
++Auch Nachrichten besitzen ein Status-Attribut. Dieses kann dadurch geändert werden, dass man eine POST-Nachricht an die Detail-URL mit einem zusätzlichen `setStatus`-Parameter sendet. Gültige Statuswerte sind:
++
++- NEW
++- READ
++- CLOSED
++- PRELIMINARY
++- HIDDEN
++- DELETED
++
++> ***Hinweis:***
++> Wird der Status auf `DELETED` gesetzt, werden der Text und alle Dateianhänge unwiderruflich gelöscht.
++
++___
++
++## Nachrichtenanhang
++
++Zu jeder Nachricht können auch Dateien hinterlegt werden. Dies erfolgt unter dem `file`-Endpunkt.
++
++### Hinzuzufügen
++
++Um eine neue Datei einer Nachricht hinzuzufügen, kann diese an eine URL der Form:\
++`/file/<Mandant>/<Nachtrichten-ID>/add` als POST gesendet werden. Der Dateiname muss dabei als Parameter `filename` übergeben werden. Der Contenttype wird dem entsprechenden HTTP-Header entnommen.
++
++### Übersicht
++
++Die Dateien, die zu einer Nachricht vorhanden sind, können der Detailansicht der Nachricht entnommen werden.
++
++___
++
++## Abruf
++
++Die Metadaten der einzelnen Dateien sind unter URLs der folgenden Form abrufbar:\
++`/file/<Mandant>/<Nachricht-ID>/<Datei-ID>`.\
++Um den Inhalt abzurufen, muss die URL nur um `/data` ergänzt werden. Der Contenttype wird dabei auf den Wert gesetzt, der beim Hochladen verwendet wurde.
++
++### Löschen
++
++Einzelne Dateien können über die Detail-URL auch wieder gelöscht werden. Dazu ist die HTTP-Methode DELETE zu verwenden.
++
++___
++
++### Beispielanwendung
++
++Um die Schnittstelle beispielhaft bedienen zu können, wird eine Demoanwendung unter folgender URL bereitgestellt: https://vertrieb.form-solutions.de/submission/swagger-ui/index.html
++
++Ebenso steht dem Anwender mit dieser Beispielanwendung eine technische Dokumentation bereit, welche die einzelnen Ressourcen detaillierter beschreibt.
++
++