Meilleures pratiques de personnalisation

  • Article

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.
  • Parmi les champs personnalisés, réduire le nombre de champs de type recherche et sous-grilles aura le plus grand impact sur les performances du formulaire, comme les temps de chargement.
  • 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 les moins utilisés par défaut sur le formulaire.

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

La personnalisation, la prise de dépendances ou l’appel personnalisé de ressources Web, d’ensembles d’options, de rôles de sécurité ou de workflows prêts à l’emploi ne sont pas pris en charge et peuvent entraîner un comportement système inattendu.

Les organisations qui personnalisent ces composants peuvent ne pas voir immédiatement les problèmes dans leur environnement. Toutefois, à mesure que Microsoft publie des modifications sur les composants personnalisés prêts à l’emploi, ces modifications ne sont pas appliquées à la couche supérieure de ce composant. La couche personnalisée spécifique remplace toutes les modifications futures, qui finissent par provoquer des erreurs et un comportement 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 date d’ordre de travail sont Temps écoulé depuis la promesse et le Temps jusqu’à la promesse. Les champs de statut sont par exemple le statut système de l’ordre de travail et le statut système du 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.

Voici un 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.

Pour en savoir plus, voir les articles suivants :

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 :

  • Ne modifiez que les Étiquettes des groupes d’options, mais ne modifiez jamais les valeurs des groupes d’options des champs prêts à l’emploi.
  • Ne supprimez aucun choix de groupe d’options.
  • N’ajoutez aucun choix de groupe d’options.

Voici juste un 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 ») avec des options telles que Non planifié, Planifié, En cours, Terminé, Annulé, etc. Chacune de ces options a 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 de la mise à niveau.

Pour éviter ces problèmes :

  • Réduisez le nombre de scripts s’exécutant 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.

Suivez les bonnes pratiques en matière de script de formulaire, notamment les bonnes pratiques suivantes :

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. Envisagez également de mettre les données en cache lorsque cela est possible pour éviter de demander des données inutilement lors des futurs chargements de page.

É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. Consultez ce billet de blog pour plus d’exemples. 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 ; vous trouverez plus de détails ici.

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

Plus vous ajoutez de scripts au formulaire, plus leur temps de téléchargement est long. Généralement, les scripts sont mis en cache dans le navigateur après leur premier téléchargement, mais les performances d’un formulaire au premier affichage créent souvent une impression durable.

É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

Lorsque des ressources Web ou des composants iframe sont inclus dans les sections d’un onglet réduit, ils ne sont pas chargés si l’onglet est réduit. Ils sont chargés 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 iframe 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. Envisagez également les requêtes réseau asynchrones, comme mentionné ci-dessus.

É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. Consultez l’article suivant sur 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

Évitez d’utiliser des scripts de formulaire dans l’événement OnLoad qui masquent des éléments de 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.

Pour plus d’informations, consultez ces ressources :

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 compléments et les activités de workflow personnalisées.

Pour plus d’informations, consultez ces ressources :

Utiliser des workflows asynchrones au lieu de 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 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. Exécutez le Centre d’intégrité de la solution Field Service régulièrement pour identifier si les processus sont dans un état désactivé.

Exécutez 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. Le Centre d’intégrité de la solution exécute des règles dans une instance pour valider la configuration de l’environnement, qui peut changer au fil de l’exploitation naturelle du système. Certaines règles sont spécifiques à Dynamics 365 Field Service et vous pouvez exécuter des règles à la demande lorsque vous rencontrez un problème. Certaines règles se déclenchent automatiquement lorsque Field Service est installé ou mis à jour.

Exécutez régulièrement l’ensemble de règles du Centre d’intégrité de la solution Field Service pour surveiller l’intégrité de votre environnement.

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

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