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, Message und XML

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:

ACT03 Statusänderung: Antrag einer Fachabteilung zugeordnet
ACT04 Statusänderung: Antrag in Bearbeitung
ACT06 Statusänderung: Antrag zurückgestellt
ACT07 Statusänderung: Antrag storniert
ACT08 Statusänderung: Antrag abgeschlossen
ACT05 Ü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.

Einleitung
Kommunikation zwischen optiGov und einem DMS
➡️ Von optiGov zum DMS
⬅️ Vom DMS zu optiGov
Der Web-Hook
Die GraphQL-API