Application Web, mode déconnecté, resynchronisation... - Page 1

Hello,
Pour le boulot, on (mon apprenti et moi-même) doit développer une application qui doit permettre la gestion de bien inventoriés/inventoriables, en lien (en lecture seul) avec une grosse usine à gaz sous SAP (c'est juste pour le contexte, ça n'a pas vraiment d'incidence).
L'idée est que les personnes qui s'occupent de l'inventaire puissent circuler avec un terminal, quel qu'il soit (tablette, smartphone, ordi+douchette...) pour avoir un rapprochement avec ce qui se trouve dans la base SAP. L'application est une appli Web, qui a sa propre base de données, avec d'un côté l'état des lieux depuis la base SAP remonté deux à trois fois par jour, les données ajoutées ou modifiées, et un contrôle de cohérence (il peut y avoir dans cette base des objets répertoriés mais non inventoriés dans la base SAP, c'est normal et voulu).
Le principal souci vient que nos bâtiments sont une immense cage de Faraday, donc avec plein de coins sans réseau (ni 3/4G, ni Wifi), et il peut y avoir des choses à inventorier dans ces endroits.
On envisage donc d'utiliser le mode déconnecté d'HTML5 pour avoir de quoi travailler quand-même, mais on a un souci de conception : pour savoir si le bien est déjà enregistré, il faut pouvoir avoir accès à la base du soft. Pour l'instant, vu qu'on va avoir un nombre relativement restreint d'enregistrements (entre 5 et 10000, en ne récupérant que les données vraiment utiles pour l'inventaire à la volée), on est parti sur un chargement complet en mode déconnecté, sauf que c'est loin d'être optimal (et, surtout, ce n'est pas adaptable à un établissement plus important). Avec une resynchronisation classique lors du passage en mode connecté (différentiel, et gestion manuelle des collisions).
Du coup, là, à vue de nez, est-ce que vous verriez une solution alternative ? (Vu qu'on inventorie en général par domaine d'activité, on va probablement faire un premier filtrage à ce niveau, mais ça reste lourd).

Qu'est ce qui bloque avec le mode déconnecté? C'est la taille des données à stocker en local qui dépasse la taille maxi autorisée par le navigateur ou juste le temps qu'il faut pour se mettre en mode "dégradé" (= déconnectable ou hors ligne) qui est conséquent?

On a une problématique similaire au boulot et on l'a résolu par une page web + base mysql locale qui fait des delta avec la base principale (master). On a un process qui s’occupe de l'UI (page web) et des fonctions primaires qui stockent tout en local comme s'il s'agissait de la master et un autre process indépendant qui s’occupe lui de la synchro entre la base locale et la véritable master. L'avantage c'est que ça marche bien et qu'on peut rester longtemps en déconnecté et que si on coupe le réseau sans prévenir ça ne bloque pas l'UI. L'inconvénient c'est que ça fait une (grosse) dépendance MySQL et donc que ça nécessite une installe sur un terminal neuf, c'est pas plug and play.

Peut-être que passer sur un truc plus léger genre sqlite te donnerai un bon entre deux?

Dans notre environnement, la taille max autorisée par le navigateur est a priori suffisante, mais ça risque de prendre du temps (cela dit, on pense partir sur une synchronisation massive à la connexion, puis des échanges en arrière plan).
Par contre, si on propose l'appli à d'autres établissements (ce qui serait bien dans la mesure où 90% des univs françaises utilisent la même souche SAP et ont des besoins similaires, donc autant rationaliser et partager), on va se retrouver avec des volumes de données possiblement 100 à 1000 fois plus gros (peut-être même plus).

Actuellement, la version alpha qu'on a fait comme tu dis : il y a un WAMP sur un ordi portable avec une base MySQL et le mode déconnecté est le mode par défaut (on fait même les synchronisations "à la main"), mais ça n'est pas tenable vu qu'on souhaite pouvoir permettre l'usage d'autres terminaux (iOS et Android). Et développer une application "pure" iOS ou Android n'est pas à l'ordre du jour (pas de compétences internes, pas de temps pour les acquérir).

Ok donc HTML5 jusqu'à ce que la limite de stockage soit atteinte puis dev d'appli pure ensuite si j'ia bien compris. Dans ce cas je ne comprend pas ce qui te bloque sur le côté HTML5 actuellement (= ce qui te fait utiliser un WAMP)

Actuellement, on utilise WAMP uniquement pour la bêta, pour ne pas être embêté avec la partie en mode déconnecté (faire valider l'interface, les actions, le workflow...).
Ma question est surtout sur "est-ce que vous avez des idées autres, ou est-ce que c'est gore mais inévitable ?"

Ha ok je comprend mieux. Selon moi HTML5 et se le webstorage sont de bons candidats (gmail en est un bon exemple, et il y en a sûrement d'autres), je laisse les autres ajouter leur avis

Nil (./1):
Le principal souci vient que nos bâtiments sont une immense cage de Faraday, donc avec plein de coins sans réseau (ni 3/4G, ni Wifi), et il peut y avoir des choses à inventorier dans ces endroits.

Si vous avez de la 2G, la boîte où je bosse on fourni un SDK android pour faire passer la data par des SMS

Faut pas être pressé ^^

Ne serait-ce pas faisable de mettre du wifi ? (sauf si le côté Faraday est volontaire, bien sûr)

Arvi89 (./7) :
Si vous avez de la 2G, la boîte où je bosse on fourni un SDK android pour faire passer la data par des SMS

x_x (cela dit, ça ne passe pas mieux que la 3G/4G, hein ^^)

flanker (./9) :
Ne serait-ce pas faisable de mettre du wifi ? (sauf si le côté Faraday est volontaire, bien sûr)

On a 12000m² au sol sur 3 niveaux, c'est impossible de déployer du wifi partout, même si on doit déjà couvrir 70% de l'espace (la cage de Faraday n'est pas du tout volontaire, c'est l'architecte qui a couvert les murs et fenêtres de moucharabiehs - pour des raisons écologicoesthétiques).

Zerosquare (./8):
Faut pas être pressé ^^

Disons qu'on ne fait pas de vidéo (on nous l'a déjà demandé ^^)
Mais pour tout ce qui est texte ça fonctionne plutôt bien
(on bosse sur l'envoie de très petites images là aussi)

Arvi89 (./11) :

Zerosquare (./8):
Faut pas être pressé ^^

Disons qu'on ne fait pas de vidéo (on nous l'a déjà demandé ^^)
Mais pour tout ce qui est texte ça fonctionne plutôt bien
(on bosse sur l'envoie de très petites images là aussi)

Intéressant. Pour les images vous faites comment si c'est pas indiscret? Un truc du genre PCX avec compression RLE puis le tout passé en base64?

(pourquoi du RLE ? Le PNG et les autres formats plus modernes font nettement mieux)

(j'utilise ça au boulot pour une imprimante qui prend des images en 1bit (monochrome), le PCX RLE c'est ce qui bouffe le moins de place (et de puissance CPU niveau traitement pour l'imprimante))

(c'est pourtant un des formats les plus vieux et les moins efficaces en matière de compression, sa seule réelle qualité est la simplicité de l'implémentation)

Jonas (./12):

Arvi89 (./11) :

Zerosquare (./8):
Faut pas être pressé ^^

Disons qu'on ne fait pas de vidéo (on nous l'a déjà demandé ^^)
Mais pour tout ce qui est texte ça fonctionne plutôt bien
(on bosse sur l'envoie de très petites images là aussi)

Intéressant. Pour les images vous faites comment si c'est pas indiscret? Un truc du genre PCX avec compression RLE puis le tout passé en base64?

Pour le moment on compresse avec webP (mais on a un mec qui bosse sur du machine learning pour améliorer ça), et après en base64 mais compressé (on a un système pour ça), un SMS ce n'est que 160 caractères c'est pas beaucoup (surtout qu'il faut qu'on envoie nos données aussi) ^^

Arvi89 (./19) :
webP (mais on a un mec qui bosse sur du machine learning pour améliorer ça)

Wat ?

Merci Arvi pour les précisions!

Zeph (./20) :

Arvi89 (./19) :
webP (mais on a un mec qui bosse sur du machine learning pour améliorer ça)

Wat ?

https://fr.wikipedia.org/wiki/WebP ? (à moins que tu ne t'interroges sur le gars qui améliore le format)

tu peux chunker, mais effecitvement envoyer 160 kb a la fois ...

Warpten (./22):
tu peux chunker, mais effecitvement envoyer 160 kb a la fois ...

160 c'est pas possible On envoie des 5 ko là, et c'est déjà bien assez ^^ Le but serait de passer sous 4, mais faut que l'image reste lisible.
(le machine learning c'est pour avoir un système qui apprend à compresser les images de mieux en mieux, apparemment ça se présente bien)

Jonas (./21) :
https://fr.wikipedia.org/wiki/WebP ? (à moins que tu ne t'interroges sur le gars qui améliore le format)

Oui je m'interrogeais sur la présence de "compression webp" et "machine learning" dans la même phrase

Hello,
(ca fait 7 ans que j'ai pas du poster sur le forum)

Et bien, je travaille pour une boîte dans laquelle on a exactement la même problématique.
On faiit une solution de gestion d'intervention.
En gros, sur une webapp (backoffice), on peut créer des interventions pour des techniciens.
Chaque technicien possède un smartphone sur lequel il possède notre application mobile (app hybride en HTML5) .
Avec l'appli mobile, il peut se synchroniser pour :

1. Redescendre sur son smartphone, les infos qu'on lui a assigné via le backoffice (phase de download)
2. Remonter les infos qu'il a saisi sur la base consolidée (master) (phase d'upload)

Donc, on a :

Un base consolidée (master) liée à l'activité backoffice
^
I
v
Un serveur de synchronisation (qui fait le deta, et gestion "manuelle" des collisions)
^
I
v
Une base embarquée sur le smartphone qui est une vue de la base consolidée (on redescend que les infos du technicien et puis c'est un "snapshot" de la base consolidée)

Et pareil que toi, par défaut, on est en mode offline, et le technicien effectue sa synchro "à la main".
On utilise un serveur de synchro qui vient de chez nous, (ca fonctionne avec des procédures sql de synchronisation qui sont directement dans la base consolidée)

Sinon je sais que Google propose aussi des solutions pour ca :
https://firebase.google.com/docs/database/android/offline-capabilities

mais je sais pas trop ce que ça vaut, n'ayant jamais utilisé ça

Hey, merci pour ces infos
Vu qu'on est dans une situation moins "lourde", on va essayer de supprimer le serveur de synchronisation (disons que tout se fera par des traitements lors de la reconnexion.

t'as pas peur de problemes de concurrence / exhaustion des pool de connections comme ca?

Non, parce qu'on est vraiment dans un cas particulier : l'inventaire physique est réalisé par au plus trois personnes (une pour la partie TP, une pour la partie info, une pour la patrie patrimoine) sur l'ensemble du site, donc même à imaginer qu'elles passent en mode déconnecté puis reconnecté en même temps, ça devrait être gérable ^^
Par contre, si on propose notre solution à d'autres établissements, il faudra qu'ils développement un système pour éviter ça, clairement
Nous, on a un grand bâtiment pour 450 élèves ; une université, c'est 100 fois plus ^^

Non, 200 fois plus.

Et toc !