Para entender cómo funcionan los plugins, necesitas visualizar el camino que recorre cada operación en Dataverse. No es magia: hay un proceso ordenado y predecible que puedes interceptar en diferentes puntos. Este proceso se llama el pipeline de ejecución, y dominarlo es la diferencia entre un plugin que funciona y uno que funciona bien.
Objetivos de aprendizaje
- Entender el flujo completo de una operación en Dataverse
- Conocer las tres etapas del pipeline: Pre-validation, Pre-operation y Post-operation
- Comprender la diferencia entre ejecución síncrona y asíncrona
- Saber elegir la etapa correcta para cada tipo de lógica
El viaje de una operación: desde el clic hasta la base de datos
Cuando un usuario hace clic en "Guardar" en un formulario de Dynamics 365, se inicia una cadena de eventos. Entender esta cadena te permite predecir exactamente cuándo y cómo se ejecutará tu plugin.
Pensemos en un ejemplo concreto: Laura es agente de ventas y acaba de completar los datos de una nueva oportunidad. Hace clic en guardar. ¿Qué ocurre?
La solicitud viaja desde el navegador de Laura hasta los servidores de Dataverse. Antes de que los datos lleguen a la base de datos, pasan por varias etapas donde diferentes piezas de código pueden intervenir. Esto incluye reglas de negocio del sistema, validaciones de seguridad, y por supuesto, plugins que hayas registrado.
El sistema procesa estas etapas de forma ordenada. Primero las validaciones previas, luego las modificaciones de datos, después la operación real en la base de datos, y finalmente las acciones posteriores. Si en cualquier punto algo falla, todo se puede revertir.
Las tres etapas que puedes interceptar
Dataverse expone tres puntos específicos donde puedes ejecutar código. Cada uno tiene un propósito diferente y características que debes entender:
Pre-validation (Stage 10) ocurre lo primero de todo, antes incluso de que el sistema inicie la transacción de base de datos. Es el momento perfecto para validaciones rápidas que pueden rechazar la operación antes de hacer cualquier trabajo costoso.
Pre-operation (Stage 20) se ejecuta después de que el sistema ha validado la operación pero antes de escribir en la base de datos. Aquí ya estás dentro de la transacción, lo que significa que si algo falla, todo se revierte. Es donde modificas los datos que van a guardarse.
Post-operation (Stage 40) ocurre después de que los datos se han escrito en la base de datos, pero todavía dentro de la transacción. Puedes acceder a los valores finales del registro y realizar operaciones adicionales. Si algo falla aquí, la operación original también se revierte.
Pre-validation: el guardián de la puerta
Imagina que tienes un portero en la entrada de un edificio. Su trabajo es verificar que la gente que intenta entrar tiene permiso para hacerlo. No le importa qué van a hacer dentro; solo verifica requisitos de entrada y deja pasar o rechaza.
Así funciona Pre-validation. Es el primer punto donde puedes interceptar una operación, y su propósito principal es decidir rápidamente si la operación debe continuar o no.
Carlos ha implementado un plugin de Pre-validation para oportunidades en su empresa. Antes de que nadie pueda crear una oportunidad, el plugin verifica que el cliente asociado no esté en una lista de morosos. Esta verificación es una consulta simple a la base de datos, toma milisegundos, y si el cliente está en la lista, la operación se rechaza inmediatamente.
Lo importante es que esta validación ocurre antes de que el sistema reserve recursos para la transacción. Si vas a rechazar muchas operaciones, es mejor hacerlo aquí que más adelante.
Lo que debes saber sobre Pre-validation
Pre-validation está fuera de la transacción de base de datos. Esto tiene implicaciones importantes. Si tu plugin de Pre-validation tiene éxito y posteriormente algo falla en Pre-operation, los cambios que hiciste en Pre-validation NO se revierten automáticamente.
Por ejemplo, si en Pre-validation creas un registro de auditoría y luego la operación falla, ese registro de auditoría permanecerá. Por eso la regla general es: en Pre-validation solo validas y rechazas, no creas ni modificas datos.
Otra característica: no tienes acceso a Post-Image en Pre-validation. Tiene sentido: la operación todavía no ha ocurrido, así que no existe un "después" que capturar.
Pre-operation: donde ocurre la magia de la modificación
Pre-operation es probablemente la etapa más utilizada para plugins. Es donde puedes modificar los datos antes de que se escriban en la base de datos.
Volvamos al ejemplo de María con la auto-numeración de pólizas. Su plugin se registra en Pre-operation del mensaje Create de la entidad Póliza. Cuando un agente crea una nueva póliza, el plugin se ejecuta después de que Dataverse ha validado que la operación es correcta, pero antes de insertar el registro.
El plugin de María consulta cuál es el último número usado para la región correspondiente, lo incrementa, formatea el número completo, y lo asigna al campo de número de póliza. Cuando el registro finalmente se inserta en la base de datos, ya tiene su número correcto.
Esto funciona porque en Pre-operation tienes acceso al objeto Target, que contiene los datos que van a guardarse. Cualquier modificación que hagas a este objeto se refleja en el registro final.
La transacción es tu amiga y tu enemiga
Pre-operation se ejecuta dentro de la transacción de base de datos. Esto significa dos cosas:
Primero, la buena noticia: si algo falla en tu plugin o en cualquier plugin posterior, todo se revierte. Los datos quedan exactamente como estaban antes de intentar la operación. Esto garantiza consistencia.
Segundo, la noticia que debes gestionar: mientras tu plugin se ejecuta, la transacción está abierta y posiblemente hay bloqueos en la base de datos. Si tu plugin tarda demasiado, otros usuarios pueden experimentar esperas cuando intentan acceder a los mismos registros.
Un plugin que consulta tablas grandes sin índices adecuados, que hace llamadas a servicios externos lentos, o que procesa muchos datos, puede causar problemas de rendimiento que afectan a todo el sistema.
Post-operation: actuando sobre hechos consumados
En Post-operation, la operación principal ya ha ocurrido. El registro ya existe en la base de datos (aunque técnicamente la transacción todavía está abierta). Esto te da acceso a información que no tenías antes.
El caso más claro es el ID del registro. Cuando se crea un nuevo registro, hasta que no se completa la operación de Create, el registro no tiene un ID asignado. En Pre-operation del Create, el campo Id del Target está vacío. En Post-operation, ya tiene su valor.
También puedes acceder al Post-Image, una instantánea del registro después de la operación. Esto es particularmente útil en operaciones de Update: puedes ver el estado final del registro con todos los campos, no solo los que se modificaron.
Escenarios típicos de Post-operation
Post-operation es ideal para lógica que depende de que la operación principal haya tenido éxito:
Crear registros relacionados. Cuando se crea una Oportunidad, automáticamente crear un registro de Actividad de seguimiento vinculado. Necesitas el ID de la Oportunidad para crear la relación, así que tiene que ser en Post-operation.
Enviar notificaciones. Enviar un email cuando un caso se escala. Quieres estar seguro de que el caso realmente se escaló antes de notificar.
Sincronización con sistemas externos. Cuando un pedido se confirma, enviar los datos a un sistema de fulfillment. Solo debes hacerlo si el pedido realmente se guardó.
Actualizaciones en cascada. Cuando cambia el propietario de una cuenta, actualizar automáticamente el propietario de todas las oportunidades relacionadas.
La transacción todavía está abierta en Post-operation síncrono. Esto significa que si tu plugin falla y lanza una excepción, la operación original también falla. A veces esto es lo que quieres (consistencia total), otras veces no (quieres que la operación original se guarde aunque la notificación falle).
Síncrono vs asíncrono: eligiendo el momento correcto
Hasta ahora hemos hablado de plugins síncronos: código que se ejecuta mientras el usuario espera. Pero hay otra opción: plugins asíncronos.
Un plugin asíncrono se registra para ejecutarse "más tarde". El sistema completa la operación, devuelve el control al usuario, y en algún momento posterior (generalmente segundos o minutos después) ejecuta el plugin asíncrono.
Cuándo elegir asíncrono
La regla es simple: si la operación puede esperar y el usuario no necesita ver el resultado inmediatamente, usa asíncrono.
Piensa en el envío de emails de confirmación. El usuario crea un pedido y hace clic en guardar. ¿Necesita esperar a que el email se envíe para continuar trabajando? No. El plugin de envío de email puede ser asíncrono: el pedido se guarda rápidamente, el usuario continúa su trabajo, y el email sale segundos después.
Otro ejemplo: actualizar estadísticas agregadas. Cuando se cierra una venta, hay que recalcular los totales del trimestre para ese vendedor. Este cálculo implica sumar decenas o cientos de registros. Hacerlo síncronamente haría que el usuario esperara varios segundos. Hacerlo asíncronamente permite que el usuario siga trabajando mientras el sistema actualiza las estadísticas en segundo plano.
Lo que pierdes con asíncrono
Los plugins asíncronos no participan en la transacción original. Si algo falla en el plugin asíncrono, la operación original ya se completó y no se puede revertir.
También pierdes la capacidad de mostrar errores al usuario de forma inmediata. Si tu plugin asíncrono falla, la única forma de saberlo es revisar los System Jobs o configurar alertas.
El orden de ejecución no está garantizado. Si registras tres plugins asíncronos en el mismo evento, no puedes asumir que se ejecutarán en un orden específico.
Además, los plugins asíncronos solo se pueden registrar en Post-operation. Tiene sentido: no puedes ejecutar algo "más tarde" si la operación todavía no ha ocurrido.
El orden de ejecución cuando hay múltiples plugins
En sistemas reales, es común tener varios plugins registrados en el mismo evento. La empresa de Carlos tiene tres plugins en el Create de Oportunidad: uno que valida el cliente, otro que asigna el territorio, y otro que crea actividades de seguimiento.
¿En qué orden se ejecutan? Dataverse usa el campo Execution Order que defines al registrar cada plugin. El plugin con menor número se ejecuta primero.
Lo importante es que cada plugin recibe el contexto modificado por el plugin anterior. Si el plugin de territorio modifica el campo Región en el Target, el plugin de actividades verá ese valor modificado, no el original.
Esto puede ser muy útil o muy peligroso, dependiendo de cómo lo gestiones. Plugins que dependen del orden de ejecución son frágiles: si alguien cambia el orden o añade un nuevo plugin en medio, las cosas pueden dejar de funcionar.
Eligiendo la etapa correcta: una guía práctica
Después de años desarrollando plugins, estas son las preguntas que me hago para decidir dónde registrar un plugin:
¿Necesito rechazar la operación basándome en una validación simple? Pre-validation. Rápido, antes de la transacción, perfecto para decir "no" temprano.
¿Necesito modificar los datos que van a guardarse? Pre-operation. Es el único lugar donde puedes cambiar el Target y que esos cambios se reflejen en el registro.
¿Necesito el ID del registro recién creado? Post-operation. En Create, el ID no existe hasta después de la operación.
¿Necesito crear registros relacionados que dependan del registro principal? Post-operation, para tener el ID y los valores finales.
¿La operación puede esperar y no afecta la experiencia del usuario? Post-operation asíncrono. Libera al usuario rápidamente.
¿Necesito que si algo falla, todo se revierta? Síncrono (Pre-operation o Post-operation). Los asíncronos no participan en la transacción.
Puntos clave
- El pipeline tiene tres etapas: Pre-validation (10), Pre-operation (20), y Post-operation (40)
- Pre-validation está fuera de la transacción, ideal para validaciones rápidas que rechazan operaciones
- Pre-operation está dentro de la transacción y es donde modificas datos antes de guardarlos
- Post-operation tiene acceso al ID del registro creado y al Post-Image con valores finales
- Los plugins síncronos bloquean al usuario y participan en la transacción
- Los plugins asíncronos liberan al usuario rápidamente pero no pueden revertir la operación original
- El Execution Order determina el orden entre plugins del mismo evento