Anwender
HilfeChangelogAdministratoren
Einrichtung BundIDWidget erstellenCSV-Mitarbeiter-ImportAnbindung Active DirectoryAnbindung d.velop documentsAnbindung Exchange ServerEinrichtung BesucherverwaltungAnbindung FormularserverDienstleister
Webseiten-WidgetSuch- und GraphQL-APIEinbindung TerminvereinbarungPartner
Anbindung DMSAnbindung FormularserverOAuth2.0Einleitung
optiGov unterstützt die Anbindung von Dokumentenmanagementsystemen (DMS) auf bi-direktionalem Weg.
Das bedeutet, dass zum Einen von Bürgern eingereichte Anträge direkt als digitale Akte im DMS gespeichert werden können. Dazu gehören i.d.R. nicht nur die menschenlesbare PDF-Datei des Antrags, sondern auch eine maschinenlesbare XML-Datei für den Export in weitere Fachverfahren. Darüber hinaus kann optiGov auch Nachrichten und Dokumente aus dem Postfach des Bürgers in die digitalen Akten überspielen.
Zum Anderen kann mithilfe der APIs von optiGov aber auch der Rückkanal bespielt werden. Das bedeutet, dass Statusänderungen, Direktnachrichten und Bescheide zu Anträgen vom DMS an optiGov übermittelt werden und von dort automatisch dem Bürger verschlüsselt und sicher zugestellt werden können (inkl. Benachrichtigungen).
Dies alles ermöglicht dem Mitarbeiter der Verwaltung eine einfachere Bearbeitung seiner Anträge und Zuständigkeiten in seinem Arbeitsalltag, da dieser nicht mehr zum Bearbeiten von Anträgen in das optiGov-Backend wechseln und zwei Anwendungen bedienen muss.
Kommunikation zwischen optiGov und einem DMS
Die Kommunikation zwischen optiGov und einem DMS teilt sich in zwei unterschiedliche Phasen auf. Zum Einen existiert die Übermittlung von Daten von optiGov zu dem DMS (kurz “Hinweg”) und zum Anderen die Übermittlung von Daten von dem DMS zu optiGov zurück (kurz “Rückweg”).
➡️ Von optiGov zum DMS
optiGov bindet sich an ein DMS über eine “Content Management Interoperability Services” (CMIS) -Schnittstelle mit Browser Binding an. CMIS ist ein offener und herstellerunabhängiger Standard zur Anbindung von Content-Management-Systemen (siehe Wikipedia).
Für die Anbindung an das Browser Binding der CMIS-Schnittstelle des DMS werden folgende Informationen benötigt:
- Benutzer und Passwort zur Authentifizierung
- URL des Browser Binding Endpoints
- Repository-ID des Kunden
- CMIS-Bezeichner für
Folder,Document,MessageundXML
Dabei ist ein Folder ein Ordner, bzw. eine digitale Akte, welche zu einem neuen Antrag angelegt wird. Das Document ist z.B. eine PDF-Datei welche von dem Formular-Server übertragen, oder von einem Bürger über den Chat nachgereicht wurde. Eine Datei vom Typ Message ist eine Nachricht, welche von einem Mitarbeiter über das DMS gesendet wurde und an das Portal übermittelt wird oder von diesem in dem Ordner abgelegt wurde und von einem Bürger verfasst wurde. Bei einer Datei vom Typ XML handelt es sich i.d.R. um Portaldaten, welche vom Formular-Server neben einer menschenlesbaren Datei wie einer PDF übertragen wurden und zur weiteren Verarbeitung wie z.B. der Weitergabe an ein Fachverfahren angehängt werden.
⬅️ Vom DMS zu optiGov
Damit das DMS mit optiGov kommunizieren kann gibt es zwei zentrale Mechanismen. Zum Einen existiert ein Web-Hook, mit welchem der optiGov-Instanz mitgeteilt werden kann, dass z.B. eine Nachricht oder ein neuer Bescheid für den Bürger vorliegt und zum Anderen die von optiGov bereitgestellte GraphQL-API mit welcher weitere Informationen zu Anträgen und Bürgern abgefragt werden können.
Der Web-Hook
Der Web-Hook dient lediglich der Benachrichtigung über das Vorhandensein neuer Dokumente innerhalb des DMS. Diese werden dann über der CMIS-Schnittstelle von optiGov abgeholt und weiterverarbeitet.
Der Web-Hook ist über die URL https://[ihre-optigov-installation.dd]/api/dms/[ihr-dms-provider]/remit zu erreichen und empfängt die Informationen über eine POST-Request mit dem Aufbau des folgenden Beispiels:
{ "ApplicationId": "384", "Event": "ACT04", "Timestamp": "08.07.2022 08:08:08", "ObjectIds": [ "P000000807" ]}Hierbei ist die ApplicationId die von optiGov übermittelte ID des Antrags.
Das Event setzt sich aus einem der folgenden Werte zusammen:
ACT03Statusänderung: Antrag einer Fachabteilung zugeordnetACT04Statusänderung: Antrag in BearbeitungACT06Statusänderung: Antrag zurückgestelltACT07Statusänderung: Antrag storniertACT08Statusänderung: Antrag abgeschlossenACT05Übermittlung einer neuen Portalnachricht
Der Timestamp gibt den Zeitpunkt an, zu welchem das Event ausgelöst wurde.
Die ObjectIds sind die eindeutigen IDs der abzurufenden Dokumente. Die erste ID ist immer die ID der Nachricht (falls übermittelt). Alle weiteren IDs sind die IDs der Anhänge (z.B. der Bescheid)
Die GraphQL-API
Neben diesen Funktionalitäten kann das DMS über die GraphQL-API von optiGov weitere Informationen zu einem Antrag abrufen. Dazu gehören alle Details eines Bürgers, des zugehörigen Formulars und der Dienstleistungen, der zuständigen Mitarbeitern uvm.
Da diese Informationen sehr sensibel sind, muss sich das DMS zuerst über die OAuth2.0-Schnittstelle authentifizieren ( siehe OAuth2.0-Schnittstelle). Dabei muss das erstellte Token mindestens über den Scope antrag.readonly verfügen, bzw. diesen bei der Request anfragen.
Eine GraphQL-Query um alle Informationen zu einem bestimmten Antrag anhand der ID abzufragen, kann wie folgt ausehen:
{
antrag(id: 1) {
id
transaktionsbezeichner
status
cmis_object_id
erstellt
bearbeitet
buerger {
id
provider_id
anrede
doktorgrad
geschlecht
vorname
mittelname
nachname
name
geburtsname
kuenstlername
email
strasse
hausnummer
plz
ort
land
anschrift
geburtsdatum
geburtsort
vertrauensstufe
erstellt
aktualisiert
}
formular {
id
externe_id
bezeichner
url
titel
erstellt
bearbeitet
dienstleistungen{
id
leistungsbezeichnung
}
}
mitarbeiter {
id
name
email
telefon
telefon_mobil
fax
raum
erstellt
bearbeitet
}
}
}Hinweis: Hier werden sehr viele Felder abgefragt die i.d.R. nicht benötigt werden. Passen Sie daher die GraphQL-Query and Ihre Bedürfnisse an, um benötigte Ressourcen, Bandbreite und Antwortzeit zu minimieren.