Continuando con la implementación de bloqueos en CRM 3.0

La semana pasada vimos una forma de implementar un sistema para establecer bloqueos de registros en el CRM. Es decir, evitar que dos usuarios pudiesen editar a la vez el mismo registro, de forma que si un usuario tiene abierto el formulario de edición de un registro otro usuario no lo pueda abrir.

En el post me comentabais que sería mejor abrir el registro en modo de sólo lectura en vez de cerrarle la ventana al usuario (muchas gracias por el comentario), y la verdad es que estoy totalmente de acuerdo en que es una forma mejor de tratar los bloqueos. Así que me he puesto a probar, y con sólo cambiar una línea del código que teníamos, ya solucionamos este problema.

El CRM tiene una página «especial» que permite mostrar un objeto en un formulario en modo sólo lectura, se trata de http://servidorcrm:5555/_forms/readonly/readonly.aspx?objTypeCode=[Código de Entidad]&id=[GUID del Objeto]. Gracias a este «generador» de formularios de sólo lectura, y a que en el código JavaScript disponemos de las propiedades crmForm.ObjectTypeCode y crmForm.ObjectId que nos indican el tipo de entidad y GUID del registro, podemos cambiar la línea 30 del código para que en vez de cerrar el formulario muestre un sin posibilidad de editar.

Línea 30 JavaScript (Antigua): window.close();

Línea 30 JavaScript (Nueva): window.navigate(«http://crm:5555/_forms/readonly/readonly.aspx?objTypeCode=»+crmForm.ObjectTypeCode+»&id=»+crmForm.ObjectId);

Bien, esta es una mejora interesante con respecto a la versión anterior. Pero aún sigue habiendo pequeños inconvenientes en el sistema de bloqueos. Los principales son:

• El sistema no es escalable porque el servicio web que controla los bloqueos no funcionaría correctamente en un cluster de IIS (por utilizar una variable estática).
  
• Seguimos sin disponer de un mecanismo para liberar bloqueos, o por lo menos para ver que usuario tiene bloqueado un registro.
  
• Creo que esta solución NO estaría soportada por utilizar el evento window.onunload.
  
• Hay que añadir el código JavaScript una por una todas las entidades a las que queramos implementar bloqueos. Eso sí, con la ventaja de que el código es independiente de a qué entidad lo que queramos aplicar, con sólo ponerlo en el OnLoad del formulario listo.

Bueno, los dos primeros problemillas se podrían solucionar si utilizásemos una BBDD de datos para almacenar la lista de bloqueos (espero poder probarlo). Pero de cualquier forma espero que os sirva de ejemplo sobre por dónde pueden ir los tiros para los que necesitéis implementar algo así, y que me dejéis vuestras ideas y opiniones.

Un saludo,

Marco Amoedo