Intégration Azure avec Microsoft Dynamics 365.

 

Date de publication : janvier 2017

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

Vous pouvez connecter Microsoft Dynamics 365 (Online et local) à la plateforme Microsoft Azure en couplant le pipeline d’exécution d'événement Dynamics 365 au Microsoft Azure Service Bus. Une fois configurée, cette connexion permet aux données traitées dans le cadre de l'opération Dynamics 365 actuelle d'être publiées sur le bus de services. Les solutions Microsoft Azure Service Bus qui sont « compatibles Dynamics 365 » peuvent écouter et lire les données Microsoft Dynamics 365 du bus des services.

Cette connexion entre Microsoft Dynamics 365 et la plateforme Microsoft Azure fournit un canal sécurisé et fiable pour la communication des données d'exécution Dynamics 365 aux applications métier externes basées sur le cloud.

Contenu de la rubrique

Éléments clés de la connexion

Scénario Dynamics 365 vers bus de services

Création d’un contrat entre Dynamics 365 et une solution Azure

Gestion des erreurs d'exécution

Éléments clés de la connexion

Les éléments clés implémentant la connexion entre Microsoft Dynamics 365 et le Microsoft Azure Service Bus sont décrits ci-dessous. Un schéma dans la section suivante illustre ces éléments en opération.

  • Contexte de données
    Le contexte de données contient les données commerciales traitées dans le cadre de l'opération Dynamics 365 actuelle. Ce traitement a été initialisé lorsqu'une demande d'exécution d'une certaine opération a été effectuée par un utilisateur, un workflow ou une application sur la plateforme Dynamics 365. Le contexte de données est transmis à toutes les activités plug-ins ou de workflow personnalisé enregistrées avec le pipeline d'événements à exécuter sur la combinaison de demande et d'entité spécifique en cours de traitement. Le contexte de données est de type IPluginExecutionContext lorsque celui-ci est transmis au pipeline d'exécution d'événement et RemoteExecutionContext lorsqu'il est publié sur le bus des services.

    Le contexte de données contenu dans le message qui est publié sur Microsoft Azure Service Bus peut être mis au format XML ou JSON outre le format binaire .NET par défaut. Cela permet l'interopérabilité entre plateformes où les clients hébergés azurés non .NET peuvent lire les données Dynamics 365 du bus des services.Cette fonctionnalité a été introduite dans la mise à jour 1 de CRM Online 2016 et le Service Pack 1 de CRM 2016 (local)..

    Pour plus d'informations sur les technologies décrites ci-dessus voir : Comprendre le contexte de données passé à un plug-in, Pipeline d’exécution des événements, et Écrire une application d'écouteur pour une solution Microsoft Azure.

  • Plug-ins
    Les plug-ins sont l'une des deux méthodes utilisées pour initier la publication du message contenant le contexte de données vers Microsoft Azure Service Bus, l'autre méthode étant une activité de workflow personnalisée. Il existe deux types de plug-ins pris en charge par la fonctionnalité de connexion Dynamics 365-Azure : prêt à l’emploi et personnalisé. Dans les deux cas, il est préférable d'enregistrer le plug-in pour une exécution asynchrone pour de meilleures performances du système.

    Un plug-in OOB compatible Azure est fourni avec Dynamics 365 et peut être enregistré via l'outil Plug-in Registration dans le téléchargement SDK. Ce plug-in s’exécute en toute confiance avec la plateforme Microsoft Dynamics 365. Vous devez enregistrer une étape plug-in dans le pipeline d'exécution d'événement qui identifie la combinaison de message et d'entité qui déclenche le plug-in pour exécuter et effectuer une notification de publication. Une fois exécuté, le plug-in avertit le service asynchrone, via un service de notification de point de terminaison de service (IServiceEndpointNotificationService), pour publier le contexte actuel de données de requête sur Microsoft Azure Service Bus.

    Vous pouvez également créer votre propre plug-in personnalisé, compatible Azure. Le plug-in personnalisé s’exécute en mode de confiance partielle dans le bac à sable. Un plug-in personnalisé peut lancer la publication du contexte de données sur le bus de services via le service de notification de point de terminaison de service. Ajouter du code pour invoquer ce service rend le plug-in « compatible Azure». Pour plus d’informations sur les plug-ins en général, voir Écrire un plug-in. Pour plus d’informations sur les plug-ins compatibles Azure, voir Écrire un plug-in compatible Azure personnalisé.

  • Activités de workflow personnalisées
    À l'instar des plug-ins, des activités de workflow personnalisées peuvent être écrites pour initier la publication du contexte actuel de données de messages de demande sur Microsoft Azure Service Bus à l'aide du service de notification de point de terminaison de service (IServiceEndpointNotificationService).Pour plus d'informations :Exemple : Activité de workflow personnalisée compatible Azure.

  • Service asynchrone
    Une fois averti par le service de notification du point de terminaison de service, le service asynchrone gère la publication du contexte de données du message de demande actuellement traité par le pipeline d'exécution d'événements sur Microsoft Azure Service Bus. Chaque publication est effectuée par une tâche système du service asynchrone. Un utilisateur peut afficher le statut de chaque tâche système à l’aide de la vue Tâches système de l'application Web Microsoft Dynamics 365.

    Pour plus d'informations sur le service asynchrone, voir Service asynchrone dans Microsoft Dynamics 365.

  • Bus des services Microsoft Azure
    Le bus de services transmet par relais le contexte de données de message de demande entre les applications d'écouteur de solution Microsoft Dynamics 365 et Microsoft Azure Service Bus. Le bus des services assure également la sécurité des données de sorte que seules les applications autorisées peuvent accéder aux données Dynamics 365 publiées. L'autorisation de Microsoft Dynamics 365 de publier le contexte de données vers le bus des services et pour les applications d'écouteur de le lire est gérée par Shared Access Signatures (SAS) Service Microsoft Azure Active Directory Access Control Service (ACS) ou Microsoft Azure.

    Notes

    À propos de l'autorisation SAS : SAS Cette fonctionnalité a été introduite dans la mise à jour 1 de CRM Online 2016 et le Service Pack 1 de CRM 2016 (local). est un formulaire d'autorisation plus moderne et affiche de meilleures performances comparé à ACS.

    Pour plus d'informations sur le bus de services, voir Bus des services.Pour plus d'informations sur l'autorisation du bus des services, voir Authentification et autorisation de Service Bus.

  • Solution Microsoft Azure
    Pour que la connexion de Dynamics 365-Azure fonctionne, il doit y avoir au moins une solution dans un compte de solution Microsoft Azure Service Bus, où la solution contient un ou plusieurs points de terminaison de service. Pour un contrat du point de terminaison de relais, une application d'écouteur compatible Dynamics 365 doit écouter activement sur le point de terminaison la demande Dynamics 365 sur le bus des services. Pour un contrat de point de terminaison de file d’attente, il n’est pas nécessaire qu’un écouteur écoute activement. Un écouteur est rendu compatible Dynamics 365 en l’associant à l’assembly Microsoft.Xrm.Sdk de sorte que le type RemoteExecutionContext soit défini.Pour plus d'informations :Écrire une application d'écouteur pour une solution Microsoft Azure

    Microsoft Dynamics 365 prend en charge l'envoi de données d'événement à une solution Azure Event Hubs.Cette fonctionnalité a été introduite dans la mise à jour 1 de CRM Online 2016 et le Service Pack 1 de CRM 2016 (local)..Pour plus d'informations sur les concentrateurs d'événements, voir Utilisation des données d'événement Dynamics 365 dans votre solution Azure Event Hub.

Scénario Dynamics 365 vers bus de services

Identifions maintenant un scénario qui implémente les composants de connexion mentionnés précédemment. Comme conditions préalables, l'ACS a été configuré pour identifier Microsoft Dynamics 365 comme l’émetteur pris en charge et la solution du Microsoft Azure Service Bus a été configurée avec des règles visant à permettre à Microsoft Dynamics 365 de publier sur le point de terminaison sur lequel l’écouteur écoute.

Le diagramme suivant illustre les éléments physiques qui composent le scénario.

Scénario Microsoft Dynamics CRM vers Service Bus

La séquence des événements identifiés dans ce diagramme est la suivante :

  1. Une application d'écouteur est inscrite sur un point de terminaison de solution du Microsoft Azure Service Bus et commence à écouter activement le contexte d’exécution distant Microsoft Dynamics 365 sur le bus des services.

  2. Un utilisateur effectue une opération dans Microsoft Dynamics 365 qui déclenche l’exécution du plug-in prêt à l’emploi inscrit ou d’un plug-in compatible Azure personnalisé. Le plug-in lance une publication, via une tâche système de service asynchrone, du contexte de données de demande actuel sur le bus des services.

  3. Les revendications publiées par Microsoft Dynamics 365 sont authentifiées. Le bus des services transmet par relais le contexte d’exécution distant à l’écouteur. L’écouteur traite les informations de contexte et effectue une tâche professionnelle avec ces informations. Le bus des services notifie le bus des services asynchrone d’une publication réussie et attribue à la tâche système le statut Terminé.

Création d’un contrat entre Dynamics 365 et une solution Azure

Pour chaque point de terminaison de solution, vous configurez un contrat qui définit la gestion de ces messages de contexte d’exécution distant sur le bus de services et la sécurité qui doit être utilisée sur ce point de terminaison. Les messages du bus des services sont reçus sur un point de terminaison via l’un des contrats pris en charge répertoriés ici.

  • File d'attente
    Un contrat de file d’attente fournit une file d’attente de messages du cloud. Avec un contrat de file d’attente, l’écouteur n’est pas obligé d’écouter activement les messages sur le point de terminaison. Pour les files d’attente, il existe une lecture destructive et une lecture non destructive. Une lecture destructive lit un message disponible dans la file d’attente et le message est supprimé. Une lecture non destructive ne supprime pas de message dans une file d’attente.

    Le type de file d'attente pris en charge par Microsoft Dynamics 365 est appelé une file d'attente persistante. Les files d’attente persistantes ont une disponibilité des messages longue mais limitée, qui peut être spécifiée dans le code.

  • Contrat unidirectionnel
    Un contrat unidirectionnel nécessite un écouteur actif. S'il n'y a aucun écouteur actif sur un point de terminaison, la publication vers le bus de services échoue.Microsoft Dynamics 365 réessaie d'effectuer la publication à des intervalles de temps augmentant exponentiellement jusqu’à ce que la tâche système asynchrone qui publie la demande soit abandonnée et que son statut passe à « Échec ».

  • Contrat bidirectionnel
    Un contrat bidirectionnel est similaire à un contrat unidirectionnel à ceci près qu'une valeur de chaîne peut être retournée de l'écouteur à l'activité de workflow ou de plug-in personnalisée à l'origine de la publication.

  • REST
    Le contrat REST est similaire au contrat bidirectionnel sur un point de terminaison REST.

  • Sujet
    Similaire à une file d’attente sauf qu’un ou plusieurs écouteurs peuvent s’abonner pour recevoir des messages du sujet.

  • Hub d'événements
    Ce type de contrat s'applique aux solutions de concentrateur d'événements Microsoft Azure.

Important

Pour utiliser ces contrats, vous devez créer vos applications d’écoute avec la version 1.7 ou ultérieure du Kit de développement logiciel (SDK) de Microsoft Azure.

L’identification du type de sécurité utilisé par un contrat fait partie de la configuration du contrat. Un contrat peut utiliser la sécurité de transport, qui utilise TLS (Transport Layer Security) ou SSL (Secure Sockets Layer) (HTTPS).

L’authentification basée sur les revendications est utilisée pour l’accès sécurisé au bus de services. La revendication utilisée pour l’authentification auprès du bus des services est générée dans Microsoft Dynamics 365 et signée par le certificat AppFabricIssuer spécifié dans la base de données de configuration Microsoft Dynamics 365.

Gestion des erreurs d'exécution

Si une erreur s’est produite après une tentative d’accès d’une publication au bus de services, vérifiez le statut de la tâche système associée dans l’application Web Microsoft Dynamics 365 pour obtenir plus d’informations sur l’erreur. Si le bus des services est arrêté ou qu’un écouteur/point de terminaison est indisponible, le message actuel en cours de traitement dans Microsoft Dynamics 365 n’est pas publié sur le bus. Le service asynchrone continuera de tenter de publier le message de manière exponentielle en essayant de publier d’abord fréquemment puis à intervalles de plus en plus longs. En cas d’erreur Microsoft Dynamics 365 interne, aucune publication de message n’est tentée. En cas d’erreur de bus des services externe ou d’erreur réseau, la tâche système associée sera mise en attente.

Voir aussi

Extensions Azure pour Microsoft Dynamics 365
Configuration de l'intégration Azure avec Microsoft Dynamics 365
Écrire des plug-ins pour étendre les processus d’entreprise
Service asynchrone dans Microsoft Dynamics 365
Entité AsyncOperation (tâche système)

Microsoft Dynamics 365

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