Enregistrements FileMaker portables à l’aide de JSON

Comment transformer un enregistrement FileMaker complet en un objet JSON à l’aide d’un simple script modulaire

Dans le développement FileMaker, comme dans tout environnement de développement, nous avons beaucoup d’astuces et de techniques que nous utilisons pour faire avancer les choses – des plus simples (comme supprimer automatiquement le formatage du texte dans un champ) aux plus avancées (utiliser des transactions de type « clé magique« ). Dans mon travail de développement, j’ai souvent besoin de déplacer des données d’un endroit à un autre, et j’ai découvert que JSON est devenu mon format de prédilection pour accomplir cette tâche, en particulier parce qu’il est bien adapté à ce cas d’utilisation précis : stocker et déplacer des données structurées. Si vous n’êtes pas familier avec l’utilisation de JSON dans FileMaker, je vous invite à lire mon guide étape par étape sur la création de JSON dans FileMaker (en anglais).

Il y a quelques années, un de mes collègues a créé un script rapide et facile pour transformer un enregistrement FileMaker complet en un objet JSON (que j’ai depuis adapté et optimisé), et je me suis retrouvé à utiliser sa technique encore et encore. Elle est particulièrement utile pour analyser les données d’une source de données texte dans plusieurs tables, mais je l’ai également utilisée pour un enregistrement complet, ajouter des métadonnées, coder le tout au format Base64 et l’envoyer sur Internet à un autre serveur à l’aide du Data API.

Le principe de base est le suivant : à l’aide d’une liste de noms de champs de ta table, il suffit d’extraire la valeur d’un enregistrement de chaque rubrique de la liste et de l’ajouter en tant qu’élément à un objet JSON. À la fin de ce processus, une liste de tous les champs de la table et de leurs valeurs se retrouvent bien rangés dans un seul objet JSON !

Voici l’intégralité du script :

Cette technique exploite la fonction ExecuteSQL et les tables système FileMaker pour obtenir une liste des rubriques de la table. Nous commençons par obtenir le nom de la table et la liste des rubriques de cette table :

Il en résulte deux variables, appelées $table et $fieldList, qui ressembleront à ceci :

Nous comptons ensuite le nombre de rubriques de notre table et nous nous préparons à parcourir en boucle la liste des rubriques :

Dans l’étape suivante, nous parcourons en boucle chacun des noms de champs de $fieldlist, utilisons la fonction GetField() pour obtenir le contenu de ce rubrique de cette table, et l’ajoutons en tant qu’élément à un objet JSON appelé $record :

À la fin de cette boucle, nous obtenons une variable appelée $record qui ressemble à ceci :

{"BirthCountry":"USA","DOB":"8/11/1954","Email":"marcus@odiorne.com","First":"Marcus","Language":"","Last":"Aurelius","Middle":"K","PersonID":"109992","Race":"White","SexAtBirth":"M","cAge":"66"}

Nous pouvons la reformater à l’aide de la fonction JSONFormatElements() pour qu’elle ait un meilleur aspect :

{
	"BirthCountry" : "United States",
	"DOB" : "8/11/1954",
	"Email" : "marcus@odiorne.com",
	"First" : "Marcus",
	"Language" : "",
	"Last" : "Odiorne",
	"Middle" : "K",
	"PersonID" : "109992",
	"Race" : "White",
	"SexAtBirth" : "M",
	"cAge" : "66"
}

À la fin du script, nous pouvons ajouter des métadonnées à ce bloc JSON, si nous le souhaitons, mais cela est totalement facultatif. Nous pourrions envisager des choses comme celles-ci :

{	
    "Record" : 	
    {
        "BirthCountry" : "United States",
  		"DOB" : "8/11/1954",
  		"Email" : "marcus@odiorne.com",
  		"First" : "Marcus",
  		"Language" : "",
  		"Last" : "Odiorne",
  		"Middle" : "K",
  		"PersonID" : "109992",
  		"Race" : "White",
  		"SexAtBirth" : "M",
  		"cAge" : "66"	
    },
    "metaData" :
    {
		"Account Name" : "Admin",
		"DeviceID" : "C56C3D9278D302299180B26B584EEE",
		"Host IP" : "",
		"PrivSet" : "[Full Access]",
		"ScreenSize" : "2560x1440",
		"System IP" : "192.168.0.7",
		"SystemVer" : "14.4.1",
		"Time" : "4/12/2024 1:58:27 PM"	
	}
}

Dans la dernière étape du script, il y a une étape de fin de script, qui renvoie le résultat JSON :

Exit Script [ Text Result: $result ]

Cette étape renvoie le JSON au script parent, qu’il est possible d’obtenir en appelant la fonction Get ( ScriptResult ) :

Set Variable [ $record ; Value: Get ( ScriptResult ) ]

C’est tout !

Une fois que l’enregistrement est récupéré de cette façon, vous pouvez en extraire des éléments individuels en utilisant les fonctions JSON intégrées de FileMaker. Par exemple, si vous voulez accéder à une nouvelle table, créer un enregistrement et définir certaines rubriques de ce nouvel enregistrement en fonction des éléments de l’exemple $record ci-dessus, vous ferez quelque chose comme ceci :

Il est important de noter ici que les données de la variable JSON sont toutes capturées au format « Chaîne », ce qui signifie que les types de données ne sont pas reconnus comme Nombre, Date, Booléen, etc. Bien que cela soit avantageux d’un certain point de vue – FileMaker n’essaie pas de reformater quoi que ce soit – lors de l’analyse des données, il se peut que vous deviez convertir les éléments au type de données dont vous avez besoin, en particulier si vous envoyez des données dans un système différent. Par exemple, vous pouvez extraire une date de votre enregistrement sous la forme d’une chaîne de caractères comme celle-ci : « 4/26/01 ». Lorsque vous l’introduirez dans un autre système, vous devrez peut-être utiliser une fonction FileMaker comme GetAsDate() pour la transformer en une véritable Date ou la reformater au format ISO (comme ‘2024-04-26’). De même, la refonte du type de données analysées à l’aide de GetAsBoolean() ou GetAsNumber() peut s’avérer nécessaire.

Remarque que le début du script comporte une étape qui vérifie si une variable globale appelée $table est la même que le nom de la table actuelle :

If [ $$table ≠ Get ( LayoutTableName ) ]

C’est simplement pour gagner du temps si vous appellez ce script à l’intérieur d’une boucle. L’exécution de la fonction ExecuteSQL sur les tables système FileMaker peut être assez lente ; la génération de la liste des rubriques peut prendre jusqu’à une demi-seconde. Bien que cela ne pose généralement pas de problème lors d’un seul appel de script, cela ralentit considérablement le processus lors de l’exécution répétée d’une boucle d’enregistrements. Étant donné qu’un processus en boucle est généralement exécuté dans le même contexte à plusieurs reprises, il n’est pas nécessaire d’obtenir la même liste de champs pour chaque boucle, nous commençons donc par définir le nom de la table sur laquelle nous nous trouvons dans la variable globale $table. Si le contexte du script est le même pour chaque boucle, nous pouvons réutiliser la $fieldList existante pour la boucle suivante !

Cette technique s’est avérée si utile dans mon développement FileMaker que j’y reviens encore et encore. J’espère que vous pourrez trouver un cas d’utilisation dans votre propre travail. Joyeuse transformation de données !