Mise à jour des données

[OBSOLÈTE] : FileMaker 17 intègre cette fonctionnalité nativement avec le Data Migration Tool (pour les membres FBA)

Suite à la passionnante session de Vincenzo Menanno (FM Nexus) lors de la FM Conférence 2010 à Paris, qui traitait des différentes stratégies de mise à jour de solutions, 1-more-thing a décidé d’emboîter le pas et de lever le voile sa méthode.

En effet, j’ai été frappé des ressemblances entre notre méthode et celle de Vincenzo, et les petites différences me font penser qu’échanger sur ce thème provoquera des réactions constructives, des ajustements nécessaires. Cet article se veut donc une proposition, et nous espérons apprendre aussi des réactions que vous ne manquerez pas de laisser ci-dessous.

Tout d’abord, ciblons le cas de figure qui fait l’objet de cet article.

La méthode exposée ci-après concerne les grosses mises à jour, et non les petits développements ponctuels, que l’on pourra faire directement sur le serveur, pendant que les utilisateurs travaillent (développement live) ou pendant les heures de fermetures, voire en reproduisant sur la version servie les modifications apportées sur une version de développement (développement offline).

Dans ce cas de grosses mises à jour, nous avons une version de développement qui a été modifiée, et le but est d’importer les données depuis la version précédente. La version de développement est donc destinée à être installée sur le serveur après le processus de migration.

Précisons également que comme Vincenzo Menanno, nous ne sommes pas convaincus par l’approche séparation données/interface, sauf dans certains cas bien précis. Aussi, nous partons du principe qu’il n’y a pas de différence majeure entre l’approche « en séparation » et l’approche classique, sachant qu’il est rare qu’un changement d’interface n’induise aucun changement dans la structure des données. Nous ne préciserons donc pas ci-après les différences qui peuvent théoriquement exister entre les deux approches.

Etapes préliminaires

Avant tout, il va de soi que le transfert massif de données sera beaucoup plus efficace sur un poste client (local) qu’à travers le réseau. Nous devons donc arrêter le serveur (du moins la solution concernée), et en faire une copie sur le poste local.

Pour éviter toute confusion, nous plaçons ce fichier dans un dossier « Old », situé au même niveau que la version de développement.

Nous avons donc une arborescence du type :

• Solution.fp7 (destination)
• Old
  • Solution.fp7 (source)

Mais ceci est en fait un peu trop simple. Lors du développement de la nouvelle version, nous avons peut-être eu besoin de créer des données dont nous aurons besoin, notamment dans les tables de référence (images, libellés, messages, code postaux ou pays…). Ces données ne figurent pas dans la source des données, mais dans la destination.

Or, comme nous le verrons ci-après, une des premières choses à réaliser est de vider le fichier de destination de ses données. En fonction du volume de données, on pourra choisir de supprimer ces données ou de faire un clone du fichier de destination (beaucoup plus rapide si le fichier contient beaucoup de données, FileMaker étant extrêmement lent à cet exercice)

Dans deuxième cas, nous créons un clone du fichier de destination dans un dossier Reference. L’arborescence est donc :

• Solution.fp7 (destination)
• Old
  • Solution.fp7 (source pour les données)
• Reference
  • Solution.fp7 (source pour les références)

Alternativement, on aura pu développer la solution avec un fichier spécifique pour les tables de référence, ce qui simplifie cette étape, mais pose des problèmes de gestion des comptes, comme toute solution multi-fichiers.

Le renommage des rubriques

Comme nous le verrons plus loin, la migration des données se fera pas un import basé sur les noms concordants des rubriques. Il est donc nécessaire de s’assurer que les rubriques n’ont pas changé de nom entre les deux versions.

Pour cela, nous utilisons l’utilitaire FMDiff, qui permet en quelques minutes de comparer deux versions du fichier fp7. Notons que nous utilisons par ailleurs beaucoup Inspector ou BaseElements, mais ces outils d’analyse demandent un import du Rapport de Structure de Base de Données en XML, ce qui prend pas mal de temps et qui est ici inutile : seuls les renommages nous intéressent. Si vous devez investir dans un outil et un seul, il va néanmoins de soi que ces outils d’analyse vont plus loin que FMDiff.

Une fois ce rapport produit, nous reproduisons scrupuleusement les renommages dans le fichier source.

Pour plus de sécurité, nous comparons ensuite le fichier source modifié au fichier de destination (on n’est jamais à l’abri d’une faute de frappe)

Les scripts de migration

La migration de données est presque entièrement automatisable. Vous n’êtes pas obligé d’attendre la première migration effective pour développer ces scripts, bien que rien ne vous empêche de le faire à ce moment. Pensez toujours néanmoins qu’on travaille mieux sans stress, et qu’une mise à jour d’une solution tournant chez le client doit être faite rapidement, et donc génère pas mal de stress. Si possible, prévoyez donc déjà d’inclure ces scripts dès la première version.

La première chose à faire sera une référence au(x) fichier(s) source(s), Old/Solution.fp7 et Reference/Solution.fp7

Puis, dans le cas où l’on n’a pas fait de clône, on exécute dans le fichier de destination un script qui va supprimer toutes les données : MAJ_SupprimerToutesLesDonnées

(note : tous les scripts décrits ci-après sont destinés à être joués en accès intégral).

Bien. Que l’on ait généré le fichier de destination par un clone ou pas, nous sommes maintenant tous dans le même bâteau.

La prochaine étape consiste à s’assurer que tous les enregistrements vont être importés.

On crée donc un nouveau script dans notre fichier de destination : « MAJ_Afficher tous les enregistrements de la source »

Ce script ne fait que qu’exécuter un sous-script dans le fichier source : « MAJ_Afficher tous les enregistrements »

Ce sous-script, qu’on prendra bien soin de copier dans le fichier de destination également (pour la prochaine mise à jour), est très simple :

Attention, ceci suppose que l’on ait au moins un modèle pour chaque table de base. Mais ceci est largement à conseiller, et pas que pour les mises à jour. Malheureusement, il n’existe pas de fonction de calcul en FileMaker permettant de s’assurer de cela. Pour cela, nous utilisons régulièrement des outils comme Inspector.

Un participant de la FMConf a proposé, en lieu et place de Annuler tri, de trier sur la clef primaire (il utilise des clefs primaires séquentielles, ou numéros de série). Il est exact que de manière exceptionnelle, on aura pu modifier un identifiant primaire, et qu’il serait ensuite confortable de voir le enregistrements importés dans l’ordre. Néanmoins, nous pensons différemment, car la procédure de mise à jour serait plus longue (le tri est consommateur de temps), et devrait être « hard-codée » (il n’est toujours pas possible, et c’est dommage, de définir un tri dynamiquement). Cela suppose que ces scripts de mise à jour seront beaucoup plus difficiles à maintenir, et qu’il y a plus de chance de provoquer une erreur. Quand ces cas de force majeure se présentent (modification d’un ID par le développeur ou l’admin), nous préférerons profiter de l’occasion pour réaliser l’opération de maintenance consistant à trier, exporter, puis réimporter les enregistrements, directement après le changement d’ID. Ainsi, nous sommes certains que le dernier numéro de série utilisé est bien le dernier enregistrement.

Nous effectuons bien sûr la même opération (script ci-dessus) pour le fichier situé sous Reference/Solution.fp7, ou pour les autres fichiers de la solution.

A ce stade, nos fichiers source et notre fichier de destination sont prêts pour l’importation.

Nous allons donc écrire un script dans le fichier de destination qui importera toutes les données, et mettra à jour les numéros de série. Comme nous devons ajouter une étape d’import pour chaque table, il est facile de cibler tel ou tel fichier source.

Pour chaque table, nous avons : (les étapes précédées d’un * sont à configurer pour chaque table)

Nous répétons cette opération pour chaque table (ce qui peut donner un script assez long). Voilà pour l’import des données.

Listes de valeurs et comptes utilisateurs

Il ne nous reste plus qu’à importer les éventuelles listes de valeurs modifiables par les utilisateurs (les listes à valeurs personnalisées). Pour cela, FileMaker 11 apporte une petite nouveauté : la possibilité de trier les listes de valeurs dans la fenêtre Gérer les listes de valeurs. On peut désormais les trier par provenance, ce qui nous évite d’avoir à utiliser une convention de nommage très stricte.

Mais il faut malgré tout copier/coller d’un fichier à l’autre.

Idem pour les comptes utilisateurs. S’ils ont été modifiés, si on en a créé de nouveaux ou désactivés certains pendant la phase de développement de la nouvelle version, il faut reproduire les modifications sur la nouvelle version. Là encore, on s’aidera d’un outil de comparaison des versions.

Il en va de même si vous avez du effectuer quelques menues modifications sur la version servie alors que vous aviez déjà commencé le développement de la nouvelle version sur une copie. Pour cela, pas d’autre moyen que de noter ce que l’on fait. Inspector peut malgré tout vous aider, mais appliquer machinalement des modification sans se souvenir de la raison pour laquelle on a du faire ces modifications n’est jamais à conseiller.

Enfin (quoi que dans notre cas cette étape soit intégrée à notre script d’import), on n’oubliera pas de documenter le numéro de version, afin qu’il soit clair pour les utilisateurs qu’ils ont changé de version, et afin de pouvoir mieux traiter les éventuels rapports de bugs futurs.

En espérant avoir rencontré votre intérêt, n’hésitez pas à nous faire par de vos expériences et de vos méthodes.