Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les développeurs qui étendent Dynamics 365 Customer Engagement (local) ont la responsabilité de suivre les règles et les bonnes pratiques documentées dans le KIT de développement logiciel (SDK) : meilleures pratiques pour le développement avec Dynamics 365 Customer Engagement (local) . Le Kit de développement logiciel (SDK) documente les API disponibles pour les développeurs et fournit des conseils sur la façon de les utiliser au mieux. Microsoft prend uniquement en charge les API et pratiques documentées dans le Kit de développement logiciel (SDK). Vous trouverez peut-être quelque chose sur Internet qui décrit comment vous pouvez résoudre un problème, mais s’il ne tire pas parti des API documentées dans le Kit de développement logiciel (SDK), il n’est pas pris en charge par Microsoft. Avant d’appliquer une modification à un développeur, vous devez vérifier si elle utilise des méthodes prises en charge.
Si les développeurs utilisent les API et les meilleures pratiques décrites dans le Kit de développement logiciel (SDK), nous pouvons vérifier si l’une des modifications apportées à Customer Engagement peut interrompre les personnalisations existantes. Notre objectif est que les personnalisations de code écrites à l’aide de méthodes prises en charge continueront de fonctionner lorsque de nouvelles versions ou mises à jour des applications Customer Engagement sont publiées. Vous bénéficiez du fait que vous pouvez effectuer une mise à niveau vers de nouvelles versions avec des fonctionnalités améliorées sans que les développeurs modifient leur code à chaque fois.
Si nous détectons qu’une modification dans une nouvelle version des applications Customer Engagement entraîne l’arrêt d’une personnalisation prise en charge, nous allons documenter ce qui est affecté et comment les utilisateurs peuvent modifier leur code pour le corriger.
Quels types de personnalisations ne sont pas pris en charge avec Dynamics 365 Customer Engagement (local) ?
Simplement parce que certaines API et certaines pratiques de programmation ne sont pas prises en charge par Microsoft ne signifie pas qu’elles ne fonctionnent pas. « Non pris en charge par Microsoft » signifie exactement ce qu’il dit : vous ne pouvez pas obtenir de support sur ces API ou pratiques de programmation de Microsoft. Nous ne les testons pas et nous ne savons pas si quelque chose que nous changeons va les briser. Nous ne pouvons pas prédire ce qui se passera si quelqu’un modifie du code dans notre application.
Le développeur qui utilise des API et des pratiques de programmation non prises en charge assume la responsabilité de prendre en charge son code. Ils devront tester leur code pour s’assurer qu’il fonctionne.
Si vous choisissez d’utiliser des personnalisations non prises en charge dans votre déploiement d’applications Customer Engagement, vous devez être sûr de documenter ce qui a été fait et d’avoir une stratégie pour supprimer ces personnalisations avant de contacter le support technique Dynamics 365 Customer Engagement (local). Si vous avez besoin d’aide pour les 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
Voici une liste des pratiques de personnalisation courantes qui ne sont pas prises en charge. Il ne s’agit pas d’une liste complète. Plus d’informations : Extensions prises en charge pour Dynamics 365 Customer Engagement (local) : Personnalisations non prises en charge.
Interaction avec les éléments DOM (Document Object Model) d’application web à l’aide de JavaScript
Toutes les bibliothèques JavaScript utilisées n’importe où dans l’application doivent uniquement interagir avec les API documentées. Lorsque les développeurs JavaScript travaillent avec des applications, ils accèdent fréquemment aux éléments DOM à l’aide de noms spécifiques. Étant donné que Dynamics 365 Customer Engagement (local) est une application web, ces techniques fonctionnent, mais elles sont susceptibles de s’interrompre pendant une mise à jour, car les noms des éléments qu’ils référencent sont susceptibles de changer à tout moment. Nous nous réservons le droit d’apporter des modifications nécessaires dans l’application et cela signifie fréquemment modifier la façon dont la page est construite. L’ajout de modifications qui dépendent de la structure actuelle de la page signifie que vous devez investir dans le test et peut-être modifier le code personnalisé dans ces scripts chaque fois que vous appliquez une mise à jour à votre application.
jQuery est une bibliothèque très courante utilisée par les développeurs JavaScript. La plupart des avantages 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 d’application des applications Customer Engagement. jQuery est recommandé lorsque les développeurs créent des interfaces utilisateur personnalisées avec des ressources web HTML, mais dans les pages d’application Customer Engagementapps, les API prises en charge ne nécessitent pas l’utilisation de jQuery.
Utilisation d’objets ou de méthodes internes non documentés à l’aide de JavaScript
Dynamics 365 Customer Engagement (local) utilise de nombreux objets JavaScript dans les pages. Un développeur JavaScript peut découvrir ces objets en débogueur une page, puis accéder à ces objets et les réutiliser. Nous nous réservons le droit d’apporter des modifications nécessaires à ces objets, notamment en les supprimant ou en modifiant les noms des méthodes. Si un script référence ces objets, le script s’interrompt s’il n’est pas trouvé.