JSONPath améliore l’accès aux données de notre moteur
Dans les systèmes numériques, les données alimentent la logique de décision. Les moteurs de règles les traitent. Leur volume et leur structure évoluent, l’accès aux données doit donc rester souple. JSONPath répond à ce besoin.
JSONPath est notre méthode privilégiée pour accéder aux données dans un moteur de règles. Elle permet d’atteindre directement les valeurs imbriquées, sans définir chaque attribut individuellement. La maintenance des règles s’en trouve simplifiée.
Les moteurs de règles traditionnels reposent souvent sur un ensemble fixe d’attributs. JSONPath s’adapte aux structures dynamiques. De nouveaux champs peuvent être ajoutés sans modifier manuellement les définitions d’attributs. JSONPath gère aussi les tableaux, ce qui est utile lorsque la logique de décision doit parcourir des listes d’objets.
Il faut un peu de temps pour se familiariser avec cette syntaxe, qui diffère de la simple recherche d’un champ. Cet apprentissage en vaut la peine lorsque l’ensemble de règles doit rester souple et lisible.
JSONPath en pratique : un exemple
Voici un objet JSON pour illustrer le fonctionnement de JSONPath :
{
"employees": [
{
"id": 1,
"name": "John",
"department": "Sales",
"email": "john@example.com"
},
{
"id": 2,
"name": "Jane",
"department": "Marketing",
"email": "jane@example.com"
}
]
}
Cet objet contient un tableau d’employés. Chaque employé possède plusieurs attributs.
Voici comment JSONPath permet d’accéder à certaines parties des données :
1. Accéder à un attribut précis d’un objet dans un tableau
Pour récupérer l’attribut « name » du premier employé, utilisez :
$['employees'][0]['name']
Le résultat est « John ».
2. Utiliser un caractère générique pour accéder aux données
L’opérateur caractère générique (*) renvoie le même attribut pour chaque objet du tableau. Pour récupérer l’attribut « email » de tous les employés, utilisez :
$['employees'][*]['email']
Le résultat est une liste d’adresses e-mail : ["john@example.com", "jane@example.com"].
3. Accéder aux données à l’aide d’une tranche de tableau
JSONPath permet aussi de sélectionner une tranche de tableau. Pour récupérer les noms des deux premiers employés, utilisez :
$['employees'][0:2]['name']
Le résultat est : ["John", "Jane"].
4. Récupérer tous les attributs d’un objet
JSONPath peut aussi renvoyer un objet entier. Pour récupérer tous les attributs du premier employé, utilisez :
$['employees'][0]
Le résultat est l’objet complet de l’employé : {"id": 1, "name": "John", "department": "Sales", "email": "john@example.com"}.
Ces exemples illustrent l’intérêt de JSONPath : les données JSON sont plus faciles à parcourir dans un moteur de règles. La logique de décision reste ainsi claire et plus facile à maintenir.
En conclusion
JSONPath permet de traiter les données de façon dynamique et de gérer les structures qui évoluent, sans réécrire constamment les règles. Le moteur de règles reste lisible et fonctionnel. C’est pourquoi nous avons choisi JSONPath pour accéder aux données.
Questions fréquentes
Quand un prêteur devrait-il utiliser JSONPath plutôt que de définir explicitement chaque attribut d’entrée ?
JSONPath convient lorsque la source présente des structures imbriquées réellement variables, par exemple une liste de comptes dont la taille peut changer. Pour des données d’entrée stables utilisées dans les principaux critères d’octroi, des correspondances explicites sont généralement plus faciles à examiner et à tester. Il faut mettre en balance la souplesse obtenue et le soin nécessaire pour définir le comportement en cas de valeur absente ou trouvée à un emplacement inattendu.
Comment tester une règle de décision qui lit des valeurs dans un tableau ?
Il faut d’abord définir le comportement de la règle lorsque le tableau est vide, contient un élément ou en contient plusieurs. Testez chacun de ces cas, ainsi que les valeurs manquantes, les doublons et les différentes positions des éléments. Déterminez explicitement si les critères d’octroi portent sur un total, une valeur maximale ou une condition satisfaite par au moins un élément. Sinon, un changement dans l’ordre des données source peut modifier la décision de façon inattendue.
Que doit faire une règle de décision si une valeur imbriquée est absente ou d’un type incorrect ?
Traitez séparément les valeurs absentes, invalides et égales à zéro. Définissez pour chacune une issue validée au regard des critères d’octroi, par exemple demander des données corrigées ou transmettre le dossier pour examen. Ne remplacez pas discrètement une valeur par zéro ou par une autre valeur par défaut : des données incomplètes pourraient alors sembler valides. Consignez la condition d’entrée qui a influé sur la décision.
Comment déployer une règle de décision après une modification de la structure d’une source de données ?
Conservez un ensemble de dossiers de test représentatifs et exécutez la version révisée de l’ensemble de règles sur ces dossiers avant le déploiement. Incluez des cas courants et des cas limites, puis comparez les résultats avec ceux de la version actuelle et examinez chaque différence. Faites approuver les changements de décision par le responsable des critères d’octroi. Il faut mettre en balance le temps consacré aux vérifications de compatibilité et le coût d’un changement inattendu dans les décisions en cours.
