← Alle Projekte
Produktiv im Einsatz
GFK-Service
Rollenbasierte Reparatur- und Bestandsverwaltung für GFK-Gießformen mit Echtzeit-Sync über drei native Apps
Die Herausforderung
In der GFK-Formenfertigung durchlaufen Gießformen mehrere Abteilungen (Mischanlage/Grundierung, GFK-Werkstatt, Schlosserei), wenn sie repariert werden müssen. Ohne ein gemeinsames System ist unklar, wo sich eine Form gerade befindet, welche Reparaturen offen sind und wer informiert werden muss. GFK-Service löst das als zentrale, rollenbasierte Anwendung, die den Reparaturstatus jeder Form abbildet und alle Endgeräte in Echtzeit auf demselben Stand hält.
Das Ziel
Eine zentrale, rollenbasierte Reparatur- und Bestandsverwaltung für GFK-Gießformen, die alle beteiligten Abteilungen (Mischanlage/Grundierung, GFK, Schlosserei) über Desktop, Tablet und Handy in Echtzeit synchron hält – mit NFC-/Deep-Link-Erfassung direkt an der Form.
Die Lösung
- Reparaturverwaltung mit Lebenszyklus: Reparatur anlegen, an GFK oder Schlosserei weiterleiten, freigeben oder Form als entsorgt markieren – jede Aktion setzt automatisch den Status der Form (Aktiv, In GFK, In Schlosserei, außer Haus, Entsorgt)
- Rollenbasierter Zugriff: Benutzergruppen (admin, mischanlage, grundierung, gfk, schlosserei) sehen nur die für sie relevanten Reparaturen und dürfen nur erlaubte Aktionen ausführen – serverseitig in der API und zusätzlich im Deep-Link-Handler geprüft
- Echtzeit-Synchronisation über WebSocket: Beim Anlegen, Ändern, Weiterleiten oder Löschen einer Reparatur wird ein Broadcast an alle verbundenen Clients gesendet (Events reparatur_created/updated/deleted, form_updated), inkl. Heartbeat-Ping und automatischer Reconnect-Logik
- Drei native Flutter-Frontends aus einer gemeinsamen Codebasis: Desktop (Verwaltung, Statistik, PDF-Export), Tablet (Werkstatt, Querformat) und Handy – jeweils auf das Einsatzszenario zugeschnitten
- NFC-/Deep-Link-Erfassung an der Form: NFC-Tags bzw. App-Links (Schema app://gfk-service.eu und https-App-Links) lösen direkt Aktionen aus – Reparatur erstellen, weiterleiten, freigeben, Entsorgung bestätigen – verarbeitet über uni_links5 und einen zentralen DeepLinkHandler
- Automatische E-Mail-Benachrichtigungen je Ereignis und Abteilung über Mailjet (neue Reparatur, Weiterleitung, Freigabe, Entsorgung, Widerruf) mit getrennten Empfängerlisten pro Abteilung
- Stammdaten- und Bestandsverwaltung: Formen (mit Seriennummer, RFID, Volumen, Form-Art, Form-Bezeichnung/Artikelnummer), Modelle, Holzformen, Reparaturbereiche und Mitarbeiterlisten
- Lückenlose Historie: abgeschlossene Reparaturen werden mit eingefrorenem Form-Namen (Snapshot), Bereichen, Mitarbeiter und Datum archiviert, sodass der historische Kontext auch nach Umbenennungen erhalten bleibt
- Auswertungen und Diagramme: Top-Formen pro Monat, häufigste Reparaturbereiche der Top-Formen, monatlicher 12-Monats-Verlauf und formspezifische Reparaturstatistik
- Volltextsuche über die Listen (Formen, Reparaturen, Historie, Modelle, Holzformen) sowie PDF-Export der Listen im Desktop-Client
- Zentrales Frontend-Logging: die Apps schicken Logeinträge an einen API-Endpunkt, der sie serverseitig in Dateien protokolliert
Technik & Architektur
- Backend: Django mit Django REST Framework, Django Channels (ASGI) und Daphne als Server; Token-Authentifizierung, gruppenbasierte Berechtigungen, DjangoFilterBackend/SearchFilter, seitenweise Paginierung
- Echtzeit: Channels mit Redis als Channel Layer; eigener ReparaturConsumer mit Gruppen-Broadcast und eigene Token-Auth-Middleware für WebSocket-Verbindungen (Token im Query-String)
- Datenbank: MySQL (mysqlclient) mit erzwungener SSL-Verbindung über CA-Zertifikat; Modelle teils auf bestehende Tabellennamen gemappt (managed/db_table), Form-Bezeichnung in eigener Tabelle (AppFormBz) ausgelagert
- E-Mail: Mailjet (mailjet-rest) über einen gekapselten EmailService/MailHandler mit abteilungsspezifischen Empfängerlisten aus Umgebungsvariablen
- Konfiguration/Sicherheit: Secrets und Hosts via .env (python-dotenv), DEBUG/ALLOWED_HOSTS aus Umgebung, RotatingFileHandler-Logging, Proxy-SSL-Header für Betrieb hinter Reverse Proxy
- Frontends: Flutter (Dart SDK ^3.7.x), gemeinsame Architektur mit Models/Screens/Services; Riverpod/Hooks (Desktop), flutter_secure_storage für Token und Rollen, http für REST, web_socket_channel für Live-Updates, intl/Lokalisierung de-DE
- Frontend-Features: PDF-Erstellung/-Druck (pdf, printing, open_filex) im Desktop-Client; Diagramme mit fl_chart/graphic; Deep-Links via uni_links5 (Tablet/Handy); window_manager für Desktop/Tablet-Fenster
- Deployment: Containerisierung per mehrstufigem Dockerfile (python:3.12-slim, eigener Non-Root-User, Daphne als Entrypoint); Betrieb auf Hetzner-Server via Docker Compose (MySQL 8, Redis 7, Gotenberg, Nginx Proxy Manager) hinter HTTPS/WSS auf api.gfk-service.eu
- Härtung des Servers: fail2ban/UFW-Konfiguration und Tailscale im Server-Datensatz vorhanden
Nutzen in der Praxis
- Jederzeit nachvollziehbar, wo sich eine Form befindet und welche Reparaturen offen sind – über Desktop, Tablet und Handy konsistent
- Echtzeit-Updates verhindern, dass Abteilungen auf veralteten Listen arbeiten oder Aktionen doppelt ausführen
- Rollenmodell reduziert Fehlbedienung: jede Abteilung sieht und darf nur das, was für sie vorgesehen ist
- NFC-/Deep-Link-Erfassung direkt an der Form spart Tipparbeit und Verwechslungen bei der Seriennummer
- Automatische E-Mails informieren genau die zuständige Abteilung ohne manuelle Benachrichtigung
- Lückenlose Historie mit Namens-Snapshot erhält den historischen Kontext auch bei späteren Umbenennungen
- Auswertungen machen wiederkehrende Schwachstellen (häufig reparierte Formen/Bereiche) sichtbar
- Containerisiertes Deployment ermöglicht reproduzierbaren, abgesicherten Betrieb auf eigener Infrastruktur
Meine Rolle
Ricardo Rehfeldt: Konzept, Entwicklung und Umsetzung eigenständig – Backend-Architektur (Django REST + Channels), drei Flutter-Clients, Echtzeit-/E-Mail-Logik und das Docker-Deployment auf dem eigenen Hetzner-Server.