[R3dKap]

Salut Sebastien Brandeis,

Rien noté de mon côté. Et rien non plus dans la mailing-list MVP avec l’équipe Microsoft.

Pour être sûr que c’est lié à la version, faites un test de la même app dans les 2 versions : si vous constatez des écarts après plusieurs essais d’affilée, ça vaudrait peut-être le coup de le remonter via un ticket au support pour qu’ils regardent si ça cache pas un loup…

CommentID=D6Ppt12tfgOR64D, PostID=ZAJrbKLjgT2TqnW

[R3dKap]

Jérémy Laplaine t’as déjà manipulé l’API Power BI toi ?

CommentID=a8XfAFQaL03keKx, PostID=uIIHkvXUWkst6on

[R3dKap]

Attention Sammy Rakotoarison, faut pas croire que parce-que tu bascules sur du Dataverse tu n’auras plus de problème de délégation et que la limite des 2000 va tout simplement sauter.

La limitation des 2000 et les problèmes de délégation sont vraies quelle que soit la source de données : c’est une limite physique imposée par Power Apps pour éviter des soucis de performance. Donc quoiqu’il arrive il faudra toujours faire attention à manipuler dans ton application de canevas moins de 2000 éléments (sauf si ta fonction, comme le Sum() est délégable). Et après, comme tu le vois, Dataverse permet plus de délégation et plus de volume.

Faire un ClearCollect() sur n’importe quelle source de données ne te ramènera jamais plus de 2000 éléments !

CommentID=Yn3tGxvRlIENgRp, PostID=JBj0Gviyal6gpJt

[R3dKap]

Pour compléter la dernière phrase de DavidZed… ou que ton application est trop “grosse” pour du Power Apps canvas : Power Apps canvas c’est du low-code pour des low-applications… 😉

Mais je sais que c’est tentant de tout faire avec… 😁

SubCommentID=31J8nnJg9OLG36c, CommentID=Yn3tGxvRlIENgRp, PostID=JBj0Gviyal6gpJt

[R3dKap]

Salut Sammy Rakotoarison,

Ta fonction Sum() tu l’utilises directement sur ta source de données je suppose : est-ce que Power Apps te signale un risque de délégation ?

Sauf erreur de ma part, la fonction Sum() n’est pas délégable à SharePoint mais elle l’est à Dataverse (mais avec une limitation) :

Source : https://learn.microsoft.com/fr-fr/connectors/commondataservice/#power-apps-delegable-functions-and-operations-for-dataverse

CommentID=oqty2ei5lXa0zp8, PostID=JBj0Gviyal6gpJt

[R3dKap]

Commençons par la structure logique de ton formulaire…

Répartir un formulaire sur plusieurs écrans ça a l’avantage d’avoir des écrans légers mais l’inconvénient d’avoir une gestion plus complexe. En effet, pour des raisons de performances, la bonne pratique veut qu’à partir d’un écran A on ne fasse jamais référence qu’aux contrôles de cet écran A et surtout pas à des contrôles situés sur un écran B.

Or, ton formulaire étant éclaté sur 3 écrans, ton Patch() sur l’écran de fin est obligé de faire référence aux formulaires de début et du milieu qui sont sur les 2 autres écrans : pas bieeeen… 😉
Pour éviter ça, il faut “transporter” les données d’un écran à l’autre. C’est assez simple à faire…

Sur ton écran de début, sur le bouton pour passer à l’écran suivant

Navigate('Ecran milieu'; ScreenTransition.None; {locDebutUpdates: FormDebut.Updates}).

Le troisième paramètre du Navigate() te permet d’envoyer des données à l’écran où tu vas naviguer. Ces données sont transmises sous la forme d’un enregistrement, c’est à dire au format {nomColonne1: valeurColonne1; nomColonne2: valeurColonne2; ...). Ce que fait Power Apps au moment de la navigation c’est qu’il crée sur l’écran d’arrivée une variable locale pour chacune des nomColonneX du 3è paramètre de ton Navigate(). Comme si sur l’écran d’arrivée tu avais fait un UpdateContext({nomColonne1: valeurColonne1; nomColonne2: valeurColonne2; ...}).

Et donc sur l’écran du milieu, sur le bouton pour passer au dernier écran :

Navigate('Ecran milieu'; ScreenTransition.None; {locDebutUpdates: locDebutUpdates; locMilieuUpdates: FormMilieu.Updates}).

Eh oui, il ne faut pas oublier aussi de transmettre au dernier écran le locDebutUpdates.

Tu te retrouves donc sur ton écran de fin avec le Patch() suivant :

Patch('Validation évaluation chariots élévateurs'; Defaults('Validation évaluation chariots élévateurs'); locDebutUpdates; locMilieuUpdates; FormFin.Updates)

Et là c’est bon parce-que tu ne fais plus référence aux formulaires qui sont sur les autres écrans.

Tu me suis ?

Par contre… Une autre solution (que perso je trouve assez élégante) pour éviter de scroller dans un formulaire consiste à faire un formulaire à onglets :

• tu mets 3 boutons sur ton écran, en dehors du formulaire

• au clic sur les boutons tu définis une variable locale qui va contenir un code qui représente chaque partie du formulaire

  • 1er bouton : UpdateContext({locOngletForm: "DEB"}) pour la première partie de ton formulaire

  • 2e bouton : UpdateContext({locOngletForm: "MIL"}) pour la 2è partie de ton formulaire

  • 3e bouton : UpdateContext({locOngletForm: "FIN"}) pour la dernière partie de ton formulaire

• tu utilises la valeur de locOngletForm pour donner une couleur particulière au bouton qui est actif

• sur chacun de tes datacards de formulaire tu définis sa visibilité en fonction de s’il doit apparaître au début, au milieu ou à la fin :

  • locOngletForm = "DEB" pour les datacards du début

  • locOngletForm = "MIL" pour les datacards du milieu

  • locOngletForm = "FIN" pour les datacards de la fin

• du coup sur le bouton d’enregistrement de ton écran, tu peux faire un simple SubmitForm() pour enregistrer tes données (plus besoin de Patch()).

Tu me suis toujours ? 🙂

Revenons au code actuel de ton bouton sur ton écran de fin actuel :

PDFdocumentRecertification.Run(HtmlText1_2.HtmlText; DataCardValue40.Text; ur");;nPatch('Validation évaluation chariots élévateurs'; Defaults('Validation évaluation chariots élévateurs'); FormDebut.Updates; FormMilieu.Updates; FormFin.Updates);; nNavigate(HTML_FR;ScreenTransition.None)

Y’a un cas de figure où tu vas te retrouver dans une situation compliquée : c’est si ton Patch() ne marche pas -> tu te retrouves avec un PDF alors que les données n’existent pas dans ta liste SharePoint et en plus tu navigues vers l’écran suivant alors que quelque chose s’est mal passé sur ton écran actuel.
D’ailleurs, ça me fait penser que c’est normal que ton Navigate() ne marchait pas dans le OnSuccess puisque le OnSuccess est déclenché par le SubmitForm() (que tu n’appelles pas puisque tu fais un Patch()).

Il faut donc que tu mettes en place une gestion des erreurs sur ton Patch(). Pour cela on utilise la fonction Errors() qui renvoie la liste des erreurs qui sont apparues lors de la dernière opération effectuée sur une source de données :

Patch('Validation évaluation chariots élévateurs'; Defaults('Validation évaluation chariots élévateurs'); FormDebut.Updates; FormMilieu.Updates; FormFin.Updates);;nIf(n    !IsEmpty(Errors('Validation évaluation chariots élévateurs'));n    Notify("Une erreur est survenue à l'enregistrement de vos données !"; NotificationType.Error; 4000);n    PDFdocumentRecertification.Run(HtmlText1_2.HtmlText; DataCardValue40.Text; ur");;n    Navigate(HTML_FR;ScreenTransition.None)n)

En gros c’est :

• si j’ai des erreurs suite au Patch() que j’ai fait :

  • alors j’affiche un message d’erreur à l’écran

  • sinon je déclenche la création PDF et je navigue

Autre intérêt de procéder comme ceci : si par hasard ton flux de génération de PDF va lire les données dans ta liste SharePoint, cela te garanti que ta donnée a bien été enregistrée dans SharePoint AVANT que tu n’appelles le flux qui en a justement besoin.

Enfin, pour ce qui est de la génération de ton PDF, même remarque que précédemment : tu n’est pas censé faire référence aux datacards qui sont situés sur les autres écrans. Il faut donc les remplacer par les variables locDebutUpdates, locMilieuUpdates et FormFin.Updates. Une fois que ton HTML est construit (en caché) sur ton écran de fin, transmets-le à ton écran de visualisation de PDF via le Navigate() comme vu précédemment : Navigate(HTML_FR; ScreenTransition.None; {locHTML: HtmlText1_2.HtmlText}). Et sur ton écran de visualisation, utilise locHTML comme valeur par défaut sur ton contrôle HTML. Comme ça, sur l’écran de visu du PDF tu évites de faire référence à ton contrôle caché HtmlText1_2 qui est sur l’écran de fin.

Voilà… Quelle que soit la solution que tu choisisses, n’hésite pas à revenir vers nous si tu as encore des soucis. Peut-être, ne casse pas tout et met juste en place la transmission des données des formulaires d’un écran à l’autre… 😉

CommentID=PFRYtEXIvj0mI4d, PostID=7GdImoaDXz8V0Lo

[R3dKap]

Avec plaisir… J’😍 les gens qui 😍 Power Apps… 😁

Alors pour ton HtmlText… En fait, un datacard n’est qu’un joli truc qui t’affiches sur ton écran tout ce qu’il faut pour afficher/saisir les données d’UNE COLONNE de ta liste SharePoint ou de ta table Dataverse : une étoile si la colonne est obligatoire, le libellé de la colonne, le contrôle pour la saisie de la donnée (qui change selon le type de donnée de la colonne) et un libellé pour afficher des messages d’erreur juste en-dessous du contrôle de saisie. Mais tout ça ne sert que pour UNE COLONNE précise : celle qui est spécifiée dans la propriété DataField de ton datacard.

Donc pour résumer : un datacard = une colonne de ta liste. Donc, dans ton HtmlText :

• si DataCardKey1 est dans le datacard de la colonne “Prénom” alors dans ton HtmlText : locDebut.Prénom

• si Radio1_1 est dans le datacard de la colonne “Marié” alors dans ton HtmlText : locDebut.Marié

C’est tout… 😉

Et pour répondre à ta dernière question : lorsque tu publies une application Power Apps elle se verrouille sur la version du Core Power Apps à ce moment-là. Cela garanti sa stabilité dans la durée.
CEPENDANT… Il y a des parties du Core Power Apps qui, lorsqu’elles sont modifiées par l’équipe Microsoft, peuvent effectivement avoir des effets de bords sur ton application publiée. C’est la raison pour laquelle Microsoft recommande de republier régulièrement ses applications afin qu’elles se branchent sur la dernière version du Core Power Apps et que cela fasse éventuellement ressortir des petits soucis que tu pourras alors facilement corriger.

Voilou…

SubCommentID=V3SrxmycnTo6Tzb, CommentID=PFRYtEXIvj0mI4d, PostID=7GdImoaDXz8V0Lo

[R3dKap]

Missel et une signature sur un écran tactile (une tablette ou un téléphone) dans un contrôle Pen input, signature qui est insérée en fin du document PDF ? Facile à faire…

CommentID=zHB7xJtRZLwcgl0, PostID=0sTHQDtu11yPfaW

[R3dKap]

Paul Auchon, au passage, tu trouveras dans l’espace Power Automate, sur la droite, pleins de liens pratiques dont celui qui t’amène sur la liste des fonctions propre au “code” de Power Automate, dont la fonction formatDateTime() où sur la page tu trouveras le lien vers les caractères de formatage que je t’ai mis ci-dessus… 😉

CommentID=cmDAQmslFDMXS1V, PostID=gtYJ8uHBUOIB0Mx

[R3dKap]

Salut Paul Auchon,

Commençons par tes questions générale sur Power Automate…

1. Le comportement que tu décris me fait penser à une époque lointaine où ce bug apparaissait de temps en temps. Aujourd’hui ce n’est plus le cas. Ce que je te suggère : change de navigateur, vide le cache de ton navigateur et retente. Sinon tu peux aussi tenter d’activer la nouvelle interface de Power Automate en allant sur l’icône engrenage en haut à droite, puis Afficher tous les paramètres Power Automate, puis activer la bascule Fonctionnalités expérimentales. Mais comme son nom l’indique, c’est stable à 95%. Attention ça recharge complètement la page.

2. Pareil. Ca m’arrive jamais ce genre de truc (ou ultra rarement). Donc même recommandations que pour le point 1.

3. Pour ta date, je te recommande de procéder en 2 temps : prends ta date du formulaire et place-là d’abord juste dans une variable de type chaîne et regarde déjà comment elle se formatte. A mon avis le résultat dépend aussi du format de ta question dans ton formulaire Forms : est-ce un champ de type texte ou de type date ? Date je suppose… Du coup, tu dois pouvoir utiliser cette date directement comme premier paramètre de ton formatDateTime(). Par contre, le deuxième paramètre doit respecter les caractères de formatage suivants (et donc tu devrais avoir en 2è paramètre : 'yyyyMMddThhmmss') :

Enfin, pour ce qui est de l’ajout d’un contenu dynamique à une fonction voici comment procéder (car l’outil est un peu capricieux selon les clics que tu fais -> faut savoir CLIQUER en gros 😅) :

1. Sur l’onglet Expression tu tapes par exemple au clavier : formatDateTime()

2. Clique une fois au milieu du mot formatDateTime puis clique entre les 2 parenthèses

3. Bascule sur l’onglet Contenu et clique sur ta date du formulaire -> il va insérer le code correspondant entre les parenthèses de ton formatDateTime()

Ce qu’il faut retenir c’est :

• dans ton expression il faut cliquer une fois ailleurs puis revenir à la position où tu veux insérer ton contenu dynamique (et à la souris hein, pas au clavier avec les flèches) et ensuite seulement basculer sur l’onglet Contenu

• c’est là où se trouve le curseur dans ton expression que le contenu dynamique sera inséré

Et tant qu’à faire voici une autre astuce contre un bug très relou que l’on rencontre souvent encore aujourd’hui :

1. Tu cliques sur un contenu dynamique déjà existant dans la propriété d’une action -> il t’affiche la popup et te place directement sur l’onglet Expression où tu vois ton “code”

2. Tu modifies le code

3. Tu cliques sur Mettre à jour (très bizarre que chez toi le bouton s’appelle D’ACCORD 😳😳😳, comme si tu utilisais le traducteur de page de Google au lieu de paramétrer la bonne langue dans ton navigateur)

4. Et là tu crois que t’as changé quelque chose mais en fait non -> si tu recliques sur ton expression tu verras que ton code n’a pas changé

Pour éviter ça, juste après l’étape 2, clique sur l’expression qui se trouve dans la propriété de l’action ET ENSUITE seulement tu cliques sur le bouton Mettre à jour (ou D’ACCORD chez toi).

Voilou… C’est gratis… et c’est pratique ! 😁

CommentID=q5y2QpbHujrjFha, PostID=gtYJ8uHBUOIB0Mx

[R3dKap]

Estelle est-ce que tu peux nous décrire plus précisément l’architecture de ta solution ? Ce que j’ai compris jusque là :

1. Sur un écran tu as un formulaire SharePoint où l’utilisateur fait son évaluation

2. Une fois qu’il a terminé il clique sur un bouton SUBMIT ce qui soumet le formulaire et crée donc la ligne correspondante dans ta liste SP

3. A la suite de quoi il arrive sur un autre écran où tu lui affiches son évaluation au format HTML (où tu utilises donc les données de l’évaluation créée précédemment)

Questions :

1. Est-ce que la génération du PDF est déclenchée par l’apparition de la nouvelle ligne dans la liste SP ou par le clic d’un bouton sur l’écran avec l’HTML ?

2. Lors de la génération du PDF (si elle déclenchée par un bouton sur ton écran) est-ce que tu transmets l’HTML de l’écran au flux Power Automate ?

Par rapport à tes questions :

• La bonne pratique veut que l’on ne mette pas de code après un Navigate(). En effet, Power Apps n’attends pas la fin de l’exécution de ton bouton SUBMIT pour naviguer : il voit le Navigate() -> il navigue. Et du coup le code qui avait derrière s’exécute alors que tu n’es même plus sur l’écran où se trouve le bouton. Tu me suis ?

• Autre bonne pratique : lorsque sur un écran où il y a un formulaire on veut naviguer vers un autre écran une fois que les données ont été correctement traitée, alors le Navigate() doit être placé dans l’événement OnSuccess du formulaire -> c’est lui qui garanti que tes données ont été correctement créées/mises à jour.

Il faut voir dans sa tête l’enchaînement des événements qui vont se produire quand tu fais une action :

1. Je clique sur SUBMIT

2. Cela déclenche le SubmitForm() -> le système effectue l’opération sur la source de données -> on ne met pas de code non plus après un SubmitForm() puisqu’on ne sait pas encore si ça va bien se passer ou pas.

3. Une fois que le système a réalisé l’opération sur la source de données, il y a 2 résultats possibles :

   • Ca s’est mal passé -> c’est l’événement OnFailure du formulaire qui est déclenché

     • C’est là qu’en général on affiche un message d’erreur et du coup on ne quitte pas l’écran on reste dessus pour donner une chance à l’utilisateur de retenter

   • Ca s’est bien passé -> c’est l’événement OnSuccess du formulaire qui est déclenché -> la propriété MonFormulaire.LastSubmit contient l’enregistrement complet qui vient d’être créé ou modifié

     • C’est là qu’on affiche un message de succès et qu’on navigue

     • C’est là aussi qu’on peut éventuellement faire une autre opération (avec un Patch() par ex.) sur une autre source de données qui est dépendante de la première

     • etc.

Tu vois l’idée ?

CommentID=2zsNgluPNgOUIJ7, PostID=7GdImoaDXz8V0Lo

[R3dKap]

Salut Estelle,

À mon avis le problème est du côté Power Apps. Dans certains cas de figure tu dois avoir une erreur de balise Html, soit mal formée soit non fermée. C’est pour ça que ton PDF n’est pas généré.

Le convertisseur PDF natif dans Power Automate attends de l’Html parfaitement formé. Il est un peu touchy… 😉

CommentID=cFl0tOF99sOVscD, PostID=7GdImoaDXz8V0Lo

[R3dKap]

Paul Auchon je voulais essayer de t’aider mais Power Automate a l’air complètement dans les choux là… Impossible de le démarrer sur aucun des mes tenants ni ceux de mon client… 😳

Quoiqu’il en soit, pense à nous mettre des captures de tes formules qui ne marchent pas et/ou des messages d’erreur affichés lors de l’exécution de ton flux… Ca nous sera très utile pour identifier l’origine du pb… 😉

CommentID=yCDbVqjKaPkk4hz, PostID=gtYJ8uHBUOIB0Mx

[R3dKap]

Apparemment la colonne Nom pose souci. Quel type de colonne c’est ? Texte simple ?

CommentID=wyOjh49EmekFzwv, PostID=tQAgIiRZN4R8jgK

[R3dKap]

Geoffroy WAGNER tu as donc probablement un petit triangle jaune quelque part (et une partie de ta formule qui est double-soulignée en bleu) qui te dit qu’effectivement tu as un risque d’erreur de chargement de données dû à un pb de délégation.

Dans ton cas précis, tu devrais pouvoir t’en débarrasser (pour le jour où tu dépasseras les 2000 documents) de la manière suivante (car la fonction StartsWith() est délégable à SharePoint) :

Set(varDoc; LookUp(Documents; StartsWith(Nom; drp_Docs.Selected.Result)))

Dis-nous si ça fonctionne…

CommentID=v5f4B8os1itMhdw, PostID=tQAgIiRZN4R8jgK