Evaluierung Dateneingabe Form.io und Open forms

Ziel

Die vorhandene Evaluierung von Tools zur Dateneingabe soll um die weiteren Optionen Form.io und Open Forms ergänzt werden, um zu evaluieren, inwiefern diese Lösungen eine niederschwellige Datenerfassung im Vergleich zu mgm A12 erlauben.

Optionen

1) nur Form.io JS Renderer

https://github.com/formio/formio.js (Lizenz: MIT)

In dieser Variante wird der JavaScript‑Renderer von Form.io verwendet, um ein mit dem öffentlich verfügbaren Form.io‑Builder erstelltes Formular in einer Custom‑Web‑Applikation darzustellen. Das vom Builder erzeugte Formular‑JSON wird direkt eingebunden, ohne ein extern gehostetes Formular zu referenzieren. Die Web‑Applikation erzwingt die Authentifizierung der Nutzer über Keycloak. Das Absenden der Formulardaten erfolgt über das API‑Gateway, welcher die Authentifizierung prüft, bevor die Daten an eine PostgREST‑Schnittstelle weitergeleitet und dort in einer PostgreSQL‑Fachdatenbank persistiert werden.

formtools_formiojs.drawio.png

Vorteile

  • Kein Setup und Hosting eines dezidierten Formular-Tools nötig.
  • Das Formular kann einfach von jedem über externen Form.io Formbuilder erstellt werden und als JSON Beschreibung exportiert werden

Nachteile

  • Es muss von einem Entwickler eine eigene Custom Web-App für die Darstellung des Formulars erstellt werden. Im dargestellten Anwendungsfall bedeutet das eine Web-App pro Formular.
  • Es muss über PostgREST eine eigene API für das Formular bereitgestellt und von Operations konfiguriert werden.
  • Die Felder in der Postgres-Tabelle für die Formularsubmissions müssen manuell von Operations so angelegt werden, dass sie denen im Formular entsprechen.
  • Formularanpassungen müssen direkt in der Custom Web-App vorgenommen werden, da das Ursprungsformular nicht direkt über den Form-Builder erweitert oder angepasst werden kann.
  • Wenn bei Formularanpassungen neue Felder hinzukommen müssen diese von Operations im DB-Schema nachgezogen werden.
  • Abhängigkeit von externen Formbuildern zur Generierung des JSON für das Formular.

2) selbstgehostetes Open-Source Form.io

https://github.com/formio/formio (Lizenz: OSL-v3, nicht kompatibel zu Redistribution unter EUPL)

In dieser Variante wird die Open Source Variante von Form.io in der Datenfabrik bereit gestellt. Diese enthält ein sogenanntes "Developer Portal" in dem Formulare angelegt und Formularsubmissions eingesehen und exportiert werden können und die Form.io API. Die Daten werden in einer MongoDB gespeichert. Die Anzeige des Formulars würde wie schon in Variante 1 in einer Custom‑Web‑Applikation über den Form.io JS Renderer erfolgen. Allerdings könnte das Formular hierbei referenziert werden und es wird keine eigene API für die Speicherung der Daten benötigt.

formtools_formio.drawio.png

Vorteile

  • Formularanpassungen können direkt im Open Source Form Builder erfolgen, da die Formulare in der Custom Web-App nur referenziert werden.
  • Es muss keine eigene API für die Speicherung der Formulardaten erstellt werden, da diese schon vorhanden ist und die Daten der referenzierten Formulare automatisch über die bereitgestellte API in der MongoDB gespeichert werden.
  • Wenn neue Felder im Formular hinzugefügt werden ist keine Anpassung des DB-Schemas nötig.

Nachteile

  • Daten werden in einer MongoDB und nicht in einer Postgres Fachdaten-DB gespeichert, damit kommt eine Infrastruktur-Komponente hinzu und es sind weitere Schritte notwendig um die Daten z.B. mittels Airflow verfügbar zu machen.
  • Die Oberfläche des Open Source Developer Portals ist eher rudimentär.
  • Für die Open Source Variante wird keine Keycloak/OIDC-Integration für den Login in das Developer Portal unterstützt.
  • Das Open Source Developer Portal ist nicht mandantenfähig und unterstützt nur verschiedene Rollen, sodass ein Zugriff auf nur bestimmte / einer gewissen Benutzergruppe zugeordnete Formulare und Formularsubmissions nicht einfach umsetzbar ist.
  • Es muss von einem Entwickler eine eigene Custom Web-App für die Darstellung des Formulars erstellt werden.

3) Open Forms

https://github.com/open-formulieren/open-forms (Lizenz: EUPL)

In dieser Variante wird Open Forms in der Datenfabrik bereit gestellt. Für ein Formular kann im Open Forms Backend jeweils eine Slug und die Form der Authentifizierung festgelegt werden. Unter dieser Slug kann das Formular dann im Frontend abgerufen werden. Das Rendering funktionert über den Open Forms SDK JS Renderer. Dieser sendet auch die Formulardaten an die Open Forms Rest API, welche die Daten dann in einer Postgres-DB persistiert. Im Backend ist für die Formularerstellung der Form.io Formbuilder mit einigen Anpassungen eingebunden.

formtools_openforms.drawio.png

Vorteile

  • OIDC-Integration für Backend und Formulare
  • funktionierender File-Upload für Formulare
  • keine Custom App nötig
  • keine extra API nötig

Nachteile

  • Benutzeroberfläche im Backend ist sehr komplex.
  • Das Backend ist etwas buggy. Beim Formularanlegen tritt zum Beispiel bereits direkt ein Fehler auf oder wenn man bei der Konfiguration der einzelnen Formularschritte auf den englischen Tab wechselt.
  • Im Backend werden beim Erstellen der Formulare für die Eingabe der Texte immer zuerst ein "NL"-Tab für die Eingabe der holländischen Texte und anschließend ein "EN"-Tab für die Eingabe der englischen Texte angezeigt. Das bleibt selbst so wenn man die Standard-Sprache von Holländisch auf Englisch ändert. Es scheint nicht ganz einfach möglich zu sein im Backend holländisch komplett zu entfernen und durch deutsch zu ersetzen.
  • Es gibt keine deutschen Übersetzungen für open forms, Formulare selbst können aber mit deutschen Texten erstellt werden.
  • Die Dokumentation - speziell das Manual für die Redakteure - ist zum Teil nur auf holländisch.

Evaluierung aller Optionen

Form.io (open source) Open Forms NocoDB Grist Baserow Mathesar LimeSurvey
Lizenz formio (core): OSL-3.0 formio.js: MIT EUPL-1.2 AGPL-3.0 Apache-2.0 Open Core (MIT/Enterprise) GPL-3.0 GPL-2.0
Github-Stars formio: 2.280 formio.js: 2.074 55 59.064 10.200 3.516 4.675 3.447
Entstehungsjahr 2015 2020 2018 2021 2020 2021 2006
SSO ✗ ✓ ✗ (nicht in CE) ✓ ✗ (nicht in CE, aber in Advanced) ✓ ✗ (über unterschiedliche Community Plugins möglich)
kein Feature-Gating (bestimmte Features nur in Enterprise Versionen) ✗ ✓ ✗ ✗ ✗ ✓ ✓
Custom Logik/Erweiterung möglich ✓ ✓ ✓ (aber AGPL-3.0, nicht EUPL-kompatibel) ✓ ✓ ✗ ✓ (aber GPL-2.0, nicht EUPL-kompatibel)
Tabellarische Ansicht der Daten ✓ ✓ ✓ ✓ ✓ ✓ ✓
Formular zur Dateneingabe ✓ ✓ ✓ (in CE nur mit nocodb branding) ✓ ✓ (in CE nur mit baserow branding) ✓ (mit mathesar branding) ✓
Formularansicht nur für authentifizierte Nutzer möglich ✗ ✓ ✗ ✗ ✓ (über Application Builder - derzeit Beta - möglich) ✗ ✗ (über das kostenpflichtige SSO Community Plugin möglich)
Formulardatenspeicherung mit User Kontext ✗ ✓ ✗ (nur mit Erweiterung) ✗ (nur mit Erweiterung) ✗ (nur mit Erweiterung) ✗ ✗ (nur mit Erweiterung)
Datenimportformate ✗ ✗ XLS, CSV XLS, CSV CSV, XML, JSON CSV CSV
Installation einfach einfach einfach, keine weiteren Dependencies einfach aber nicht skalierend ausgelegt (benötigt rwx) einfach einfach kein offizieller Docker-Setup-Support, aber über Community
Komponenten viele sehr viele/komplex einfach einfach viele/schwergewichtig einfach viele/komplex
Persistenz der Daten DB (MongoDB) DB (pg) DB (pg, sqlite, mysql) sqlite file/s3 DB (pg) DB (pg) DB (mariadb, mysql, mssql, pg)
Visuelle Oberfläche (max. 3 Sterne) ★★ ★★ ★★★ ★★ ★★★ ★ ★★
Preise für benötigten Funktionsumfang 0 Euro (in Open Source keine Unterteilung in Projekte und kein Dateiupload) 0 Euro Für Business $216 pro Monat, jährlich abgerechnet für unlimitierte Useranzahl (falls Audit-Logs benötigt werden Enterprise ohne Preisangabe) 0 Euro (für diverse Admin-Funktionen und mehrere Team-Sites $24 per User/Monat) Für Advanced $18 per User/Monat jährlich abgerechnet 0 Euro 0 Euro (falls für SSO das kostenpflichtige Plugin benötigt wird, einmalig 249 Euro)

Fazit

Option 1: nur Form.io JS Renderer

Die leichtgewichtigste Variante die nur den Form.io JS Renderer in einer Custom Web Applikation nutzt ist sehr niederschwellig für den Formularersteller. Sie könnte für einfache Formulare geeignet sein, solange kein Dateiupload benötigt wird. Hier entstehen allerdings im Vergleich zu anderen Formulartools Entwicklungs- und Betriebsaufwände, sowohl initial als auch bei Formularanpassungen.

Option 2: selbstgehostetes Form.io Open Source

Bei der selbstgehosteten Form.io Open Source Variante hat man den Vorteil, dass Formulare referenziert werden können und die API schon mitkommt. Da das Open Source Developer Portal, also das bereitgestellte Backend für Form.io, keine sinnvolle Trennung von Benutzergruppen ermöglicht und die Daten in einer MongoDB speichert bietet diese Variante für unsere Anwendungsfälle keinen allzu großen Mehrwert. Zudem erlaubt die OSL Lizenz keine Redistribution unter der EUPL.

Option 3: Open Forms

Open Forms bietet viele Vorteile wie etwa die Definition des Zugriffsschutzes pro Formular oder die OIDC-Integration für Backend und Frontend. Die Benutzeroberfläche zum Verwalten der Formulare und Submissions ist derzeit allerdings teilweise fehlerhaft und sehr überladen, sodass sich ein Redakteur hier schnell überfordert fühlen dürfte. Dazu kommt dass Open Forms einen klaren Fokus auf die Niederlande hat und es nicht ganz einfach möglich zu sein scheint im Backend holländisch komplett zu entfernen und durch deutsch zu ersetzen. Für eine niedrigschwellige Datenerfassung ist es daher keine gute Variante.