Applicazioni POS (Point of Sale) consumer
Le applicazioni POS (Point of Sale) consumer includono tutte le applicazioni che i clienti possono trovare direttamente o indirettamente in un punto vendita, ad esempio, i terminali utilizzati dai cassieri, gli sportelli Bancomat e i chioschi multimediali disponibili all'interno dei negozi. Queste applicazioni consentono di raccogliere dati in siti remoti e di trasmetterli a una postazione centrale, come la sede centrale o un data center. Spesso queste applicazioni prevedono inizialmente la raccolta dei dati nel punto vendita e successivamente il caricamento dei dati nelle sedi centrali senza conflitti, poiché un singolo utente remoto, in genere un cliente o un addetto alle vendite, aggiorna una determinata parte dei dati.
Nella figura seguente viene illustrato uno scenario tipico che prevede il flusso dei dati in due direzioni tra un sito centrale e postazioni remote:
.gif "Replica dei dati dai punti vendita alla sede centrale")
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.
Molti dei punti vendita al dettaglio che distribuiscono prodotti di Adventure Works Cycles utilizzano sistemi POS che ricevono dati da e trasmettono dati a un sito centrale. In genere i dati relativi ai prezzi dei prodotti in sola lettura e all'inventario del magazzino vengono inviati al punto vendita al dettaglio ogni volta che questi dati vengono aggiornati. Le informazioni sugli acquisti dei clienti vengono trasmesse da ogni punto vendita al dettaglio al sito centrale.
Requisiti comuni per questo scenario
Le applicazioni POS in genere presentano le caratteristiche seguenti, che devono essere prese in considerazione da una soluzione di replica appropriata:
La maggior parte dei dati viene immessa e aggiornata nei siti remoti.
Gli utenti remoti devono essere in grado di eseguire aggiornamenti in modo indipendente, senza che sia necessaria una connessione al sito centrale.
I dati aggiornati in un sito remoto non vengono aggiornati negli altri siti, pertanto solitamente non si verificano conflitti.
Alcuni dati dovrebbero essere aggiornati solo nel sito centrale, ad esempio i dati delle tabelle di descrizione dei prodotti.
Gli utenti sincronizzano i dati a orari pianificati, ad esempio, alla fine della giornata lavorativa.
L'applicazione deve stabilire l'intervallo di tempo massimo per cui un sito remoto può rimanere non sincronizzato.
Per alcune tabelle sono necessarie operazioni di filtro, in modo che ogni negozio riceva dati diversi per una o più tabelle. Ad esempio, ogni negozio riceverà informazioni relative solo ai prodotti forniti.
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.
Nella figura seguente viene illustrato il filtro associato a questo scenario:
.gif "Filtraggio per applicazioni POS")
Tipo di replica da utilizzare per questo scenario
Microsoft In SQL Server viene utilizzata 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 sopra riportata il sito centrale è rappresentato dal server di pubblicazione. I dati disponibili nel sito centrale corrispondono alla pubblicazione e ogni tabella di dati costituisce un articolo (gli articoli possono inoltre essere altri oggetti di database, come le stored procedure). Ogni terminale POS è un Sottoscrittore della pubblicazione che riceve schemi e dati sotto forma di sottoscrizione. Per ulteriori informazioni sui componenti del sistema, vedere Panoramica del modello di pubblicazione della replica.
SQL Server supporta diversi tipi di replica per soddisfare diverse esigenze applicative, ovvero la replica snapshot, transazionale e di tipo merge. Per ottenere i migliori risultati, per l'implementazione di questo scenario è consigliabile utilizzare la replica di tipo merge, essendo 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.
Opzioni della replica di tipo merge applicabili a questo scenario
La replica di tipo merge prevede diverse opzioni per soddisfare i requisiti descritti più indietro in questo argomento. Nell'elenco seguente vengono riportati i singoli requisiti e le specifiche opzioni della replica di tipo merge.
La maggior parte dei dati viene immessa e aggiornata nei 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.
I dati aggiornati in un sito remoto non vengono aggiornati negli altri siti, pertanto solitamente non si verificano conflitti.
Nelle applicazioni POS i conflitti vengono spesso evitati in quanto i singoli utenti aggiornano una determinata parte dei dati. Poiché non si verificano sovrapposizioni dei dati tra gli utenti, è possibile ottimizzare le prestazioni mediante l'opzione relativa alle partizioni non sovrapposte. Per ulteriori informazioni, vedere la sezione relativa all'impostazione delle opzioni di partizionamento in Filtri di riga con parametri.
La replica di tipo merge consente il rilevamento e la risoluzione dei conflitti nei casi in cui sono previsti conflitti di dati. 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 offre un'opzione di solo download per gli articoli relativi alle tabelle da aggiornare esclusivamente nel server di pubblicazione. Per ulteriori informazioni, vedere Ottimizzazione delle prestazioni della replica di tipo merge con gli articoli di solo download.
Gli utenti remoti devono essere in grado di sincronizzare i dati su richiesta, anziché solo agli orari pianificati.
La replica prevede due tipi di sottoscrizione: push e pull. Le sottoscrizioni pull sono più adatte per la 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 per cui 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 eseguano la sincronizzazione entro un determinato intervallo di tempo. Per ulteriori informazioni, vedere Scadenza e disattivazione delle sottoscrizioni.
Per la maggior parte delle tabelle sono necessarie operazioni di filtro, in modo che ogni utente riceva dati diversi per una o più tabelle.
La replica di tipo merge consente di filtrare le colonne e le righe. I filtri di righe possono essere statici o con parametri. I filtri statici vengono applicati solo al momento della creazione di una pubblicazione e determinano un unico set di dati. I filtri con parametri vengono applicati ogni volta che un Sottoscrittore esegue la sincronizzazione e determinano diversi set di dati per ogni Sottoscrittore. Sebbene le applicazioni POS utilizzino spesso i filtri con parametri, possono utilizzare anche filtri statici. Per ulteriori informazioni, vedere Filtraggio dei dati pubblicati per la replica di tipo merge.
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. Questo codice può gestire un'ampia gamma di eventi e ha accesso ai dati in corso di sincronizzazione. 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 tramite il Web, che richiede la connessione HTTPS. Per ulteriori informazioni, vedere Sincronizzazione Web per la replica di tipo merge.
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 ulteriori informazioni sulle attività più comuni di amministrazione e monitoraggio: