BLOG

06 luglio 2018 - Web

Sincronizzazione dei dati fra due database: come gestirla per evitare disservizi

sincronizzazione-dati.jpg

Quando si lavora all'aggiornamento o alla manutenzione di applicazioni web aziendali già progettate e funzionanti, può capitare di dover gestire la sincronizzazione dei dati fra due database diversi o fra più database, per motivi disparati; e di non avere alternative per l'utilizzo di un unico archivio dati, soluzione sicuramente perfetta e ampiamente preferibile.

A differenza dei progetti web più o meno semplici, per cui raramente si profila una simil necessità, le applicazioni web aziendali o professionali non sempre possono essere semplicemente riscritte e non sempre i dati che vengono elaborati possono essere gestiti da una unica fonte o re-inseriti. Infatti, quando uno sviluppatore viene incaricato della riprogettazione di una applicazione web aziendale, spesso può avere a che fare con applicazioni che interrogano database esterni, appartenenti a servizi/aziende di terze parti o a database che lavorano su altre piattaforme e in cui non è possibile scrivere alcun nuovo dato o addirittura modificarlo ma soltanto leggerne i record già memorizzati. Questo perché i database esterni non possono essere accessibili né consultabili da applicazioni esterne al loro software o perché i database che lavorano su altre piattaforme costituiscono un archivio aziendale sicuro per uso interno e non possono essere sottoposti a vulnerabilità scaturenti da una accessibilità pubblica autorizzata in lettura/scrittura.

In questi casi la sicurezza è fondamentale e più i dati sono sensibili e di vitale importanza per il funzionamento dell'azienda, più è seriamente rischioso consentirne la lettura/scrittura. Persino un sistema di back-up preimpostato può non essere sufficiente a garantire l'immediato ripristino di eventuali danni causati dall'esterno né è sempre possibile impostare un back-up a ogni inserimento/aggiornamento di un dato. Tutto dipende dalle risorse aziendali e dall'apparato hardware utilizzato.

Per poter dunque avere a disposizione un database completo di tutti i dati e costantemente aggiornato, da interrogare tramite web, scongiurando problemi di sicurezza, la soluzione più adottata consiste proprio nella sincronizzazione dei dati fra due o più database (dai database esterni al database di riferimento da utilizzare come unica fonte). Ma come gestire la sincronizzazione senza causare disservizi durante la consultazione e fruizione dell'applicazione?

Il primo passo da compiere consiste sicuramente nell'impostazione dell'operazione durante le ore notturne, le meno trafficate nella maggior parte dei casi e le più indicate per ridurre al minimo l'eventuale disservizio.

Impostato l'orario notturno, per eliminare quasi del tutto l'eventuale black-out che potrebbe essere causato al visitatore durante la fruizione dell'app durante quella fascia oraria, bisogna pensare a cosa predisporre per ingannare l'attesa impiegata dall'operazione di sincronizzazione:

  • Una pagina web in HTML in cui ci si scusa per il disservizio arrecato;
  • Un livello sovrapposto con una gif di caricamento che ritarda di qualche istante l'accesso all'applicazione (una pagina bianca completamente sovrapposta all'applicazione con la gif posizionata verticalmente e orizzontalmente in centro).

La prima soluzione risulta particolarmente utile se la sincronizzazione dei dati richiede del tempo non trascurabile, informando gli utenti sullo stato di manutenzione in corso. Un esempio semplicissimo di pagina può essere simile a questo:

<!DOCTYPE html>
<html lang='it'>
  <head>
    <title>Manutenzione in corso</title>
    <meta charset='utf-8'>
    <style>
    body {
      text-align: center;
      font-family: Arial;
    }
    </style>
  </head>
  <body>
    <h1>Manutenzione in corso</h1>
    <p>Ci scusiamo per il temporaneo disservizio. L'applicazione verr&agrave; ripristinata a breve.</p>
  </body>
</html>

Per la seconda soluzione, invece, è possibile ipotizzare un espediente di questo tipo:

<!DOCTYPE html>
<html lang='it'>
  <head>
    <title>Titolo dell'applicazione</title>
    <meta charset='utf-8'>
    <style>
    body {
      font-family: Arial;
    }
    
    #overlay {
      display: block;
      position: absolute;
      left: 0;
      top: 0;
      width: 100%;
      height: 100%;
      text-align: center;
    }
    </style>
  </head>
  <body>
    <!-- Overlay con un avviso di caricamento o con una gif di caricamento -->
    <span id="overlay">Caricamento in corso..</span>
    <!-- Albero della pagina -->
  </body>
</html>

Nel primo caso, la pagina viene richiamata appositamente quando l'utente accede durante la sincronizzazione. Nel secondo caso, invece, viene creato soltanto il livello all'interno della pagina se l'utente accede durante la sincronizzazione, mascherandone temporaneamente il contenuto e quindi impedendone la visualizzazione e la consultazione.

Se viene utilizzato PHP e la classe PDO per interrogare il database e la sincronizzazione viene avviata con una preliminare rimozione dei record memorizzati in tabella, nel primo caso è possibile effettuare un redirect alla pagina di manutenzione, ad esempio così:

<?php

  if ($sql->rowCount() == 0) {
  
    header('Location: manutenzione.html');
    exit;
  
  }

?>

Invece nel secondo caso il livello verrebbe creato dinamicamente così:

<?php if ($sql->rowCount() == 0) : ?>
  <!-- Overlay con un avviso di caricamento o con una gif di caricamento -->
  <span id="overlay">Caricamento in corso..</span>
<?php endif; ?>

oppure, se l'applicazione è stata progettata accuratamente, separando i file di elaborazione da quelli markup (modus operandi che condivido pienamente), il livello verrebbe incluso dinamicamente, così:

<?php

  if ($sql->rowCount() == 0) {
  
    // Includo l'overlay
    // La cartella 'template' indica l'eventuale cartella di riferimento in cui sono state salvate le pagine html di mark-up
    
    require_once 'template/overlay.html';
  
  }

?>

In entrambi i casi la gestione del disservizio avverrebbe senza complicazioni, evitando la visualizzazione di errori tecnici o che l'utente venga indotto erroneamente a pensare che i dati richiesti siano in realtà inesistenti.

Ho volutamente omesso eventuale codice JS e le istruzioni necessarie all'interrogazione della tabella sottoposta a sincronizzazione per una maggiore esemplificazione e per concentrare l'attenzione esclusivamente sui metodi di gestione della sincronizzazione stessa.

In base alle situazioni e alle piattaforme di sviluppo o alle esigenze tecniche, se i dati da sincronizzare sono pochi e il tempo impiegato dall'operazione durante le ore notturne è quasi impercettibile, è possibile anche soprasssedere alla pagina di manutenzione. Se invece l'applicazione web deve garantire un funzionamento e una fruizione ai limiti della perfezione, una pagina di manutenzione è una delle vie da considerare e percorrere.

Fonte immagine: Google Immagini

CATEGORIE