Meilleures pratiques de personnalisation

Suivez ces bonnes pratiques pour éviter les problèmes de performances, de convivialité et de prise en charge avec Dynamics 365 Field Service.

Réduire les champs personnalisés sur les formulaires

Les personnalisateurs de système ajoutent des champs personnalisés aux formulaires d’entité pour capturer des informations spécifiques à leur secteur et à leur activité, pour exécuter des processus d’entreprise et collecter des informations sur lesquelles créer des rapports. Cependant, trop de champs personnalisés sur un formulaire peuvent entraîner des problèmes de performances.

Pour éviter les problèmes de performance :

• Réduisez le nombre de champs personnalisés sur tous les formulaires. Il est bon de commencer par le formulaire d’ordre de travail s’il s’agit de votre formulaire le plus utilisé dans l’application Field Service.
• Réduisez le nombre de champs de type de recherche et de sous-grilles parmi les champs personnalisés.
• Déplacez les champs personnalisés (en particulier les champs de recherche et les sous-grille) du premier onglet du formulaire vers d’autres onglets.
• Masquez les champs moins utilisés par défaut sur un formulaire.

Ne changez pas les ressources Web, les groupes d’options, les rôles de sécurité ou les workflows prêts à l’emploi

Ne changez pas ni ne personnalisez les ressources web, les groupes d’options, les rôles de sécurité ou les workflows prêts à l’emploi. Sinon, vous risquez de provoquer un comportement système involontaire.

Les organisations qui personnalisent ces composants peuvent ne pas connaître immédiatement de problèmes dans leur environnement. Cependant, les modifications apportées par Microsoft aux composants personnalisés prêts à l’emploi ne sont pas appliquées à la couche supérieure de ces composants. Au lieu de cela, la couche personnalisée spécifique remplace toutes les modifications futures, et ces remplacements finissent par provoquer des erreurs et des comportements imprévisibles.

Ne modifiez pas, ni n’éditez ou ne supprimez pas les champs de date ou les statuts système

La modification, l’édition ou la suppression de champs de date et de statut peut affecter la logique métier et peut perturber les mises à jour de la solution. Des exemples de champs de date d’ordre de travail sont notamment Temps écoulé depuis la promesse et Temps jusqu’à la promesse. Des exemples de champs de statut sont Statut système pour l’ordre de travail et Statut systèm pour le contrat.

Ne modifiez ni ne supprimez les champs de formulaire prédéfinis

Les clients modifient les champs prêts à l’emploi pour répondre aux besoins de l’organisation. Cependant, la modification des champs prêts à l’emploi peut provoquer des erreurs, en particulier lorsque des processus dépendent des valeurs de ces champs.

Pour éviter les erreurs :

• Masquez les champs indésirables d’un formulaire.
• Déplacez les champs indésirables vers un autre onglet de formulaire.

Par exemple : les processus Field Service calculent la valeur du champ Heure d’arrivée estimée sur l’enregistrement Réservation de ressources réservables pour indiquer quand un travailleur de première ligne est censé arriver sur le site. Si votre organisation n’a pas besoin de ce champ, masquez-le sur le formulaire plutôt que de le supprimer.

Ne modifiez pas les valeurs des groupes d’options (choix)

La modification des valeurs des groupes d’options des champs prêts à l’emploi peut provoquer des erreurs, en particulier lorsque les processus dépendent des valeurs de ces champs ou au moment des mises à niveau.

Pour éviter les erreurs :

• Modifiez uniquement les étiquettes de groupe d’options des champs prêts à l’emploi. Ne jamais modifier les valeurs du groupe d’options de ces champs.
• Ne supprimez aucun choix de groupe d’options.
• N’ajoutez aucun choix de groupe d’options.

Par exemple, l’ordre de travail Field Service comprend un champ appelé Statut système par défaut. Ce champ est un groupe d’options (de type choix) et comporte des options telles que Non planifié, Planifié, En cours, Terminé et Annulé. Chaque option contient une étiquette et une valeur numérique associée. Les administrateurs système peuvent modifier les étiquettes des groupes d’options (comme Non planifié), mais ne peuvent jamais modifier la valeur numérique associée à l’étiquette.

Utilisez moins de scripts personnalisés et suivez les bonnes pratiques

Les personnalisateurs de système écrivent des scripts, généralement des ressources web JavaScript, pour exécuter la logique métier. Cependant, les scripts personnalisés peuvent entraîner des problèmes de performances, des erreurs et des complications lors des mises à niveau.

Pour éviter ces problèmes :

• Réduisez le nombre de scripts qui s’exécutent au chargement.
• N’écrivez pas de scripts qui appellent beaucoup de données ou n’écrivez pas plusieurs scripts qui appellent les mêmes données.

Les sous-sections suivantes décrivent les meilleures pratiques. En outre, suivez les meilleures pratiques de script de formulaire dans Meilleures pratiques pour le développement avec Dynamics 365 Customer Engagement.

Minimisez le nombre de requêtes réseau et la quantité de données demandées dans l’événement OnLoad

Plus le nombre de demandes réseau effectuées lors d’un chargement de formulaire est élevé et plus la quantité de données téléchargées à partir de ces demandes est élevée, plus le chargement d’un formulaire prendra du temps. Ne demandez que la quantité minimale de données nécessaire. En outre, envisagez de mettre les données en cache lorsque cela est possible pour éviter de demander des données inutilement lors des futurs chargements de formulaire.

Éviter d’utiliser des requêtes réseau synchrones

Les requêtes réseau synchrones peuvent entraîner des chargements de page lents et des formulaires qui ne répondent pas. Utiliser plutôt des demandes asynchrones. Le billet de blog suivant offre plusieurs exemples : Boostez vos applications pilotées par modèle en vous éloignant des requêtes synchrones. En outre, envisagez d’utiliser « asynchrone et attente » dans tout scénario qui implique plusieurs appels réseau pour la même entité et le même enregistrement. En savoir plus sur Asynchrone et attente.

Éviter d’ajouter des bibliothèques de ressource Web JavaScript inutiles

Plus vous ajoutez de scripts à un formulaire, plus leur temps de téléchargement est long. Habituellement, les scripts sont mis en cache dans votre navigateur après avoir été chargés pour la première fois. Cependant, la performance lors de la première visualisation d’un formulaire génère souvent une impression significative.

Éviter de télécharger tous les scripts dans l’événement Onload

Si vous avez un code qui prend uniquement en charge les événements OnChange pour les colonnes ou l’événement OnSave, veillez à définir la bibliothèque de scripts avec le gestionnaire d’événements pour ces événements au lieu de l’événement OnLoad. De cette façon, le chargement des bibliothèques peut être reporté et les performances du formulaire peuvent être améliorées lors du chargement.

Utiliser des onglets réduits pour reporter le chargement des ressources Web

Les ressources web ou composants iFrame inclus dans les sections d’un onglet réduit ne sont pas chargés si l’onglet est réduit. Ils sont chargés uniquement lorsque l’onglet est développé. Lorsque le statut de l’onglet change, l’événement TabStateChange se produit. Le code requis pour prendre en charge les ressources Web ou les iFrames dans les onglets réduits peut utiliser les gestionnaires d’événements pour l’événement TabStateChange et réduire le code autrement susceptible de se produire dans l’événement OnLoad.

Évitez les requêtes réseau en double dans le code côté client

Des requêtes réseau multiples ou en double peuvent provoquer le blocage du navigateur web et affecter le temps de chargement du formulaire. La réduction du nombre de requêtes peut améliorer les performances. Une alternative consiste à consolider les requêtes réseau et à mettre en cache la valeur des requêtes. En outre, envisagez des requêtes réseau asynchrones, comme cela a été mentionné précédemment.

Évitez d’utiliser des rôles et des appels spécifiques à l’utilisateur système si les informations pertinentes sont disponibles dans les API XRM

Utilisez les API XRM pour éviter les requêtes réseau pour obtenir des informations sur les privilèges de l’utilisateur. En savoir plus sur la transition vers l’abandon des requêtes synchrones. De même, évitez les appels d’utilisateurs système si les informations des API XRM répondent à vos besoins.

Définir des options de visibilité par défaut

Dans l’événement OnLoad, évitez d’utiliser les scripts de formulaire qui masquent des éléments du formulaire. Définissez plutôt des options de visibilité par défaut pour des éléments de formulaire pouvant être masqués par défaut lors du chargement du formulaire. Utilisez ensuite des scripts dans l’événement OnLoad pour afficher les éléments de formulaire à afficher.

En savoir plus dans les ressources suivantes :

• Concevoir des formulaires pour les performances dans les applications pilotées par modèle
• Personnalisations non prises en charge

Exécuter le vérificateur de solution sur vos scripts

Le vérificateur de solution Power Apps est un outil précieux de Microsoft qui vérifie les solutions Power Apps pour y détecter les problèmes et recommander les meilleures pratiques. Ces problèmes incluent des problèmes avec JavaScript, HTML, plug-ins et les activités de workflow personnalisées.

En savoir plus dans les ressources suivantes :

• Améliorer les performances, la stabilité et la fiabilité des composants avec le vérificateur de solutions
• Comment exécuter et utiliser le vérificateur de solution Power Apps
• Vérificateur de solution Dataverse

Utiliser des workflows asynchrones au lieu de workflows synchrones

Les personnalisateurs de système écrivent souvent des workflows synchrones pour exécuter une logique métier en temps réel qui s’exécute lorsque les données sont modifiées dans Field Service. Cependant, l’exécution synchrone des workflows nuit aux performances. Pour éviter les problèmes de performances, exécutez plutôt les workflows de manière asynchrone.

Activez les processus prêts à l’emploi de Field Service et de la planification des ressources

Field Service et la Planification des ressources sont livrés avec de nombreux processus qui exécutent la logique métier nécessaire. Les processus désactivés peuvent entraîner des erreurs. Pour éviter les problèmes, assurez-vous que tous les processus Field Service et Planification des ressources sont dans un état actif. Pour identifier si les processus sont dans un état désactivé, exécutez le Centre d’intégrité de la solution Field Service régulièrement.

Exécuter le Contre d’intégrité de la solution pour détecter les problèmes

Le Centre d’intégrité de la solution vous permet d’obtenir une meilleure image de l’état de votre environnement et de détecter des problèmes dans l’environnement Microsoft Dynamics 365. La configuration d’un environnement peut changer au fil du temps en raison des opérations du système naturel. Le Centre d’intégrité de la solution exécute des règles au sein d’une instance pour valider la configuration de l’environnement. Certaines règles sont spécifiques à Field Service et vous pouvez les exécuter à la demande lorsque vous rencontrez un problème. Certaines règles se déclenchent automatiquement lorsque Field Service est installé ou mis à jour.

Pour surveiller l’intégrité de votre environnement, eécutez régulièrement l’ensemble de règles du Centre d’intégrité de la solution.

Éléments à prendre en compte pour les performances de l’application mobile

La personnalisation de l’application mobile peut affecter les performances. Pour plus d’informations, consultez la rubrique Considérations relatives aux performances lors de la personnalisation de l’application mobile.