[ypicot]

Bonjour

Petit avertissement : ce qui suit est issu de mon expérience de développeur “général”, pas de développeur PApps, domaine dans lequel je suis relativement nouveau. Il est tout à fait possible que je sois contredit par d’autres personnnes plus expérimentées.

Eternel problème : faut-il une grosse appli ou des tas de petites ?

A titre indicatif, cette question est presque universelle en architecture informatique. Il n’y a qu’à voir les débats passionnés entre micro-services et architecture monolithique.

En ce qui concerne Power Apps, sa conception interne fait clairement pencher la balance vers l’option “je découpe à mort” en réalisant des petites apps qui éventuellement s’appellent entre elles. En effet, plus une app contient de composants, plus elle rame. Attention, je parle bien ici de découper l’appli PApp, pas forcément de créer des tas de sites SP. L’idée est même souvent que plusieurs apps utilisent les mêmes listes SP dans la mesure où les règles de sécurité le permettent.

Ca, c’est la théorie.

Dans la pratique, c’est bien sûr plus délicat. Il y a des tas de choix à faire, et comme tout choix, ceux-ci seront largement contestables, seul le temps pouvant in fine déterminer si l’approche choisie est bonne ou pas.

“Une solution n’est valable que dans un contexte donné”.

Je n’ai malheureusment pas de lien particulier à te proposer, hormis certaines vidéos de Shane Young ou Reza Dorrani (en grand-breton malheureusement).

CommentID=tQ9PDSfXvssYrLs, PostID=k7h02yUE6xwHQDo

[Shadoks_]

Hello ypicot,

Je suis également partisan du fait qu’une grosse apps n’est pas une solution géniale, sachant que dans mon cas, je vais très rapidement me retrouver avec un grand nombre d’utilisateur pour des cas utilisations qui peuvent légèrement changer.

Je pense plutôt partir sur la solution suivante (étant donné que la solution est sur demande de l’utilisateur) :

1) Création d’un site SharePoint, de ces listes et des groupes SharePoint via PowerShell et fichier XML (l’administrateur n’aura qu’à remplir les mails des personnes concernées pour ce périmètre, un nom générale pour l’application via la demande de l’utilisateur)

2)Import d’un package PowerApps contenant l’application et les flux Power Automate intégrés. Tout ce qui concerne les Power Automates sera variabilisé dans l’application ainsi il suffira de rebrancher le nouveau site SPO dans l’application.

3)Partager l’apps aux personnes concernées

Je pense de cette manière éviter au maximum les problèmes de saisi manuelle et les actions fastidieuses !

CommentID=Rm8wTkWnYAINavc, PostID=k7h02yUE6xwHQDo

[R3dKap]

Hello Shadoks_,

De mon côte, j’ai réalisé (et je réalise toujours) une application assez conséquente chez mon client actuel (25 écrans, des milliers de contrôles, 6 rôles d’autorisation, 500 utilisateurs, 40 tables, 20 flux, …).

L’application tient la route. Elle se lance en quelques secondes et ses performances sont correctes. Mais il faut la concevoir (à la fois en terme d’UI et en terme de gestion des données surtout) de manière à optimiser les écrans, les traitements et les chargements. Et garder à l’esprit que désormais, un écran n’est instancié (i.e. initialisé/chargé) par Power Apps que lorsqu’il est affiché <- très important pour les perfs. Le découpage doit donc se faire intelligemment au niveau des écrans et il faut utiliser des composants pour les éléments communs.

Dans ton cas, je trouverais bcp plus compliqué de mettre en place des mécaniques complexes de réplication pour une même application fonctionnant sur un même modèle de données. Car cela pose de nombreux problèmes :

• multiplier les sites et les applications implique également une multiplication de la maintenance

• la maintenance de l’application : faire évoluer l’application (ou corriger des bugs) implique de le faire sur chaque instance d’application 😱… alors on pourrait imaginer créer une bibliothèque de composants et faire en sorte que l’application soit constituée à 90% de composants mais ça t’obligera quand même à rouvrir chaque application pour appliquer la mise à jour du composant et republier l’application

• la maintenance des sites SP : il va falloir créer des tas de scripts PowerShell pour faire évoluer ou corriger le modèle de données

Clairement, perso je trouve que c’est pas la bonne approche.

Tu fais un seul site SharePoint et une seule application. Quand ton modèle de données évolue, tu ne dois modifier qu’une seule colonne ou une seule liste. Côté application, c’est à toi de gérer les rôles des utilisateurs dans l’application :

• au moment où l’application se lance, j’identifie le rôle de l’utilisateur connecté

• en fonction de ce rôle l’application se comporte différemment (affichage/grisage d’éléments, accès ou pas à des écrans, etc.)

Pour terminer, si ton application va être conséquente, assure-toi de mettre en place 3 environnements Power Platform DEV, TEST, PROD et de tout mettre dans des solutions. Perso j’ai organisé mes solutions de la manière suivante :

Voilà, n’hésite pas si t’as d’autres questions… 😉

CommentID=PFwXuDIhqfXrLYb, PostID=k7h02yUE6xwHQDo

[ypicot]

Je ne sais pas pourquoi je m’attendais à une réaction d’un boss 😉

Merci pour ce post intéressant

SubCommentID=K2Z88the4TqdHJG, CommentID=PFwXuDIhqfXrLYb, PostID=k7h02yUE6xwHQDo

[Shadoks_]

Hello R3dKap, ton message est vraiment top. Je vais préciser un peu les limitations en face desquels je me trouve vis à vis de mon besoin.

Dans cette application, j’ai un groupe A qui doit pouvoir modifier et créer des enregistrements dans une liste A.

Dans cette même application, j’ai un groupe B qui doit pouvoir modifier et créer des enregistrements dans une liste B.

Les enregistrements entre la liste A et B communique via l’ID de l’enregistrement A (Relation 1:1)

Maintenant, deux nouveaux groupes Abis et Bbis sont à créer. Ils vont pouvoir faire la même chose que les groupes A et B précédents. Mais les groupes Abis et Bbis ne doivent voir que leur enregistrement respectif (enregistrements saisies par Abis et Bbis). Ils ne doivent pas voir les enregistrements des groupes A et B (est des autres groupes Atris et Btris imaginons).

Un groupe C, qui ne voit que les enregistrements des deux listes A et B créés par les groupes A et B, est également à prévoir.

Durant toute l’année, les personnes administrant la solution vont devoir ajouter des groupes A, B et C.

Je ne m’y connais pas assez en SPO mais comment gérer cette complexité de vue sur 2 listes SPO avec potentiellement plusieurs centaines de groupes SPO voir des milliers à termes ?

Les groupes SPO ne permettent pas de gérer la vue sur les enregistrements selon un groupe précis. Quand bien même j’arrive à limiter cela dans mon application PowerApps, des personnes assez malignes peuvent aller consulter directement la liste SPO et créer des enregistrements pour des périmètres ne les concernant pas (Exemple créer un enregistrement avec une valeur qu’il n’aurai pas pu atteindre d’habitude).

Précédemment, la solution était une création de SPO et de workflow (2013/2016) via PowerShell à chaque fois que le besoin se présentait. La solution était vraiment peu ergonomique et les workflows ne sont plus maintenus. Je cherche donc à remplacer ça.

Egalement, je faisais comme toi pour mes précédentes applications (identifications du rôle de la personne, gestion de ce que la personne doit voir en fonction dans l’application) mais dans mon cas, je ne peux pas me permettre qu’un utilisateur voit la donnée qu’il n’est pas censé voir en allant dans le SPO.

Dis moi ce que tu penses de tout cela 🙂 ! Encore merci pour tous tes conseils c’est super sympa de ta part.

Si mon sujet t’intéresse, on peut toujours en discuter de vive voix !
N’hésite pas à me contacter ici : Alexis LOUIS | LinkedIn

CommentID=ombW3BZHzMP4PAY, PostID=k7h02yUE6xwHQDo