FileMaker 2023 – « Audit log »

Comme nous l’avons vu dans cette revue détaillée des nouveautés de FileMaker 2023, une des deux fonctionnalités phares, avec l’exécution de script sur serveur avec call-back, est ce que Claris appelle « Audit Log »

Il y a tellement de choses à savoir sur cette fonctionnalité que nous avons préféré lui consacrer un billet complet.

Tout d’abord mettons-nous d’accord, même si le marketing de Claris n’a pas résisté à la tentation de l’appeler ainsi, cette fonctionnalité n’est pas un réel audit log, et ce pour plusieurs raison.

• D’abord pour une raison assez simple : cette fonctionnalité ne logue rien du tout. Elle permet éventuellement à un développeur de bâtir son audit log dessus.
• Ensuite un audit log, pour être digne de se nom, doit répondre à certains impératif d’inviolabilité (on ne doit pas pouvoir faire une modification sans qu’elle soit loguée, on ne doit pas pouvoir modifier une entrée dans le log…). Même si on verra que c’est ce que FileMaker pouvait proposer de mieux, la nouvelle fonctionnalité ne répond pas à ces critères.

Est-ce à dire qu’il faut passer son chemin sans regarder ? Pas du tout ! La nouvelle fonctionnalité est enthousiasmante, mais comme disait Camus, « mal nommer les choses c’est s’exposer à la critique »  (ou un truc comme ça). Et s’exposer à la critique d’un auditeur externe à qui on aurait vendu un « audit log » qui n’en serait pas un… voilà bien une situation que je préférerais éviter.

Donc non, l’audit log n’est pas un audit log. Soit. Comment l’appeler alors ?

C’est le nom « technique » de la fonctionnalité. C’est sous ce nom qu’on la retrouve dans FileMaker Pro, et ça me semble être déjà beaucoup plus proche de la réalité.

Enfin, c’est ainsi qu’on la retrouve dans FileMaker Pro… en anglais (OnWindowTransaction), car le déclencheur a été étrangement traduit par SurOperationFenetre en français, mais à moins que l’on parle de finance ou de compatibilité, c’est bien de transaction qu’il s’agit ici. Je réalise en écrivant que les transactions de la version 19.6 sont également, partiellement traduites en « opérations », mais pas le nom de la fonction Obtenir ( EtatTransactionOuvert ).

Les transactions de fenêtres apparaissent sous la forme d’un déclencheur de script dans les options de fichier, et vont s’appliquer à toutes les transactions.

Une fois activé, chaque transaction (ou presque) déclenchera le script.

Qu’est-ce qu’une transaction ? La question se pose car quand on nomme mal les choses… et depuis 30 ans, il faut dire que nommer les choses bizarrement est une spécialité de FileMaker (essayez de parler de rubriques à des pros de la base de données, ou de modèles à des designers, et vous verrez ce que je veux dire). Donc une transaction n’est pas particulièrement ce que Claris a appelé transaction dans la version 19.6.
Une transaction, c’est simplement le fait de créer, modifier, supprimer un ensemble d’enregistrements (y compris un seul enregistrement) et de valider. Ça existait déjà avant la 19.6, même si la 19.6 a permis d’écrire des transactions plus facilement, ou de rendre certaines actions « transactionnelles » alors que ça n’était pas possible préalablement.
Notons que la modification d’une rubrique globale, qui n’est pas a proprement parler une modification de données, ne provoque pas de transaction de fenêtre, (sauf bien sûr si la modification d’une rubrique globale entraîne une modification d’une autre rubrique, standard elle, par le truchement d’une auto-entrée en résultat de calcul).

Bref, vous avez compris ce qu’est une transaction de données. Lors d’une transaction on peut :

• créer des enregistrements
• modifier des enregistrements
• supprimer des enregistrements

Les transactions de fenêtre sont en FileMaker ce qui se rapproche le plus d’une transaction de données, ou plus exactement d’un événement qui a lieu sur transaction de données.

Mais ce sont des transactions… de fenêtre. Encore faut il donc avoir une fenêtre, même virtuelle.

Autrement dit, sont exclus de ces transactions les interactions directes avec la couche data :

• Data API (sauf si elle exécute un script)
• OData (sauf si elle exécute un script)
• PHP/XML (sauf s’ils exécutent un script)
• ODBC
• Instruction de script Tronquer la table
• Un fichier est défini comme une source de données externes d’un fichier d’interface dans lequel les transactions de fenêtres sont activées (déclencheur actif), mais les données sont modifiées depuis un autre fichier.

Voilà pourquoi même si un système de log était fourni, cette fonctionnalité ne permettrait pas d’avoir un réel « audit log ».

Nous l’avons déjà évoqué, l’interface de configuration se trouve dans les options de fichier.

On peut sélectionner le script qui sera activé quand on valide une transaction, et indiquer facultativement le nom hard-codé d’une rubrique. Comme pour les autres déclencheurs au niveau du fichier, seul un script du fichier en cours peut être sélectionné. Dans ce cas ci, c’est un peu dommage, mais on comprend bien la raison.

Quand une transaction est validée, le script sera déclenché et recevra automatiquement un paramètre en JSON tel que :

{
   "nomDuFichier":
   {
       "nomDeLaTable":
       [
             [ //(pour chaque enregistrement):
                  type de modification ("New", "Modified" ; "Deleted"),
                  ID de l'enregistrement,
                  "paramètre facultatif"
             ];
             [ 
                  type de modification ("New", "Modified" ; "Deleted"),
                  ID de l'enregistrement,
                  "paramètre facultatif"
             ]
        ]
   }
}

Comme vous l’avez repéré du premier coup d’œil car vous êtes désormais des experts en JSON, les enregistrements modifiés sont les éléments d’un tableau (array), avec 3 informations dont il faut donc connaître l’ordre : le type de modification (New, Modified, Deleted), l’ID de l’enregistrement, et le paramètre facultatif, qui sera présent mais vide si vous ne l’avez pas défini.

L’autre chose que vous avez immédiatement repérée est qu’il n’y a pas de trace de données ou de noms de rubriques modifiées.

Le contenu du paramètre facultatif provient de la fameuse rubrique que vous avez pu choisir dans les options du fichier.

Si vous n’avez pas indiqué de nom de rubrique et qu’il existe une rubrique du nom de OnWindowTransaction (un truc que vous n’auriez pas inventé si on ne vous l’avait pas dit… un peu comme la chanson de la Sorcière du placard aux balais), cette rubrique sera prise en compte.

Donc au moment de la validation de la transaction, pour chaque enregistrement créé, modifié, ou supprimé (dans ce dernier cas la rubrique est évaluée avant la suppression), la rubrique -qui peut bien sûr être calculée- est évaluée et son contenu transmis comme paramètre facultatif pour cet enregistrement.

JSON

Notons que si le contenu de la rubrique est un JSON, ce JSON n’est pas rendu en string (« stringifié »). Pour être très précis, afin de ne pas perdre trop de temps à valider chaque JSON, ce qui ralentirait fortement les transactions avec beaucoup d’enregistrements, FileMaker considère que si le contenu commence et finit par { et } ou [ et ], il s’agit d’un JSON valide.

Il existe neuf manières de modifier plusieurs enregistrements en une opération avec FileMaker.

Certaines d’entre elles sont parfaitement gérées par les transactions de fenêtres, d’autres non.

Eliminons d’abord celles qui ne sont pas gérées, mais gardons-les en tête si nous voulons vraiment parler d’audit log :

• requêtes externes directement sur la couche données (Data API, OData, PHP/XML, ODBC). Dans le cas d’exécution de script (et donc de l’existence d’une fenêtre), les transactions de fenêtre auront lieu.
• action de script Tronquer la table.
• modification du schéma de données (on peut supprimer une table, créer une rubrique calculée ou modifier une formule de calcul, valider la modification, puis changer le type de rubrique pour en faire une rubrique standard, et les données ont été modifiées sans qu’il y ait de transaction de fenêtre.
• ajoutons une variante de cette dernière : la création de fichier par conversion. Si par exemple vous glissez un fichier Excel sur l’icône de FileMaker, vous obtiendrez un fichier avec déjà une table et des données, avant même d’avoir pu configurer le moindre déclencheur ou le moindre script.

Les méthodes gérées sont donc :

Les méthodes non transactionnelles :

• Les importations (Importer enregistrements, Importer un dossier, Importer depuis une source ODBC) sont capables de créer ou modifier des données, ou les deux à la fois.
• Supprimer tous les enregistrements (ou Supprimer les enregistrements trouvés, selon qu’on a fait une sélection préalablement ou non)
• Remplacer le contenu d’une rubrique

Les méthodes transactionnelles :

• Les transactions par lien, telles qu’elles existent depuis que FileMaker est relationnel (FileMaker 3, sorti en 1996) : on peut modifier l’enregistrement principal (celui affiché) ainsi que créer, modifier, supprimer des enregistrements liés -la suppression nécessitant une table externe.
• Les transactions de FileMaker 19.6, qui sont la même chose si ce n’est que :
  • elles peuvent être faites en changeant de contexte (on n’a donc plus besoin de lien)
  • elles peuvent inclure les autres types de transactions massive (importation, suppression de l’ensemble trouvé, remplacer)

Importance de l’utilisation des transactions de script « de la 19.6 » pour les transactions massives

Pour les méthodes transactionnelles, c’est assez évident : une transaction occasionnera une et une seule transaction de fenêtre (tous les enregistrements créés, modifiés et supprimés se retrouveront  donc dans le paramètre du script)

Quant aux trois autres méthodes (import, supprimer tous, remplacer), il est très avantageux de les inclure également dans une transaction.

En effet, contrairement à notre FM AuditLog Pro (qui sera bien évidemment mis à jour très prochainement pour tirer parti de cette nouvelle fonctionnalité) qui parvenait à réunir les différentes transactions réelles en une seule transaction logique, les transactions de fenêtres reflètent exactement le fonctionnement interne de FileMaker.

Par exemple, quand on supprime tous les enregistrements, FileMaker les supprime 100 par 100. Quand on importe, cela dépend du format du fichier (par tranches de 25 pour le format csv, mais par tranches alternées de 25 et de 1000 pour le format mer (un csv avec les titres de colonnes), par tranches de 500 pour Remplacer contenu rubrique…
Bref, c’est tout ce que j’avais découvert en développant FM AuditLog Pro, mais cette « popote interne » n’intéresse sûrement pas l’utilisateur et on aurait préféré qu’un import ou une suppression soit résumé en une transaction. Or ça n’est pas le cas, le script SurOperationFenetre sera déclenché autant de fois qu’il y a de transactions internes. Il est donc très important d’encapsuler ces opérations dans une transaction de script.

Conseil : si l’utilisateur peut lui-même procéder à un import, à une suppression de l’ensemble trouvé, ou à un remplacement de rubrique, nous recommandons d’utiliser les menus personnalisés pour remplacer ces commandes, avec des scripts associés tels que :

Ouvrir une opération
   Importer enregistrements
Valider l'opération

Reste le cas marginal où l’utilisateur est déjà dans le cas d’une transaction (opération) avec un script en pause. Si on veut éviter l’erreur 3 pour des transactions imbriquées (erreur qui ne pose pas de problème mais c’est moins joli et on aime bien que ce soit joli), alors on peut écrire :

Si [ Obtenir ( EtatOperationOuvert )]
   Importer enregistrements
Sinon
   Ouvrir une opération
      Importer enregistrements
   Valider l'opération
Fin de si

Data API, OData, XML

Pour ce qui est de ces modes d’interaction avec FileMaker, il existe la possibilité de privilégier les scripts. Afin de garantir la validité d’un audit log (au sens strict), on pourra, dans les réglages de sécurité, s’assurer que ces modes d’interaction ne peuvent modifier des enregistrements que si un script est en cours d’exécution.

not EstVide ( Obtenir ( NomScript ))

Mais cela se fait malheureusement au prix d’une baisse des performances.

On peut vraiment regretter que le pas de script Exécuter FileMaker Data API soit limité à la lecture. Il serait tellement plus simple de convertir les appels à l’API en scripts…

Depuis toujours, deux événements se distinguent dans la manière de modifier des données : le drag and drop et Remplacer contenu de rubrique.

En effet, ces deux événements ont la particularité de pouvoir opérer sur des enregistrements non ouverts préalablement, de modifier les enregistrements, et de les garder « fermés », sans déclencher d’événement SurValidationEnregistrement donc.

Dans le cas du glisser/déposer, cela va même encore plus loin puisque l’on peut carrément modifier un enregistrement alors qu’il est ouvert par un autre utilisateur !

Et bien c’est une excellente nouvelle : les transactions de fenêtre permettent désormais de capter ces événements. Si l’enregistrement actif n’est pas ouvert quand on entame une action de remplacement ou que l’on glisse un contenu sur une rubrique, alors une transaction de fenêtre sera déclenchée après l’événement.

En terme d’intégrité des données, c’est un gros progrès !

Une des difficultés que l’on rencontrera en mettant en place un script pour logguer ses transactions, c’est d’inhiber le script après avoir enregistré la transaction.

Souvenons-nous, toutes les transactions ayant lieu dans une fenêtre du fichier déclenchent le script.

Parade : écrire en début de script une condition de sortie comme

Si [ Obtenir ( NomModèle ) = <leModèleSurLequelJeLogueLesTransactions>
   Fin de Script
Fin de Si
Suite du script

Un bug ennuyeux

La version qui sort aujourd’hui comporte un bug très ennuyeux. Gageons qu’il sera vite réglé lors d’une prochaine mise à jour.

Lors de l’exécution du script SurOperationFenetre, l’action de script Fermer Fenêtre est tout simplement ignorée. Elle ne retourne pas d’erreur mais est sans effet.

C’est très embêtant car comme souvent, quand on ne veut pas perdre le contexte de l’utilisateur (onglets sélectionnés, position de défilement de la fenêtre et des tables externes…) un script classique serait de la forme :

Nouvelle fenêtre
Activer modèle [ <modèleOùJeLogueLesTransactions> ]
Nouvel enregistrement
Définir rubrique [ rubrique ; Obtenir ( ParamètreScript )]
Fermer Fenêtre

Or la dernière action ne sera pas prise en compte ! C’est embêtant.

En attendant la correction, deux parades à cela :

• dès le départ, transmettre le paramètre à un script exécuté sur serveur, mais cela présente deux inconvénients majeurs :
  • si l’on n’est pas sur serveur (c’est encore le cas dans de nombreuses situations, notamment pour des applications asynchrones sur iPhone ou iPad)
  • sur des grosses transactions, la taille limite du paramètre pourrait être atteinte (un million de caractères)
• utiliser un déclencheur SurTemporisation. Le script prend donc la forme :

Nouvelle fenêtre
Activer modèle [ <modèleOùJeLogueLesTransactions> ]
Nouvel enregistrement
Définir rubrique [ rubrique ; Obtenir ( ParamètreScript )]
Installer un script sur temporisation [ script: Fermer fenêtre; Intervalle : 0,00001 ]
Fin de script

Et bien sûr le script Fermer fenêtre… ferme la fenêtre ! (Bravo si vous aviez deviné ! 😉 )

Si vous avez lu jusqu’ici, vous allez être récompensé(e), car au-delà des aspects techniques, la grande question est : « que faire de cette nouvelle fonctionnalité ? »

Or vous allez le voir, le potentiel est énorme -« juste énorme ! », comme disent ceux qui sont nés après la sortie de FileMaker 7.

Exemples d’utilisation :

• Bien sûr, garder la trace des modifications. Cela tombe sous le sens mais il ne faut pas l’oublier
• Mettre à jour des enregistrements liés, voir des « vues ». C’est un éternel challenge avec FileMaker -dépourvu de déclencheurs de tables (OnUpdate)- de mettre à jour des enregistrements liés. Par exemple si je mets à jour le montant d’un paiement je veux que la facture correspondante soit mise à jour, ainsi que la fiche client (pour connaître son solde). Dorénavant, je peux capter à coup sûr qu’un enregistrement de la table PAIEMENTS a été créé/modifié/supprimé et mettre à jour les enregistrements correspondants.
  On peut facilement envisager des tables de vues qui remplacent les vues liste et qui synthétisent l’information que l’utilisateur doit voir, sans calcul et sans lien, afin d’optimiser la vitesse de défilement ou de tri).
  Par exemple un enregistrement de la table CLIENTS, qui est liée à n factures, n commandes, n paiements… peut avoir son pendant dans la table CLIENTS_VUE, avec des rubriques standard (non calculées) qui permettent d’afficher des listes très rapides. Il est en effet relativement facile de développer une logique qui provoque le rafraichissement d’un tel enregistrement dès qu’un paiement, une commande ou une facture est modifié dans une transaction.
• « Réplication ». avec un outil comme FM AuditLog Pro 3.0 en préparation, il sera possible non seulement de faire du Roll-back comme avec FM AuditLog Pro 2.0, mais on pourra ré-exécuter les transactions sur un autre serveur, par exemple dans un scénario ou des utilisateurs travaillent sur plusieurs continents, chacun sur son serveur, mais où les modifications doivent être reportées sur un serveur central.

Voilà, j’espère que ces quelques pistes vous auront permis d’envisager le potentiel de cette nouvelle fonctionnalité et que vous avez apprécié cet article au point de le partager sur les réseaux.