4DSYNC - Synchroniser un client HTTP avec 4D Server v12Par Christophe KEROMEN, Cabinet de Consultants CKTINote technique 4D-201012-28-FR

Version 1 - Date 1 décembre 2010

RésuméLa synchronisationdebasesdedonnéesestunedesnouvellesfonctionnalitésalléchantesapparuesavec4Dv12. La version12.1apportela possibilitéà tout client HTTP desynchroniserdesdonnéesavecun serveur4D au travers d’Internet.

Nousallonsdécrirecettenouvellefonctionnalité,puis la mettreen oeuvredansun client AdobeAIR ce quinouspermettrade réaliseruneapplicationstand-alonemulti plateforme(Mac-Win-Linux) et mêmetournantsur les mobiles (Android, Blackberry, iPhone...) et synchronisant ses données avec 4D.

4D Notes techniquesCopyright © 1985-2010 4D SAS - Tous droits réservés

Tous les efforts ont été faits pour que le contenu de cette note technique présente le maximum de fiabilité possible.Néanmoins, les différents éléments composant cette note technique, et le cas échéant, le code, sont fournis sans garantie d'aucune sorte.L'auteur et 4D SAS déclinent donc toute responsabilité quant à l'utilisation qui pourrait être faite de ces éléments, tant à l'égard de leurs utilisateurs que des tiers.

Lesinformationscontenuesdanscedocumentpeuventfairel'objetdemodificationssanspréaviset nesauraientenaucunemanièreengager4D SAS. La fournituredulogicieldécritdanscedocumentestrégieparun octroi delicencedont lestermessontprécisésparailleurs dansla licenceélectroniquefigurant sur le supportduLogicieletdelaDocumentationafférente.Le logiciel et sadocumentationnepeuventêtreutilisés,copiésou reproduitssur quelquesupportque ce soit et dequelque manière que ce soit, que conformément aux termes de cette licence.Aucunepartiede ce documentne peut être reproduiteou recopiéede quelquemanièreque ce soit, électroniqueou mécanique,y compris par photocopie,enregistrement,archivageoutoutautreprocédédestockage,detraitementet derécupérationd'informations,pourd'autresbuts que l'usagepersonnelde l'acheteur,et ce exclusivement aux conditions contractuelles, sans la permission explicite de 4D SAS.4D, 4ème Dimension, 4D Server, ainsi que tous les logos sont des marques enregistrées de 4D SAS.Windows,Windows NT, Vista, Windows 7, Win 32s et Microsoft sont des marques enregistrées de Microsoft Corporation.ICU © Copyright 1995-2010 International Business Machines Corporation and others - iODBC © Copyright 1995-2006: Open Linck Software - LibZip ©Copyright 2006 Dieter Baron and Thomas Klausner. OpenSSL : OpenSSL Project for use in the OpenSSL Toolkit. - SYNAPSE © Copyright 1994-2010 SynapseDevelopement - XALAN © Copyright 2010 4D SAS/ XERCES © Copyright 2010 4D SAS - zLib © Copyright 1995-2010 Jean-Loup Gailly and Mark Adler.Apple,Macintosh,QuickTimesontdesmarquesenregistréesou desnomscommerciauxdeApple Computer,Inc.Mac2Win SoftwareCopyright © 1990-2002estun produit de Altura Software,Inc.

Tous les autres noms de produits ou appellations sont des marques déposées ou des noms commerciaux appartenant à leurs propriétaires respectifs.

1 / 23

Synchroniser un client HTTP avec 4D Server v12

La synchronisation de bases de données est une des nouvellesfonctionnalités alléchantes apparues avec 4Dv12. La version 12.1 apporte la possibilité à tout client HTTP de synchroniser des données avec un serveur4D au travers d’Internet.

Nous allons décrire cette nouvelle fonctionnalité, puis lamettre en oeuvre dans un client Adobe AIR ce quinous permettra de réaliser une applicationstand-alone multi plateforme (Mac-Win-Linux) et même tournantsur les mobiles (Android, Blackberry, iPhone...) et synchronisant ses données avec 4D.

Introduction

4D v12 introduit la réplication de données entre deux bases 4D avec une économie de moyens étonnante. Lasynchronisation de données dans 4D s’effectue table par table :

• une case à cocher dans les propriétés de la table ciblée afinque le moteur de base de données journaliseles modifications apportées aux enregistrements de cette table

• une commande SQL, avec quelques paramètres (!), pour déclencher la réplication des données d’unetable :

REPLICATE liste_répliquéeFROM ref_table[WHERE critère_recherche][LIMIT {nombre_entier | ref_langage_4d}] [OFFSET {nombre_entier | ref_langage_4d}]FOR REMOTE [STAMP] {nombre_entier | ref_langage_4d}[, LOCAL [STAMP] {nombre_entier | ref_langage_4d}][{REMOTE OVER LOCAL | LOCAL OVER REMOTE}][LATEST REMOTE [STAMP] ref_langage_4d[, LATEST LOCAL [STAMP] ref_langage_4d]]INTO {liste_cible | ref_table(nom_sql_1;...;nom_sql_N)}

http://doc.4d.com/4D-Reference-SQL-12.1/Commandes-SQL/REPLICATE.300-494446.fr.html

Et c’est tout ! Pas de modification du schéma de données, pas de code à écrire dans les triggers. Simple,efficace.

Fonctionnement

Le principe de fonctionnement est simple. 4D journalise lesactions effectuées sur les enregistrements selondeux catégories : update (création ou modification) et delete (suppression). Il enregistre l’action, la cléprimaire permettant d’identifier l’enregistrement de manière unique et un compteur (stamp) s’incrémentant àchaque action. Aucune autre donnée n’est stockée, en particulier 4D ne conserve pas un historique de lavaleur de l’enregistrement au moment de l’action.A noter que c’est toujours le poste local qui demande au serveur 4D de lui envoyer les données de réplication.

2 / 23

Lors d’une demande de réplication, 4D envoie la liste des actions et la valeur courante des enregistrementsimpactés et non supprimés. Le passage du stamp (compteur) permet de demander à 4D de ne recevoir que lesactions qui se sont produites depuis la dernière réplication :

• première réplication, 4D envoie au poste local toutes les actions enregistrées et la valeur du dernierstamp : X ;

• réplication suivante, le poste local demande à 4D toutes les actions enregistrées depuis le dernier stampX et reçoit la valeur du dernier stamp X2 ;

• etc.

Plateformes Web

4D version 12.1 ouvre l’accès à la réplication de données 4D àn’importe quel programme capable d’accéderau Web et d’envoyer une requête HTTP en manipulant des données au format JSON (JavaScript ObjectNotation : www.json.org/) :

• application desktop 4D ou non 4D, par exemple sur un portable, fonctionnant en mode déconnecté parrapport au serveur ;

• application native sur un smartphone ;• webApp sur desktop ou mobile.

Base exemple 4D

Nous utilisons la base exemple 'Synchronize_Directory' fournie avec 4D v12 pour la mise en application dela réplication HTTP.

Préparation de la réplicationDans notre exemple, la table concernée est[SUBSIDIARY_NC] . Pour que la réplication fonctionne, il fautdans un premier temps 'Activer la réplication'. Cela signifie donner les moyens au moteur de base de donnéesde 4D de journaliser les modifications effectuées sur les enregistrements. Activer la réplication ne provoquepas de réplication, celle-ci s’effectuant toujours sur demande du poste local vers le serveur.

Clé primaireLa première étape consiste à définir une clé primaire pour la table. Dans notre cas, il s’agit du champ PKey.

Il est ensuite possible dans les propriétés de la table de cocher 'Activer réplication'.

3 / 23

Dorénavant, toute modification sur un enregistrement de latable [SUBSIDIARY_NC] donnera lieu à uneécriture dans le fichier externe{nomDeLabase}.4DSyncDatadont la structure est décrite dans le fichier{nomDeLabase}.4DSyncHeader.

Cette structure externe enregistrant les actions sur les enregistrements n’est ni plus ni moins qu’une base 4D :

• .4DSyncHeader <=> .4DB• .4DSyncData <=> .4DD

Déclenchement de la synchronisation

Une fois le cadre de suivi des actions sur les enregistrements mis en place, nous pouvons déclencher desréplications. Dans le cas de réplications entre moteurs 4D, cela s’effectue au moyen du langage SQL.

4 / 23

Voici le code de synchronisation utilisé dans notre base exemple 4D :

En version française :

// Login from TX to NC

SQL LOGIN("IP:127.0.0.1";"user";"password";*)

Si (OK=1) // Code executé sur le site Texan

Synchronize_Get_Pars (->$NC_Stamp_l;->$LocalStamp_l)

Debut SQLSYNCHRONIZE SUBSIDIARY_TX (FName,LName,Salary,Male)WITH SUBSIDIARY_NC ( FName,LName,Salary,Male)

FOR REMOTE STAMP :$NC_Stamp_l , LOCAL STAMP :$LocalStamp_l

LOCAL OVER REMOTE

LATEST REMOTE STAMP :$Latest_NC_Stamp_l ,LATEST LOCAL STAMP :$LatestLocalStamp_l

Fin SQL

Si (OK=1)Synchronize_Set_Pars (->$Latest_NC_Stamp_l;->$LatestLocalStamp_l)

5 / 23

Fin de si

// Pour affichage des infosNC_Stamp_l:=$Latest_NC_Stamp_lTX_Stamp_l:=$LatestLocalStamp_l

Fin de si

SQL LOGOUT

Il ne rentre pas dans le cadre de cette note de décrire les commandesSYNCHRONIZE et REPLICATE , sereporter à la documentation pour cela...

STAMPRappelons simplement que tout le mécanisme de la réplication est basé sur la notion deSTAMP. Lors d’uneréplication via HTTP, la réplication sera demandée par une requête sur une URL et non une commande SQL,mais la notion de STAMP sera commune afin de déterminer les enregistrements à récupérer.

url 4DSYNCVoyons comment demander à 4D de nous fournir les données de réplication au travers d’http.

iSort, le précurseur4D a d’abord ouvert son mécanisme de réplication vers iSort, application iOS de gestion de fichiers :

http://www.iphonecode.fr/

Vous pouvez trouver une description de cette fonctionnalité ainsi qu'une démo en ligne sur le site de 4D :

http://www.4d.com/fr/solutions/internet/iapps.html

A consulter également la FAQ : http://www.4d.com/fr/solutions/internet/iapps/faq.html . iSort fonctionne sur HTTPS en mode SSL, avec en option une authentification de type Digest. De plus, lesconnexions s'appuient sur le système de mots de passe intégré dans 4D. Mais le format utilisé pour véhiculerles données entre iSort et 4D est un format binaire propriétaire.

Extension du domaine de la lutte

Dans un second temps, avec la sortie de la version 12.1, 4D a publié un format ouvert pour le protocole et leformat des données échangées via HTTP.http://doc.4d.com/4D-Langage-12.1/Serveur-Web/URLs-et-actions-de-formulaires.300-479663.fr.html

Il est maintenant possible à tout client capable d’émettre une requête HTTP de bénéficier du mécanisme deréplication. 4D propose pour cela l’url magique4DSYNC. Les données échangées sont formatées en JSON.Le client peut recevoir ou envoyer des données.

6 / 23

Extrait de la doc :L'URL 4DSYNC/ peut être utilisé en méthodeGET afin de récupérer les données de la base 4D ou enméthode POST afin de mettre à jour les données de la base 4D. Attention : contrairement à la réplication binaire utilisée par iSort, la réplication via HTTP en 12.1 nesupporte pas les images et d’une manière générale les données binaires.

Requêtes HTTP

Expérimentons un peu en envoyant directement depuis un navigateur des requêtes HTTP vers 4D. Pour cela,nous commençons par activer le serveur HTTP de la base 4D dansle dialogue Développement/Propriétés dela base/Web :

Nous pouvons maintenant envoyer des requêtes vers notre base 4D au travers d’HTTP. Nous utilisonsFirefox et son extension restclient : https://addons.mozilla.org/fr/firefox/addon/9780/

7 / 23

Les requêtes sur le catalogue de la base de données

Nous commençons par lister les requêtes permettant d’obtenir des informations sur les tables répliquables etles champs de ces tables.

Liste des tables répliquables : GET /4DSYNC/$catalog

Ce qui donne dans notre exemple:http://localhost/4DSYNC/$catalog. La réponse retournée par 4D est lasuivante : SUBSIDIARY_TX 3 SUBSIDIARY_NC 3

• En effet, la table[SUBSIDIARY_TX] est également disponible pour la réplication, mais nous ne laprenons pas en compte dans cette note.

• 3 représente ici le nombre d’enregistrements courants de la table. Le format de données est ici une simple sérialisation de la réponse en texte.

Description de la structure d’une table : GET /4DSYNC/$catalog/NomTable

Maintenant que nous disposons de la liste des tables répliquables, nous pouvons demander à recevoir lastructure d’une de ces tables. Dans notre cas, afin de travailler sur la table[SUBSIDIARY_NC] , la requêteest : http://localhost/4DSYNC/$catalog/SUBSIDIARY_NC La réponse retournée, formatée en XML, est la suivante :

<SUBSIDIARY_NC name="SUBSIDIARY_NC" uuid="BB7D230A3662DE439D1198C850F47929" id="3"keep_record_stamps="true" keep_record_sync_info="true"> <field name="PKey" uuid="19CEDF22BCCE3B4581ADE56D783ACB90" type="10" limiting_length="255" unique="true"not_null="true" never_null="true" id="1" visible="true"/> <field name="FName" uuid="ABBF6FC96C3E3949B449FA768CA272A6" type="10" limiting_length="255"never_null="true" id="2" visible="true"/> <field name="LName" uuid="779F54CBF1167E4B83A7ED2381839708" type="10" limiting_length="255"never_null="true" id="3" visible="true"/> <field name="Salary" uuid="10742A4DDAD7844B9F3975D4FC44DFD2" type="6" never_null="true" id="4"visible="true"/> <field name="Male" uuid="970BEE068895244C98EB4C7770B888C2" type="1" never_null="true" id="5" visible="true"/> <primary_key field_name="PKey" field_uuid="19CEDF22BCCE3B4581ADE56D783ACB90"/> <table_extra> <editor_table_info displayable_fields_count="5">

8 / 23

<color red="168" green="206" blue="226" alpha="255"/> <coordinates left="0" top="5" width="174" height="155"/> </editor_table_info> </table_extra>

</SUBSIDIARY_NC>

On y retrouve un simple extrait de la structure exportée en XML, comme on peut l’obtenir en Structure avecle menu 'Fichier/Exporter/Définition de structure vers le fichier XML...' :

Ci-dessous, l’export complet de la structure au format XML et, mis en évidence, la partie concernant la table[SUBSIDIARY_NC] :

9 / 23

Les requêtes de réplication

GET /4DSYNC/tableName/fieldName Exemple:

Si l’on envoie la requête suivante à 4D :http://localhost/4DSYNC/SUBSIDIARY_NC/PKey,FName,LName,Salary,Male

10 / 23

Nous recevons de 4D des caractères un peu bizarres ! Notre requête est unGET qui ne transporte pas de données et ne modifie pas l’état de laressource demandéecôté serveur. L’opération effectuée est donc une réplication des données du serveur vers le client. Sans précision du format désiré pour les données, celles-cisont retournées au format binaire utilisé par iSort.Pour obtenir des données formatées en json, il faut spécifier $format=json dans la query string. Réitérons notre requête en la complétant par le format souhaité pour les données retournées :http://localhost/4DSYNC/SUBSIDIARY_NC/PKey,FName,LName,Salary,Male?$format=json L’extension de Firefox prenant en charge le JSON, le résultat est alors automatiquement mis en forme :

Voici les données reçues sans mise en forme :

11 / 23

{"__SENT":3,"__LATEST_STAMP":"3","__ACTIONS":[{"__ACTION":"update","__PRIMARY_KEY_COUNT":1,"__PRIMARY_KEY":{"PKey":"NC00001"},"__STAMP":1,"__TIMESTAMP":"Sun, 00 0000 00:00:00GMT","__FIELD_COUNT":5,"__VALUES":{"PKey":"NC00001","FName":"Rosanna","LName":"Shakespeare(nc)","Salary":17293,"Male":true}},{"__ACTION":"update","__PRIMARY_KEY_COUNT":1,"__PRIMARY_KEY":{"PKey":"NC00002"},"__STAMP":2,"__TIMESTAMP":"Sun, 00 0000 00:00:00GMT","__FIELD_COUNT":5,"__VALUES":{"PKey":"NC00002","FName":"William","LName":"Lincoln(nc)","Salary":22431,"Male":false}},{"__ACTION":"update","__PRIMARY_KEY_COUNT":1,"__PRIMARY_KEY":{"PKey":"NC00003"},"__STAMP":3,"__TIMESTAMP":"Sun, 00 0000 00:00:00GMT","__FIELD_COUNT":5,"__VALUES":{"PKey":"NC00003","FName":"Lionel","LName":"Arquette(nc)","Salary":23858,"Male":false}}]}

Un éditeur de texte évolué comme TextMate sur MacOS permet deformater ces données à l’écran pourobtenir une représentation plus compréhensible que nous commentons dans le schéma ci-dessous :

Méta-Données

Nous constatons qu’en dehors des valeurs des champs des enregistrements, des informations supplémentairesnous sont fournies. Elles sont qualifiées de méta-données.

• "__SENT" : nombre d’enregistrements contenus dans la réponse. • "__LATEST_STAMP" : le dernier stamp retourné dans cette requête. Il est de la responsabilité du

client de conserver cette valeur afin de la fournir en paramètre à 4D lors de prochaine réplication. Ils’agit d’une chaine et non d’un entier.

• "__ACTIONS" peut prendre la valeur update ou delete. Dans les deux cas, l’identification del’enregistrement impacté s’effectue par le moyen de la clé primaire. Comme celle-ci peut être

12 / 23

composite (composée de plusieurs champs), elle est fourniesous forme d’un objet pour lequel__PRIMARY_KEY_COUNT indique le nombre d’éléments composants.

Restreindre les enregistrements

Suite à la requête précédente, nous recevons tous les enregistrements à répliquer. Dans le cas où noussouhaitons répliquer uniquement les enregistrements non répliqués depuis la dernière réplication, il fautpasser l’information équivalente au paramètreLATEST REMOTE STAMP de la commande SQLREPLICATE . Cela s’effectue en rajoutant le mot-clé $stamp dans la querystring. Renvoyons notre requête en précisant ce paramètre supplémentaire :http://localhost/4DSYNC/SUBSIDIARY_NC/PKey,FName,LName,Salary,Male?$format=json&$stamp=2 Nous obtenons le résultat suivant :

Effectuer une réplication du client local vers le serveur

Dans ce cas, nous envoyons au serveur une requête similaire,mais sous forme d’unPOST contenant desdonnées formatées en JSON.

Création

Premier exemple, nous créons un nouvel enregistrement localement et nous le répliquons vers le serveur :{ "__SENT":1, "__LATEST_STAMP":"1", "__ACTIONS": [ { "__ACTION":"update", "__PRIMARY_KEY_COUNT":1, "__PRIMARY_KEY": { "PKey":"MB00005" }, "__STAMP":1, "__TIMESTAMP":"Sun, 00 0000 00:00:00 GMT", "__FIELD_COUNT":5, "__VALUES": { "PKey":"MB00005", "FName":"Lucida", "LName":"Somerset (mob)", "Salary":19700, "Male":false } } ]

13 / 23

}

Le serveur nous renvoie simplement en réponse le latest stamp = 10 au format texte.A noter que nous fournissons unePrimary Key calculée localement. Nous reviendrons sur cette question unpeu plus loin.Nous fournissons un stamp à trois endroits différents :

• dans la querystring ($stamp)• dans l’entête du message (__LATEST_STAMP)• dans la méta-donnée de l’enregistrement (__STAMP)

Si ces données doivent être présentes, leur valeur n’est cependant pas signifiante.

Suppression

Dans cet exemple, nous envoyons au serveur, toujours sur la même url, le message suivant :

{ "__SENT":1, "__LATEST_STAMP":"1", "__ACTIONS": [ { "__ACTION":"delete", "__PRIMARY_KEY_COUNT":1, "__PRIMARY_KEY": { "PKey":"NC00002" }, "__STAMP":1, "__TIMESTAMP":"Fri, 26 Nov 2010 16:47:05 GMT" } ]

}

L’attribut __ACTION , correspondant au__ROW_ACTION de la commandeSQL REPLICATE , peutprendre deux valeurs update pour une création ou une modification et delete pour une suppression.

Le serveur nous renvoie une seule valeur, le dernier stamp, afin de pouvoir effectuer la prochaine réplicationen partant du dernier état. A noter que dans le cas dudelete, il faut fournir dans laquerystring la valeur du dernierstamp, parexemple :

http://localhost/4DSYNC/SUBSIDIARY_NC/PKey,FName,LName,Salary,Male?$format=json&$stamp=67

Modification

Cette fois, le message suivant, contenant deux demandes de modifications, est envoyé à 4D :

{

14 / 23

"__SENT":2, "__LATEST_STAMP":"1", "__ACTIONS": [ { "__ACTION":"update", "__PRIMARY_KEY_COUNT":1, "__PRIMARY_KEY": { "PKey":"NC00054" }, "__STAMP":1, "__TIMESTAMP":"Sun, 00 0000 00:00:00 GMT", "__FIELD_COUNT":5, "__VALUES": { "PKey":"NC00054", "FName":"Patricia", "LName":"Harrison", "Salary":20000, "Male":false } }, { "__ACTION":"update", "__PRIMARY_KEY_COUNT":1, "__PRIMARY_KEY": { "PKey":"NC00048" }, "__STAMP":1, "__TIMESTAMP":"Sun, 00 0000 00:00:00 GMT", "__FIELD_COUNT":5, "__VALUES": { "PKey":"NC00048", "FName":"Paul", "LName":"McCartney", "Salary":15000, "Male":true } } ]

}

Les différents stamps (__LATEST_STAMP et __STAMP) doivent être présents, mais leur valeur n’est passignifiante.

Synchronisation localeIl est intéressant de constater que dans la base 4D la réplication étant simulée entre la table[SUBSIDIARY_NC] et la base [SUBSIDIARY_TX] , une fois nos données répliquées vers[SUBSIDIAIRY_NC] , elles sont automatiquement répliquées vers [SUBSDIARY_TX] .

Pagination

Dans le cas où de nombreuses actions sont à répliquer, il est possible d’utiliser le mécanisme intégré depagination qui s'appuie sur les mots-clés optionnels : skip et top.

15 / 23

• top : nombre d’actions (update ou delete) à retourner en réponse à cette requête. Le serveurn’indiquant pas combien de réponses restent à recevoir dansce cas, il faut renouveler la requête jusqu’àce que le serveur ne renvoie plus de réponse.

• skip : offset de départ des actions retournées Dans notre exemple AIR, nous n’utilisons pas de pagination.

Compléments

Complétons cette présentation par quelques informations importantes fournies en ligne (FAQ oudocumentation de 4D).

Licence requise

Quelle licence 4D dois-je utiliser pour faire fonctionner iSort avec mon application 4D v12 ?

N'importe quelle application 4D v12 avec les licences 4D WebServer ou 4D Web Services expansion peutêtre utilisée avec iSort. 4D Developer Professional et 4D Team Developer Professional peuvent être utilisésavec iSort à des fins de tests et développements sans aucune licence supplémentaire. Comme touteapplication Web, le nombre de connexions entrantes vers 4D est illimité.

Dans le cas de l’utilisation de 4DSYNC, la réponse est identique.

Restriction des accès

Pour des raisons de sécurité, nous vous conseillons de filtrer explicitement les URLs4DSYNC/ et de lesaccepter ou de les rejeter selon que vous autorisez ou non la synchronisation avec une application ou unsystème distant.

Lorsque 4D reçoit une requête/4DSYNC, la Méthode baseSur authentificationWeb est appelée (hormis encas de mot de passe incorrect, voir le schéma de connexion dans la section Sécurité des connexions). Si elleretourne Vrai , la requête est exécutée, sinon elle est rejetée.

Structure virtuelle

Extrait de la doc :Vous devez tenir compte des principes suivants lorsque vous utilisez l'URL 4DSYNC/ :4D travaille avec la structure virtuelle de la base si elle existe. Dans ce cas, les paramètresNomTable etNomChamp correspondent aux noms de tables et champs tels qu'ils ont été définis via les commandesFIXER TITRES CHAMPS et FIXER TITRES TABLES . A noter que la portée de ces commandes est lasession, dans le cadre de 4D Server vous devez les appeler en procédure stockée sur le serveur.

Limitations

L’implémentation actuelle (v12.1) comprend les limitations suivantes :

• le parser JSON du serveur est séquentiel et attend les attributs et valeurs du message JSON dans l’ordreexact où ils sont fournis par le serveur 4D lui-même. Le non respect de cet ordre peut faire crasher 4D !

16 / 23

• l’ordre des champs de la table dans l’url de réplication doit respecter exactement l’ordre des champsque l’on retrouve dans le message JSON ;

• de même l’ordre d’indication des champs composant une clé primaire composite doit êtresoigneusement respecté.

Mise en oeuvre avec une application AIR

Maintenant que nous maîtrisons les concepts et le format desmessages à échanger avec le serveur, ce n’estplus qu’une question de codage afin de réaliser un exemple. Pour illustrer le fonctionnement, nous avonschoisi de fournir une application AIR.

Plateforme Adobe AIR

La technologie AIR d’Adobe permet de développer des applications desktop ou mobiles avec la technologieFlex en incorporant un Runtime afin d’obtenir une exécution autonome.

Les avantages de cette approche sont multiples :

• le runtime AIR est disponible pour de nombreuses plateformes et sa redistribution est libre ;• le runtime AIR prend en charge la gestion d’une base de données locale SQLLite dans laquelle nous

stockerons nos enregistrements.

Nous obtiendrons ainsi une application autonome capable destocker les enregistrements répliqués etfonctionnant aussi bien sur un ordinateur sous Linux que surun mobile Blackberry ou une tablette Android.Après une conversion en code natif grâce à l’iPhone packager, il est même possible de la faire fonctionnersous iOS.

17 / 23

Un équivalent HTML-JavaScript consisterait à développer une webApp avec Sencha extJS et son pendantSencha Touch (www.sencha.com/) pour les mobiles WebKit ou toute autre technologie du même genre.Cependant, la question du stockage de données en local n’a pas aujourd’hui de réponse unique dans cecontexte. Si Google a apporté une solution avec Google Gears(), il faut cependant l’installer sur chaquemachine, tandis que le local storage qui fera partie de l’HTML5 semble s’éloigner de la solution SQLLiteconsidérée comme trop fermée. Le framework DAF du 4D Web 2.0 Pack fournit une solution prêteà l’emploi pour la réalisation de clientsJavaScript proposant les fonctionnalités suivantes : réplication de données génériques depuis toute table ettoute base, modifications et stockage local et synchronisation vers le serveur.

L’application

Un fichier .swf de présentation de l'exemple est joint à la présente note technique : il s'ouvre par glisser-déposer dans tout navigateur

L'application AIR fournie en test ("Air4DSYNC"), requiert Adobe AIR 2.5.1 :http://get.adobe.com/fr/air/

L'application se nomme 'Air4DSYNC.app' et se compose de deux écrans.

• Le premier écran 'BDD Locale' liste les enregistrements de la base de données locale et permet d’encréer et d’en supprimer (la modification n’a pas été implémentée) :

18 / 23

L’écran d’ajout d’enregistrement :

• Le second écran 'Réplication' permet de récupérer depuis le serveur les actions à répliquer localement

et dans un second temps d’appliquer ces actions à la base de données locale. Nous avonsvolontairement segmenté ces deux opérations pour une meilleure compréhension des mécanismes. Lesactions en attente d’application à la base de données locale sont affichées dans deux grilles de données :

19 / 23

• Le bouton 'Initialiser la BDD locale' permet lors de la première utilisation de l’application d’initialiser

la base de données locale, de récupérer tous les enregistrements du serveur et de les créer localement.La valeur du champ stamp est alors sauvegardée et affichée dans le libellé 'Remote Stamp'.

• Le bouton 'Recevoir modifications'demande au serveur 4D de renvoyer les actions à effectuer depuisle dernier remote stamp. La nouvelle valeur retournée par 4Dpour ce paramètre est de nouveausauvegardée. Les actions sont listées en attente d’application sur la base de données locale.

• La zone de saisie 'Remote url:' permet de modifier l’url du serveur 4D. Attention à toujours préciserhttp:// devant le nom d’hôte.

• Le bouton 'Appliquer à la BDD locale' applique les actions listées dans les grilles 'Updated' et'Deleted' à la base de données locale.

En entête des écrans, les actions en attente d’application sont listées :

• Réplication depuis le serveur : il s’agit d’actions récupérées depuis le serveur, mais non encoreappliquées sur la base de données locale ;

• Modifications locales : il s’agit d’actions effectuées sur les enregistrements locaux, mais non répliquésvers le serveur. Si l’on quitte l’application sans avoir effectué la réplication vers le serveur, ces actionssont sauvegardées et rechargées à l’ouverture de session suivante.

Le problème de la PK

20 / 23

Lorsque l’on créé les enregistrements dans la base de données locale, il faut les identifier de manière uniqueen utilisant un système compatible avec celui de la base distante. Dans la base 4D exemple, la clé primaire est composée d’un préfixe dépendant du site suivi d’un numéroséquentiel unique. Par exemple :

$0:="NC"+Chaine(Numerotation automatique([SUBSIDIARY_NC]);"00000")

Pour un fonctionnement en mode déconnecté, il faudrait implémenter un mécanisme identique sur le postedistant.

Dans notre exemple, nous utilisons une requête http pour récupérer une clé primaire compatible. Mais, celaimpose au moment de la création d’un enregistrement de pouvoir communiquer avec la base distante , ce quin’est en général dans la pratique, pas forcément le cas.

Requete HTTP de récupération d’une clé primaire

Le code de la méthode 4D appelée côté serveur :

//getNextPK

C_TEXTE($1) // peut être appelée par 4DACTIONC_TEXTE($0) C_BOOLEEN($ifCanceltransaction)Si (Nouvel enregistrement([SUBSIDIARY_NC]))Sinon$ifCanceltransaction:=VraiDEBUT TRANSACTIONCREER ENREGISTREMENT([SUBSIDIARY_NC])Fin de si $0:="NC"+Chaine(Numerotation automatique([SUBSIDIARY_NC])+10;"00000") Si ($ifCanceltransaction)[SUBSIDIARY_NC]PKey:=$0STOCKER ENREGISTREMENT([SUBSIDIARY_NC])ANNULER TRANSACTIONFin de si Si (http_isHTTPrequest )ENVOYER TEXTE HTML($0)

Fin de si

Exemple de requête et de résultat renvoyé :http://localhost/4DACTION/getNextPK-> NC00016

Utiliser un UUID

Une alternative possible serait d’utiliser un UUID comme clé primaire, mais il faut l’avoir prévu dès ledépart dans la définition de la table cible, ce qui n’est pas le cas dans notre exemple.

21 / 23

Quelques compléments

La BDD locale de l’application AIR est enregistrée dans le dossier ‘Utilisateur’ dont l’emplacement varie enfonction de la plateforme et du système.Les données locales de réplication sont conservées entre deux sessions dans un espace particulier et privénommé sharedObject par Adobe. Quelques outils d'administration de bases de données SQLite permettent de manipuler la base locale qui senomme 'directory.db' et n’a qu’une seule table :

• SQLite Admin AIR Application : http://coenraets.org/blog/2008/02/sqlite-admin-for-air-10/• SQLite Manager Firefox Extension : http://code.google.com/p/sqlite-manager/• Lita (AIR Application) : http://www.dehats.com/drupal/?q=node/58 • SQLite Database Browser : http://sqlitebrowser.sourceforge.net/

SQLite Database Browser est en particulier un outil assez puissant.

Et les mobiles alors ?

Pour valider nos promesses initiales, il fallait vérifier que cette application tourne bien sur un mobile, enl’occurrence sous Android 2.2. Voici donc une capture d’écran dans l’émulateur d’Android fourni parGoogle :

Ici nous émulons un smartphone du type HTC Desire qui offre unécran d’une résolution WVGA de 800 x480 qui semble assez répandue: Google Nexus One, Samsung Galaxy S,... Cependant, si la réplication et le

22 / 23

stockage local fonctionnent parfaitement, il reste à adapter les écrans à l’utilisation d’un smartphone.Comme nous le constatons sur cette photo prise lors de l’exécutuon sur un HTC Desire, l’interface n’est pascelle attendue sur un smartphone :

Mais ceci est une autre histoire...

Conclusion

L’utilisation de la réplication au travers d’HTTP ouvre la porte à beaucoup de possibilités de réalisationd’applications sur de multiples plateformes, en particulier mobiles.

Côté 4D, cela ne requiert que très peu d’effort : déclarer uneclé primaire, activer la réplication, gérer l’accèshttp et c’est tout !

Côté client http, il faut gérer beaucoup plus de choses, écrire pas mal de code technique et si plusieurs tablessont concernées, l’investissement dans l’élaboration d’une bibliothèque générique s’impose rapidement.C’est d’ailleurs la raison pour laquelle, 4DAF, le Framework Ajax contenu dans le Web 2.0 Pack, proposecette fonctionnalité. Des démonstrations ont été effectuées lors de la conférence internationale annuelle quis’est tenue à San Diego en 2010. Le plus gros problème rencontré lors de la réalisation de cetexemple a été la nécessité de respecterscrupuleusement l’ordre des attributs dans le message JSONsous peine d’erreur lors de la réplication. Cela aimposé d’abandonner la sérialiation JSON générique et de réaliser notre propre sérialisation ce qui n’est pasla partie du code la plus passionnante !

23 / 23