[R3dKap]

Salut Anthony,

Mon avis…

La mise en place de la gestion des erreurs dans un flux tel que présenté dans la vidéo de Reza (ou via toute autre méthode) DOIT être systématique. C’est nécessaire pour pouvoir mettre en place une maintenance efficace des flux. Perso je stocke les erreurs dans une liste SharePoint unique dédiée où j’indique l’environnement sur lequel l’erreur est apparue.

Pour ce qui est de donner accès aux développeurs aux flux en PROD, y’a 2 écoles :

1. Oui, ça facilite grandement les choses pour pouvoir déboguer. Mais il faut responsabiliser les DEV en leur précisant bien que toute modification est évidemment interdite (attention, malgré tout le risque de l’erreur humaine reste présent : je crois que je suis sur la DEV, je modifie le flux et en fait j’étais sur la PROD… pas très grave après, on peut en 2 clics supprimer la couche custom)
2. Non, techniquement ce n’est pas forcément nécessaire, on peut s’en passer, voire c’est peut-être plus sain de s’en passer. De base, un DEV n’est pas censé avoir accès à une PROD. Pour déboguer les erreurs de flux :
   • il lui faut le maximum de détails sur l’erreur concernée (d’où la nécessité de mettre en place un bon traçage des erreurs dans les flux)
   • il lui faut les conditions exactes dans lesquelles le flux a tourné (quelles données étaient concernées)
   • il doit être capable de reproduire le bug sur l’environnement de QUAL puis de DEV pour pouvoir le corriger

Perso, comme je suis un afficionados de la simplicité et de l’efficacité, j’ai plutôt tendance à partir sur la solution 1… 😜

[anthony]

Oh merci pour cette réponse captivante. L’idée de la liste SP est excellente et celait permettrait de centraliser les erreurs de toutes les solutions en PROD.

Je te rejoins sur le . 1, ce serait tellement plus facile. De mon côté ils ont tous le SR basic user sur l’env. Et effecivement une couche non gérée se supprime facilement car les erreurs d’inattention sont inévitables.

En fait c’est cette stratégie que j’ai mis en place pour l’env de TEST.

Pour ton point 2, je vais quand même essayer ton idée avec la gestion des erreurs, si j’ai trop de retours, on envisagera la solution 1. Ce qui est compliqué c’est que les Ministères sont audités par le Verificateur General du Quebec et je dois pouvoir expliquer pourquoi nous avons opté pour soit la solution 1 ou la solution 2. C’est la raison pour laquelle je trouve ton retour très instructif.

[anthony]

Je reviens vers toi.

J’ai fini par faire un flux qui centralise les erreurs dans une liste SP, cela fonctionne plutôt bien mais c’est loin d’être évident de donner suffisament d’informations pour que le DEV n’ai pas besoin d’aller en PROD.

Aussi je me suis démandé si tu as déjà réussi à faire un SR read only mais qui donne suffisament de droits pour permettre au dev de consulter l’historique d’excution des flows.

Cela éviterait que le DEV puisse créer une couche non gérée.

Il faut dire que c’est la jungle les permissions et peu de docs dessus même avec chatgpt.