Mobile EGO et EPM dans l’architecture PWA

Un sol de production, un entrepôt, la sécurité à la porte — c’est un environnement où un employé tient un téléphone à la main, souvent avec des gants, une faible luminosité et aucune patience pour les menus navigateurs conçus pour la souris. HIT4B3, notre plateforme construite dans l’architecture SPA sur uniGUI, fonctionne très bien sur ordinateur — mais le mobile est un tout autre monde. Au lieu d’écrire une application distincte (native ou hybride), nous avons élargi l’écosystème existant avec un mode mobile dédié et l’avons présenté sous forme d’application Web progressive.

Un backend, deux interfaces

uniGUI permet d’exécuter en parallèle TUniForm classique (bureau) et TUnimForm mobile (disposition de cartes, gros boutons, gestes tactiles) dans le même projet. Le serveur reconnaît le type de périphérique et sert l’ensemble approprié de formulaires — la logique métier, la base de données Firebird, le pooling de connexions et l’i18n sont partagés en 1:1 entre les versions. Chaque module possède son propre mobile / :

• EGO - Portail d’entrée (Connexion, Sélection de l’entreprise, Liste de liens Web)
• EPM - Module de Protection avec scan QR et confirmation de passage
• _shr/mobile/ - Composants partagés entre modules.

EGO en tant que passerelle SSO

L’utilisateur se connecte une fois à EGO, puis lance des liens web individuels. Sur mobile, le lien web sélectionné se charge en plein écran, et EGO gère la session en arrière-plan. Le mécanisme est basé sur des jetons chiffrés à usage unique :

1. EGO génère un jeton à usage unique – un ensemble de commandes chiffrées
2. Sauvegarde dans la base de données avec le contexte (entreprise, langue, permissions)
3. Ouvre l’adresse du lien web de destination avec le mode mobile et le basculement du jeton
4. Le module cible déchiffre le jeton, le vérifie avec une entrée dans la base de données, et connecte automatiquement l’utilisateur

Cela garantit que l’utilisateur ne se reconnecte pas, même s’il existe des processus applicatifs séparés en cours en dessous.

Le problème le plus difficile : une session en direct sur deux applications à la fois

Dans le navigateur mobile, nous avons deux sessions uniGUI indépendantes en même temps — EGO et le lien web intégré — et l’événement natif OnSessionIdle présente une erreur confirmée et ne se déclenche pas du tout pour TUnimForm. Solution :

• Compteur au lieu d’événement - TUniTimer récurrent au lieu de dépendre de l’événement OnSessionIdle
• Un battement de cœur commun entre les images via window.postMessage, de sorte qu’un simple toucher n’importe où réinitialise le compteur d’inactivité des deux sessions
• Écran d’avertissement cohérent - Une fenêtre modale avec un compte à rebours avant l’expiration de la session ; si la session EGO expire, le message met également fin à la session weblink intégrée

La dernière étape : PWA

Un manifest.json minimal (nom, icônes, mode autonome sans barre d’adresse) et intentionnellement « vide » - HIT4B3 EGO est une application avec un état avec une session WebSocket, donc mettre en cache le contenu briserait la cohérence de la session. Service Worker existe uniquement pour répondre au critère technique de l’installabilité dans Chrome/Android. Le résultat : le téléphone propose « Ajouter à l’écran d’accueil », et à partir de ce moment, HIT4B3 fonctionne comme une application native — pas de barre d’adresse, pas d’icône propre, pas de code mobile séparé en dehors de la couche de présentation.

Cette approche supporte déjà aujourd’hui le Mobile Protection Module (EPM) et servira de base à de futures applications web lancées en mode mobile.

Une description technique complète de l’architecture — avec des détails sur l’implémentation du token SSO, du mécanisme keepalive et de la configuration PWA — se trouve dans l’article sur notre site : HIT4B3 on the phone : how we built EGO and EPM mobile mode in the PWA architecture.