Inscrire et déployer des plug-ins

Date de publication : janvier 2017

S’applique à : Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

Les plug-ins et les activités de workflow personnalisées représentent du code personnalisé que vous développez pour étendre les fonctionnalités existantes de Microsoft Dynamics 365. Avant de pouvoir utiliser un plug-in ou une activité de workflow personnalisée, une inscription serveur est nécessaire. Vous pouvez effectuer l’inscription des plug-ins et des activités de workflow personnalisées par programme avec Microsoft Dynamics 365 (Online et local) en écrivant le code d’inscription à l’aide de certaines classes SDK. Toutefois, pour faciliter la courbe d’apprentissage et accélérer le développement et le déploiement de code personnalisé, un plug-in et l’outil d’inscription des activités de workflow personnalisées est inclus dans le dossier BIN du Kit de développement logiciel.Téléchargez le package Kit de développement logiciel (SDK) de Microsoft Dynamics CRM.

Même si cette rubrique se concentre principalement sur les plug-ins, la plupart des informations s’appliquent également aux activités de workflow personnalisées. La seule différence entre les deux est que pour les assemblys d’activité de workflow personnalisée, vous n’inscrivez que l’assembly. Pour les plug-ins, inscrivez l’assembly de plug-in et une ou plusieurs étapes par plug-in. Pour plus d’informations sur les activités de workflow personnalisées, voir Activités de workflow personnalisées (assemblys de workflow).

Sécurité Remarque
N’inscrivez aucun plug-in ni aucune activité de workflow personnalisée sauf en cas d’obtention d’une une source fiable et approuvée.

Pour plus d’informations sur le mode de création de package de vos plug-ins en composants de solution, voir Empaqueter et distribuer les extensions à l’aide des solutions.

Contenu de la rubrique

Outil d’inscription de plug-ins

Enregistrement des plug-ins

Déploiement

Gestion des versions d’assembly et solutions

Restrictions de sécurité

Inscrire des plug-ins par programme

Activer ou désactiver l’exécution de code personnalisé

Outil d’inscription de plug-ins

L’outil Plug-in Registration fournit une interface graphique et prend en charge l’inscription des plug-ins et des activités de workflow personnalisées avec Microsoft Dynamics 365. Toutefois, les plug-ins et les activités de workflow personnalisées peuvent être inscrits dans le bac à sable (mode d’isolation) de Microsoft Dynamics 365 (Online).

Pour plus d’informations sur le mode d’inscription et de déploiement d’un plug-in à l’aide de l’outil, voir Procédure pas-à-pas : inscrire un plug-in à l’aide de l’outil Plug-in Registration (Inscription de plug-in). L’outil peut être ajouté au menu Outils de Visual Studio comme un outil externe pour accélérer le processus de développement.

Enregistrement des plug-ins

Pour un déploiement local, les plug-ins qui ne sont pas inscrits dans le bac à sable (sandbox) peuvent être enregistrés dans la base de données du serveur Microsoft Dynamics 365 ou dans le système de fichiers sur disque. Nous vous recommandons vivement d’enregistrer vos plug-ins prêts pour la production dans la base de données Microsoft Dynamics 365, au lieu de le faire sur le disque. Les plug-ins enregistrés dans la base de données sont automatiquement distribués sur plusieurs serveurs Microsoft Dynamics 365 dans un cluster de centre de données. Le stockage sur disque des plug-ins est utile pour déboguer les plug-ins avec Microsoft Visual Studio. Cependant, vous pouvez déboguer un plug-in qui est stocké dans la base de données. Pour plus d'informations, voir Déboguer un plug-in.

Les plug-ins inscrits dans le bac à sable doivent être stockés dans la base de données indépendamment du déploiement de Microsoft Dynamics 365 (en local, IFD, ou en ligne).

Déploiement

Pour les installations Microsoft Dynamics 365 locales ou avec accès via internet, lorsque vous déployez des plug-ins à partir d’un ordinateur sur le disque de serveur Microsoft Dynamics 365 (déploiement sur disque), l’assembly de plug-in doit être copié manuellement sur le serveur avant l’inscription. L’assembly doit être déployé dans le dossier <installdir>\Program Files\Microsoft CRM\server\bin\assembly sur chaque serveur où le plug-in doit être exécuté.

L’inscription des plug-ins doit être effectuée après la copie de l’assembly dans le dossier …\bin\assembly sur le serveur pour empêcher le cas où un utilisateur système déclenche un événement dans Microsoft Dynamics 365, mais l’assembly de plug-in inscrit n’existe pas encore sur le serveur. Pour le déploiement de base de données serveur, l’assembly du plug-in est copié automatiquement lors de l’inscription des plug-ins pour que la situation antérieure ne constitue pas un problème.

En fonction de la conception de votre plug-in, vos plug-ins peuvent nécessiter d’autres assemblys référencés pour s’exécuter. Que vous déployez votre plug-in dans la base de données ou sur le disque, si votre plug-in nécessite d’autres assemblys pour s’exécuter, vous devrez placer les copies de ces assemblys dans le cache d’assembly global sur chaque serveur où le plug-in doit être exécuté. Cela ne s’applique pas à un serveur Microsoft Dynamics 365 (Online) car vous n’avez pas accès au cache d’assembly global sur ce serveur.

Pour déplacer un plug-in d’un environnement de développement vers un serveur intermédiaire ou de production

1. Sur l’ordinateur de développement, définissez le code du plug-in. N’ajoutez pas d’informations de débogage. Optimisez le plug-in pour obtenir de meilleures performances.

2. Inscrivez le plug-in dans la base de données du serveur Microsoft Dynamics 365.

3. À l’aide de l’application Web Microsoft Dynamics 365, créez une solution ou utilisez-en une existante et ajoutez le plug-in à cette solution.

4. Après avoir ajouté tous les autres composants souhaités à la solution, exportez la solution.

5. Importez la solution vers le serveur intermédiaire ou de production.

Gestion des versions d’assembly et solutions

Les versions des assemblys de plug-in peuvent être gérées à l’aide d’un format de numéro du type principale.secondaire.build.révision défini dans le fichier Assembly.info du projet Microsoft Visual Studio. En fonction de la partie du numéro de version de l’assembly qui est modifiée dans une solution récente, le comportement suivant s’applique lorsqu’une solution existante est mise à jour via l’importation.

• Le numéro de version de la build ou de l’assembly de révision est modifié.

  Ceci est considéré comme une mise à niveau sur place. La version antérieure de l’assembly est supprimée lorsque la solution contenant l’assembly mis à jour est importée. Toutes les étapes préexistantes de la solution antérieure sont automatiquement modifiées pour faire référence à la version la plus récente de l’assembly.

• Le numéro de version d’assembly principale ou secondaire, sauf pour les numéros de build ou de révision, est modifié.

  Lorsqu’une solution mise à jour contenant l’assembly modifié est importée, l’assembly est considéré comme un assembly complètement différent de la version précédente de cet assembly dans la solution existante. Les étapes d’inscription du plug-in dans la solution existante continuent de faire référence à la version précédente de l’assembly. Si vous souhaitez que la procédure d’inscription existante du plug-in de l’assembly précédent pointe vers l’assembly modifié, vous devrez utiliser l’outil d’inscription des plug-ins pour modifier manuellement la configuration des étapes pour faire référence au type d’assembly révisé. L’opération doit être effectuée avant l’exportation de l’assembly mis à jour en une solution à des fins d’importation ultérieure.

Pour plus d’informations sur les solutions, voir Présentation des solutions.

Restrictions de sécurité

Il existe une restriction de sécurité qui permet aux utilisateurs privilégiés uniquement d’inscrire les plug-ins. Pour les plug-ins qui ne sont pas inscrits dans un contexte isolé, le compte d’utilisateur système sous lequel est inscrit le plug-in doit exister dans le groupe Administrateurs de déploiement du Gestionnaire de déploiement. Seul le compte Administrateur système ou n’importe quel autre compte d’utilisateur inclus dans le groupe Administrateurs de déploiement peut exécuter le Gestionnaire de déploiement.

Le compte d’utilisateur système sous lequel est inscrit le plug-in doit disposer des privilèges de sécurité au niveau de l’organisation suivants :

• prvCreatePluginAssembly

• prvCreatePluginType

• prvCreateSdkMessageProcessingStep

• prvCreateSdkMessageProcessingStepImage

• prvCreateSdkMessageProcessingStepSecureConfig

Pour plus d'informations, consultez les rubriques Security role and privilege reference et Le modèle de sécurité de Microsoft Dynamics 365.

Pour les plug-ins inscrits dans le bac à sable (mode d’isolation), le compte d’utilisateur système sous lequel le plug-in est inscrit doit avoir le rôle d’administrateur système. L’appartenance au groupe Administrateurs de déploiement n’est pas nécessaire.

Inscrire des plug-ins par programme

Les principaux types d’entités permettant d’inscrire des plug-ins et des images sont : PluginAssembly, PluginType, SdkMessageProcessingStep et SdkMessageProcessingStepImage. Les principaux types d’entités permettant d’inscrire des activités de workflow personnalisées sont PluginAssembly et PluginType. Utilisez ces entités dans le cadre des opérations de création, de mise à jour, d’extraction et de suppression.

Pour plus d’informations sur les images, voir Comprendre le contexte de données passé à un plug-in.

Activer ou désactiver l’exécution de code personnalisé

Vous pouvez utiliser Windows PowerShell pour activer ou désactiver un code personnalisé, notamment les plug-ins et les activités de workflow personnalisées, sur le serveur comme décrit ici. Par ailleurs, vous pouvez utiliser le service Web de déploiement. Pour plus d’informations, voir Entités de déploiement et paramètres de configuration du déploiement pour définir la propriété CustomCodeSettings.AllowExternalCode property.

Pour activer l’exécution de code personnalisé

1. Ouvrez une fenêtre de commande Windows PowerShell.

2. Ajoutez le composant logiciel enfichable PowerShell Microsoft Dynamics 365 :

   Add-PSSnapin Microsoft.Crm.PowerShell
   

3. Récupérez le paramètre actuel :

   $setting = get-crmsetting customcodesettings
   

4. Modifiez le paramètre actuel :

   $setting.AllowExternalCode="True"
   

   set-crmsetting $setting
   

5. Vérifiez le paramètre :

   get-crmsetting customcodesettings
   

Pour désactiver l’exécution de code personnalisé

1. Ouvrez une fenêtre de commande Windows PowerShell.

2. Ajoutez le composant logiciel enfichable PowerShell Microsoft Dynamics 365 :

   Add-PSSnapin Microsoft.Crm.PowerShell
   

3. Récupérez le paramètre actuel :

   $setting = get-crmsetting customcodesettings
   

4. Modifiez le paramètre actuel :

   $setting.AllowExternalCode=0
   

   set-crmsetting $setting
   

5. Vérifiez le paramètre :

   get-crmsetting customcodesettings
   

Voir aussi

Développement de plug-ins
Déboguer un plug-in
Isolement, approbations et statistiques des plug-ins
Empaqueter et distribuer les extensions à l’aide des solutions
Privilèges pat entité

Microsoft Dynamics 365

© 2017 Microsoft. Tous droits réservés. Copyright