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 d’activité et à leur entreprise, pour exécuter des processus métier et pour collecter des informations à analyser. 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. Si le formulaire ordre de travail est votre formulaire le plus utilisé dans l’application Field Service, c’est une bonne idée de commencer par ce formulaire.
• Réduisez le nombre de champs de type 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.
• Masquer les champs les moins utilisés d’un formulaire par défaut.

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. Dans le cas contraire, vous risquez de provoquer un comportement inattendu du système.

Les organisations qui personnalisent ces composants risquent de ne pas rencontrer immédiatement de problèmes dans leur idée. Cependant, les modifications apportées par Microsoft aux composants personnalisés prêts à l’emploi ne sont pas appliquées aux composants supérieurs couche. Au lieu de cela, le couche personnalisé spécifique remplace tous les changements futurs, 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. Les exemples de champs de date ordre de travail incluent Heure depuis la date promise et Heure jusqu’à la date promise. Les exemples de champs d’état incluent État du système pour le ordre de travail et État du système pour l’accord.

Ne modifiez pas les champs prédéfinis et ne les supprimez pas des formulaires

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

Pour éviter les erreurs :

• Masquer les champs indésirables sur 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 site. Si votre organisation n’a pas besoin de ce champ, masquez-le sur le formulaire au lieu de le supprimer.

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

La modification des valeurs groupe 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 lors des mises à niveau.

Pour éviter les erreurs :

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

Par exemple, le service de terrain ordre de travail inclut un champ État du 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 possède une étiquette et une valeur numérique associée. Les administrateurs système peuvent modifier les libellés des ensembles d’options (tels que Non planifié), mais ils ne peuvent jamais modifier la valeur numérique associée au libellé.

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 exécutés lors du chargement.
• N’écrivez pas de scripts qui appellent beaucoup de données et n’écrivez pas plusieurs scripts qui appellent les mêmes données.

Les sous-sections suivantes décrivent les meilleures pratiques. De plus, suivre les meilleures pratiques en matière de script de formulaire dans Bonnes pratiques de 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 les requêtes réseau sont effectuées lors du chargement d’un formulaire et plus les données téléchargées à partir de ces requêtes sont importantes, plus le temps de chargement du formulaire est long. Demandez uniquement la quantité minimale de données nécessaire. En outre, pensez à mettre les données en cache lorsque cela est possible, pour éviter de demander des données inutilement lors des futurs chargements de formulaires.

É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. L’article de blog suivant fournit d’autres exemples : Optimisez vos applications pilotées par modèle en abandonnant les requêtes synchrones. En outre, envisagez d’utiliser "async and wait" dans tout scénario où plusieurs appels réseau pour la même entité et le même enregistrement sont nécessaires. En savoir plus sur async et wait.

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

Plus vous ajoutez de scripts à un formulaire, plus il faut de temps pour les télécharger. Généralement, les scripts sont mis en cache dans votre navigateur après avoir été chargés pour la première fois. Cependant, la performance la première fois qu’une forme est vue crée souvent une impression significative.

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

Si vous avez du code qui prend en charge uniquement les événements pour les colonnes ou uniquement l’événement, assurez-vous de définir la bibliothèque de scripts avec le gestionnaire d’événements pour ces événements au lieu de l’événement. OnChange OnSave OnLoad De cette façon, le chargement de ces bibliothèques peut être différé et les performances augmentent lorsque le formulaire est chargé.

Utilisez des onglets réduits pour différer le chargement des ressources Web

Les ressources Web ou les composants inclus dans les sections d’un onglet réductible ne sont pas chargés si l’onglet est réduit. iFrame Ils ne sont chargés que lorsque l’onglet est développé. Lorsque l’état de l’onglet change, l’événement se produit. TabStateChange Tout code requis pour prendre en charge les ressources Web ou les iFrames sur les onglets réduits peut utiliser des gestionnaires d’événements pour l’événement et réduire le code qui pourrait autrement devoir apparaître dans l’événement. TabStateChange 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, tenez compte 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 visant à obtenir des informations sur les privilèges des utilisateurs. En savoir plus sur la façon de passer des requêtes synchrones. De plus, évitez les appels des utilisateurs système si les informations des API XRM répondent à vos exigences.

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

Dans ce cas, évitez d’utiliser des scripts de formulaire qui masquent des éléments de formulaire. OnLoad Au lieu de cela, pour les éléments de formulaire qui pourraient être masqués, définissez les options de visibilité par défaut afin que les éléments soient masqués par défaut lorsque le formulaire est chargé. Utilisez ensuite des scripts dans l’événement pour afficher les éléments de formulaire que vous souhaitez rendre visibles. OnLoad

Pour en savoir plus, consultez les ressources suivantes :

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

Exécutez 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, les plugins et les activités de workflow personnalisées.

Pour en savoir plus, consultez les ressources suivantes :

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

Utilisez des workflows asynchrones au lieu de workflows synchrones

Les personnalisateurs de système écrivent souvent des workflows synchrones pour exécuter, en temps réel, la logique métier 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

Le service sur le terrain et la planification des ressources incluent 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 de service sur le terrain et de planification des ressources sont dans un état actif. Pour identifier si les processus sont dans un état désactivé, exécutez régulièrement le Field Service Centre d’intégrité de la solution .

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

Le Centre d’intégrité de la solution vous aide à avoir une meilleure image de l’état de votre environnement et à détecter les problèmes avec votre Dynamics 365 environnement. La configuration d’un environnement peut changer au fil du temps grâce aux opérations naturelles du système. Le Centre d’intégrité de la solution exécute des règles dans une instance pour valider la configuration du 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 sont automatiquement déclenchées lors de l’installation ou de la mise à jour de Field Service.

Pour surveiller la santé de votre environnement, exécutez régulièrement le jeu de règles 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 en savoir plus, consultez Considérations relatives aux performances lors de la personnalisation de l’application mobile.