Tieni i canali online, anche se i sistemi sottostanti sono offline?

Naviga le tue risposte
0

Abbiamo sei sistemi molto vecchi in cui è stato costruito il più recente 1995. Tutti questi sistemi hanno processi batch che vanno da mezzanotte alle 6 del mattino ogni notte, e questi sistemi sono offline. Oltre a questi sei sistemi esiste un'API da cui diversi canali accedono ai dati dai sei sistemi. Naturalmente ogni canale è offline anche tra queste ore, poiché dipendono dall'API che dipende in base ai sei sistemi mainframe (vedi disegno schematico sotto).

Ora abbiamo nuove regole aziendali che dicono che i canali devono essere online 24 ore su 7, 7 giorni alla settimana. La nostra interpretazione è che i clienti devono essere in grado di accedere ai propri dati, anche se i sistemi sottostanti sono offline a causa di processi di elaborazione batch.

Quindi, la mia domanda è: come possiamo sfruttare l'API, sincronizzare e archiviare i dati da utilizzare quando i sistemi sottostanti sono offline? Usiamo un meccanismo di memorizzazione nella cache o costruiamo un'applicazione di database che sincronizza i dati in una pianificazione?

Ulteriori informazioni basate sul feedback nei commenti

  1. Puoi chiarire se i sistemi sono di solito online, ovvero gestire le richieste per l'API?

    • I sistemi sono online tra le 6 del mattino e a mezzanotte. I canali sono online 24 ore su 24, ma senza accesso ai sistemi da mezzanotte alle 6.

  2. Le operazioni API eseguono regole aziendali o richiedono solo dati dai sistemi sottostanti?

    • l'API richiede e riceve solo dati. Il disegno è eccessivamente semplificato, ma la logica aziendale vive nei sistemi sottostanti 1-6.

  3. Ci sono motivi specifici (come il costo dell'hardware, i rischi di modifica del codice) perché i sistemi non possono essere duplicati in modo che un sistema possa gestire le operazioni batch mentre l'altro risponde alle richieste API?

    • Non sono sicuro, devo scavare più a fondo per rispondere. Il costo è sempre un fattore, ma non nella misura in cui fermerebbe un bisogno aziendale come questo.

  4. Sarebbe possibile accodare le richieste API ed eseguirle dopo che i sistemi sono tornati online?

    • Non proprio. È un sistema assicurativo, e i clienti vogliono solo accedere ai propri dati come quando sono dove i sistemi sono online.

  5. In genere un canale B2B supporta le richieste di ordini come ordini. Anche gli altri due canali potrebbero supportare gli invii. Sei sicuro che sia limitato al recupero dei dati?

    • Al momento, in questo caso ci sono limitazioni ai vecchi sistemi. Vogliamo mostrare assicurazioni, termini, documenti ma non apportare modifiche durante le ore offline. Ma nel periodo di 5-6 anni, i vecchi sistemi saranno sostituiti da un sistema più recente e da allora saranno supportati. Questo non è l'ideale, ma un compromesso tra esigenze aziendali e vincoli tecnici.
posta 4rchit3ct 23.07.2018 - 13:29
fonte

2 risposte

1

Non penso che sia possibile senza affrontare il problema sottostante dei processi batch che portano il sistema offline.

La soluzione sarebbe come dici tu per copiare l'intera origine dati prima che i lavori batch inizino, e puntare l'api fino a quando i sistemi torneranno online.

Ma se è necessario portare il sistema offline per eseguire questi lavori batch, penso che copiare l'intero database, senza tempi di inattività, sarà problematico.

Allo stesso modo l'approccio di caching richiede effettivamente di costruire e mantenere una copia dell'intero database in una cache tutto il tempo. A meno che le query non siano limitate a un insieme di dati molto più piccolo, non sarà molto efficace.

    
risposta data 23.07.2018 - 16:16
fonte
1

La distinzione che hai tracciato tra un'applicazione di database e la memorizzazione nella cache non è probabilmente utile. Indipendentemente dal fatto che tu usi un database o meno per archiviare i dati non importa molto. E anche se in un certo senso quello che stai facendo è il caching, non è proprio così tipicamente quello che chiameremmo il caching (dal momento che non è guidato dalle chiamate dal lato del richiedente e dal momento che ciò che devi memorizzare è una copia completa dei dati disponibili).

Ma quello che devi fare è chiaro. Salvare DUE copie dell'intero set di dati disponibili, uno chiamato PIÙ RECENTI e uno chiamato NEXT MOST RECENT. Ogni volta che hai accesso ai nuovi dati (non appena hai accesso ad essi) -

  • elimina "SUCCESSIVO PIÙ RECENTI"
  • inizia a copiare i dati in una nuova area di archiviazione
  • una volta terminata la copia, rinomina i DATI PIÙ RECENTI esistenti in "PROSSIMO AL PIÙ RECENTE" e rinomina i tuoi dati temporanei di attesa (che hai appena copiato) in "PIÙ RECENTE"

E servono sempre i dati delle API pubbliche rivolte dalla tabella del database "PIÙ RECENTI".

Utilizzare un database o una memoria del filesystem come desiderato, in base a ciò che è più semplice per l'implementazione API esistente e al formato dei dati che si estraggono correntemente dai mainframe. Niente su questo piano di rotazione richiede l'introduzione di un database.

    
risposta data 23.07.2018 - 16:19
fonte

Leggi altre domande sui tag

Il mio approccio alla compilazione dinamica dei contenuti web è ok? Dove dovrebbero essere applicate le regole del dominio sull'input dell'utente?