Optimo Uso de Transacciones dentro de un Plug-in en Microsoft Dynamics CRM

Por diseño, los plug-ins en Microsoft Dynamics CRM son disparados por un evento que se ejecuta dentro de la misma transacción en la base de datos de SQL y no incluye llamados relacionados a SDK. Por ejemplo: la creación de una cuenta y la llamada subsecuente a SDK para generar una tarea relacionada a dar la Bienvenida al cliente se ejecuta en una transacción simple. Esta funcionalidad intenta asegurar que el caso de que exista un error o falla la actividad completa haga un rol back, el cual es de un valor inigualable en algunos escenarios.

Aunque esta característica ofrece una gran protección sobre fallas, la enorme transacción puede impactar sobre actividades concurrentes en si sistema, causando con ello retrasos o errores. Como resultado, es recomendable tener esto en mente el diseño del plug-in para ayudar a minimizar cualquier bloqueo en la aplicación implícitamente asociada con las acciones iniciales que resultan bloqueos en base de datos. 

Algunas causas comunes de bloqueos son descritas a continuación:

• Realización de Consultas: Cuando un usuario ejecuta una consulta en la base de datos, el servidor de SQL utiliza estrategias de bloqueos de transacciones para asegurar que la transacción sea completada consistente y realmente. Cuando la información es consultada, el servidor de SQL determina cuando bloqueará o no la información para lectura, previniendo que otras transacciones escriban datos. El servidor de SQL entonces determinará el rango más apropiado para el bloqueo de información de consultas que acceden a grandes volúmenes de datos en una tabla o que realizan búsquedas de información almacenada que se extienden a través de una variedad de tablas, en las cuales la tabla completa podría ser bloqueada. En este escenario, el bloqueo puede no desaparecer hasta que la transacción haya sido completada o abortada, lo cual puede causar un gran impacto sobre otras transacciones que requieran también bloquear información en la tabla. Por ejemplo, si un usuario accede a las cuentas con la cuenta propietaria del usuario actual, esto podría provocar que la aplicación haga consultas de datos a través de las de cuenta.

• La mayoría de las consultas en Microsoft Dynamics CRM usa "hints" de base de datos para indicar que los bloqueos no son necesarios antes de una consulta. El uso de ellas en la base de datos es particularmente útil cuando se utilizan vistas, donde sabemos que ninguna acción resultante será tomada con base al conjunto de resultados devuelto en ese momento dentro del sistema, pues los resultados de la vista están diseñados para mostrar un punto específico en un periodo definido. Como resultado los "hints” indican al servidor de SQL no enviar un bloqueo de lectura durante las solicitudes comunes, y las consultas de Microsoft Dynamics
  CRM hechas mediante el web service no desencadenar este tipo de bloqueo en condiciones normales.

  Toma en cuenta que en algunos escenarios, como las situaciones en que se comprueba la disponibilidad del usuario antes de reservar una actividad de servicio, el sistema requiere el bloqueo transaccional, bloqueo puede tener un impacto en las peticiones relacionadas.

• Creación de registros puede bloqueada por ejecutar consultas concurrentes. Si bien la creación registros por sí mismo no es problemático, otros procesos simultáneamente pueden requerir el bloqueo de la tabla para ejecutar una consulta bloqueándola hasta completar la transacción que contiene la creación del registro.

• Actualización de recursos comunes. Escenarios en que múltiples procesos son capaces de actualizar un recurso común, como una situación en la que cada petición de un miembro de un equipo para ver un registro actualiza un atributo en el registro que indica la última vez que fue visto, potencialmente pueden crear bloqueo dentro del sistema. Si un gran número de usuarios ve regularmente un registro, el bloqueo ocurriría porque sólo un usuario a la vez puede actualizar el registro

A pesar de que es natural que un bloqueo ocurra cuando una consulta grande se está ejecutando, otras transacciones pueden bloquearse esperando a que se complete dicha transacción, pero no es siempre evidente que se lleva a cabo una transacción en SQL a través de los plug-ins registrado en pipeline de evento en particular, por ejemplo el tiempo ejecutado en acciones ajenas a la base de datos extienden la longitud de la transacción y ningún bloqueo presente es relacionado.

El punto a notar es que la acción propiamente dicha no puede requerir un bloqueo durante un largo periodo, pero debe mantenerse hasta que la transacción se compromete entendiendo la importancia del ciclo de vida de la transacción que se utiliza a través de pipeline del evento. Esto es importante porque puede ser que bloqueo puede deberse a acciones de larga duración que ocurre fuera de la acción de la base de datos ya que evitan que el evento en el pipeline se complete.

Los bloqueos en sí no son un problema y de hecho es un comportamiento esperado para situaciones en que se requiere consistencia dentro de una transacción, forzando la serialización de transacciones que necesitan acceso a los mismos datos. El tiempo total de ejecución de cada uno de los bloqueos de plug-in puede
alargarse mientras esperan por recursos necesarios antes de que pueda empezar su propia tarea. Para escenarios en los que esto ocurre regularmente, puede ser afectada la escalabilidad general de una solución pues el sistema es menos capaz de procesar solicitudes simultáneas múltiples.

Para reducir al mínimo o el impacto potencial de las transacciones de la base de datos SQL en escalabilidad, durante el diseño del plug-in, asegúrate de tener en cuenta las siguientes sugerencias:

1. Minimiza la cantidad de procesamiento complejo o largo dentro de cualquier plug-in que es parte de una transacción que tiene recursos que pueden ser requeridos por otros procesos.
2. Registra un plug-in como una etapa que no participa en la transacción padre para situaciones en que la acción realizada por el plug-in no necesita la protección de la transacción
3. Registra un plug-in para ejecutarse de forma asincrónica.

Si en un comienzo el plug-in comienza a ejecutarse de forma inconsistente, falla intermitentemente o muestra variables de rendimiento, vale la pena revisar el diseño plug-in para determinar si la naturaleza intermitente de las fallas o las variaciones en el rendimiento puede ser atribuida al loqueo de la transacción. 

Mayor información: msdn.microsoft.com/en-us/library/gg334724.aspx.

Saludos,

Claudia Cisneros