Integrazione di dati da più siti (Client)
Molte società dispongono di entità o uffici regionali che raccolgono ed elaborano dati che devono essere inviati a una posizione centrale. Ad esempio:
I dati di inventario possono essere consolidati da diversi server presenti in warehouse locali in un server centrale disponibile nella sede centrale dell'azienda.
Le informazioni provenienti da divisioni aziendali autonome all'interno di una società possono essere inviate in un server centrale.
È possibile consolidare le informazioni sull'elaborazione degli ordini provenienti da diverse posizioni.
In alcuni casi i dati vengono anche inviati dal sito centrale in siti remoti. In genere, tali dati sono specificamente progettati per essere di sola lettura nel sito remoto, ad esempio un set di tabelle di inventario dei prodotti che vengono aggiornate solo in un sito centrale.
Nella figura seguente viene illustrato uno scenario tipico con dati che fluiscono in due direzioni tra un sito centrale e posizioni remote:
.gif "Replica dei dati nelle filiali")
In tale figura i dati fluiscono innanzitutto in un hub prima di fluire negli uffici regionali serviti da tale hub. È inoltre possibile fare in modo che i dati fluiscano direttamente tra il sito centrale e gli uffici regionali se l'organizzazione non dispone di un layer intermedio.
Esempio Adventure Works Cycles
Adventure Works Cycles è un'azienda manifatturiera fittizia utilizzata per esemplificare concetti e scenari relativi ai database. Per ulteriori informazioni, vedere Database di esempio AdventureWorks.
Adventure Works Cycles dispone di un numero elevato di uffici vendite nel mondo. In ogni ufficio vendite vengono raccolti i dati forniti dal personale addetto alle vendite a livello regionale. Tali dati vengono trasmessi agli hub regionali e quindi al sito centrale alla fine di ogni giornata lavorativa. Essi vengono inoltre trasmessi tramite gli hub dal sito centrale a ciascun ufficio vendite, in modo che questo disponga delle informazioni più aggiornate su prezzi e promozioni.
Requisiti comuni per questo scenario
Le applicazioni per gli uffici regionali presentano generalmente le caratteristiche riportate di seguito, che una soluzione per la replica appropriata deve essere in grado di soddisfare:
I dati vengono immessi e aggiornati in un sito centrale e in siti remoti.
Gli utenti remoti devono essere in grado di eseguire aggiornamenti in modo indipendente, senza che sia necessaria una connessione al sito centrale.
Poiché più utenti potrebbero aggiornare gli stessi dati in modo indipendente, possono verificarsi conflitti dei dati che devono essere gestiti.
Alcuni dati dovrebbero essere aggiornati solo nel sito centrale, ad esempio i dati delle tabelle dei prezzi dei prodotti.
Gli utenti devono essere in grado di sincronizzare i dati su richiesta o in base a orari pianificati.
L'applicazione deve stabilire l'intervallo di tempo massimo durante il quale un sito remoto può rimanere non sincronizzato.
Per alcune tabelle sono necessarie operazioni di filtro, in modo che ogni utente riceva dati diversi per una o più tabelle. Un ufficio regionale, ad esempio, riceve informazioni solo sui clienti appartenenti all'area dell'ufficio.
Alcuni dati devono essere gestiti come singola unità durante il trasferimento tra siti. Se, ad esempio, un utente remoto invia un ordine al sito centrale, è necessario eseguire il commit dell'intestazione dell'ordine prima dei dettagli dell'ordine.
L'applicazione potrebbe richiedere l'esecuzione di logiche di business personalizzate al momento della sincronizzazione dei dati.
L'applicazione potrebbe richiedere la sincronizzazione dei dati tramite Internet anziché tramite una connessione dedicata.
L'azienda potrebbe essere organizzata in modo che i dati fluiscano attraverso uno o più layer intermedi tra il sito centrale e i siti remoti (come nella figura più indietro in questo argomento).
Nella figura seguente viene illustrato il filtro associato a questo scenario:
.gif "Filtraggio per le applicazioni delle filiali")
Tipo di replica da utilizzare per questo scenario
MicrosoftSQL Server utilizza una metafora basata sul settore dell'editoria per la descrizione dei componenti del sistema di replica. I componenti includono il server di pubblicazione, Sottoscrittori, pubblicazioni, articoli e sottoscrizioni. Nella figura riportata sopra il sito centrale è il server di pubblicazione. I dati nel sito centrale sono costituiti dalla pubblicazione, con ogni tabella di dati che rappresenta un articolo (gli articoli possono essere anche altri oggetti del database, come le stored procedure). Ogni hub è un Sottoscrittore della pubblicazione che riceve schema e dati come sottoscrizione. Gli hub quindi ripubblicano i dati e gli uffici regionali li sottoscrivono. Per ulteriori informazioni sui componenti del sistema, vedere Panoramica del modello di pubblicazione della replica.
SQL Server supporta diversi tipi di replica per soddisfare differenti esigenze applicative, ovvero la replica snapshot, transazionale e di tipo merge. Per ottenere i risultati migliori, per l'implementazione di questo scenario è consigliabile utilizzare la replica di tipo merge dal momento che è la più appropriata per la gestione dei requisiti descritti nella sezione precedente. Per ulteriori informazioni sulla replica di tipo merge, vedere Panoramica della replica di tipo merge e Funzionamento della replica di tipo merge.
.gif "Nota importante") Importante |
|---|
È possibile implementare questo scenario in due modi, ovvero supponendo che l'ufficio centrale sia un server di pubblicazione e gli uffici remoti siano Sottoscrittori o che l'ufficio centrale sia un Sottoscrittore e gli uffici remoti siano server di pubblicazione. La replica di tipo merge non supporta topologie centrali di Sottoscrittore. Anche se tutte le modifiche vengono apportate nei siti remoti, è necessario configurare l'ufficio centrale come server di pubblicazione con i siti remoti che agiscono da Sottoscrittori. È possibile implementare uno scenario simile con la replica transazionale utilizzando una topologia centrale di Sottoscrittore. Se l'applicazione non richiede risoluzione dei conflitti o filtri che forniscano a ogni sito remoto un set di dati univoco, provare a utilizzare la replica transazionale. Per ulteriori informazioni, vedere Integrazione di dati da più siti (server). |
Opzioni della replica di tipo merge rilevanti per questo scenario
La replica di tipo merge offre diverse opzioni in grado di soddisfare i requisiti descritti più indietro in questo argomento. Nell'elenco seguente sono riportati tutti i requisiti e le opzioni della replica di tipo merge che li soddisfano.
I dati vengono immessi e aggiornati in un sito centrale e in siti remoti.
La replica di tipo merge offre questa funzionalità senza dover impostare opzioni specifiche.
Gli utenti remoti devono essere in grado di eseguire aggiornamenti in modo indipendente, senza che sia necessaria una connessione al sito centrale.
La replica di tipo merge offre questa funzionalità senza dover impostare opzioni specifiche.
Poiché più utenti potrebbero aggiornare gli stessi dati in modo indipendente, possono verificarsi conflitti dei dati che devono essere gestiti.
La replica di tipo merge consente di rilevare i conflitti nonché risolvere i casi in cui sono previsti conflitti tra dati. È consigliabile progettare applicazioni in grado di evitare conflitti, ma laddove questo non sia possibile l'utente può selezionare il meccanismo predefinito di risoluzione dei conflitti (con una priorità maggiore) oppure utilizzare la risoluzione dei conflitti personalizzata. Per ulteriori informazioni, vedere Rilevamento e risoluzione di conflitti tra repliche di tipo merge.
Alcuni dati dovrebbero essere aggiornati solo nel sito centrale, ad esempio i dati delle tabelle dei prezzi dei prodotti.
La replica di tipo merge include articoli di solo download per le tabelle che devono essere aggiornate solo nel server di pubblicazione. Per ulteriori informazioni, vedere Ottimizzazione delle prestazioni della replica di tipo merge con gli articoli di solo download.
Gli utenti devono essere in grado di sincronizzare i dati su richiesta o in base a orari pianificati.
La replica offre due tipi di sottoscrizione, ovvero le sottoscrizioni push e le sottoscrizioni pull. Le sottoscrizioni pull sono più adatte per una sincronizzazione su richiesta. Per ulteriori informazioni sui tipi di sottoscrizione e sulla pianificazione della sincronizzazione, vedere Sottoscrizione delle pubblicazioni e Sincronizzazione dei dati.
L'applicazione deve stabilire l'intervallo di tempo massimo durante il quale un sito remoto può rimanere non sincronizzato.
La replica di tipo merge consente di impostare un periodo di scadenza della sottoscrizione per garantire che tutti i Sottoscrittori vengano sincronizzati entro un determinato periodo di tempo. Per ulteriori informazioni, vedere Scadenza e disattivazione delle sottoscrizioni.
Per alcune tabelle sono necessarie operazioni di filtro, in modo che ogni utente riceva dati diversi per una o più tabelle. Ogni venditore, ad esempio, può ricevere informazioni solo sui propri clienti.
La replica di tipo merge consente di filtrare colonne e righe. I filtri di riga possono essere statici o con parametri. Un filtro statico viene applicato solo quando viene creata un'applicazione e produce un set di dati. Un filtro con parametri viene applicato a ogni sincronizzazione di un Sottoscrittore e produce un set di dati differente per ogni Sottoscrittore. Tali filtri vengono spesso utilizzati per le applicazioni degli uffici regionali, sebbene sia possibile utilizzare anche i filtri statici. Per ulteriori informazioni, vedere Filtraggio dei dati pubblicati per la replica di tipo merge.
Alcuni dati devono essere gestiti come singola unità durante il trasferimento tra siti. Se, ad esempio, un utente remoto invia un ordine al sito centrale, è necessario eseguire il commit dell'intestazione dell'ordine prima dei dettagli dell'ordine.
La replica di tipo merge consente di specificare che un set di tabelle correlate venga elaborato come unità. Questa unità viene definita record logico. Per ulteriori informazioni, vedere Raggruppamento di modifiche alla righe correlate con record logici.
L'applicazione potrebbe richiedere l'esecuzione di logiche di business personalizzate al momento della sincronizzazione dei dati.
La replica di tipo merge consente di specificare il codice da eseguire durante la sincronizzazione. Tale codice può rispondere a un'ampia gamma di eventi e dispone di accesso ai dati sincronizzati. Per ulteriori informazioni, vedere Esecuzione di logiche di business durante la sincronizzazione di tipo merge.
L'applicazione potrebbe richiedere la sincronizzazione dei dati tramite Internet anziché tramite una connessione dedicata.
Se si utilizza (SQL Server Compact 3.5 SP1), i dati vengono sincronizzati tramite una connessione HTTP o HTTPS. Per le altre edizioni di SQL Server è possibile utilizzare la sincronizzazione Web che richiede HTTPS. Per ulteriori informazioni, vedere Sincronizzazione Web per la replica di tipo merge.
È possibile che l'azienda sia organizzata in modo che i dati fluiscano tramite uno o più layer intermedi tra il sito centrale e i siti remoti.
La replica di tipo merge può soddisfare questo requisito mediante la ripubblicazione, ovvero un approccio in cui un server di pubblicazione centrale pubblica i dati in uno o più Sottoscrittori, che a sua volta li pubblica in altri Sottoscrittori. Per ulteriori informazioni, vedere Ripubblicazione dei dati.
Passaggi per l'implementazione dello scenario
Per l'implementazione di questo scenario, è innanzitutto necessario creare una pubblicazione e le sottoscrizioni, quindi inizializzare ogni sottoscrizione. Fare clic sui collegamenti seguenti per ulteriori informazioni su ogni passaggio:
Dopo l'inizializzazione della sottoscrizione e l'attivazione del flusso di dati tra il server di pubblicazione e i Sottoscrittori, potrebbe essere utile consultare gli argomenti seguenti per raccogliere ulteriori informazioni sulle attività più comuni di amministrazione e monitoraggio: