Guidelines de développement d'une application déconnectée

Guidelines de développement d'une application déconnectée

Règles de conception à appliquer dès la conception de l'app

La page 4-Mode_deconnecte explique comment fonctionne le mode offline dans Vision. Cette page décrit comment construire une application pour qu'elle fonctionne réellement sans réseau.

Ces règles ne sont pas des optimisations : ce sont des prérequis. Une application conçue « normalement » puis testée en mode avion ne fonctionnera pas.

La règle d'or

Toute modification de données doit passer par un workflow, jamais par un smartflow.

Un smartflow s'exécute côté serveur → il échoue s'il n'y a pas de réseau.
Un workflow s'exécute côté client → il est empilé dans la file d'attente locale et rejoué automatiquement au retour de la connexion.

Besoin	Mode déconnecté	Outil
Lire les données au démarrage	Connecté (1re exécution)	Smartflow ou workflow
Créer / modifier / supprimer	Déconnecté	Workflow uniquement
Calculs, filtres, contrôles	Déconnecté	Workflow
Appels API tiers temps réel	Impossible	À proscrire

1 – Une page de connexion qui charge tout

La première page de l'application est une page de connexion / chargement. Son rôle n'est pas seulement d'authentifier : elle récupère l'intégralité des données nécessaires à toute la session.

L'utilisateur ouvre l'application (PWA installée) en étant connecté.
La page de connexion exécute les smartflows (ou workflows) de récupération.
Les jeux de données sont stockés dans le cache du navigateur embarqué.
L'utilisateur peut ensuite partir sur le terrain : plus aucun appel serveur n'est nécessaire.

Important
Ce chargement initial doit être exhaustif. Toute donnée non chargée à cette étape sera indisponible hors ligne — il n'y aura pas de seconde chance.

2 – Préparer les pages avec des variables de réception

C'est le point structurant. Les pages intérieures ne rechargent jamais leurs données : elles les reçoivent de la page d'accueil.

Sur la page d'accueil

On crée le smartflow de récupération et on nomme sa variable de sortie, par exemple :

varCommandes   ← résultat du smartflow "Récupérer les commandes"
varClients     ← résultat du smartflow "Récupérer les clients"

Sur chaque page intérieure

On crée une variable de réception, par exemple var2, qui recevra le jeu de données à l'appel de la page.

Important
Cette variable doit être déclarée en variable globale.
C'est cette propriété qui permet de la remplir à l'appel, via l'URL.

Les liens de la page d'accueil vers les pages intérieures doivent transmettre varCommandes dans var2.

Page d'accueil                        Page intérieure
──────────────                        ───────────────
smartflow → varCommandes  ──lien──▶   var2 (globale)
                                      = varCommandes

Résultat : la page intérieure travaille sur les données déjà en cache, sans aucun appel serveur.

Conseillé : regrouper le cache dans un smartobject unique

Transmettre une variable par jeu de données devient vite lourd (une variable de réception par page, un paramètre par lien). Pour ne travailler qu'avec une seule variable transmise de page en page, créez un smartobject dédié — par exemple donnees_en_cache — qui contient l'ensemble des données dans des champs distincts :

Smartobject `donnees_en_cache`	Contenu
champ `commandes`	`varCommandes`
champ `clients`	`varClients`
champ `articles`	`varArticles`
…	…

La page de connexion remplit ce smartobject une fois pour toutes, puis une seule variable circule de page en page. Chaque page intérieure pioche dans le champ dont elle a besoin.

Avantages :

Un seul paramètre à transmettre dans les liens
Une seule variable globale à déclarer par page
Un point unique pour vérifier ce qui est réellement en cache
Ajouter un nouveau jeu de données = ajouter un champ, sans toucher à la navigation

Ce n'est pas obligatoire. Il reste tout à fait possible de s'en passer et de transférer plusieurs variables de page en page. Le smartobject de cache est une simplification, pas une contrainte.

Sécurité : une clé par utilisateur

La table donnees_en_cache est un smartobject partagé : tous les utilisateurs y écrivent. Il faut donc cloisonner les données par utilisateur.

Ajoutez un champ clé dans le smartobject :

Smartobject `donnees_en_cache`	Contenu
champ `utilisateur`	clé — identifiant de l'utilisateur en cours
champ `commandes`	`varCommandes`
champ `clients`	`varClients`
…	…

Ce que doit faire le smartflow de chargement

Le smartflow s'exécute en mode connecté, depuis la page de connexion, et enchaîne trois étapes :

Récupérer la liste des commandes et des clients depuis les sources (BDD, API, ERP…).
Écrire ces données dans la table donnees_en_cache, sur la ligne de l'utilisateur en cours.
Retourner les données de la table donnees_en_cache pour l'utilisateur en cours — c'est ce retour qui alimente la variable mise en cache navigateur et transmise ensuite de page en page.

Smartflow "Charger le cache" (connecté)
────────────────────────────────────────
  1. Récupérer commandes + clients
  2. Écrire → donnees_en_cache [clé = utilisateur en cours]
  3. Lire   → donnees_en_cache [clé = utilisateur en cours]  ──▶ variable de session

Important
L'étape 3 n'est pas redondante avec l'étape 1 : c'est la relecture filtrée par utilisateur qui garantit que le terminal n'emporte hors ligne que les données auxquelles cet utilisateur a droit.

3 – Modifier les données hors ligne

Toutes les modifications portant sur ce jeu de données (var2, donnees_en_cache et leurs dérivés) se font exclusivement en workflows.

Le workflow modifie la variable en local.
L'action est empilée dans la file d'attente.
Au retour du réseau, les workflows sont rejoués dans l'ordre vers le serveur.

Important
Ne jamais appeler un smartflow pour enregistrer une modification dans une application déconnectée : l'action serait perdue ou l'écran bloqué en erreur.

Conséquence : workflows idempotents

Un workflow rejoué doit produire le même résultat s'il est exécuté une seule fois ou plusieurs fois. Prévoir un identifiant métier stable et une gestion des conflits côté serveur.

4 – Checklist avant mise sur le terrain

✅ Application installée en PWA (hors navigateur)
✅ Une page de connexion qui charge toutes les données
✅ Aucun smartflow appelé depuis les pages intérieures
✅ Variables de réception déclarées en variable globale
✅ Liens de navigation transmettant les variables
✅ (optionnel) Données regroupées dans un smartobject donnees_en_cache
✅ Si table de cache : clé par utilisateur et retour du smartflow filtré sur l'utilisateur en cours
✅ Toutes les écritures en workflows
✅ Workflows idempotents
✅ Test complet en mode avion, sur le terminal cible