Pratiques recommandées pour développer avec Dynamics 365 Customer Engagement

Cette rubrique décrit les pratiques recommandées pour personnaliser Dynamics 365 for Customer Engagement.

Important

Consultez les Extensions prises en charge pour Dynamics 365 Customer Engagement (on-premises) pour en savoir plus sur les techniques prises en charge ou non pour la personnalisation.

Meilleures pratiques pour les performances

Les recommandations suivantes peuvent vous aider à écrire un code plus performant.

Utiliser plusieurs threads

Ajoutez la prise en charge des threads à votre application pour répartir le travail entre plusieurs processeurs. Cette suggestion suppose que vous exécutiez votre code sur un système multiprocesseur. Autres informations : Article Guide de développement avancé du .NET Framework sur les threads gérés.

Autoriser le système à créer des GUID

Autorisez le système à attribuer automatiquement le GUID (ID) au lieu de le créer manuellement vous-même. Cette suggestion permet à Dynamics 365 Customer Engagement (on-premises) de tirer parti des GUID séquentiels, qui fournissent de meilleures performances SQL. L’exemple de code suivant montre comment appeler la méthode Create pour obtenir un GUID attribué par le système.

// Instantiate an account object.
Account account = new Account { Name = "Fourth Coffee" };  
// Create an account record named Fourth Coffee and retrieve the GUID.
accountId = serviceProxy.Create(account);  

Utilisation des types à liaison anticipée

Utilisez la classe Entity lorsque votre code doit utiliser des entités et des attributs qui ne sont pas connus au moment de l’écriture du code. En outre, si votre code personnalisé fonctionne avec des milliers d’enregistrements d’entités, l’utilisation de la classe Entity entraîne des performances légèrement meilleures que les types à liaison anticipée. Toutefois, cette souplesse a un inconvénient, car vous ne pouvez pas vérifier les noms d’entité et d’attribut à la compilation. Si les entités sont déjà définies lors du code et que la légère dégradation des performances est acceptable, vous devez utiliser les types à liaison anticipée que vous pouvez générer à l’aide de l’outil CrmSvcUtil. Plus d’informations : Utiliser les classes d’entité à liaison anticipée dans le code

Désactiver les plug-ins

Si possible, désactivez les plug-ins enregistrés avant d’exécuter l’application.

Écrire des plug-ins qui s’exécutent plus rapidement

Écrivez toujours un plug-in qui prend le moins le temps possible pour effectuer la tâche planifiée. Par exemple, la méthode Execute est souvent traitée dans Dynamics 365 Customer Engagement (on-premises). Si vous enregistrez un plug-in sur ce message, votre plug-in peut avoir un impact important sur les performances du système, car il s’exécute chaque fois que la méthode Execute est traitée, ce qui se passe souvent.

Si vous envisagez d’enregistrer vos plug-ins pour l’exécution synchrone, il est recommandé de les concevoir pour que leur opération s’exécute en moins de 2 secondes. Il est préférable de réduire le temps de traitement des plug-ins afin de maintenir l’interactivité des applications clientes qui sont connectées au même service d’organisation que celui qui exécute le plug-in.

Limiter les données que vous récupérez

Lorsque vous utilisez les méthodes qui récupèrent les données du serveur, extrayez le volume minimal de données dont votre application a besoin. Pour ce faire, spécifiez l’ensemble de colonnes, qui est l’ensemble des attributs d’entité à récupérer.

Par exemple, il est rarement conseillé de récupérer toutes les métadonnées avec le message RetrieveAllEntities à l’aide de la classe RetrieveAllEntitiesRequest, en spécifiant le filtre d’entité All` pour la propriété EntityFilters. Par contre, vous pouvez obtenir des performances optimisées si vous limitez le filtre d’entité ou utilisez l’une des classes de demande de message suivantes : RetrieveEntityRequest, RetrieveOptionSetRequest, RetrieveAttributeRequest, RetrieveRelationshipRequest ou RetrieveMetadataChangesRequest. Le message RetrieveMetadataChanges permet de créer une requête pour renvoyer uniquement les données nécessaires ou les métadonnées modifiées. Pour plus d’informations : Récupérer et détecter les modifications apportées aux métadonnées.

Limitez le nombre d’entités activées pour le mode hors connexion

Réfléchissez si une entité doit être disponible pour les utilisateurs en mode hors connexion. Chaque entité activée pour le mode hors connexion affecte directement le temps nécessaire à l’utilisateur pour synchroniser les données lorsqu’il revient en ligne. Cela est particulièrement utile pour les utilisateurs avec des ordinateurs moins puissants.

Limiter les opérations qui s’affichent en cascade jusqu’aux entités associées

Lorsque vous utilisez la méthode Update ou le message UpdateRequest, ne définissez pas l’attribut OwnerId sur un enregistrement, à moins que le propriétaire n’ait réellement changé. Lorsque vous définissez cet attribut, les modifications s’affichent souvent en cascade jusqu’aux entités associées, ce qui augmente la durée nécessaire pour l’opération de mise à jour. Plus d’informations : Comportement en cascade

Ajuster les paramètres du proxy sur le client (local uniquement)

 

Un serveur proxy réside entre une application cliente, telle qu’un navigateur web, et le serveur cible réel. Lorsqu’un ordinateur est dans un réseau local, il peut utiliser un serveur proxy pour se connecter à Internet. Dans ce cas, le serveur proxy est associé au serveur de passerelle serveur et au serveur de pare-feu (ou en fait partie). Le proxy peut mettre en cache les demandes web et traiter plusieurs demandes de clients en utilisant les données mises en cache. Si les données demandées ne sont pas présentes dans le cache du serveur proxy, ce dernier fait suivre la demande vers le serveur actif à l’aide de sa propre adresse IP. Ici, le serveur proxy agit au nom de l’ordinateur client.

Bien qu’un serveur proxy puisse agir en tant que serveur de cache et aider à télécharger une page web plus rapidement, il peut parfois diminuer les performances s’il n’est pas utilisé correctement.

Souvent, les utilisateurs évitent la configuration manuelle du proxy et utilisent à la place la configuration automatique. Ce raccourci aide à équilibrer la charge des serveurs proxys, mais en fonction de la complexité du script de configuration, un délai important peut être rencontré lors de la configuration du proxy automatique.

Lorsque le serveur des applications Dynamics 365 Server est installé, vous pouvez ignorer le serveur proxy pour obtenir un meilleur débit.

Le serveur offre une adresse web locale qui ne requiert aucun proxy cible. Vous pouvez sélectionner Ignorer le serveur proxy pour les adresses locales et fournir le nom complet du serveur des applications Dynamics 365 Server dans la liste des exceptions. De cette façon, vous obtenez un meilleur débit lorsque les enregistrements sont créés à l’aide des assemblys SDK.

Améliorer les performances d’allocation des canaux de service

Vous pouvez créer une connexion aux services web Dynamics 365 Customer Engagement (on-premises) et authentifier les utilisateurs à l’aide des classes de proxy de service OrganizationServiceProxy et DiscoveryServiceProxy. Toutefois, l’utilisation incorrecte de ces classes de proxy de service peut parfois réduire les performances des applications. Par conséquent, si vous savez quand et comment utiliser les différents classes clientes disponibles dans le SDK, vous pouvez souvent obtenir de meilleures performances de l’application.

Lorsque vous créez un canal de service Windows Communication Foundation (WCF) à l’aide d’un point de terminaison de service, par exemple, en utilisant le service web d’organisation, votre application doit effectuer deux opérations longues : le téléchargement des métadonnées depuis le point de terminaison et l’authentification de l’utilisateur. Vous pouvez améliorer les performances si votre application exécute ces opérations un nombre minimal de fois pour chaque session d’application.

Le constructeur OrganizationServiceProxy illustré ici effectue ces deux opérations chaque fois qu’un objet proxy de service est créé.

OrganizationServiceProxy (Uri uri, Uri homeRealmUri, ClientCredentials clientCredentials, 
    ClientCredentials deviceCredentials)  

Vous obtenez généralement de meilleures performances si votre application utilise ce constructeur une fois pour créer une instance du proxy de service pendant la session d’application et pour mettre en cache la référence retournée en vue de l’utiliser dans différents chemins d’accès au code au sein de votre application. Notez que comme la référence de service retournée n’est pas thread-safe, les applications multithread devront allouer une instance par thread. Les applications doivent également appeler Dispose sur l’objet proxy de service avant qu’ils ne se terminent afin de libérer les ressources allouées par canal de service.

La classe de proxy de service effectue le téléchargement des métadonnées et l’authentification utilisateur à l’aide des méthodes de classe suivantes.

IServiceManagement<IOrganizationService> orgServiceManagement = 
    ServiceConfigurationFactory.CreateManagement<IOrganizationService>(
    new Uri(organizationUrl));

AuthenticationCredentials authCredentials = orgServiceManagement.Authenticate(credentials);

La méthode ServiceConfigurationFactory .CreateManagement effectue le téléchargement des métadonnées, tandis que la méthode Authenticate(AuthenticationCredentials) authentifie l’utilisateur. Les objets retournés depuis ces méthodes sont thread-safe et peuvent être statiquement mises en cache par votre application. Vous pouvez alors utiliser ces objets pour construire un objet proxy de service qui utilise l’un des autres constructeurs disponibles.

OrganizationServiceProxy (orgServiceManagement, authCredentials.ClientCredentials)
OrganizationServiceProxy (orgServiceManagement, authCredentials.SecurityTokenResponse)  

En mettant en cache la gestion des services et les objets des informations d’identification authentifiées, votre application peut créer plus efficacement les objets proxy de service plusieurs fois par session d’application. Si vous activez les types à liaison anticipée sur OrganizationServiceProxy via l’une des méthodes EnableProxyTypes(), vous devez procéder de même sur tous les proxys de service créés à partir de l’objet IServiceManagement<TService> mis en cache. Si votre application utilise les métadonnées, il est recommandé qu’elle mette en cache les métadonnées qu’elle extrait et appelle régulièrement le message RetrieveTimestampRequest pour déterminer si elle doit actualiser le cache.

En outre, surveillez votre jeton de sécurité WCF (Token) et actualisez-le avant qu’il n’expire pour éviter de perdre le jeton et de devoir recommencer l’authentification. Pour activer le jeton, créez une classe personnalisée qui hérite de la classe OrganizationServiceProxy ou de la classe DiscoveryServiceProxy et qui implémente la logique métier pour contrôler le jeton. Ou enveloppez les classes proxy dans une nouvelle classe. Une autre technique consiste à contrôler explicitement le jeton avant chaque appel au service web. Un exemple de code illustrant ces techniques se trouve dans les classes ManagedTokenDiscoveryServiceProxy, ManagedTokenOrganizationServiceProxy et AutoRefreshSecurityToken de la rubrique Code d’assistance : classe ServerConnection.

Meilleures pratiques de personnalisation

Les meilleures pratiques suivantes peuvent vous aider à personnaliser et à étendre Dynamics 365 Customer Engagement (on-premises).

Meilleures pratiques pour Dynamics 365 Customer Engagement (on-premises)

Le livre blanc Modèles et principes pour les concepteurs de solutions d’applications Microsoft Dynamics 365 Customer Engagement (on-premises) fournit des instructions spécifiques sur l’élaboration de solutions à l’aide de Dynamics 365 for Customer Engagement.

Utilisation des entités et des attributs personnalisés

Utilisez toujours le nom d’entité pour faire référence à des entités dans le code et les requêtes. N’utilisez pas le code de type objet (également désigné comme le type d’entité), car la valeur entière varie entre entités personnalisées de différentes organisations.

Gagnez de l’espace sur votre serveur au moyen de ces techniques :

• Créez des attributs personnalisés pour les entités existantes au lieu de créer une nouvelle entité.
• Renommez les entités existantes pour les rendre plus significatives.

Quand doit-on personnaliser une entité ?

Personnalisez une entité système, telle que l’entité opportunité, au lieu de la remplacer par une nouvelle entité personnalisée afin que vous puissiez utiliser les nombreuses fonctions intégrées d’une entité existante.

Contextes d’utilisation des plug-ins et du workflow

En tant que développeur intéressé par l’extension ou la personnalisation de Dynamics 365 Customer Engagement (on-premises), vous pouvez choisir entre plusieurs méthodes pour effectuer vos tâches. En plus de l’ajout de code JavaScript côté client à un formulaire ou de l’ajout de pages personnalisées ASP.NET, vous pouvez créer un plug-in ou un workflow personnalisé via l’interface web qui appelle une activité de workflow personnalisée. Comment choisir entre l’utilisation d’un plug-in et celle d’un workflow ? La technologie que vous utilisez dépend de la tâche à effectuer et de l’auteur de la personnalisation.

Par exemple, vous devez utiliser un workflow en temps réel de plug-in synchrone si vous souhaitez exécuter un code personnalisé immédiatement avant ou après que l’opération de plateforme principale ne s’exécute et avant que le résultat de l’opération ne soit renvoyé de la plateforme. Vous ne pouvez pas utiliser un workflow asynchrone ou un plug-in asynchrone dans cette situation, car ils sont mis en file d’attente pour s’exécuter une fois que l’opération principale a fini de s’exécuter. Par conséquent, vous ne pouvez pas prévoir quand ils s’exécuteront. Pour ajouter la fonctionnalité personnalisée à Dynamics 365 for Customer Engagement, les workflows, les activités de workflow personnalisées et les plug-ins sont pris en charge, mais pas les workflows XAML.

Évaluez ces technologies et sélectionnez celle qui répond le mieux à vos objectifs métier après avoir pris en compte les questions de déploiement, de performance et de maintenance de votre solution de plug-in ou de workflow.

Le tableau suivant récapitule les caractéristiques des plug-ins et des workflows.

Critères	Plug-in	Workflow
Exécution avant son après l’opération principale de la plateforme (Créer, Supprimer, Mettre à jour, etc.)	S’exécute juste avant ou après l’opération principale (synchrone). Peut également être mis en file d’attente pour s’exécuter après l’opération principale (asynchrone).	Les workflows asynchrones sont mis en file d’attente pour s’exécuter après l’opération principale. Les workflows en temps réel possèdent des caractéristiques similaires aux plug-ins.
Impact des performances sur le serveur	Les plug-ins synchrones peuvent augmenter le temps de réponse de la plateforme, car ils font partie du traitement principal de la plateforme. Les connexions asynchrones ont moins d’impact sur le temps de réponse du serveur, car le code s’exécute dans un autre processus.	Les workflows asynchrones ont moins d’impact sur le temps de réponse du serveur, car le code s’exécute dans un autre processus. Les workflows en temps réel possèdent des performances similaires aux plug-ins en mode bac à sable.
Restrictions de sécurité	Inscrire un plug-in auprès de la plateforme nécessite un rôle de sécurité Administrateur système ou Personnalisateur de système, ainsi que l’appartenance au groupe Administrateur de déploiement.	Les utilisateurs peuvent interactivement créer des workflows dans l’application web. Toutefois, pour inscrire une activité de workflow personnalisée, l’utilisateur en charge du déploiement doit avoir les mêmes rôles de sécurité que ceux requis pour inscrire les plug-ins.
Support de la version Dynamics 365 Customer Engagement (on-premises) (SKU)	Pris en charge dans Dynamics 365 for Customer Engagement lorsqu’il est enregistré dans le bac à sable. Peut être pris en charge dans les installations hébergées par un partenaire à la discrétion de celui-ci.	Les workflows sont pris en charge par tous les déploiements Customer Engagement. Les activités de workflow personnalisées sont prises en charge dans le bac à sable de Dynamics 365 for Customer Engagement , et dans le bac à sable ou à l’extérieur de celui-ci pour les déploiements locaux/IFD.
Longueur du temps de traitement	Un plug-in inscrit pour l’exécution synchrone ou asynchrone doit achever son exécution dans un délai de deux minutes.	Fonctionne bien pour les processus courts ou longs. Toutefois, chaque activité d’un workflow ne peut pas prendre plus de deux minutes pou s’achever.
Fonctionne lorsque le client de Dynamics 365 for Outlook est en mode hors connexion	Les modes en ligne et hors connexion sont pris en charge.	Les workflows ne s’exécutent pas en mode hors connexion.
Persistance des processus et données	Les plug-ins s’exécutent jusqu’à ce qu’ils soient terminés. Les plug-ins doivent être écrits comme sans état quand aucune donnée en mémoire n’est conservée.	Les workflows asynchrones peuvent être suspendus, remis, annulés ou repris par le biais des appels SDK ou par l’utilisateur via l’application web. L’état du workflow est automatiquement enregistré avant d’être suspendu ou reporté. Les workflows en temps réel ne peuvent pas être en état d’attente. Ils doivent s’exécuter jusqu’à la fin tout comme les plug-ins.
Emprunt d’identité	Les plug-ins peuvent effectuer des opérations de données au nom d’un autre utilisateur système.	Les workflows asynchrones ne peuvent pas utiliser l’emprunt d’identité, contrairement aux workflows en temps réel. Les workflows en temps réel peuvent s’exécuter en tant que propriétaire du workflow ou en tant qu’utilisateur appelant.
Création	Les ingénieurs ou programmeurs logiciels peuvent créer des plug-ins.	Quiconque, que ce soit un utilisateur final, un analyste d’entreprise ou un administrateur, peut créer des workflows s’il dispose des autorisations appropriées.

Il n’y a aucun impact significatif sur les performances du serveur entre un plug-in asynchrone et un workflow.

Quel type de workflow est préférable ?

Du point de vue des performances, est-il préférable de créer un seul long workflow ou plusieurs workflows enfants et de les appeler dans un workflow parent ? L’approche workflow enfant produit un débit inférieur, mais elle est plus facile à gérer si vous modifiez souvent votre définition de workflow. Le temps de compilation n’est pas un problème majeur, car le workflow n’est compilé que lors de la publication. Toutefois, Dynamics 365 Customer Engagement (on-premises) occasionne une surcharge quand il démarre chaque instance de workflow. La surcharge se produit quand toutes les entités utilisées dans le workflow sont récupérées et que le workflow enfant est démarré dans un processus à deux étapes qui inclut une « tâche d’extension du workflow » et l’instance du workflow réelle. Par conséquent, pour un débit maximal, utilisez un seul long workflow.

Comment doit-on marquer comme terminée l’activité de workflow personnalisée ?

La valeur renvoyée par la méthode Execute est utilisée par l’exécution du workflow pour marquer l’activité comme « terminée ». Vous devez utiliser return base.Execute(executionContext) à moins que l’activité n’ignore la fonctionnalité de la classe de base. Évitez de retourner ActivityExecutionStatus.Closed. Autres informations : Énumération ActivityExecutionStatus

Comment reporter les exceptions des activités de workflow personnalisées ?

Vous devez lever une exception InvalidPluginExecutionException dans votre code. Cette erreur s’affiche dans le formulaire de l’instance de workflow.

Peut-on définir les entités personnalisées spécifiques aux divisions ?

Les entités personnalisées ont des privilèges pour chaque rôle de sécurité, mais pas pour chaque division. Pour définir les entités personnalisées visibles uniquement par les divisions spécifiées, vous devez créer différents rôles de sécurité pour chaque division et accorder les privilèges à l’entité personnalisée du rôle approprié.

Meilleures pratiques de sécurité

Suivez ces instructions pour protéger vos données d’entreprise.

Général

Les meilleures pratiques pour sécuriser votre implémentation de Dynamics 365 Customer Engagement (on-premises) incluent les actions suivantes :

• Établissez un plan approuvé des données de sécurité pour l’implémentation Dynamics 365 Customer Engagement (on-premises) de votre organisation.
• Attribuez les privilèges minimaux obligatoires lorsque vous configurez votre pool d’applications.
• Exigez que tous les utilisateurs utilisent des mots de passe forts pour leurs comptes.

Pour plus d’informations : Concepts de sécurité pour Dynamics 365 Customer Engagement (on-premises)

Rôles, privilèges et droits d’accès

Les meilleures pratiques pour l’utilisation du modèle de sécurité Dynamics 365 Customer Engagement (on-premises) incluent les actions suivantes :

• Limitez strictement le nombre de personnes affectées au rôle Administrateur système. Ne supprimez jamais ce rôle.
• Créez des rôles selon la meilleure pratique de sécurité du privilège minimal, en fournissant l’accès à la quantité minimale de données commerciales nécessaires à la tâche. Attribuez aux utilisateurs le rôle approprié à leur travail.
• Créez un nouveau rôle avec ces privilèges spécifiques et ajoutez l’utilisateur au nouveau rôle si un utilisateur a besoin de niveaux d’accès ou de droits supplémentaires. Les droits d’un utilisateur sont l’union de tous les rôles auxquels il a été affecté. N’octroyez pas les privilèges de rôle originaux nécessaires uniquement à un ou plusieurs membres.
• Utilisez le partage, le cas échéant, pour attribuer à des utilisateurs spécifiques des droits spécifiques sur des objets, et non des privilèges plus larges sur tous les objets d’un type donné.
• Utilisez des équipes pour créer des groupes fonctionnels croisés afin que les objets spécifiques puissent être partagés avec l’équipe.
• Formez les utilisateurs ayant des droits d’accès de partage pour partager les informations minimales nécessaires.

Éviter élévation du privilège

Les attaques par élévation de privilège se produisent lorsqu’un utilisateur peut assumer les privilèges d’un compte approuvé, tels qu’un propriétaire ou un administrateur. Exécutez toujours sous des comptes d’utilisateur avec moins de privilèges et attribuez uniquement les autorisations nécessaires. Évitez l’utilisation de comptes administrateur ou propriétaire pour exécuter le code. Vous limitez ainsi la quantité de dommage qui peut se produire si une attaque aboutit. Dans les tâches qui requièrent des autorisations supplémentaires, utilisez la signature de procédure ou l’emprunt d’identité uniquement pendant la durée de la tâche.

Développement côté serveur

Les meilleures pratiques du développement du code côté serveur pour Dynamics 365 Customer Engagement (on-premises) concernent les éléments suivants :

• Ne modifiez pas la base de données Dynamics 365 Customer Engagement (on-premises) par quelque autre moyen que l’utilisation du SDK, car cela permet d’ignorer le modèle de sécurité Dynamics 365 Customer Engagement (on-premises).
• Les plug-ins s’exécutent dans le contexte d’un administrateur – vous devez savoir que ce code peut accéder à des informations auxquelles l’utilisateur connecté n’a pas accès.
• Pour les assemblys de workflow et les plug-ins, évitez d’écrire un code qui nécessite un temps d’exécution long. Il est important que le code du plug-in inscrit pour s’exécuter de manière synchrone retourne aussi rapidement que possible.
• Si vous répliquez les données Dynamics 365 Customer Engagement (on-premises) dans votre propre magasin de données, vous êtes responsable de la sécurité des données. Si vous utilisez un plug-in pour transmettre les données, n’oubliez pas d’inscrire le plug-in pour qu’il s’exécute après l’opération de plateforme principale. Les contrôles de privilège de sécurité de l’utilisateur connecté se produisent lors de l’opération de plateforme principale.
• Les données qui proviennent de Dynamics 365 Customer Engagement (on-premises) peuvent ne pas être sûres pour le rendu. Les données peuvent avoir été injectées avec des balises HTML qui ne sont pas sécurisées.
• Respectez l’exigence de ne pas accéder directement aux bases de données Dynamics 365 Customer Engagement (on-premises) via SQL Server Enterprise Manager. Ignorer le SDK peut ouvrir la voie à des menaces d’injection SQL.
• Pour les déploiement avec accès via Internet, n’oubliez pas que votre solution n’est aussi sécurisée que le lien le plus faible. Lorsque votre application est exposée à Internet, elle est également exposée à des menaces de sécurité.
• Utilisez uniquement les langages qui produisent un code managé pour obtenir la meilleure sécurité à partir des dépassements de mémoire tampon, des exceptions, etc.

Pour plus d’informations sur la sécurité, consultez les rubriques suivantes :

• Sécurité dans Visual Studio
• Instructions de codage sécurisé pour le .NET Framework
• Sécurisation des sites web ASP.NET

Développement côté client

Les bonnes pratiques pour développer les personnalisations de l’application Web de Customer Engagement et Dynamics 365 for Outlook comprennent les pratiques suivantes :

• Utilisez les ressources web à la place de pages qui nécessitent un traitement côté serveur chaque fois que possible. Si vos besoins peuvent être satisfaits à l’aide du traitement côté serveur, respectez la condition que vos pages web personnalisées soient installées dans un site web distinct de Dynamics 365 Customer Engagement (on-premises). Définissez le niveau d’approbation pour votre site de manière appropriée, selon votre niveau de confiance en la sécurité de votre code. Cela réduit la menace de scripts de site à site et autres menaces.
• Pour une sécurité renforcée, vérifiez que votre site web distinct s’exécute sur un compte différent de Dynamics 365 Customer Engagement (on-premises). Ce compte doit disposer de l’accès minimal possible, sans accès direct aux bases de données Microsoft. Vous pouvez utiliser un mot de passe complexe qui n’expire pas, car aucun utilisateur ne se connecte à ce compte – uniquement à votre application.
• Évitez l’utilisation des contrôles ActiveX, car ils sont réputés pour présenter des problèmes de sécurité.
• Soyez conscient des limites des scripts client. En savoir plus : Pratiques recommandées : création de scripts client dans Customer Engagement
• Utilisez les plug-ins pour appliquer la logique métier, quelle que soit la façon dont les modifications apportées aux données sont effectuées.
• Utilisez toujours une boîte de dialogue de confirmation lorsque vous supprimez des enregistrements ou appliquer des modifications confidentielles, comme l’ajout d’un nouvel utilisateur à un rôle de sécurité. Vous pouvez utiliser openConfirmDialog pour afficher une boîte de dialogue. Cela permet d’éviter les techniques telles que le détournement de clic ou la réparation d’interface utilisateur où un développeur malveillant peut inclure votre page dans une page en apparence inoffensive pour duper un utilisateur et le conduire à exécuter des actions qui peuvent compromettre la sécurité ou engendrer des actions indésirables sur les données.

Les meilleures pratiques de sécurité pour votre site web incluent les actions suivantes :

• N’utilisez pas l’accès anonyme.

• Utilisez l’authentification Windows intégrée, NTLM ou l’authentification de base sur Transport Layer Security (TLS) ou Secure Sockets Layer (SSL).

• Utilisez TLS/SSL pour éviter d’envoyer des données non chiffrées sur le réseau si votre site web est installé sur un autre ordinateur que Dynamics 365 Customer Engagement (on-premises).

  Pour plus d’informations, consultez les ressources suivantes :

• [Présentation des menaces de sécurité contre les applications web](/previous-versions/f13d73y6(v=vs.140)

• Sécurité des applications web ASP.NET

• Présentation de la sécurité des applications web

Meilleures pratiques d’extensibilité des ISV

L’un des principaux éléments de l’extensibilité des ISV est que vous ne devez pas présumer que votre solution ISV est la seule installée. La liste ci-après répertorie les meilleures pratiques à suivre.

Pratiques recommandées pour utiliser les services Web Dynamics 365 Customer Engagement

Vous devez placer les URL du service web Dynamics 365 Customer Engagement (on-premises) dans un fichier de configuration, par exemple, dans un fichier app.config, afin que votre code soit à l’écart des modifications de l’URL. Par exemple, il existe des URL différentes pour les centres de données de Dynamics 365 for Customer Engagement à travers le monde.

Où placer les applications web ou pages web personnalisées ?

Reportez-vous à la rubrique Implémenter une authentification unique d’une page web ASPX ou IFRAME.

Comment exécuter un plug-in lorsque la vue grille de l’application web est mise à jour ?

Inscrivez le plug-in sur la demande de message RetrieveMultipleRequest et ne spécifiez aucun type d’entité au cours de l’inscription.

Quand créer un site web ?

Créez un site web pour votre code lorsque l’un des éléments suivants s’applique :

• Votre application doit être liée à un domaine, un protocole ou un port qui est différent de l’application Dynamics 365 Customer Engagement (on-premises), ou doit s’exécuter dans un autre pool d’applications.
• Votre application peut exister et être accessible par elle-même. Par exemple, un portail qui interagit avec Dynamics 365 Customer Engagement (on-premises) comme serveur (à l’aide des services web) doit être hébergé comme nouveau site web.
• Votre application utilise toujours Active Directory ou l’authentification Windows intégrée (non IFD) et les scripts inter-domaines ne sont pas un problème. Par exemple, votre application interagit avec une entité principale à l’aide des services web et interagit avec le formulaire Dynamics 365 Customer Engagement (on-premises). Une page hébergée dans un IFRAME joint à l’application Dynamics 365 Customer Engagement (on-premises) qui n’interagit pas avec le formulaire Dynamics 365 Customer Engagement (on-premises) appartient à cette catégorie.

Voir aussi

Entrer le code pour Dynamics 365 Customer Engagement (services Web)
Écrire du code pour les formulaires Dynamics 365 Customer Engagement (on-premises)
Plug-ins pour étendre Dynamics 365 Customer Engagement (on-premises)
Activités de workflow personnalisées (assemblys de workflow)