Sincronizzazione dei dati dell'applicazione: esecuzione della nuova app in tandem con l'eredità

Question

Stiamo sostituendo un sistema legacy. Ci sarà un periodo di tempo con entrambe le applicazioni in esecuzione in tandem. Gli utenti saranno in grado di utilizzare entrambi i sistemi e la sfida è riuscire a mantenere i loro database sincronizzati tra loro.

Il nuovo sistema è ASP.NET e l'eredità è VB6. Entrambi sono in esecuzione su un database SQL Server. Non è chiaro in questo momento se i database saranno nella stessa sala server, per non parlare dello stesso paese.

Le due soluzioni sul tavolo finora sono:

1. Servizi Web che si trovano su ogni macchina e sono chiamati dall'altra applicazione.
   • È necessario modificare il metodo Save sulla classe di base (es?) per gli oggetti nativi. Questo è invasivo e potrebbe essere un problema quando si tratta di spegnerlo.

2. Un singolo servizio di Windows che esegue il polling di ciascun database e scopre cosa è cambiato e inoltra gli aggiornamenti adattati come appropriato.

   • È necessario modificare gli schemi in entrambe le applicazioni per assicurarsi che abbiano un LastModified (DateTime) su tutte le tabelle in modo da poter effettuare una SELEZIONE periodica ad ogni intervallo.

Entrambe le soluzioni sembrano ragionevoli. Entrambe le soluzioni hanno pro e contro. L'azienda non ha richiesto più di un ritardo di 2 secondi (!) Tra l'aggiornamento di un sistema e il vederlo nell'altro. Questo è probabilmente un obiettivo estensibile ma è qualcosa su cui mirare.

Altri che sono stati suggeriti ma respinti (sono disposto a riconsiderare) sono:

• Trigger del database (blugrh)
• BizTalk o altri bus (sembra una mazza ed è troppo complesso per una soluzione di commutazione)
• Modifica di tutte le procedure memorizzate (noooo.)
• SSIS (non ne so ancora abbastanza)

Apprezzo qualsiasi pensiero tu possa avere.

MODIFICA: N.B. Gli schemi sono completamente diversi.

Answer 1

Alla fine questo è stato risolto con un servizio web. Ha funzionato davvero bene.

Answer 2

2 secondi, questa è una linea temporale molto stretta, e immagino che la tua soluzione per app Windows potrebbe non tagliarla, non se ci sono centinaia di modifiche o altro alla volta e il tempo del sondaggio deve essere quasi ogni secondo sperando di farcela entro 2.

I database stanno usando la stessa struttura? In tal caso, esaminerei l'implementazione della replica.

Modifica

Dopo il commento e l'aggiunta che gli schemi sono completamente diversi, devo dire che in realtà vedo due serie di operazioni.

1. Modifica le opzioni di archiviazione dei dati nell'app per effettuare inserimenti / aggiornamenti / eliminazioni in entrambe le tabelle. Vantaggio: immediato, nessun processo esterno da condividere. Svantaggio: modificare tutto il codice, difficile da disabilitare, ecc.

2. Crea un'applicazione di sincronizzazione come hai detto, per sincronizzare i dati modificati. Vantaggio: può semplicemente disabilitare dopo il trasferimento effettuato. Svantaggio: molto complesso da scrivere soprattutto se ci sono molte tabelle. Inoltre, non così velocemente, 2 secondi saranno MOLTO difficili da realizzare

Answer 3

Personalmente respingerei l'idea che gli utenti usassero entrambi i sistemi contemporaneamente. Come risolverete il problema se l'utente 1 ha modificato il record 1 sul sistema 1 e l'utente 2 ha modificato il record 1 in modo diverso sul sistema 2?

Inoltre, se non si richiede alle persone di utilizzare il nuovo sistema, non lo faranno. La resistenza al cambiamento è molto forte nella maggior parte delle organizzazioni.

Suggerirei invece di implementare il nuovo sistema e richiedere a tutti di usarlo e di inviare ogni ora i dati al vecchio sistema nel caso in cui sia necessario ripristinare per qualsiasi motivo.

Non vedo alcun modo ragionevole per ottenere una sincronizzazione di 2 secondi. Questo è un requisito ridicolo e il lato aziendale dovrebbe dirlo in termini non incerti.

A volte devi solo reagire quando gli utenti aziendali vogliono qualcosa di irragionevole.

Answer 4

Quello che descrivi qui mi fa sentire nel mezzo di un incubo! Penso che dovresti prima iniziare a chiarire a tutti che è impossibile (o almeno estremamente costoso) pensare di poter consentire agli utenti di aggiornare tutti i dati attraverso 2 diverse applicazioni con 2 database diversi durante l'intero processo di transizione ! Non sto nemmeno parlando del ritardo di 2 secondi ...

Secondo me, la strategia di base dovrebbe essere quella di cambiare gradualmente i diritti e le possibilità di aggiornamento dei dati dall'eredità alla nuova app. Gli utenti saranno in grado di vedere i dati da entrambi i lati, ma potranno aggiornarli solo attraverso una delle app.

(per inciso, questo metodo costringerà anche gli utenti a passare gradualmente alla nuova versione, evitando atteso e fastidioso problema di resistenza già esposto da @HLGEM )

Una volta che questa regola è chiaramente accettata, è possibile implementare i seguenti passaggi.

1. Imposta tutte le procedure che consentono il trasferimento dei dati dal database legacy al nuovo database. Immagino che dovrai eseguirli alcune volte nei prossimi mesi ...
2. Imposta tutte le procedure che consentono il trasferimento dei dati nell'altro modo (trasferimento inverso dei dati)
3. Qui dovresti aver identificato gruppi omogenei di tabelle che possono essere spostati insieme. Unisci il codice precedente in modo da ottenere per ciascuno di questi gruppi un "trasferimento dati" procedura e un "trasferimento inverso" uno.

Quindi, per ciascuno di questi gruppi

4. Inserisci le tue restrizioni di aggiornamento tramite codice o a livello di database
5. Esegui il tuo " trasferimento dati " Procedura
6. Organizza il tuo trasferimento inverso " procedura come trigger nel nuovo database

Suppongo che il primo tipo di dati che potrai trasferire saranno gli elenchi che non contengono chiavi esterne.

Lavorando in questo modo, passerai gradualmente da una situazione in cui ti trovi

• app legacy di lettura / scrittura + sola lettura     nuova app

a

• app legacy di sola lettura + lettura / scrittura     nuova app.