Mobile EGO und EPM in der PWA-Architektur

Ein Produktionsboden, ein Lagerhaus, Sicherheit am Tor – das ist eine Umgebung, in der ein Mitarbeiter ein Handy in der Hand hält, oft mit Handschuhen, wenig Licht und keinerlei Geduld für browserbasierte Menüs, die für die Maus entwickelt wurden. HIT4B3, unsere Plattform, die in der SPA-Architektur auf uniGUI gebaut wurde, funktioniert hervorragend auf dem Desktop – aber Mobile ist eine völlig andere Welt. Anstatt eine separate Anwendung (native oder hybrid) zu schreiben, erweiterten wir das bestehende Ökosystem mit einem dedizierten mobilen Modus und paketierten es als Progressive Web App.

Ein Backend, zwei Schnittstellen

uniGUI ermöglicht es, klassische TUniForm (Desktop) und mobile TUnimForm (Kartenlayout, große Buttons, Touch-Gesten) parallel im selben Projekt auszuführen. Der Server erkennt den Gerätetyp und liefert die entsprechenden Formulare – Geschäftslogik, Firebird-Datenbank, Verbindungspooling und i18n werden 1:1 zwischen den Versionen geteilt. Jedes Modul hat sein eigenes mobile/:

• EGO – Entry Portal (Login, Firmenauswahl, Weblink-Liste)
• EPM – Schutzmodul mit QR-Scan und Bestehensbestätigung
• _shr/mobile/ – Komponenten, die zwischen Modulen geteilt werden.

EGO als SSO Gateway

Der Nutzer meldet sich einmal bei EGO an und startet von dort einzelne Weblinks. Auf dem Handy lädt der ausgewählte Weblink im Vollbildbild, und EGO verwaltet die Sitzung im Hintergrund. Der Mechanismus basiert auf einmaligen verschlüsselten Tokens:

1. EGO erzeugt einen einmaligen Token – eine verschlüsselte Menge von Befehlen
2. Speichert es zusammen mit dem Kontext (Firma, Sprache, Berechtigungen) in der Datenbank.
3. öffnet die Ziel-Weblink-Adresse mit dem mobilen Modus und dem Token-Umschalter
4. Das Zielmodul entschlüsselt das Token, verifiziert es mit einem Eintrag in der Datenbank und meldet den Benutzer automatisch an

Dies stellt sicher, dass der Benutzer sich nicht ein zweites Mal anmeldet, obwohl darunter separate Anwendungsprozesse laufen.

Das schwierigste Problem: eine Live-Sitzung in zwei Anwendungen gleichzeitig

Im mobilen Browser haben wir zwei unabhängige UniGUI-Sitzungen gleichzeitig – EGO und den darin eingebetteten Weblink – und das native OnSessionIdle-Ereignis zeigt einen bestätigten Fehler und löst für TUnimForm überhaupt nicht aus. Lösung:

• Zähler statt Ereignis – Wiederkehrender TUniTimer statt auf das OnSessionIdle-Ereignis zu vertrauen
• Ein gemeinsamer Herzschlag zwischen den Frames über window.postMessage, sodass ein einziger Berührung irgendwo den Leerlaufzähler beider Sitzungen zurücksetzt
• Konsistenter Warnbildschirm – Ein Modalfenster mit einem Countdown, bevor die Sitzung abläuft; wenn die EGO-Sitzung abläuft, beendet die Nachricht auch die eingebettete Weblink-Sitzung

Der letzte Schritt: PWA

Minimale manifest.json (Name, Symbole, eigenständiger Modus ohne Adressleiste) und absichtlich "leerer" Service Worker – HIT4B3 EGO ist eine stateful Anwendung mit einer WebSocket-Sitzung, daher würde das Caching von Inhalten die Konsistenz der Sitzung stören. Service Worker existiert ausschließlich, um das technische Kriterium der Installierbarkeit in Chrome/Android zu erfüllen. Das Ergebnis: Das Telefon schlägt "Zum Startbildschirm hinzufügen" vor, und von diesem Moment an funktioniert HIT4B3 wie eine native App – keine Adressleiste, kein eigenes Symbol, kein separater mobiler Code außerhalb der Präsentationsebene.

Dieser Ansatz unterstützt bereits heute das Mobile Protection Module (EPM) und wird die Grundlage für zukünftige webbasierte Anwendungen im mobilen Modus bilden.

Eine vollständige, technische Beschreibung der Architektur – mit Details zur Implementierung des Token-SSO, zum Keepalive-Mechanismus und zur PWA-Konfiguration – findet sich im Artikel auf unserer Website: HIT4B3 am Telefon: wie wir EGO und EPM Mobile Mode in der PWA-Architektur gebaut haben.