V.Z.docs, ein Softwareprojekt

IT | 11. Juli 2020

1 / 6
3-Tier-Architektur
2 / 6
DB-Verwaltung mit Sequel Pro
3 / 6
Applikationsentwicklung mit Xojo
4 / 6
Webentwicklung mit Coda
5 / 6
Debugger MacGDBp
6 / 6
Webservices testen mit Postman

Auch ich erhalte und versende wichtige Dokumente. Diese Dokumente müssen abgelegt und - weitaus aufwendiger - wiedergefunden werden. Um dies elektronisch zu erledigen entstand vor einigen Jahren ein selbst entworfenes Werkzeug: V.Z.docs.

Die Ausgangssituation

Die Ausgangssituation war die übliche: Papierdokumente werden in Ordnern, deren Inhalt mittels Register kategorisiert wird, abgelegt. Die Sortierung erfolgt nach Datum aufsteigend. Nichts wird fortgeworfen, alles wird gelocht und abgeheftet. Es stehen zehn Aktenordner im Regal.

Für elektronische Dokumente kann ich die Mittel eines Dateisystems (Baumstruktur, Ordner, Dateinamen) nutzen. Das von mir genutzte Betriebssystem macOS hat noch zusätzlich die Möglichkeit, Dateien mit Tags und Kategorien zu versehen und indiziert außerdem den Inhalt lesbarer Dokumente in einem ständig laufenden Hintergrundprozess. Damit ist bereits eine gute Archivierung von elektronischen Dokumenten und eine schnelle Recherche nach Inhalten möglich (ggf. ist das bei anderen Desktop-Betriebssystemen auch der Fall, diese kenne ich aber nicht gut genug).

Es bleibt aber der Medienbruch zwischen Papier und Bytes. Der kann auf zwei Wegen überwunden werden:

  • Elektronische Dokumente drucken und abheften
  • Papierdokumente scannen und speichern

Die erste Variante ist anachronistisch. Für die zweite Variante sind für macOS einige fertige Programme erhältlich. Nach dem Testen von zwei Desktop- und einer Weblösung habe ich festgestellt, dass keines dieser Programme meine Anforderungen gänzlich erfüllt (oder aber übererfüllt). Meine Ansprüche an ein solches Programm sind:

  • Kategorisierung nach Themen
  • Ablage der Dateien in einer flachen Baumstruktur
  • Durchsuchbarkeit von Metadaten und Inhalt
  • Verknüpfbarkeit mit anderen Daten wie z.B. Absender
  • Automatische Verschlagwortung
  • Nutzung der PDF-Metainformationen
  • Verknüpfung mit dem Papierarchiv
  • Pflege des Papierarchivs z.B. durch Vergabe von Aufbewahrungsfristen

Die erste praktisch nutzbare Version war im Januar 2011 fertig. Seitdem wurde das Programm ständig weiterentwickelt.

Die Architektur

Die Architektur der ersten Versionen war einfach, aber funktionell: Die Applikation hielt die Klassen für den Datenbankzugriff, die Datenbank selbst befand sich auf dem Client. SQL-Statement wurden direkt an die Datenbank abgesetzt. Mittlerweile ist das Leben (bewusst) komplizierter, die Architektur folgt dem klassischen 3-Tier-Modell und die Kommunikation mit der Datenbank dem RESTful-API Paradigma:

  • Tier 1 (Client-App) für die Datenein- und -ausgabe
  • Tier 2 (Web-Services) für die Businesslogik
  • Tier 3 (RDBMS u. Filesystem) für die Datenhaltung

(Für eine kleine privat genutzte App mit vielleicht ein paar tausend Datensätzen ist diese Architektur wie mit Kanonen auf Spatzen geschossen? Völlig übertrieben? Ja, das stimmt!)

Benutzte Entwicklungswerkzeuge

Die genutzte Datenbank ist MySQL. Es gibt eine Instanz für Entwicklung und Test auf dem Desktop, sowie eine Instanz mit den produktiven Daten auf dem NAS. MySQL übererfüllt sämtliche Anforderungen, die ich mir für eine privat genutzte Dokumentenverwaltung vorstellen kann und ich verfüge über genügend Erfahrung mit MySQL.

Die Desktop-Instanz ist Teil der MAMP-Distribution (MacOS Apache MySQL PHP), die produktive Instanz ist Teil der QNAP-NAS Software. Die Versionsstände der Datenbanken (und auch von PHP und Apache) der Instanzen sind selten identisch, was bisher noch kein Problem war.

Sequel Pro

Für die Verwaltung der Datenbank und dem Formulieren der SQL-Abfragen verwende ich das (kostenfreie) Tool Sequel Pro.

Datenbankverwaltung mit Sequel Pro

Xojo

Die Client-App wird mit Xojo entwickelt. Einer Cross-Platform-IDE, auf der Applikationen für macOS, Linux und Windows entwickelt werden können. Weiterhin können auch Apps für iOS und Android sowie für Webserver entwickelt werden.

Die IDE Xojo

Coda

HTML- und PHP-Dateien schreibe ich mit Coda 2 der Fa. Panic Inc., einem Web-Editor, der zwar die Möglichkeit eines Debugging vermissen lässt, der sich aber in allen anderen Belangen sehr gut für mich eignet.

Webentwicklung mit Coda

MacGDBp

Coda 2 hat - wie bereits erwähnt - keinen eigenen Debugger. Um PHP zu debuggen verwende ich daher das Tool MacGDBp. Dieses Programm wird aktuell leider nicht mehr weiterentwickelt.

Um PHP debuggen zu können, habe ich die Datei php.ini angepasst:
[xdebug] zend_extension="/Applications/MAMP/bin/php/php7.4.21/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so"
xdebug.file_link_format="txmt://open?url=file://%f&line=%1"
xdebug.var_display_max_depth = 20
xdebug.remote_enable=1
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_autostart=1
(Ggf. existiert ein weiterer "zend_extension"-Eintrag. Dieser kann gelöscht oder mit einem vorangestellten Semikolon deaktiviert werden. Welche php.ini-Datei die aktuell aktive ist und ob die obigen Änderungen übernommen wurden, kann mit dem Output von phpinfo.php ausgegeben werden.

PHP-Debugging mit MacGDBp

Postman

Zum Testen der Webservices ist schließlich und endlich die Applikation Postman im Einsatz.

Testdaten in Postman

Tags


Mehr zum Thema