Marco de eventos

La capacidad de ampliar el comportamiento predeterminado de Microsoft Dataverse depende de detectar cuándo se producen eventos en el servidor. Event Framework proporciona la capacidad de registrar código personalizado que se va a ejecutar en respuesta a eventos específicos.

Todas las funcionalidades para ampliar el comportamiento predeterminado de la plataforma dependen del marco de eventos. Al configurar un flujo de trabajo para responder a un evento mediante el diseñador de flujo de trabajo sin escribir código, el marco de eventos proporciona ese evento.

Como desarrollador, usará la herramienta de registro de complementos para configurar complementos, integraciones de Azure, proveedores de datos de tabla virtual y webhooks para responder a los eventos proporcionados por el marco de eventos. Cuando se producen eventos y se registra una extensión para responder a ellos, se pasa información contextual sobre los datos implicados en la operación a la extensión. En función de cómo se configure el registro del evento, la extensión puede modificar los datos pasados, iniciar algún proceso automatizado para que se aplique inmediatamente o definir que se agrega una acción a una cola para que se realice más adelante.

Para aprovechar el marco de eventos de las extensiones personalizadas, debe comprender lo siguiente:

• Qué eventos están disponibles
• Cómo se procesa el evento
• ¿qué tipo de datos están disponibles para la extensión personalizada cuando se produce el evento?
• ¿Qué limitaciones de tiempo y recursos se aplican?
• Supervisión del rendimiento

Eventos disponibles

Como se describe en Uso de mensajes con el SDK para .NET, las operaciones de datos en la plataforma de Dataverse se basan en mensajes y cada mensaje tiene un nombre. Hay Create, Retrieve, RetrieveMultiple, Update, Delete, Associate y Disassociate mensajes que cubren las operaciones básicas de datos que se producen con tablas. También hay mensajes especializados para operaciones más complejas y las acciones personalizadas agregan nuevos mensajes.

Cuando use la herramienta Registro de complementos para asociar una extensión a un mensaje determinado, la registrará como paso. La captura de pantalla siguiente es el cuadro de diálogo Registrar nuevo paso que se usa al registrar un complemento.

Un paso proporciona la información sobre el mensaje al que deben responder las extensiones, así como otras opciones de configuración. Use el campo Mensaje para elegir el mensaje al que responderá la extensión.

Por lo general, puede esperar encontrar un mensaje para la mayoría de las clases *Request en los espacios de nombres Microsoft.Crm.Sdk.Messages o Microsoft.Xrm.Sdk.Messages, pero también encontrará mensajes para cualquier acción personalizada que se haya creado en la organización. Las operaciones que impliquen definiciones de tabla no están disponibles.

Los datos sobre los mensajes se almacenan en las tablas SdkMessage y SdkMessageFilter . La herramienta de registro del complemento filtrará esta información para mostrar solo mensajes válidos.

Para comprobar si una combinación de mensajes y tablas admite la ejecución de complementos mediante una consulta de base de datos, puede usar la siguiente consulta de API web:

[Organization URI]/api/data/v9.1/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

También puede usar el siguiente FetchXML para recuperar esta información. FetchXML Builder es una herramienta útil para ejecutar este tipo de consulta.

<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>

Canalización de ejecución de eventos

Al registrar un paso mediante la Herramienta de registro de complementos también debe elegir la Fase de la canalización de eventos de ejecución. Cada mensaje se procesa en una serie de 4 fases, como se describe en la tabla siguiente:

La fase que debe elegir depende del propósito de la extensión. No es necesario aplicar toda la lógica de negocios en un solo paso. Puede aplicar varios pasos para que la lógica sobre si se permite que una operación continúe puede estar en la fase PreValidation y la lógica para realizar modificaciones en las propiedades del mensaje puede producirse en la fase PostOperation .

Se pueden registrar varias extensiones para el mismo mensaje y fase. Dentro del registro de pasos, el valor del orden de ejecución determina el orden en el que se deben procesar varias extensiones para una fase determinada.

La información sobre los pasos registrados se almacena en la tabla SdkMessageProcessingStep.

Pasos del complemento asincrónico

Al registrarse en la fase PostOperation , tiene la opción de registrar el paso para ejecutarse en modo de ejecución asincrónica. Estos complementos se ejecutarán una vez completada la operación de registro.

Esto suele ser necesario cuando se trabaja con registros asociados al registro actual, pero se crean en un proceso diferente. Por ejemplo, UserSettings relacionado con un SystemUser no se creará hasta que se cree la fila SystemUser.

Más información: Servicio asincrónico

Contexto de evento

Si la extensión es un complemento, recibirá un parámetro que implementa la IPluginExecutionContext interfaz. Esta clase proporciona información sobre la Stage para el que está registrado el complemento, así como información sobre el ParentContext que proporciona información sobre cualquier operación en otro complemento que activó la operación actual.

Si la extensión es un punto de conexión de Azure Service Bus, un tópico de Azure EventHub o un webhook, los datos que se publicarán en el punto de conexión registrado estarán en forma de un RemoteExecutionContext que implementa ambos IPluginExecutionContext y IExecutionContext.

Para obtener más información sobre el contexto de ejecución, lea Descripción del contexto de ejecución.