Notre approche en tant que développeurs d’applications sur mesure est d’apporter des solutions évolutives à nos clients.
Leurs besoins progressent, et ils souhaitent adapter rapidement leur outil à la réalité de leur métier et de leur structure.
Mises à part quelques petites adaptations mineures qui peuvent être “reportées” en direct dans le fichier de production, la plupart du temps, pour pouvoir mettre en oeuvre de nouvelles fonctionnalités, nous devions nous lancer dans une aventure parfois fastidieuse : le versioning.
Ceci est bientôt de l’histoire ancienne
Souvenez-vous de ce à quoi pouvait ressembler un versioning :
Table par table, nous importions les données dans la nouvelle version.
En préparation de cet import, il avait fallu régler les correspondances de rubriques entre la table source de production et la table destination du nouveau fichier. L’interface que FileMaker propose pour régler l’import est sans doute le plus indigeste des interfaces de la plateforme : difficulté de positionner les rubriques qui “glissent” de haut en bas, contrôle de correspondance uniquement visuel… cette étape de configuration peut s’avérer gourmande en temps de développement (dans cet article de juin 2010 sur la mise à jour des données, nous revenons sur la méthodologie que nous adoptions dans pareille situation).
Après avoir réglé la séquence d’import, nous devions penser à mettre à jour les éventuels compteurs basés sur des numéros de série.
D’autres couches de l’application contiennent également des données qui avaient pu évoluer et être modifiées par les utilisateurs au cours de leur usage du fichier à mettre à jour :
- la sécurité, dans laquelle des comptes ont pu être créés, modifiés, supprimés;
- les listes de valeurs personnalisées dont certaines ont pu être adaptées par des utilisateurs disposants des droits pour ce faire.
Vue la complexité et la lenteur du processus de versioning, nous options souvent pour procéder à ces manoeuvres la nuit, le week-end… prévoyant selon le nombre d’enregistrements à transférer de nombreuses heures où avancerait lentement la barre de progression de la fenêtre d’import.
Parfois nous n’avions pas le choix, suite à une corruption de fichier, nous devions repartir d’une clone sain et injecter les données de production, en espérant ne pas interrompre trop longtemps le travail en cours des utilisateurs bloqués.
Un gain de temps considérable
Avec la version 17 de FileMaker, ceci va changer radicalement ! Mais c’est en dehors de l’application qu’il faut aller chercher cette excitante nouveauté. En accompagnement de FileMaker 17 (dans le package de la Developer Subscription), nous trouvons un petit outil léger en ligne de commande…léger mais d’une puissance telle qu’il va nous permettre de revoir fondamentalement le rythme de mise à jour de nos applications.
(On peut s’interroger sur la raison d’une attente si longue dans l’histoire de la plateforme pour bénéficier d’un tel outil – Fabrice se souvient que ses demandes à FileMaker pour un système du genre remontent à plus de 10 ans, et les développeurs étaient nombreux à appuyer dans ce sens.)
Le DMT, data migration tool, est donc un outil en ligne de commande qui permet d’injecter en un temps record les couches de données d’un fichier source vers un clone de la même base, et ce avec un tout petit minimum de préparation de notre part.
Comme pour le iOS SDK, cet outil vient de le “package” qui accompagne la Developer Subscription (89€HT/an). (Un package qui devient encore plus attractif avec le nouveau modèle de licence…allez jeter un oeil)
Comment utiliser le DMT
(Attention, veuillez prendre connaissance de l’article relatif à un bug important de la version actuelle de l’outil)
Le principe est simple :
- Réalisez un clone de la base de données de destination. Précision importante : un clone est une copie du fichier, dénuée des parties données (enregistrements et données locales). Un clone est un clone tant que le fichier n’est pas ouvert. Dès son ouverture, FileMaker y écrit des paramètres locaux (langue, format de date,…) et il perd dès lors son caractère de clone.
- en ligne de commande, appeler l’outil FMDataMigration, identifier la source, le clone et la destination
FMDataMigration -src_path <path> -clone_path <path> [<other options>]
Et c’est réglé ! … un journal affiche la progression, les résultats et erreurs éventuelles.
Un cas vécu : le temps de versionning d’un fichier comportant environ 40 tables et des millions d’enregistrements est passé de 3h00 à 10 minutes !! Et c’est évidement sans compter le temps gagné à ne pas devoir paramétrer la séquence d’importation des données pour chacune des tables.
Au final, nous récupérons non seulement les enregistrements, mais aussi les comptes utilisateurs et les modifications dans les listes de valeurs personnalisées, ainsi que les polices de caractères intégrées au fichier.
Ce qui est transféré
(en fonction des options cfr infra) :
- les comptes utilisateurs
- les enregistrements
- les listes de valeurs personnalisées
- le numéro de série suivant des rubriques entrée automatique numéro de série
- les index
- les ID d’enregistrements
- les paramètres régionaux (formats de date, langue par défaut…)
Paramètres de la ligne de commande
(en gras les paramètres obligatoires)
-src_path : le chemin du fichier source
-src_account : un compte accès intégral dans le fichier source (par défaut = Admin)
-src_pwd : le mot de passe du compte (par défaut = vide)
-src_key : l'éventuelle clé d'encryption du fichier source
-clone_path : le chemin du fichier clone
-clone_account : un compte accès intégral dans le fichier clone (par défaut = Admin)
-clone_pwd : le mot de passe du compte (par défaut = vide)
-clone_key : l'éventuelle clé d'encryption du fichier clone
-target_path : le chemin du fichier de destination (par défaut = chemin de la source avec ajout de 'migrated' )
-ignore_valuelists : par défaut le DMT va recopier les valeurs des listes de valeurs personnalisées du fichier source. Ajoutez cette option pour ne garder que les valeurs du fichier clone
-ignore_accounts : par défaut le DMT va recopier les comptes du fichier source ainsi que la clé d'encryption. Ajoutez cette option pour ne garder que les comptes du fichier clone
-ignore_fonts : par défaut le DMT va recopier les polices du fichier source. Ajoutez cette option pour ne garder que les polices du fichier clone
-v : (verbose) mode avec log de progression qui décrit étape par étape ce que le DMT est en train de faire
-q : (quiet) mode silencieux
-force : permet d'écraser un fichier de destination déjà existant
Quelques remarques et points d’attention:
Comment se fait la correspondance ?
Pour la correspondance des tables et rubriques, FM Data Migration Tool procède d’abord par nom et ID identique, puis s’il ne trouve pas par nom identique, puis enfin par ID interne correspondant. Cela signifie par exemple que si vous renommez la rubrique RUBOld en RUBNew et puis que vous créez une rubrique nommée RUBOld, les données de la source contenue dans la rubrique RUBOld seront transférées dans la nouvelle rubrique RUBOld.
Des conteneurs
L’outil est prévu pour que le fichier résultat soit ensuite placé au même endroit qu’à l’origine. Ce point doit être pris en considération dans le cas de stockage externe de conteneurs : l’outil ne gère pas de déplacement ou de conversion de ces fichiers.
Clone tu resteras
Petit rappel : un clone reste un clone tant qu’il n’a pas été ouvert !
Réparation du code ?
Le DMT n’est pas un outil de réparation. Si on a dans la source une donnée corrompue, elle le restera après versioning.
Attention plug-in
Lors du versioning, le DMT “réévalue” les valeurs des rubriques calculs stockées. Ceci peut poser un gros problème si ces calculs font appel à des fonctions issues de plug-in. Le DMT n’ayant pas accès aux plug-in, les résultats de ces calculs sera un ? dans tous les enregistrements. Il faudra par la suite évaluer à nouveau ces calculs en entrant dans la définition de la base de données et en éditant la formule de calcul (y ajouter un espace suffit).
Sécurité : login et mot de passe
Dans les instructions en ligne de commande, il faut passer en clair un login et mot de passe du fichier clone et du fichier source. Ce login et mot de passe peut être soit celui d’un compte disposant de l’accès intégral au fichier…dans ce cas, vous exposez aux regards indiscrets et laissez dans l’historique du terminal un mot de passe critique. Soit vous pouvez mentionner un compte et mot de passe qui est associé à un jeu de privilège qui dispose d’un privilège étendu dont le nom commence par “fmmigration”. Le nom du privilège étendu doit être rigoureusement le même dans le fichier source et dans le clone (sensible à la casse). Le jeu de privilège ne doit disposer d’aucun droit particulier dans la base de données (ni lecture des données, ni accès aux modèles, scripts,…). C’est sans aucun doute la manière la plus sûre de gérer cet aspect sécurité lors de l’usage du DMT.
Dans l’exemple ci-dessous. Nous avons créé un compte “mig” dont le mot de passe est “123456”; ce compte est associé au jeu de privilège “Mig” qui n’a aucun droit de lecture, d’accès au modèle, scripts,..dans la base. Ce jeu de privilège dispose d’un privilège étendu dont le nom commence par fmmigration : “fmmigrationTest”.
La commande devient la suivante :
./FMDataMigration -src_path Old.fmp12 -src_account mig -src_pwd 123456 -clone_path New.fmp12 -clone_account mig -clone_pwd 123456
Pour disposer de l’outil Data Migration Tool
Comme pour le iOS SDK, cet outil vient de le “package” qui accompagne la Developer Subscription (89€HT/an).
Enjoy !
