Costruire un set di API su un'applicazione legacy che può anche scrivere nel database di origine?

0

OK, quindi dimmi se questa è la peggiore idea di sempre, o se potrebbe avere qualche merito. Ecco qui:

Ho un cliente che usa un'applicazione legacy che memorizza i dati in un file di database Omnis (* .DF1). Questa applicazione gestisce le prenotazioni e le prenotazioni per i campeggi ed è localmente ospitata su un server che viene eseguito sul sito del mio cliente. Il cliente è in grado di effettuare prenotazioni online tramite un motore di prenotazione di terze parti, ma non è completamente automatizzato - il gestore del sito deve caricare una lista di disponibilità sul sito di prenotazione, e anche una volta effettuata la prenotazione, il gestore deve chiamare e confermare la prenotazione (molto probabilmente perché a causa di problemi di sincronizzazione è possibile effettuare una doppia prenotazione).

Solo il 5% circa delle prenotazioni è attualmente effettuato online; il resto è per telefono. Stiamo cercando di inclinarci drasticamente nella direzione opposta mentre aumentiamo gli sforzi di marketing online e puntiamo ai nuovi clienti, quindi abbiamo bisogno di un modo per supportare la prenotazione online facile e accurata in modo da scalare. Il motore di prenotazioni non ha un'API e, naturalmente, nemmeno questa applicazione legacy (entrambe sono in realtà create dalla stessa società madre).

Il mio piano iniziale è quello di creare un set di API in grado di connettersi a questo file di database locale ed esporre servizi Web per consentire il recupero e la creazione / aggiornamento delle prenotazioni. In questo modo, il gestore del sito può ancora utilizzare l'app per creare prenotazioni come al solito, ma ora abbiamo il controllo delle prenotazioni online potendo sincronizzarsi con il database di origine. Ho intenzione di risolvere i problemi di caricamento utilizzando un database intermedio ospitato su AWS per fungere da sistema di registrazione surrogato. Le prenotazioni verrebbero scritte nel database surrogato, quindi inserite nel database di origine.

Fondamentalmente l'installazione sarebbe simile a questa:

Sito web - > Servizio web prenotazioni - > DB Surrogate Bookings (AWS) - > Client Java sul server gestito dal sito - > DB di origine

Mi rendo conto che potrebbero esserci ancora problemi di sincronizzazione in quanto il gestore del sito potrebbe creare una prenotazione, ma potrei potenzialmente risolverlo inviando un'email o un avviso quando viene effettuata una prenotazione online, in modo tale che se sono attivi il telefono con un cliente hanno l'ultima visione di ciò che viene prenotato online.

Sta avendo un'API separata che può scrivere in un database che un'altra applicazione può scrivere anche in una ricetta per il disastro? L'altra soluzione è mantenere il mio database delle prenotazioni surrogate completamente separato, ma poi ho il problema di come facciamo a essere assolutamente sicuri che nulla venga prenotato doppio nel sistema principale perché sarebbero disconnessi.

Gradirei qualsiasi idea su come le persone aggirano questo tipo di problemi quando le applicazioni legacy soddisfano i requisiti moderni.

    
posta Ryan 21.12.2016 - 18:44
fonte

0 risposte

Leggi altre domande sui tag