Hola,
Me he enfrentado a este dilema recientemente: en qué evento debería registrar mis plugins? En el Pre? En el Post? Cuando se ejecutan? En qué orden? Que pasa si falla la operación?
Compartiré a continuación algunas conclusiones, basadas en este breve artículo de la MSDN donde explica el pipeline de ejecución de los plugins.
Tomaremos como referencia el siguiente diagrama muestra como es el proceso de ejecución, tanto para plugins sincrónicos como asincrónicos:
De aquí extraemos como primer conclusión que:
- Si nuestro plugin es sincrónico, tanto la operación de la plataforma invocada (ej. el evento Create de una entidad) como los plugins que están registrados para ejecutarse en el Pre o en el Post son ejecutados de inmediato, de acuerdo al orden que se le indique.
- Si nuestro plugin es asíncrono, éste queda encolado para ejecutarse posteriormente en el contexto del servicio AsyncService (como los Workflows).
Notas:
- En caso que hubiesen Workflows asociados al mismo evento que se dispara un plugin sincrónico, éste úlitmo se ejecuta primero y el Workflow después.
- Sin importar si es síncrono o asíncrono, la ejecución de nuestro plugin no puede tomar más de 2 minutos en ejecutarse. Si llega a este tiempo, automáticamente el sistema arrojará una System.TimeoutException. El workaround es utilizar un Workflow o algún otro proceso si es que realmente nuestra lógica necesita más de 2 minutos para ejecutarse.
El modo de ejecución (sincrónico o asincrónico) lo podemos especificar al momento de la registración con la PluginRegistration Tool incluída en el SDK del producto asi como también el orden.
Luego, si bien técnicamente durante el proceso de ejecución de un plugin existen 5 fases, a nuestros efectos solo nos interesan 2 de esas fases que es donde podemos suscribir nuestros plugins: Pre-Event y Post-Event.
Veamos que implican y cuando se ejecuta cada fase:
Pre-Event:
- Se ejecuta previo a la operación de la plataforma (ej. previo a que realmente se cree la entidad en la base de datos si estamos hablando de un plugin registrado para el mensaje Create).
- Si desde nuestro plugin arrojamos una InvalidPluginExecutionException, entonces, cancela lo restante en el pipeline de ejecución (directamente no ejecuta otros pre-event plugins, la operación de la plataforma, cancela la transacción en la base de datos si existe una, cualquier Workflow registrado para ese evento y cualquier post-event).
- Hay 2 tipos de etapas Pre-Events en CRM 2011: Pre-Validation y Pre-Operation
- Pre-validation
- En esta fase no se realizan validaciones de seguridad (chequeo de privilegios que tiene el usuario logueado), por lo que debemos tomar las precauciones de acuerdo a la lógica de nuestro plugin, ya que el usuario podría estar realizando operaciones para las que no tiene privilegios, a la vez que si se trata de una fuente externa, el usuario no estará validado por Dynamics CRM.
- No es transaccional. La lógica se ejecuta fuera de la transacción de la base de datos correspondiente a la operación que se desea realizar.
- Ejemplo de uso: se utiliza comunmente en los eventos Delete de una entidad (ej. Cuenta), ya aquí podemos validar en base a determinada lógica si permitimos o no la eliminación del registro o consultar los registros relacionados a la entidad a eliminar (estos registros pierden la relación en el Pre-Operation por lo que no lograríamos encontrarlos en esa instancia con una query).
- Pre-Operation
- Se realizan las validaciones de seguridad, ya sea que el plugin se ejecute como el usuario que lo invoca (Calling User) o como un usuario específico.
- Es transaccional. Esto quiere decir que las operaciones se realizan en la misma transacción a nivel de base de datos.
- Ejemplo de uso: En un Create o un Update de una entidad, cuando necesitamos realizar ciertos cálculos antes de almacenar el registro.
Post-Event:
- Se ejecuta posterior a la operación de la plataforma (ej, posterior a la creación o la modificación en la base de datos si estamos hablando de un plugin registrado para el mensaje Create o Update de una entidad respectivamente).
- Puede modificar ‘en el aire’ la respuesta (Response) que se le devolverá al invocador del evento.
- Es transaccional. Esto quiere decir que las operaciones se realizan en la misma transacción a nivel de base de datos.
- Luego de su ejecución, con el resultado (OrganizationResponse) se procede a encolar los plugins asincrónicos que estén registrados para ser ejecutados.
- Ejemplo de uso: Luego del Create u Update de un registro (ej. una Orden), debemos dejar algún registro en otra base de datos para sincronizar datos con otro sistema o bien, precisamos actualizar otros elementos como puede ser el stock disponible de un artículo.
Nota: en CRM 4.0 existían 2 tipo de pipelines, Child Pipeline y Parent Pipeline. Esto ha sido deprecado en CRM 2011 por lo que no aplica más.
Espero les haya resultado útil la recopilación y el análisis de esta información. Como siempre, nos gustaría conocer y que nos compartan su experiencia.
Saludos,
PP [twitter: @pabloperalta]
Fundador de elblogdedynamicscrm.com!
Co-autor del libro The CRM Field Guide
Product Manager | CRMGamified®
UruIT Dynamix | #1 en servicios de Outsourcing de Dynamics CRM
