Pratiques de personnalisation prises en charge et non prises en charge
Les développeurs qui étendent Dynamics 365 Customer Engagement (on-premises) doivent suivre les règles et les meilleures pratiques documentées dans le Kit de développement logiciel (SDK) : Meilleures pratiques de développement avec Dynamics 365 Customer Engagement (on-premises). Le SDK documente les API disponibles pour les développeurs et fournit des instructions pour les utiliser au mieux. Microsoft prend en charge uniquement les API et les pratiques qui sont documentées dans le Kit de développement logiciel. Vous trouverez peut-être sur Internet des explications pour résoudre un problème, mais si les méthodes ne tirent pas parti des API documentées dans le Kit de développement logiciel, elles ne sont pas prises en charge par Microsoft. Avant de demander à un développeur d’appliquer une modification, vérifiez qu’elle utilise des méthodes prises en charge.
Si les développeurs utilisent les API et les meilleures pratiques décrites dans le SDK, nous sommes surs de pouvoir tester si les modifications que nous apportons à Customer Engagement risquent de désactiver les personnalisations existantes. Notre objectif est que les personnalisations de code entrées en utilisant les méthodes prises en charge continuent de fonctionner au fil des publications des nouvelles versions ou mises à jour des applications Customer Engagement. Vous avez tout à y gagner, car vous pouvez effectuer des mises à niveau vers les nouvelles versions avec des fonctionnalités améliorées sans que les développeurs ne modifient leur code à chaque fois.
Si nous détectons qu’un changement dans une nouvelle version des applications Customer Engagement provoque la désactivation d’une personnalisation prise en charge, nous documenterons ce point et la modification à apporter au code pour résoudre le problème.
Quels types de personnalisations ne sont pas pris en charge avec Dynamics 365 Customer Engagement (on-premises) ?
Ce n’est pas parce que certaines API et pratiques de programmation ne sont pas prises en charge par Microsoft qu’elles ne fonctionnent pas. « Non pris en charge par Microsoft » signifie exactement ce qui est écrit : vous ne pouvez pas obtenir d’aide de Microsoft pour ces API ou pratiques de programmation de la part de Microsoft. Nous ne les testons pas, et nous ne savons pas si l’une de nos modifications risque de les désactiver. Nous ne pouvons pas prévoir ce qui se produit si un utilisateur modifie du code dans notre application.
Les développeurs qui utilisent des API et des pratiques de programmation non prises en charge assument la responsabilité du suivi de leur code. Ils devront tester leur code pour vérifier son fonctionnement.
Si vous choisissez d’utiliser des personnalisations non prises en charge dans votre déploiement des applications Customer Engagement, vous devez absolument documenter ce qui a été fait et avoir une stratégie pour supprimer ces personnalisations avant de contacter le support technique des applications Dynamics 365 Customer Engagement (on-premises). Si vous avez besoin d’aide pour des personnalisations non prises en charge, contactez le développeur ou l’organisation qui a préparé les personnalisations.
Pratiques courantes de personnalisation non prises en charge
La liste suivante répertorie les pratiques courantes de personnalisation qui ne sont pas prises en charge. Ce n’est pas une liste complète. Pour plus d’informations : Extensions prises en charge pour Dynamics 365 Customer Engagement (on-premises) : personnalisations non prises en charge.
Interaction avec les éléments DOM (Document Object Model) d’application Web utilisant JavaScript
Toutes les bibliothèques JavaScript utilisées dans l’application doivent interagir uniquement avec les API documentées. Lorsque les développeurs JavaScript utilisent des applications, ils accèdent souvent aux éléments DOM en utilisant des noms spécifiques. Dans la mesure où Dynamics 365 Customer Engagement (on-premises) est une application Web, ces techniques fonctionnent, mais elles sont susceptibles d’être désactivées pendant une mise à jour, car les noms des éléments qu’ils référencent sont susceptibles d’être modifiés à tout moment. Nous nous réservons le droit d’apporter les modifications nécessaires dans l’application, ce qui implique souvent de modifier la construction de la page. Apporter des modifications en fonction de la structure actuelle de la page implique d’investir dans des tests et, peut-être, en de modifier le code personnalisé dans ces scripts à chaque fois que vous appliquez une mise à jour à votre application.
La bibliothèque jQuery est très souvent utilisée par les développeurs JavaScript. Le plus grand avantage de l’utilisation de jQuery est qu’il simplifie la capacité d’un développeur à accéder et à créer des éléments DOM, ce qui est exactement ce que nous ne prenons pas en charge dans les pages des applications Customer Engagement. jQuery est recommandé lorsque les développeurs créent des interfaces utilisateur personnalisées avec les ressources Web HTML, mais dans les pages des applications Customer Engagement, les API prises en charge ne nécessitent pas l’utilisation de jQuery.
Utilisation des objets ou méthodes internes non documentés avec JavaScript
Dynamics 365 Customer Engagement (on-premises) utilise nombre des objets JavaScript dans les pages. Un développeur JavaScript peut identifier ces objets en déboguant une page, puis accéder à ces objets et les réutiliser. Nous nous réservons le droit d’apporter les modifications nécessaires à ces objets, notamment de les supprimer ou de modifier le nom des méthodes. Si un script fait référence à ces objets, le script s’interrompt s’ils sont introuvables.