Pipeline d’exécution des événements

 

Date de publication : janvier 2017

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

Le sous-système de traitement des événements Microsoft Dynamics 365 exécute les plug-ins en fonction d’un modèle d’exécution du pipeline de messages. Une action de l’utilisateur dans l’application Web Microsoft Dynamics 365 ou un appel de méthode SDK par un plug-in ou une autre application entraîne l’envoi d’un message au service Web d’organisation. Le message contient des informations sur l’entité commerciale et l’opération principale. Il est transmis via le pipeline d’exécution des événements où il peut être lu ou modifié par l’opération principale de la plateforme et les plug-ins inscrits.

Notes

Plusieurs services Web sont hébergés par la plateforme Microsoft Dynamics 365, mais seuls les événements déclenchés par l’organisation et les points de terminaison OData peuvent provoquer l’exécution des plug-ins.

Contenu de la rubrique

Architecture et composants associés

Phases du pipeline

Traitement des messages

Inscription des plug-ins

Inclusion dans les transactions de base de données

Architecture et composants associés

La figure suivante illustre l’architecture générale de la plateforme Microsoft Dynamics 365 en ce qui concerne le traitement des événements synchrones et asynchrones.

Diagramme de traitement des événements synchrones et asynchrones

Le pipeline d’exécution des événements traite les événements de manière synchrone ou asynchrone. L’opération principale de la plateforme et les plug-ins inscrits pour l’exécution synchrone sont exécutés immédiatement. Les plug-ins synchrones inscrits pour l’événement sont exécutés dans un ordre bien défini. Les plug-ins inscrits pour l’exécution asynchrone sont mis en file d’attente par l’agent de mise en file d’attente asynchrone et exécutés ultérieurement par le service asynchrone.

Important

Que le plug-in s’exécute de manière synchrone ou asynchrone, un délai de deux minutes est imposé à l’exécution d’une demande (message). Si l’exécution de votre logique de plug-in dépasse le délai, une exception System.TimeoutException est levée. Si un plug-in nécessite un temps de traitement supplémentaire, envisagez d’utiliser un workflow ou un autre processus en arrière-plan pour effectuer la tâche prévue. Ce délai de deux minutes ne s'applique qu'aux plug-ins enregistrés pour s'exécuter sous approbation partielle, également appelée sandbox.Pour plus d'informations :Isolement, approbations et statistiques des plug-ins

Phases du pipeline

Le pipeline des événements est divisé en plusieurs étapes, dont 4 sont disponibles pour inscrire les plug-ins tiers ou développés de manière personnalisée. Plusieurs plug-ins inscrits dans chaque phase peuvent être classés dans cette phase lors de l’inscription du plug-in.

Événement	Nom de la phase	Numéro de la phase	Description
Pré-événementiel	Validation préalable	10	Phase du pipeline pour les plug-ins devant s’exécuter avant l’opération système principale. Les plug-ins inscrits dans cette phase peuvent s’exécuter en dehors de la transaction de base de données. Sécurité Remarque La phase de validation préalable se produit avant l’exécution des contrôles de sécurité pour vérifier que l’appelant ou l’utilisateur connecté dispose des autorisations appropriées pour effectuer l’opération prévue.
Pré-événementiel	Opération préalable	20	Phase du pipeline pour les plug-ins devant s’exécuter avant l’opération système principale. Les plug-ins inscrits dans cette phase sont exécutés dans la transaction de base de données.
Opération principale de la plateforme	MainOperation	30	Opération principale dans la transaction du système, telle que la création, la mise à jour, la suppression, etc. Aucun plug-in personnalisé ne peut être inscrit dans cette étape.Utilisation interne uniquement.
Post-événementiel	Opération postérieure	40	Phase du pipeline pour les plug-ins devant s’exécuter après l’opération principale. Les plug-ins inscrits dans cette phase sont exécutés dans la transaction de base de données.

Traitement des messages

Lorsque le code d’application ou un workflow appelle une méthode du service Web Microsoft Dynamics 365, il se produit un changement d’état dans le système qui déclenche un événement. Les informations transmises en tant que paramètre à la méthode du service Web sont stockées en interne dans un message OrganizationRequest et traitées par le pipeline. Les informations contenues dans le message OrganizationRequest sont transmises au premier plug-in inscrit pour cet événement où elles peuvent être lues ou modifiées avant d’être transmises au plug-in inscrit suivant pour cet événement, etc. Les plug-ins reçoivent les informations du message sous forme de contexte transmis à leur méthode Execute. Le message est également transmis à l’opération principale de la plateforme.

Inscription des plug-ins

Les plug-ins peuvent être inscrits pour s’exécuter avant son après l’opération de plateforme principale. Les plug-ins inscrits pré-événementiels reçoivent d’abord le message OrganizationRequest et peuvent modifier les informations du message avant qu’il soit transmis à l’opération principale. Une fois l’opération de plateforme principale terminée, le message est ensuite appelé OrganizationResponse. La réponse est transmise aux plug-ins post-événementiels inscrits. Les plug-ins inscrits post-événementiels ont la possibilité de modifier le message avant qu’une copie de la réponse soit transmise à tous les plug-ins asynchrones inscrits. Enfin, la réponse est retournée à l’application ou au workflow qui a invoqué l’appel de méthode de service Web initial.

Étant donné qu’un serveur Microsoft Dynamics 365 unique peut héberger plusieurs organisations, le pipeline d’exécution est spécifique à l’organisation. Il existe un pipeline virtuel pour chaque organisation. Les plug-ins inscrits dans le pipeline peuvent uniquement traiter les données d’entreprise pour une seule organisation. Un plug-in conçu pour fonctionner avec plusieurs organisations doit être inscrit dans le pipeline d’exécution de chaque organisation.

Inclusion dans les transactions de base de données

Les plug-ins peuvent ou non s’exécuter dans la transaction de base de données de la plateforme Microsoft Dynamics 365. L’inclusion d’un plug-in dans la transaction dépend de la manière dont la demande de message est traitée par le pipeline. Vous pouvez vérifier si le plug-in s’exécute dans la transaction en lisant la propriété IsInTransaction héritée par IPluginExecutionContext qui est transmis au plug-in. Si un plug-in s’exécute dans la transaction de base de données et autorise la transmission d’une exception à la plateforme, la transaction entière est restaurée. Les phases 20 et 40 sont garanties pour faire partie de la transaction de base de données alors que la phase 10 peut faire partie de la transaction.

Un plug-in inscrit qui s’exécute pendant la transaction de base de données et qui transmet une exception à la plateforme restaure l’opération principale. Cela entraîne la restauration de l’opération principale. En outre, les plug-ins inscrits pré-événementiels ou post-événementiels qui n’ont pas encore été exécutés et tout workflow déclenché par le même événement pour lequel le plug-in a été inscrit ne s’exécutent pas.

Voir aussi

Présentation de l’infrastructure d’événements
Isolement, approbations et statistiques des plug-ins
Inscrire et déployer des plug-ins
Service asynchrone dans Microsoft Dynamics 365

Microsoft Dynamics 365

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