Scambio di dati con utenti mobili
L'invio di dati agli utenti mobili e la ricezione di dati dagli stessi rappresentano una parte essenziale di numerose applicazioni. La maggior parte delle applicazioni che supportano gli utenti mobili rientra in una delle due categorie generali seguenti:
Gestione delle relazioni con i clienti (CRM) e automazione della forza vendita (SFA)
Ad esempio, un venditore può utilizzare un'applicazione SFA per immettere dati relativi agli ordini durante un incontro con un cliente. Tali dati verranno successivamente trasmessi a una posizione centrale, ad esempio la sede centrale o il data center dell'azienda.
Automazione del personale esterno (FFA)
Ad esempio, un lavoratore esterno (addetto ai recapiti, addetto alla manutenzione, ispettori e altre figure) può utilizzare un'applicazione FFA tramite un palmare per raccogliere e trasmettere dati da posizioni remote. Un addetto ai recapiti può immettere i dati relativi alla consegna di un pacco alle destinazioni del recapito e tali dati verranno successivamente trasmessi a una posizione centrale.
Entrambe le categorie di applicazioni richiedono funzionalità di replica simili. La principale differenza tra le applicazioni consiste nella possibilità che i dati vengano aggiornati da più di un utente. Questo aspetto è esaminato nella sezione "Requisiti comuni per questo scenario" in questo argomento.
Nelle figure seguenti vengono illustrati due diversi approcci al recapito dei dati agli utenti mobili. Uno prevede l'utilizzo di portatili e l'altro l'utilizzo di dispositivi che eseguono Microsoft SQL Server Compact 3.5 SP2. Il primo approccio viene generalmente utilizzato con applicazioni SFA e CRM, mentre il secondo viene adottato con applicazioni FFA. In ogni caso, entrambi gli approcci possono essere utilizzati per qualsiasi categoria di applicazione.
Nella prima figura viene illustrato uno scenario in cui un gruppo di utenti con computer portatili si connette direttamente a un sito centrale:
.gif "Replica dei dati dai venditori alla sede centrale")
Nella seconda figura viene illustrato uno scenario in cui gli utenti con dispositivi si connettono tramite server Microsoft Windows Internet Information Services (IIS) a un sito centrale. I server IIS sono necessari quando si utilizza SQL Server Compact 3.5 SP2.
.gif "Replica dei dati per gli addetti ai recapiti")
Esempi 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 AdventureWorks2008R2.
Adventure Works Cycles dispone di una vasta forza vendita che dedica una considerevole parte del proprio tempo all'interazione diretta con i principali clienti dell'azienda, rivenditori di biciclette indipendenti e in franchising. I team di venditori vengono assegnati a diverse regioni e ogni venditore in genere gestisce i propri clienti. I dati dei clienti possono tuttavia essere condivisi tra venditori e responsabili delle vendite. I venditori immettono i dati relativi agli ordini nei computer portatili e li trasmettono all'ufficio centrale al momento opportuno.
Adventure Works Cycles utilizza il sistema di distribuzione A-1 per i recapiti di pezzi di ricambio e biciclette. Gli addetti ai recapiti del sistema di distribuzione A-1 utilizzano tutti dispositivi che eseguono SQL Server Compact 3.5 SP2. Gli addetti ai recapiti immettono i dati dopo aver effettuato ogni recapito. I dati vengono quindi replicati all'ufficio centrale del sistema di distribuzione A-1 e vengono eliminati dal dispositivo. Tali dati vengono quindi resi disponibili in Adventure Works Cycles tramite la rete Extranet di un cliente.
Requisiti comuni per questo scenario
Le applicazioni CRM, SFA e FFA in genere presentano le caratteristiche seguenti, che devono essere prese in considerazione da una soluzione di replica appropriata:
La sincronizzazione dei dati deve poter essere programmata in modo da poter personalizzare un'applicazione o un computer portatile affinché includano la sincronizzazione senza che l'utente debba occuparsi della replica.
Nella maggior parte delle applicazioni mobili i dati possono essere immessi e aggiornati in un sito centrale e in siti remoti. Nelle applicazioni FFA la maggior parte dei dati viene immessa da siti remoti.
Gli utenti remoti immettono e aggiornano i dati mediante un computer portatile, un dispositivo o un Tablet PC.
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 remoti devono essere in grado di sincronizzare i dati su richiesta, anziché solo agli orari pianificati.
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 utente riceva dati diversi per una o più tabelle. Ad esempio, ogni venditore riceve informazioni sul contatto solo per i propri clienti.
Alcuni dati devono essere gestiti come singola unità durante il trasferimento tra i siti. Ad esempio, se 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 di rete remota VPN o IPSEC.
La principale differenza tra le applicazioni CRM e SFA e le applicazioni FFA in relazione alla replica riguarda la possibilità che i dati vengano aggiornati da più di un utente (gli aggiornamenti eseguiti da più di un utente possono determinare conflitti). La quantità di dati aggiornata dagli utenti dipende dal tipo di filtro applicato ai dati. Ad esempio, se i dati vengono filtrati in modo che gli utenti possano solo aggiornare determinati set di dati, non si verificano conflitti tra gli utenti:
Nelle applicazioni CRM e SFA i dati vengono spesso filtrati, ma alcuni dati vengono comunque aggiornati da più posizioni. Alcuni dati vengono aggiornati solo nelle sedi centrali e di questi una parte viene aggiornata da un solo utente remoto mentre altri dati vengono aggiornati da più utenti remoti. Nella figura seguente viene illustrata l'applicazione di filtri alle applicazioni CRM e SFA:
.gif "Filtraggio per applicazioni di automazione della forza vendita (SFA)")
Nella applicazioni FFA in genere i dati vengono raccolti principalmente sul campo e successivamente caricati nelle sedi centrali senza conflitti, poiché un singolo utente remoto aggiorna una determinata parte dei dati. Nella figura seguente viene illustrata l'applicazione di filtri alle applicazioni FFA:
.gif "Filtraggio per applicazioni di automazione del personale esterno (FFA)")
Tipo di replica da utilizzare per questo scenario
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. Nelle prime due figure sopra riportate 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). I computer portatili dei venditori e i dispositivi degli addetti ai recapiti rappresentano i Sottoscrittori della pubblicazione che ricevono 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 differenti esigenze applicative, ovvero la replica snapshot, transazionale e di tipo merge. Per ottenere i migliori risultati nell'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 sincronizzazione dei dati deve poter essere programmata.
La replica può essere programmata tramite stored procedure e oggetti RMO (Replication Management Objects). Gli oggetti RMO vengono generalmente utilizzati per le applicazioni mobili. Per ulteriori informazioni sulla programmazione della replica, vedere Guida per gli sviluppatori (replica) e Sales Orders Sample Scenario.
Nella maggior parte delle applicazioni mobili i dati possono essere immessi e aggiornati in un sito centrale e in siti remoti. Nelle applicazioni FFA la maggior parte dei dati viene immessa da siti remoti.
La replica di tipo merge offre questa funzionalità senza dover impostare opzioni specifiche.
Gli utenti remoti immettono e aggiornano i dati mediante un computer portatile, un dispositivo o un Tablet PC.
I computer portatili e i Tablet PC possono eseguire SQL Server Standard e altre edizioni, tra cui SQL Server Compact 3.5 SP2, mentre i dispositivi Pocket PC richiedono SQL Server Compact 3.5 SP2. La replica di tipo merge consente di creare pubblicazioni e sottoscrizioni che possono essere utilizzate da SQL Server Compact 3.5 SP2. Per ulteriori informazioni, vedere Replica di dati in SQL Server Compact.
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 il rilevamento e la risoluzione dei conflitti nei casi in cui sono previsti conflitti di dati. È consigliabile configurare le applicazioni in modo da evitare i conflitti. Tuttavia, quando non è possibile adottare questa soluzione, è necessario selezionare il meccanismo di risoluzione dei conflitti predefinito (la prima modifica viene confermata) o utilizzare un sistema di risoluzione dei conflitti personalizzato. 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 alcune tabelle sono necessarie operazioni di filtro, in modo che ogni utente riceva dati diversi per una o più tabelle. Ad esempio, ogni venditore può ricevere informazioni di contatto solo per i propri clienti.
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 CRM e SFA 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.
Alcuni dati devono essere gestiti come singola unità durante il trasferimento tra i siti. Ad esempio, se 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 debba essere elaborato come una singola 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. 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 SP2), 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 raccogliere ulteriori informazioni sulle attività più comuni di amministrazione e monitoraggio: