MobiLink: la tecnologia di sincronizzazione di Sybase SQL Anywhere

Sincronizzazione dati eterogenea da/verso SQL Anywhere, SQL Anywhere Ultralite, MS SQL Server, Oracle, IBM DB2, MySQL

Gli sviluppatori hanno a disposizione uno strumento grafico per implementare velocemente la sincronizzazione dei dati tra i database consolidati e remoti supportati

Amministrazione Plug-in Mobilink

– Synchronization model: File creato da un wizard per realizzare applicazioni Mobilink. – Model mode: File XML per gli adattamenti fatti sul synchronization model. – Deploy wizard…..

MobiLink Server Row Handling API

– Gli utenti desiderano sincronizzare direttamente verso sistemi aziendali diversi dai database consolidati supportati da Mobilink – Esempi di applicazioni aziendali: ERP System, Data Warehouse, Application Server, Legacy System, Non-Standard Relational Database, Messaging Server …

MobiLink: la tecnologia di sincronizzazione di Sybase SQL Anywhere

Sincronizzazione dati eterogenea da/verso SQL Anywhere, SQL Anywhere Ultralite, MS SQL Server, Oracle, IBM DB2, MySQL

Gli sviluppatori hanno a disposizione uno strumento grafico per implementare velocemente la sincronizzazione dei dati tra i database consolidati e remoti supportati

Amministrazione Plug-in Mobilink

– Synchronization model • File creato da un wizard per realizzare applicazioni Mobilink. – Model mode • File XML per gli adattamenti fatti sul synchronization model. – Deploy wizard • Wizard per applicare le modifiche contenute nel synchronization model ai database consolidato e remoto. – Update schema wizard (fa parte del Model mode) • Wizard per aggiornare gli schema dei database nel synchronization model – Admin model • Mobilink plug-in

– E’ possibile collegare simultaneamente diversi Mobilink Monitor allo stesso Mobilink Server • Visualizzazione dati nella “chart” • Dati visualizzabili per utente e in visuale compatta • “Session Properties” • Contiene una nuova “tab” per le statistiche

Mobilink Monitor, dati in visuale compatta

MobiLink Server Row Handling API

– Gli utenti desiderano sincronizzare direttamente verso sistemi aziendali diversi dai database consolidati supportati da Mobilink – Esempi di applicazioni aziendali: • ERP System • Data Warehouse • Application Server • Legacy System • Non-Standard Relational Database • Messaging Server

– Con le versioni precedenti di Mobilink occorreva uno “staging database” che inviava i dati verso l’applicazione aziendale. • Un altro database da amministrare • Dati duplicati • Dati potenzialmente sensibili da proteggere con misure di sicurezza complesse

– Script di sincronizzazione Mobilink scritti in C# o Java usati per fare l’upload dei dati verso il sistema aziendale e generare i dati in download per i client remoti – Un database consolidato è ancora richiesto ma solo per le tabelle di sistema di Mobilink e per le stored procedure necessarie per gestire la sincronizzazione. Nessun dato del sistema aziendale duplicato. – Il database consolidato di Mobilink può essere SQL Anywhere, Sybase ASE, MS SQL Server, Oracle o IBM DB2.

Named Parameter – Difficile gestire i parametri rappresentati da ? (secondo la convenzione ODBC) negli script di sincronizzazione • Ordine di utilizzo dei parametri prestabilito ed immutabile • Se si vuole usare un parametro, quello precedente, se esiste, deve essere usato – Username e last_download_timestamp referenziabili solo una volta in uno stesso script di sincronizzazione – Parametri esistenti non disponibili in tutti gli script di sincronizzazione (es. user authentication) – Non facile ottenere informazioni dai client per utilizzarle negli script sul server (ad esempio occorre creare e popolare una tabella)

– Named Parameter al posto dei ?  – Fornire  parametri di sistema (definiti dal server), di autenticazione (definiti dai client) e definiti dall’utente (lato server) che possono essere usati e riusati in ogni script di sincronizzazione SQL nell’ordine che si preferisce. – Tipi di named parameter: • System parameter (Remote ID per identificare univocamente un database remoto in un sistema Mobilink) • Row parameter (nome della colonna) • Authentication parameter • User defined parameter (cioè personalizzabili dall’utente) – Authentication parameter possono essere usati in qualunque evento (tranne begin_connection e end_connection) per passare informazioni dai client Mobilink. – Si possono ancora usare ? negli script ma non insieme ai named parameter (nello stesso script)>

Ottimizzazione Sincronizzazione Dati • Throughput, flessibilità del Mobilink server migliorati attraverso una nuova architettura interna. • Compressione dati • Supporto a IPv6 • Dal client SQL Anywhere connessioni persistenti consentono di mantenere una connessione al ML server – Importante specialmente quando connettersi ad una rete richiede molto tempo – Utile anche quando piccole quantità di dati sono sincronizzate poiché si può riusare la stessa connessione – Il client deve connettersi direttamente al ML server senza passare per il Redirector • Snapshot isolation  – Comportamento di default per SQL Anywhere 10 e MS Sql 2005 per download (opzionale per upload) – Elimina il problema del blocco dei download fino a che le transazioni sono completate sul consolidato

Cambiamenti ODBC • I seguenti driver ODBC sono stati testati per funzionare con Mobilink:

• iAnywhere Oracle Wire Protocol driver – Disponibile separatamente attraverso un download

• IBM DB2 ODBC native driver – Non esiste più un driver nativo iAnywhere per DB2

• Sybase ASE native Driver – Non esiste più un driver nativo iAnywhere per ASE

• SQL Anywhere può essere usato come database consolidato da Mobilink solo dopo aver eseguito uno script per la creazione delle tabelle di sistema Mobilink

• Synchronization ID  – Ogni sincronizzazione è ora identificata da un numero intero – Ogni MobiLink server mantiene il suo proprio synchronization ID. – Reset a 1 quando MobiLink riparte

• Supporto alle connessioni https dal redirector per alcuni web server al MobiLink Server

• Global script version  – Gli script inclusi in una global version sono automaticamente usati in tutte le sincronizzazioni a meno che per uno stesso evento non venga riscritto uno script e poi associato ad una versione particolare – Solo script a livello di connessione – Quando si usano versioni multiple si può evitare di duplicare gli script. • Pulizia e Reset delle tabelle di sistema di MobiLink (attraverso stored procedure) – Eliminazione informazioni relative a database obsoleti dalle tabelle di sistema di Mobilink. – Cancellazione di informazioni sullo stato delle sincronizzazioni non usate o non volute. – Reset delle informazioni sullo stato della sincronizzazione.

MobiLink Client File Transfer Utility

– Utenti vogliono fare il download di file sul dispositivo mobile – La soluzione attuale richiede di immagazzinare i file sui database remoto e consolidato (Mobilink file-based download)

– MLFileTransfer: strumento che permette il download di un file attraverso MobiLink – Disponibile come un utility (EXE) o metodo UltraLite – MobiLink prima cerca il file nella sotto-cartella ‘username’ e poi nella cartella di root (la cartella di root è specificata dal flag ‘-ftr’ di Mobilink) – Solo Download – Utile per fare l’aggiornamento di un’applicazione

File Transfer Utility

• Uso dell’eseguibile (EXE):

• MLFileTransfer [opzioni]

• Opzioni: •     -ap ,…  Parametri di autenticazione •     -dp path                   Il percorso di destinazione dove mettere il file •     -df filename  Il nome locale del file scaricato •     -f                               Download forzato, anche se il file è aggiornato •     -g                             Mostra i progressi del download. •     -p password        La password dell’utente Mobilink •     -r                              Abilita il recupero di un download parziale •     -u username        Nome utente Mobilink (indispensabile) •     -v version             Versione dello script •     -x protocol(opts)   Il protocollo usato (tcpip, tls, http o https) con    relative opzioni

Nuovo Remote ID

– MobiLink ora genera un ID unico chiamato remote ID la prima volta che un database remoto sincronizza. – Remote ID è creato automaticamente come un GUID ma può essere una qualunque stringa (deve essere unica). – Utile per identificare un database remoto quando un singolo utente MobiLink sincronizza database remoti multipli. – Nei database UltraLite, il remote ID è utile per consentire utenti MobiLink multipli di sincronizzare lo stesso database remoto. – Ogni script che accetta il MobiLink user name come  parametro ora accetta anche un parametro remote_id (named parameter).

Scripted Upload

• PROBLEMA – Utenti vogliono un maggiore controllo sui dati in upload da un database SQL Anywhere – Utenti possono non volere un file di log per risparmiare spazio sui client

• SOLUZIONE – Stored Procedure per bypassare dbmlsync che legge il file di transaction log per preparare lo stream di upload – Per ogni tabella nella pubblicazione, zero o più stored procedure definiscono le righe da inviare in upload (cioè Insert, Update, Delete) – Le stored procedure devono essere implementate dal programmatore – Stored procedure definiscono lo stream di upload restituendo i result set che contengono la lista delle righe da inserire, aggiornare o cancellare sul database consolidato.

Scripted Upload

 Se lo “Scripted Upload” viene implementato, il client SQL Anywhere, dbmlsync, non utilizza più il file di transaction log per costruire lo stream di upload.  Per molte applicazioni l’utilizzo del file di transaction log è il metodo consigliato.  Errori nell’implementazione degli Scripted Upload possono portare a perdita di dati.

Altre nuove funzionalità

• Nuove stored procedure (da implemetare) per la gestione degli errori – sp_hook_dbmlsync_all_error (per messaggi di errore di tutti i tipi) – sp_hook_dbmlsync_communication_error (per errori di comunicazione) – sp_hook_dbmlsync_misc_error (per errori non classificati di comunicazione o di database) – sp_hook_dbmlsync_sql_error (per errori di database che avvengono durante la sincronizzazione) • Pubblicazioni Download-only  – Pubblicazioni che fanno solo il download di dati. – Non usano un file di transaction log sul client. – Possono sovrascrivere righe già modificate ma mai inviate in upload (cosa che non si può fare con la download-only sync)

Server Initiated Synchronization SYNC Gateway

– Dispositivi connessi al desktop attraverso il cradle non possono essere sempre raggiunti via UDP

– SYNC Gateway per dispositivi che necessitano di iniziare una connessione IP con il Notifier per ricevere notifiche in push – Usa lo stesso protocollo usato per la sincronizzazione Mobilinik – Usa una connessione persistente – E’ il gateway usato di default (alternative: UDP e SMTP)

Server Initiated Sync: Configurazione attraverso wizard – Integrato nel nuovo plug-in MobiLink per Sybase Central – Configurazione semplificata, scelta delle tabelle da monitorare – Usa il download_cursor per determinare i dati da monitorare e in caso di una modifica parte la notifica verso i client – Disponibile per tabelle con download basato su timestamp

• Semplice API di sincronizzazione – API per i client per adattarsi all’ambiente di sincronizzazione MobiLink • Capaci di catturare cambiamenti locali • Capaci di portare cambiamenti centrali verso i client – Java e/o C/C++ – Scopi principali: • 1.  Utilizzo su piattaforme non supportate con un database  es. RIM Blackberry • 2.  Per applicazioni molto semplici che non necessitano di un RDBMS  es. Uso del datastore nativo di Palm • 3.  Per client dove c’è un database non supportato es. Access, SQL Server CE –  Probabilmente partiremo dall’ambiente J2ME per raggiungere scopo #1