« Une bonne application ne doit pas collecter beaucoup de données. »

À la suite d'une demande d'un client, nous avons débattu de cette règle non écrite. Après avoir passé des heures à chercher la meilleure solution pour lui, nous avons décidé d'aller à contre-courant. Il a néanmoins fallu trouver le juste équilibre entre télécharger toutes les données dès le départ, d'une part, et laisser les utilisateurs récupérer des lots de données plus petits plusieurs fois par heure, d'autre part.

Cet exercice nous a donné une bonne compréhension de la meilleure façon de gérer de grands ensembles de données. Nous sommes ravis de partager notre solution avec vous.

Commençons par une approche alternative de mon collègue Hans Santens. Il a écrit un article intéressant sur l'analyse de grands ensembles de données avec Power Automate, qui vaut vraiment la peine d'être lu. Il explique comment utiliser Power Automate pour collecter de grands ensembles de données (+2K) et les charger dans une Power App.

J'ai emprunté la même voie pendant le développement, mais j'ai ensuite opté pour une autre approche. La solution Power Automate a fini par devenir plus lente, non seulement à cause du volume de données, mais aussi à cause de chaque colonne supplémentaire ajoutée à la requête.

Nous avons rencontré plusieurs problèmes délicats que nous voulions résoudre :

• Un temps supplémentaire, même court, pour l'aller-retour vers et depuis Power Automate, en plus du temps d'exécution de Power Automate lui-même. Chaque seconde compte 😊

• Tout ralentissait avec chaque enregistrement et colonne supplémentaires, car le JSON retourné devait être typé par colonne (dans une boucle).

• De nombreuses lignes de code étaient nécessaires pour typer tous les champs.

• Il était difficile de travailler avec des types de données plus complexes.

• Le script Power Automate demandait un entretien supplémentaire.

• Nous devions quand même créer des collections distinctes correspondant aux champs dans SharePoint à des fins de patching.

Cela ne veut pas dire que l'approche de mon collègue ne mérite pas d'être envisagée. C'est certainement une solution valable pour collecter des ensembles de données plus volumineux.

L'approche sur laquelle je souhaite me concentrer ici ne fonctionne que dans Power Apps et permet de collecter plus de 30K enregistrements dans une seule collection. La vitesse du réseau peut influencer la rapidité de collecte des données. Je vous conseille, par précaution, de redémarrer l'application pendant une pause.

Pour ma solution, j'ai utilisé une boucle qui récupère un maximum de 2K enregistrements (la limite maximale par défaut pour une collection) à chaque exécution de la boucle.

J'ai d'abord essayé de filtrer la liste sur la base de l'ID de chaque élément. Il faut une variante intermédiaire, ou un équivalent supérieur/inférieur, mais '>=' et '<=' déclenchent un avertissement de délégation. J'ai donc continué à chercher, ne voulant pas prendre le risque de perdre des données.

J'ai décidé d'ajouter ma propre colonne de valeur entière par enregistrement. Tous les enregistrements avec un ID < 2000 ont reçu la valeur 1, le groupe suivant de 2K enregistrements a reçu 2, et ainsi de suite. C'est la clé pour résoudre ce problème – tout en le réduisant en même temps.

Avec cette valeur entière, vous pouvez utiliser '=', ce qui évite l'avertissement de délégation. Il faut toutefois calculer cette valeur au moment de la création de l'enregistrement, via un patch/edit supplémentaire.

Vous avez ici deux options :

Il y a deux sujets essentiels sur lesquels nous devons nous concentrer :

• Veiller à ce que chaque enregistrement soit sauvegardé avec la bonne valeur entière.

• Récupérer les données via la valeur entière à l'aide de boucles.

Dans Power Apps, une collection récupère un maximum de 2K enregistrements. En utilisant 'Collect' après 'ClearCollect', vous pouvez facilement ajouter davantage de lignes à la même collection.

Par exemple :

• 2K clients à Londres

• 3K clients à Paris

• Total = 2,5K lignes dans colCustomers

Maintenant que nous le savons, il nous faut trouver un moyen de répéter cela aussi souvent que nécessaire.

Pour récupérer les données, nous devons connaître la valeur entière la plus élevée de la liste et construire une boucle de 1 jusqu'à ce nombre. J'ai appelé ma colonne 'dg' (DataGrouping).

Vous remarquerez que je trie par ID (ordre décroissant) et demande la première valeur 'dg', qui est la plus élevée selon ce tri. L'utilisation de 'Max' sur 'dg' déclenchait elle aussi un avertissement de délégation.

Set( varLastDG, First( Sort( <SP List>, ID, SortOrder.Descending ) ).dg )

Construisez maintenant la boucle (ForAll). Utilisez 'Sequence' pour créer une liste de nombres de 1 à varLastDG.

ForAll( Sequence(varLastDG), Collect( <collection name>, Filter( <SP list>, dg = Value, Department = "R&D", Active = true ) ) )

Les filtres supplémentaires sur 'Department' ou 'Active' peuvent réduire le nombre d'enregistrements retournés et accélérer l'ensemble du processus. Chaque boucle ne retournera pas nécessairement exactement 2K enregistrements – il se peut même qu'elle n'en retourne aucun.

Ajoutez votre collection à une grille pour visualiser le résultat. C'est tout ce dont vous avez besoin pour collecter vos données !

Vous devez maintenant vous assurer que chaque enregistrement reçoit la bonne valeur entière. Vous devez également veiller à ne pas ajouter la même valeur plus de 2K fois.

Pour cette solution, je patche un nouvel enregistrement de la manière standard. Cela dit, vous ne savez pas avec une certitude à 100 % quel ID l'enregistrement recevra. C'est pourquoi l'enregistrement nouvellement créé est stocké dans une variable. Vous pouvez récupérer le nouvel ID à partir de cette variable, puis patcher (mettre à jour) l'enregistrement avec cette valeur.

Utilisez une action de patch pour ajouter ou mettre à jour un enregistrement. Enregistrez le résultat de l'action de patch dans une variable et récupérez l'ID. Pour une mise à jour, il n'est pas nécessaire de patcher la valeur entière. L'enregistrement obtient sa valeur entière au moment de sa création. Ce nombre ne change jamais.

// Créer l'enregistrement et le stocker dans une variable

Set( varSavedRecord, Patch( <SP List>, Defaults(<SP List>) { Title: txtWPNumber.Text, ....... } ) );

// Récupérer l'ID de l'enregistrement utilisé dans le patch

Set( varPatchedID, varSavedRecord.ID );

// Calculer votre valeur entière

Set( varNewDG, Int(varPatchedID / 2000) + 1 );

// Patcher la valeur entière dans l'enregistrement (non nécessaire lors de la mise à jour d'un enregistrement, puisqu'il a déjà reçu son ID lors de sa création)

If( varEditState = "New", Patch( <SP List>, LookUp( <SP List>, ID = varPatchedID ), {dg: varNewDG } );

Grâce à cette valeur entière dans la colonne 'dg', nous disposons d'un moyen simple de collecter les données.

• Nous recherchons la plus grande valeur 'dg' et construisons une boucle de 1 jusqu'à ce nombre.

• Nous récupérons tous les enregistrements dont la valeur 'dg' = la valeur de la boucle (le '=' peut être délégué)

J'ai déjà mentionné à deux reprises la réduction du nombre de patches, mais j'espère qu'à présent les avantages de cette approche sont clairs :

• Aucun outil supplémentaire (Power Automate) à entretenir.

• Seulement quelques lignes de code.

• Aucun typecasting nécessaire.

• Les collections sont identiques à la liste SharePoint.

Vous avez maintenant deux options à choisir : utiliser Power Automate et récupérer toutes les données en une fois, ou utiliser l'approche Power Apps avec une boucle.

Amusez-vous bien à explorer ! Et si vous avez besoin d'assistance : mes collègues et moi serons ravis de vous aider 😊.