Introduzione

Per un moderno database lavorare in multiutenza è diventato un requisito obbligatorio, ed in effetti disporre di una base dati comune consultabile da tutti gli utenti di una stessa equipe è un istinto naturale, direi primordiale.

Da questo punto di vista la piattaforma che FileMaker Inc. propone è [language]particolarmente avanzata[/language] , tanto da coprire l'utenza di rete LAN, WAN, l'utenza web e quella mobile. Abbiamo quindi una lunga serie di opzioni, ognuna con i suoi pro e i suoi contro.

Nella prima parte dell'articolo abbiamo visto quali sono le opzioni di condivisione dati disponibili, e come funziona il processo di sincronizzazione con FileMaker Syncro. Al termine di questo articolo troverete allegato FMGo Syncro, nella sua ultima versione e scaricabile in modo totalmente gratuito.

Quali sono i passaggi successivi?

Ricostruzione dati

Abbiamo visto che una volta avvenuto il passaggio dei dati abbiamo nel file centrale una serie di record nella tabella Importazione, uno per transazione. Una procedura nel file centrale ci consente di riportare il contenuto della transazione nelle tabelle e campi di appartenenza.

In sostanza si tratta di smontare quanto creato in precedenza dalla procedura di passaggio dati. Si può scegliere come lanciare la procedura di ricostruzione dei dati, manualmente, su un client con uno script onTimer (cosiddetto “robot”), o con una procedura schedulata da FM server. Utilizzando FileMaker Server 13 possiamo anche chiamare direttamente la procedura centrale usando la funzione Esegui script sul server.

Vediamo la procedura in dettaglio.

    • Lo script parte dal record di Importazioni ed imposta alcune variabili con i nomi delle tabelle da processare;
    • carica nella variabile $testo il contenuto del campo testoINPUT;
    • si inizia con la processazione della tabella master:

Set Variable [ $dati; Value:EstraiXML ( $testo ; $nome_master ) ]

Go to Layout [ “Preventivi” (Preventivi) ]

New Record/Request
Loop

Set Variable [ $str; Value:GetValue ( $dati ; 1 ) ] If [ Left ( $str ; 1 ) = "<" ]

Set Variable [ $field; Value:Left ( $str ; Position ( $str ; ">" ; 1 ; 1 ) ) ]

Set Variable [ $field; Value:Substitute (Substitute ($field ; "<" ; "") ; ">" ; "") ]

// ricava il nome del campo

If [ GetValue ( Substitute (  FieldType ( Get( FileName) ; Get ( LayoutTableName ) & "::" & $field ) ; " " ;  "¶");2) ="container"]
Set Field By Name [ $nome_master & "::" & $field; Base64Decode ( EstraiXML  ( $dati ; $field ) ; "img.png") ]

Else
Set Field By Name [ $nome_master & "::" & $field; EstraiXML ( $dati ; $field ) ]

End If
Set Variable [ $dati; Value:Substitute ( $dati ; PassaXML ( $field ; EstraiXML ( $dati ;  $field ) ) ; "" ) ]

Set Variable [ $dati; Value:MiddleValues ( $dati ; 2 ; 99999999999 ) ]

Exit Loop If [ ValueCount ( $dati) < 1 ]

End Loop


    • Si procede con la processazione della tabella correlata

Set Variable [ $dati; Value:EstraiXML ( $testo ; $nome_correlata ) ]

Set Variable [ $n; Value:1 ]
Loop

//loop esterno, uno per riga

Set Variable [ $subdato; Value:EstraiXML ( $dati ; "riga" & $n ) ]

Exit Loop If [ IsEmpty ($subdato) ]
Go to Layout [ “RighePreventivo” (RighePreventivo) ]
New Record/Request

Loop

//loop interno, uno per campo
Set Variable [ $str; Value:GetValue ( $subdato ; 1 ) ] If [ Left ( $str ; 1 ) = "<" ]

Set Variable [ $field; Value:Substitute (Substitute ($field ; "<" ; "") ; ">" ; "") ]

If [ tipo campo ="container"]

Set Field By Name [ $nome_correlata & "::" & $field; Base64Decode ( EstraiXML ( $subdato ; $field ) ; "img.png") ]

Else
Set Field By Name [ $nome_correlata & "::" & $field; EstraiXML  ( $subdato ; $field ) ]

End If
Set Variable [ $subdato; Value:Substitute ( $subdato ; PassaXML ( $field ;  EstraiXML ( $subdato ; $field ) ) ; "" ) ]

Set Variable [ $subdato; Value:MiddleValues ( $subdato ; 2 ; 999999 ) ]

Exit Loop If [ ValueCount ( $subdato ) < 1 ]

End Loop
Commit Records/Requests Set Variable [ $n; Value:$n + 1 ]

End Loop


FMGo Syncro: i pro

Cerchiamo di analizzare adesso quali possono essere i punti di forza di FMGo Syncro, e quali i limiti o le sue debolezze.

Tra i punti di forza possiamo sicuramente annoverare la completa transazionalità della procedura. La procedura utilizzata da FMGo Syncro rispetta pienamente i canoni della transazionalità, facendo sì che ogni insieme di dati (Preventivo e relative righe) venga riunito in un unico blocco dati, che comprende quindi l’interezza della transazione.

Il passaggio dei dati avviene verso una tabella d’appoggio creando un nuovo record per ogni transazione, evitando quindi ogni problematica relativa al record locking derivante dalla scrittura dei dati in tabella utilizzate da altri utenti.

La procedura esegue un error trapping estremo, catturando l’errore sia relativamente alla creazione del record che alla scrittura dei dati: solo in presenza di zero errori il record viene considerato trasferito.

La procedura utilizza lo schema di privilegi e permessi nativi di FileMaker, garantendo quindi un elevato livello di sicurezza. È possibile criptare il traffico utilizzando l’opzione presente in FileMaker Server.

Un altro grosso pregio di FMGo Syncro è la portabilità della procedura: molte procedure che si trovano sul web sono elegantissime, modulari, estremamente curate e ben fatte ma quasi impossibili da replicare. La procedura utilizzata da FMGo Syncro invece è semplice da applicare ai propri files. La parte di configurazione dei files è modesta, l'impostazione del layout di raccolta dati è banale, ed è sufficiente ripuntare pochi step degli script di raccolta dati e di ricostruzione dei dati perchè funzionino.

Nei file allegati all'articolo troverete anche una versione parametrica delle procedure che evita anche le modifiche agli script

In maniera analoga la linearità della procedura le conferisce una flessibilità estrema. La parte “core” della procedura è costituita dalla costruzione di blocchi di testo del tipo <nome campo> contenuto</nome campo>. Questo avviene in maniera “astratta” grazie a funzioni [Get ( ActiveFieldName )  e Get ( ActiveFieldContents )] che utilizzano il nome ed il contenuto dei campi presenti in un formato specifico, senza mai far riferimento a campi dichiarati esplicitamente.

Ne consegue che basta mettere o togliere campi dal layout utilizzato per la raccolta dei dati nel file remoto per far sì che vengano trasferiti o meno. Questo vale sia per la tabella master che per quella/e correlata.

A sua volta questa flessibilità consente una semplice scalabilità della procedura.

Cosa succede se la nostra base dati è più complessa, ed abbiamo più tabelle correlate?

1. Si aggiunge un portale della nuova tabella correlata al formato di passaggio dati; lo script di raccolta dati NON va modificato.

2. Si modifica lo script di ricostruzione dati per scrivere i dati nella nuova tabella correlata.

Cosa succede se la nostra base dati è più complessa, ed abbiamo più tabelle master con le relative tabelle correlate?

1. Si duplica il formato di passaggio dati puntandolo alla nuova tabella master e relative correlate;

2. si duplica lo script di raccolta dati puntandolo al nuovo layout (1 step).

3. si duplica lo script di ricostruzione dati per puntare le nuove tabelle.

Nei file allegati all'articolo troverete anche una versione parametrica delle procedure che evita anche i punti 2 e 3.

FMGo Syncro: i contro

Quali sono invece le debolezze di FMGo Syncro? Un piccolo punto di rigidità c'è: la procedura prevede che i nomi dei campi siano gli stessi nel file remoto e nel file centrale.

Tecnicamente si tratta di un limite, ma lo considero solo teorico: in pratica non si vede perchè lo stesso campo debba avere 2 nomi diversi. Volendo il limite sarebbe superabile con una tabella di conversione in cui si indicano le corrispondenze tra campo del file remoto e campo del file centrale, ma continuo a pensare che si tratti di energie sprecate.

Una debolezza vera sta nel fatto che la procedura non utilizza un file intermedio per il passaggio dei dati. Molte delle procedure di sincronizzazione utilizzano un file di appoggio, sul device remoto e sulla macchina centrale. Questi file contengono i riferimenti alle tabelle dati originali, e vengono usati per consentire di chiudere ogni connessione coi files centrali lasciando aperto il file remoto.

Ma allora perchè non utilizzare un file intermedio per il passaggio dei dati?

La risposta è che il non utilizzo di un file intermedio aiuta a mantenere le cose più semplici possibili, a fronte di una utilità tutto sommato marginale (resta aperto il file centrale sul device remoto). È quindi non tanto un limite quanto una scelta, deliberata, di barattare praticità (tanta) contro eleganza (poca).

Se vogliamo argomentare con fare elegante possiamo citare alcuni principi:

Principio KISS:

Keep It Stupid Simple (è il principio alla base del successo dell’iPod).

Legge di Pareto:

Col 20% di sforzo si ottengono l’80% dei risultati, per ottenere il restante 20% di risultati occorre l’80% dello sforzo.

Developers’ motto:

The professional has to know the rules, and when to break them.

Nanni Moretti: 

Pensare in modo diverso può essere rischioso, ma offre un grande vantaggio: quello di appartenere a una minoranza.

Conclusioni

L’utilità del lavoro in mobilità sta crescendo esponenzialmente, e con essa la necessità di procedure di sincronizzazione tra file.

La piattaforma FileMaker fornisce gli strumenti per dare risposta a queste necessità, e le funzioni di FileMaker ci consentono di creare ottime procedure di sincronizzazione.

FMGo Syncro costituisce un sistema robusto, flessibile e scalabile che possiamo applicare rapidamente ai nostri file.

Clicca qui per scaricare FMGo Syncro, nella sua ultima versione e scaricabile in modo totalmente gratuito.

Per scaricare il file è necessario essere utenti registrati a FileMaker Guru. Se non lo hai ancora fatto, registrati gratuitamente qui.

Qual è il tuo metodo per sincronizzare un database? Raccontaci la tua soluzione e condividi le tue idee con gli altri Guru: scopri la comunità Filemaker su Guru Corner!

3 Commenti

  1. salve io uso da anni file maker 1998, con il quale gestisco mie ordini offerte anagrafica da anni

    con filemaker 10 pro ed goipad 11.02 , che uso su ipad iphone .
    i file storici degli anni sono su dropbox , che richiamo via limea dati, tutto benissimo, salvo non essere mai riuscito a sincronizzare iphone ed ipad e dropbox .... e a sua volta il computer fisso in ufficio window

    nelle versione nuove filemaker esiste la possiiblità di sincronizzare i file su server tipo dropbox e aèparati portatili iphone ipad ??

    grazie per suo aiuto

    francesco camana
    6-9-15

    • Non ci sono grosse novità
      La "sincronizzazione" che si ottiene con Dropbox è sempre dello stesso tipo: si ha un file su un disco remoto, cui si può accedere, un utente per volta
      Non esistono routine di sincronizzazione reale tra 2 files con dati differenti; va tutto fatto a mano, con importazioni o con la metodica descritta nell'articolo

      g. pupita

    • il problema non è tanto lato FileMaker quanto lato iOs. in sintesi per come funziona iOS salvo che per la applicazioni Apple non è possibile far interagire el applicazioni in maniera dinamica, dato che ognuna ha la sua propria sandbox.

      .g.

LASCIA UN COMMENTO

Please enter your comment!
Please enter your name here