[Theophile CHIN-NIN]

@R3dKap Je crois que tu as exactement ce genre de cas d’usage dans ta besace non ?

CommentID=knK6kTGhdR1wXsK, PostID=4BxZK1snba2M2pC

[R3dKap]

@Tanguy Touzard marrant, je vais justement participer aux journées complètes de formation de la MWCP2022 où j’aborderais (entre autres) le sujet du mode déconnecté sous Power Apps 😁 :

https://modern-workplace.pro/agenda-2022/#page-content

Alors pour répondre à tes questions :

1. La première chose vraiment importante c’est de bien prendre en compte ce besoin du mode déconnecté dès le début de la conception. Car transformer une application déjà existante pour lui rajouter du mode déconnecté c’est juste l’enfer. Principalement à cause de la manière dont tu gères les données dans l’appli lorsqu’elle inclue le mode déconnecté.
2. La gestion des données est donc particulière en mode déconnecté. J’ai fait une grosse appli en mode déconnecté et j’ai choisi de fonctionner comme ceci : la totalité de l’application ne tourne qu’avec des collections locales. Dans les écrans de l’application il n’y a jamais aucun référencement direct aux sources de données (moi c’était du SharePoint), SAUF à la sauvegarde.
3. Cela implique qu’il faut impérativement que ton applications puisse tourner avec des volumes de données inférieur à 2000 enregistrements. Parce-que sinon tu t’embarques dans un truc encore plus complexe qu’il ne l’est déjà. Je dis pas que c’est pas impossible mais bon, si on peut l’éviter…
4. Dans mon appli, le seul écran qui fait appel aux sources de données c’est l’écran de démarrage qui charge les données nécessaires pour que l’application soit utilisable :
5. Il regarde si on est en mode connecté ou pas.
6. Si on est connecté, il charge dans des collections toutes les données depuis les sources de données et les RE-stocke en cache local avec SaveData() pour les avoir à dispo au lancement suivant pour le cas où on soit en déconnecté.
7. Si on est déconnecté, il charge dans des collections toutes les données depuis le cache local avec LoadData().
8. A partir de ce moment-là, vu que tout est chargé dans des collections et que toute ton application ne fait que travailler avec ces collections, ton appli est utilisable que l’on soit en mode connecté ou pas. Et pendant toute son utilisation finalement on s’en fichera pas mal de savoir si on est connecté ou pas, SAUF à la sauvegarde.
9. Astuce : pour simuler le mode déconnecté pendant la phase de développement, tu peux mettre un toggle togConnecté quelque part sur un écran que tu définis par défaut à true. Et là l’étape 4.a) tu alimentes une variable gloConnecté avec togConnecté.Value || Connection.Connected. Et c’est gloConnecté que tu testes pour savoir si t’es connecté ou pas.
10. Dans l’application, à la sauvegarde :
11. Si t’es connecté tu sauvegardes tes collections dans tes datasources
12. Ensuite tu sauvegardes toujours tes collections dans le cache local avec le SaveData()
13. Attention : si ta source de données génère des données automatiques à la création des enregistrements et que tu en as besoin dans l’appli en mode déconnecté, alors après avoir sauvegardé tes données vers tes datasources, recharge tes collections à partir de tes datasources avant de les sauvegarder dans le cache local.
14. Attention : si tu utilises des formulaires dans ton appli et que tu as des champs de type Choice (liste de valeurs), il va falloir que tu les sauvegardes aussi en cache local car la fonction Choices() ne fonctionne que sur de la vraie source de données. Il faudra donc que toi-même tu forces le Items de ces champs-là non pas à du Choices() mais à une collection chargée depuis le cache local.
15. Prévois-toi aussi un écran de débogage qui t’affiche facilement en permanence le contenu de tes collections qui sont en cache local. Parce-qu’il n’y a aucun moyen d’y accéder autrement… Et tant qu’à faire, moi j’y avais ajouté la possibilité de supprimer des enregistrements du cache voire carrément de vider une entrée du cache local.
16. Tu as de la chance, désormais les fonctions LoadData() et SaveData() fonctionnent en mode web. Auparavant elles ne fonctionnaient que sur des devices mobiles (bien relou pour les test). Assure-toi juste d’avoir activé la fonctionnalité expérimentale correspondante :

Enfin, par rapport aux volumes de données, désormais la limite est celle du device sur lequel l’application tourne (ah : je viens de voir qu’à priori en mode web c’est assez limité… surprenant… à challenger peut-être) :

C’est extrait de la doc de la fonction SaveData() que je t’ai mis ci-dessous…

👉 Ah et par rapport à ta question sur les PDF, je suis pas sûr d’avoir bien compris : tu veux pouvoir rendre des PDF accessibles en mode offline ? Si c’est le cas, je ne crois pas que ce soit possible car le composant lecteur de PDF proposé par Power Apps ne prend en entrée que des URLs. Or, un fichier PDF stocké en local n’aurait pas d’url… A creuser… Je vais réfléchir de mon côté…

Autre resources

• La doc officielle des fonctions SaveData(), LoadData(), ClearData() et Connection.
• Matthew Devaney a fait un p’tit article qui donne les base du concept également, avec un exemple :

Voilou… N’hésite pas à poser d’autres questions si nécessaire… 😉

CommentID=UnAK1rctoRaMZ2o, PostID=4BxZK1snba2M2pC

[Tanguy Touzard]

@R3dKap Merci pour cette réponse très complète!

Pour les PDF, le but n’est pas forcément de les visualiser dans l’appli mais à minima de pouvoir les télécharger sur le device et les montrer au client. Possible?

SubCommentID=6d4E7ek4qsyVWtf, CommentID=UnAK1rctoRaMZ2o, PostID=4BxZK1snba2M2pC

[R3dKap]

@Tanguy Touzard j’ai oublié de parler de la synchro.

Et avant ça, une petite précision : dans la gestion des données de l’application, je fais la différence entre ce que j’appelle le référentiel et les données applicatives :

• Référentiel : liste de valeurs qui servent principalement dans des lookups, ou listes de paramétrage, etc. (par ex. une liste des véhicules de location de l’entreprise, ou une liste de bouquins à louer, etc.). Ces données ne sont pas modifiées par les utilisateurs mais plutôt par les admins.
• Données applicatives : ces données sont celles qui sont manipulées par les utilisateurs finaux (par ex. : les locations des véhicules par les salariés, ou les emprunts de bouquins, etc.).

Revenons sur la synchro…

La synchro a 2 raisons d’être :

1. T’as des données stockées dans le cache local lorsque tu étais en mode déconnecté et tu ne les as pas encore poussées vers tes sources de données.
2. T’as des utilisateurs qui peuvent aussi modifier les données côté backend et il faut donc les pousser vers l’application pour qu’elle en aie connaissance.

L’idéal c’est évidemment d’éviter le point 2 😉 et de faire en sorte que tes données ne puissent être modifiées que par le biais de l’application. Ca évite de faire une synchro avec gestion des conflits où tu finis par redévelopper l’algorithme de OneDrive 😁.

En gros y’a 3 solutions pour réaliser la synchro :

• soit ton appli synchronise les données dès l’ouverture : toutes les données du cache local non encore sauvegardées sont poussées vers tes sources de données puis tous les référentiels de tes sources de données sont mis à jour dans le cache local ;
• soit ton appli effectue cette synchro à intervalle régulier “en tâche de fond” à l’aide d’un timer (toutes les 2mn par ex.)
• soit la synchro est déclenchée manuellement par l’utilisateur : l’avantage c’est qu’il peut choisir ce qu’il pousse ou pas côté sources de données (c’est que j’avais fait dans mon appli).

Et pour finir j’ai oublié de préciser aussi que j’ai ouï dire que les applications model-driven intègrent automatiquement un mode déconnecté. A creuser…

SubCommentID=vLRQU5SFtn7jkE7, CommentID=UnAK1rctoRaMZ2o, PostID=4BxZK1snba2M2pC

[Tanguy Touzard]

Oui, les MdA ont un mode offline mais les données étant toutes dans NAV, ca fera un trop gros projet de commencer à mettre les données dans un dataverse.

Sinon, télécharger des PJ sur le device pour les ouvrir? possible?

SubCommentID=SYpTRXwwkGWFEDH, CommentID=UnAK1rctoRaMZ2o, PostID=4BxZK1snba2M2pC

[R3dKap]

@Tanguy Touzard NAV ? T’envisages quoi pour le stockage des données ? En gros l’appli fait quoi ?

Pour les PJ, ce que tu peux faire c’est de mettre tes docs dans une bib SharePoint par ex., puis de la mettre en source de données dans l’appli Powe Apps et proposer des liens qui mènent directement aux docs. En cliquant dessus, quand t’es sur un mobile, je crois qu’il te propose de le télécharger : charge à l’utilisateur de le mettre où bon lui semble pour le retrouver plus tard.

Mais tu ne peux pas à partir de Power Apps spécifier un emplacement d’enregistrement d’un document que t’aurais éventuellement pré-chargé via un flow…

SubCommentID=UFyWm5QAKTHYuyy, CommentID=UnAK1rctoRaMZ2o, PostID=4BxZK1snba2M2pC

[Tanguy Touzard]

Le but est que l’app appelle NAV via des api (connecteur NAV et/ou HTTP) pour récupérer des données, les stocker en local pour faire du mode offline et pouvoir travailler sur ces données.

En plus, quand l’utilisateur est chez le client, pouvoir lui présenter des PJ qui auront aussi été stockées localement

SubCommentID=pIndNm8xn1ASjnK, CommentID=UnAK1rctoRaMZ2o, PostID=4BxZK1snba2M2pC

[R3dKap]

Ok, je vois. Et t’aurais quoi comme volume ?

Et tu stockerais ces données où ? SharePoint ?

SubCommentID=RgyoNWgBmKUy8kp, CommentID=UnAK1rctoRaMZ2o, PostID=4BxZK1snba2M2pC