Sincronización de datos de la aplicación: ejecutar la nueva aplicación junto con el legado

Question

Estamos en el proceso de reemplazar un sistema heredado. Habrá un período de tiempo con ambas aplicaciones ejecutándose en conjunto. Los usuarios podrán usar cualquiera de los sistemas y el desafío es poder mantener sus bases de datos sincronizadas entre sí.

El nuevo sistema es ASP.NET y el legado es VB6. Ambos se ejecutan en una base de datos de SQL Server. No está claro en este momento si las bases de datos estarán en la misma sala de servidores, y mucho menos en el mismo país.

Las dos soluciones sobre la mesa hasta ahora son:

1. Servicios web que se encuentran en cada máquina y son llamados por la otra aplicación.
   • ¿Necesita modificar el método Save en la (s) clase (s) base para los objetos nativos? Esto es invasivo y podría ser un problema a la hora de apagarlo.

2. Un servicio de Windows único que sondea cada base de datos y calcula qué ha cambiado y envía actualizaciones adaptadas según corresponda.

   • Es necesario cambiar los esquemas en ambas aplicaciones para asegurarse de que tengan un LastModified (DateTime) en todas las tablas para que podamos hacer una SELECCIÓN periódica en cualquier intervalo dado.

Ambas soluciones parecen razonables. Ambas soluciones tienen pros y contras. La empresa no ha solicitado más de 2 segundos de retraso (!) Entre actualizar un sistema y verlo en el otro. Posiblemente sea un objetivo extendido, pero es algo a lo que apuntar.

Otros que han sido sugeridos pero rechazados (estoy dispuesto a reconsiderar) son:

• Activadores de bases de datos (blugrh)
• BizTalk u otro bus (parece un mazo y es demasiado complejo para una solución de cambio)
• Modificación de todos los procedimientos almacenados (noooo.)
• SSIS (todavía no sé lo suficiente sobre esto)

Apreciar cualquier pensamiento que pueda tener.

EDITAR: N.B. Los esquemas son completamente diferentes.

Answer 1

Al final, esto se resolvió con un servicio web. Funcionó muy bien.

Answer 2

2 segundos, esa es una línea de tiempo muy ajustada, y supongo que su solución de aplicación de Windows podría no ser suficiente, no si hay cientos de cambios o algo al mismo tiempo, y el tiempo de la encuesta tiene que ser casi cada segundo con la esperanza de llegar dentro de 2.

¿Las bases de datos usan la misma estructura? Si es así, consideraría implementar la replicación.

Editar

Después del comentario y la adición de que los esquemas son completamente diferentes, debo decir que realmente veo dos conjuntos de operaciones.

1. Modifique las opciones de almacenamiento de datos EN la aplicación para realizar inserciones / actualizaciones / eliminaciones en ambas tablas. Ventaja: Inmediata, sin proceso externo para compartir. Desventaja: tiene que modificar todo el código, es difícil de deshabilitar, etc.

2. Cree una aplicación de sincronización como mencionó, para sincronizar los datos modificados. Ventaja: simplemente puede deshabilitar después de la transferencia realizada. Desventaja: muy complejo de escribir, especialmente si hay una gran cantidad de tablas. Además, no tan rápido, 2 segundos serán MUY difíciles de lograr

Answer 3

Personalmente, rechazaría la idea de que los usuarios utilicen cualquiera de los sistemas de forma simultánea. ¿Cómo va a resolver el problema si el usuario 1 cambió el registro 1 en el sistema 1 y el usuario 2 cambió el registro 1 de una manera diferente en el sistema 2?

Además, si no requiere que las personas usen el nuevo sistema, no lo harán. La resistencia al cambio es muy muy fuerte en la mayoría de las organizaciones.

Sugeriría en su lugar que implemente el nuevo sistema y requiera que todos lo usen y envíen datos cada hora al sistema anterior en caso de que necesite revertirlo por cualquier motivo.

No veo una forma razonable de obtener una sincronización de 2 segundos. Ese es un requisito ridículo y la parte comercial debe ser informada en términos claros.

A veces solo tienes que defenderte cuando los usuarios de negocios quieren algo irrazonable.

Answer 4

¡Lo que describe aquí me hace sentir en medio de una pesadilla! Creo que primero debe comenzar a dejar en claro a todos que es imposible (o al menos extremadamente costoso) pensar en permitir que los usuarios actualicen todos los datos a través de 2 aplicaciones diferentes con 2 bases de datos diferentes durante todo el proceso de transición ! Ni siquiera estoy hablando del retraso de 2 segundos ...

Según yo, la estrategia básica debería ser cambiar gradualmente los derechos y posibilidades de actualización de datos del legado a la nueva aplicación. Los usuarios podrán ver los datos desde ambos lados, pero podrán actualizarlos solo a través de una de las aplicaciones.

(incidentalmente, este método también obligará a los usuarios a cambiar gradualmente a la nueva versión, evitando problema de resistencia esperado y molesto ya expuesto por @HLGEM )

Una vez que esta regla se acepta claramente, puede implementar los siguientes pasos.

1. Establezca todos los procedimientos que permitan la transferencia de datos de la base de datos heredada a la nueva base de datos. Supongo que tendrás que ejecutarlos varias veces en los próximos meses ...
2. Establezca todos los procedimientos que permitan la transferencia de datos de otra manera (transferencia inversa de datos)
3. Aquí debería haber identificado grupos homogéneos de tablas que se pueden mover juntos. Combine el código anterior de forma que obtenga para cada uno de estos grupos una "transferencia de datos" procedimiento y una transferencia inversa uno.

Entonces, para cada uno de estos grupos

4. Ponga sus restricciones de actualización a través del código o en el nivel de la base de datos
5. Ejecute su " transferencia de datos " procedimiento
6. Organice su "transferencia inversa" procedimiento como desencadenante en la nueva base de datos

Supongo que el primer tipo de datos que podrá transferir serán listas que no contengan claves foráneas.

Trabajando de esta manera, cambiará gradualmente de una situación en la que tiene

• aplicación heredada de lectura / escritura + solo lectura     nueva aplicación

a

• aplicación heredada de solo lectura + lectura / escritura     nueva aplicación.