[R3dKap]

@Alexandre @Lo

Il n’existe pas à proprement parler une documentation qui liste ce genre de choses. C’est plus un feeling basé sur l’expérience. Mais maintenant que j’y pense ça pourrait être intéressant que je pose la question à l’équipe Power Apps chez MS pour qu’ils me donnent quelques billes sur la mécanique interne d’exécution et de traitements des formules dans les applications de canevas.

Je me base aussi sur le fait, par exemple, qu’il existe une option qui permet de désactiver l’exécution du App.OnStart en parallèle des autres événements de lancement d’une application :

👉 D’une manière générale, les formules sont quand-même traitées en séquence. Sinon on aurait de grave soucis lorsqu’il y a des dépendances entre variables par exemple. Et d’ailleurs, c’est pas pour rien non plus qu’il existe une fonction Concurrent() qui sert précisément à paralléliser les traitements (ce qui laisse sous-entendre que le reste est séquentiel).

Par contre, il y a quelques cas particuliers :

• Le SubmitForm() justement… En règle général on ne met pas de code après le SubmitForm() car là, pour le coup, le système n’attends pas que le formulaire soit entièrement soumis pour continuer à traiter un éventuel code qui suivrait juste derrière. Pourquoi ? Justement parce qu’il y a un événement OnSuccess qui est là pour garantir la fin de la soumission du formulaire. Donc, en toute logique, s’il y a un traitement à faire après la soumission d’un formulaire, il doit être placé dans le OnSuccess.

• Le Navigate() : comme pour le SubmitFormt() normalement on ne met pas de code après le Navigate() car on indique à Power Apps que l’on veut changer d’écran : si l’on veut changer d’écran pourquoi mettrions-nous encore du code juste après le Navigate() -> ça n’a pas de sens. Tout code situé après un Navigate() doit donc être placé dans le OnVisible de l’écran cible. Clairement, je pense que lorsque Power Apps voit une instruction Navigate() il navigue immédiatement et n’attends pas qu’un éventuel bout de code derrière le Navigate() soit entièrement exécuté pour changer d’écran.

• L’appel de flux Power Automate : là c’est particulier car cela dépend si à la fin du flux il y a l’action suivante :

• Si le flux se termine par cette action alors Power Apps attends la fin de l’exécution du flux pour continuer le code qui se situe après l’appel du flux. Dans le cas contraire, l’appel du flux ne fait que déclencher le flux et Power Apps poursuit l’exécution de l’application dans la foulée avant même que le flux n’aie terminé de s’exécuter.

Voilou… 🙂

CommentID=lzLXw1GYPx9MAt5, PostID=YZsSIl0iuKjZa8u