La sincronización bidireccional exige reglas de escritura
Si CRM y ERP pueden escribir, cada campo compartido necesita una regla de conflicto. El último mensaje recibido no es necesariamente la última decisión de negocio.
Una conexión puede transferir datos en ambos sentidos. Eso no significa que cada campo deba sobrescribirse libremente en ambos lados. Los campos compartidos necesitan una regla que una permisos de edición, versión de partida y gestión de conflictos. De lo contrario, un mensaje técnicamente nuevo puede recuperar un valor antiguo para el negocio.
Un mensaje tardío puede basarse en datos antiguos
Una empresa ficticia de software sincroniza CRM y ERP. El ERP confirma la dirección de facturación y el CRM mantiene el contacto del proyecto. Esta secuencia inventada muestra lo que podría causar una actualización completa del registro:
Hora | Operación | Versión de los datos |
|---|---|---|
| El CRM lee el registro del cliente. |
|
| El equipo del ERP confirma una nueva dirección de facturación. |
|
| El CRM devuelve el contacto del proyecto modificado junto con la dirección antigua. | El mensaje aún contiene |
El mensaje llega después, pero la dirección procede de una versión anterior. Si la integración aceptara todo el registro sin comprobarlo, podría perderse el cambio confirmado. Aquí v7 y v8 corresponden al mismo registro del ERP; los contadores locales independientes de sistemas distintos no son directamente comparables.
Detectar la versión de partida y resolver el conflicto
Microsoft describe la concurrencia optimista para Dataverse: una aplicación puede detectar si el registro del servidor cambió entre lectura y escritura. La comprobación disponible y cómo se activa dependen del producto y su interfaz.
Detectar una diferencia todavía no decide qué dirección es correcta para el negocio. En este ejemplo, la dirección antigua debe esperar una aclaración o tratarse como una escritura de retorno no permitida. Reenviar simplemente el valor antiguo rechazado con otro identificador de versión anularía ese control sin resolver la diferencia de negocio. Una comprobación de versión aislada tampoco hace atómicos todos los pasos entre varios sistemas.
Cuándo pueden escribir ambos lados
Si ambos equipos necesitan realmente editar la misma información, una solución bidireccional puede ser adecuada. Deben explicitarse entonces los campos permitidos, los cambios y las decisiones en caso de conflicto. La documentación de dual-write de Microsoft muestra, por ejemplo, sentidos distintos por relación de columnas; un ajuste global para todo no es una necesidad de negocio.
También puede bastar transferir campos distintos en sentidos distintos. En el ejemplo, el nuevo contacto del proyecto debe aceptarse según su regla, mientras la dirección antigua no debe reescribirse sin control. Ambos valores pertenecen al mismo cliente, pero requieren decisiones de escritura diferentes.
Fuentes
Seguir leyendo
Todos los artículos
APIs e integración con ASES
ERP, CRM y tienda bien conectados