Infrastructure d’événements dans Microsoft Dataverse

L’infrastructure d’événements Microsoft Dataverse vous permet de détecter quand des événements se produisent sur le serveur et d’exécuter du code personnalisé en réponse. Utilisez l’infrastructure d’événements pour étendre le comportement de plateforme par défaut en inscrivant des plug-ins, des flux de travail, des intégrations Azure et des webhooks.

Toutes les fonctionnalités permettant d’étendre le comportement par défaut de la plateforme dépendent de l’infrastructure d’événements. Lorsque vous configurez un flux de travail pour répondre à un événement à l’aide du concepteur de flux de travail sans écrire de code, l’infrastructure d’événements fournit cet événement.

En tant que développeur, utilisez l’outil d’inscription de plug-ins pour configurer des plug-ins, des intégrations Azure, des fournisseurs de données de table virtuelle et des webhooks pour répondre aux événements que fournit l’infrastructure d’événements. Lorsque des événements se produisent et que vous inscrivez une extension pour y répondre, l’infrastructure transmet des informations contextuelles sur les données impliquées dans l’opération à l’extension. Selon la façon dont vous configurez l’inscription pour l’événement, l’extension peut modifier les données transmises, lancer un processus automatisé à appliquer immédiatement ou définir qu’une action est ajoutée à une file d’attente pour effectuer ultérieurement.

Pour tirer parti de l’infrastructure d’événements pour vos extensions personnalisées, vous devez comprendre :

• Quels événements sont disponibles
• Traitement de l’événement
• Quel type de données est disponible pour votre extension personnalisée lorsque l’événement se produit
• Quelles sont les contraintes de temps et de ressource qui s’appliquent
• Comment surveiller les performances

Événements disponibles

Comme décrit dans Utiliser des messages avec le Kit de développement logiciel (SDK) pour .NET, la plateforme Dataverse base les opérations de données sur les messages et chaque message a un nom. La plateforme inclut Create, , RetrieveRetrieveMultipleUpdate, Delete, , Associateet Disassociate les messages qui couvrent les opérations de données de base qui se produisent avec des tables. La plateforme inclut également des messages spécialisés pour des opérations plus complexes et des actions personnalisées ajoutent de nouveaux messages.

Lorsque vous utilisez l’outil d’inscription de plug-in pour associer une extension à un message particulier, vous l’inscrivez en tant qu’étape. La capture d’écran suivante est la boîte de dialogue Inscrire une nouvelle étape utilisée lors de l’inscription d’un plug-in.

Une étape fournit les informations sur le message auquel les extensions doivent répondre, ainsi qu’un certain nombre d’autres choix de configuration. Utilisez le champ Message pour choisir le message auquel votre extension répond.

En règle générale, vous pouvez vous attendre à trouver un message pour la plupart des classes Request dans les espaces de noms Microsoft.Crm.Sdk.Messages ou Microsoft.Xrm.Sdk.Messages. Vous trouverez également des messages pour toutes les actions personnalisées que vous créez dans l’organisation. La plateforme ne met à disposition aucune opération impliquant des définitions de table.

Le système stocke des données sur les messages dans les tables SdkMessage et SdkMessageFilter . L’outil d’inscription de plug-in filtre ces informations pour afficher uniquement les messages valides.

Pour vérifier si une combinaison de messages et de tables prend en charge l’exécution des plug-ins à l’aide d’une requête de base de données, utilisez la requête d’API web suivante :

[Organization URI]/api/data/v9.2/sdkmessages?$select=name
&$filter=isprivate eq false 
and (name ne 'SetStateDynamicEntity' 
and name ne 'RemoveRelated' 
and name ne 'SetRelated' and 
name ne 'Execute') 
and sdkmessageid_sdkmessagefilter/any(s:s/iscustomprocessingstepallowed eq true 
and s/isvisible eq true)
&$expand=sdkmessageid_sdkmessagefilter($select=primaryobjecttypecode;
$filter=iscustomprocessingstepallowed eq true and isvisible eq true)
&$orderby=name

Vous pouvez également utiliser le fetchXML suivant pour récupérer ces informations. FetchXML Builder est un outil utile pour exécuter ce type de requête.

<fetch>
  <entity name='sdkmessage'>
    <attribute name='name' />
    <link-entity name='sdkmessagefilter'
      alias='filter'
      to='sdkmessageid'
      from='sdkmessageid'
      link-type='inner'>
      <filter type='and'>
        <condition attribute='iscustomprocessingstepallowed' 
          operator='eq' 
          value='1' />
        <condition attribute='isvisible' 
          operator='eq' 
          value='1' />
      </filter>
      <attribute name='primaryobjecttypecode' />
    </link-entity>
    <filter>
      <condition attribute='isprivate' 
        operator='eq' 
        value='0' />
      <condition attribute='name' 
        operator='not-in'>
        <value>SetStateDynamicEntity</value>
        <value>RemoveRelated</value>
        <value>SetRelated</value>
        <value>Execute</value>
      </condition>
    </filter>
    <order attribute='name' />
  </entity>
</fetch>

Pipeline d’exécution d’événements

Lorsque vous inscrivez une étape à l’aide de l’outil d’inscription de plug-in, vous devez également choisir l’étape d’exécution du pipeline d’événements. Chaque message est traité dans une série de quatre étapes, comme décrit dans le tableau suivant :

La phase que vous choisissez dépend de l’objectif de l’extension. Vous n’avez pas besoin d’appliquer toute votre logique métier à une seule étape. Vous pouvez appliquer plusieurs étapes afin que votre logique indiquant s’il faut autoriser une opération à continuer peut se trouver dans l’étape PreValidation et que votre logique pour apporter des modifications aux propriétés du message peut se produire dans l’étape PostOperation .

Vous pouvez inscrire plusieurs extensions pour le même message et la même étape. Dans l'enregistrement de l'étape, la valeur de l’ordre d’exécution détermine l'ordre selon lequel le système traite les extensions multiples pour une étape donnée.

Le système stocke des informations sur les étapes inscrites dans la table SdkMessageProcessingStep.

Étapes de plug-in asynchrones

Lorsque vous vous inscrivez à l’étape PostOperation , vous pouvez inscrire l’étape à exécuter en mode d’exécution asynchrone. Ces plug-ins s’exécutent une fois l’opération d’enregistrement terminée.

Ce comportement est souvent nécessaire lors de l’utilisation d’enregistrements associés à l’enregistrement actif, mais créés dans un autre processus. Par exemple, UserSettings lié à un enregistrement spécifique SystemUser n’est pas créé tant que l’enregistrement SystemUser n’est pas créé.

Plus d’informations : Service asynchrone

Contexte d’événement

Si votre extension est un plug-in, elle reçoit un paramètre qui implémente l’interface IPluginExecutionContext . Cette classe fournit des informations sur le Stage pour lequel le plug-in s'inscrit. Il fournit également des informations sur le ParentContext, qui fournit des détails sur toute opération au sein d’un autre plug-in qui a déclenché l’opération actuelle.

Si votre extension est un point de terminaison Azure Service Bus, une rubrique Azure Event Hubs ou un hook web, les données publiées sur le point de terminaison inscrit sont sous la forme d’un RemoteExecutionContext. Cette classe implémente à la fois IPluginExecutionContext et IExecutionContext.

Pour plus d’informations sur le contexte d’exécution, consultez Comprendre le contexte d’exécution.