Préparation de données (issues d'un CMS) et diffusion (API, export)

Le CNRS développe un nouveau CMS pour créer des "coopératives de données" sur les territoires. Ces données seront communiqués au format Json à des dispositifs tiers via des exports quotidiens et une API de consultation. Il est à noter qu'il y aura autant de structure des données que de "coopératives de données" créées avec ce CMS d'un nouveau genre. Ce qui signifie que le logiciel devra s'adapter à différentes configurations de données (nombres et types d'objets, nombre et types de champs, relations) ; pour autant ces structures seront toujours basées sur le modèle objets/relations.
Dans ce contexte, nous cherchons un développeur freelance qui réalisera les fonctionnalités de prépartation des données pour différents clients (sites web, applications mobiles, widgets, plugins, etc.) et leur mise à disposition via une API et un module d'export.
Le cahier des charges sera à définir entre le commanditaires (énonciation des besoins dans un environnement logiciel plus large) et le prestataire (proposition de solutions techniques adaptées aux besoins).

L'ensemble de cette partie logicielle sera organisé en trois processus :

• PROCESSUS 1
a) création de Json à partir de modèles de formats
Il s'agit de produire des Json en des formats prédéfinis à partir des données relationnelles d'une bdd mise à disposition par le commanditaire. Les modèles de formats sont rédigés dans un formalisme prédéfinit (propre au logiciel). Pour préparer les Json, ces modèles peuvent filtrer les objets "candidats" (pour récupérer des champs selon une fonction "conditions"*), réaliser des concaténations de champs et faire appel à des fonctions php (ex : Ucfirst). Plusieurs modèles de formats peuvent être créés et enregistrés dans une table de configuration admin. Les Json produits avec ces différents modèles sont stockés sur une table dédiée.
b) sélection des objets "candidats" pour créer une liste d'objets "éligibles"
A partir de la configuration du client** et de la fonction "conditions"* fournie par le commanditaire, il s'agit de sélectionner les objets et relations "éligibles" (qui répondent aux conditions enregistrées sur le compte du client) dans la base de données des "candidats". Pour chaque objet éligible (et relations associées), il est spécifié son statut de fourniture : création (nouvel objet depuis la dernière fourniture), modification , suppression, null (objet toujours éligible mais changement depuis la dernière fourniture). Les "éligibles" sont stockés dans une table spécifique sous format Json, sans les contenus associés (uniquement les données techniques : id, date_creation, etc.)

• PROCESSUS 2 (à terme, ce processus sera sur un autre serveur ; il communiquera avec les Processus 1 & 3 par API et il s'appuie sur une autre bdd que le Processus 1 & 3)
a) création des Json "lauréats" à partir de la liste des "éligibles"
Le premier processus a permis de créer une sélection d'objets et relations "éligibles", ici il s'agit d'appliquer une seconde série de filtres pour en extraire une liste d'objets et de relations "lauréats". Cette nouvelle méthode de sélection fait appel à des données externes à la BDD du processus 1 et ce module pourra accueillir toutes sortes de données externes et traitements à des fins de filtrage de la première liste d'objets éligibles. Pour une première utilisation de ce module nous ferons appel à une base de données du type "distancier" (distance kilométrique entre les différentes communes d'un territoire) fournie par le commanditaire. Il s'agira de filtrer les objets liés à une commune en fonction de leur distance kilométrique avec une commune de référence (enregistrée dans une table de configuration des clients).
b) création de Json de "manipulation"
Comme précédemment, ce module accueillera à terme différentes données externes afin de les préparer pour chaque client en fonction de la liste de "ses objets lauréats" (précédemment créée) et de la configuration du client. Nous crérons ici les premiers Json issus de ce module à partir de la bdd distanciers (la même que précédemment). Il s'agit donc de produire pour chaque client un Json indiquant la distance kilométrique entre la commune de l'objet éligible et la commune de référence (config client du processus 2). Ces Json seront enregistrés dans une bdd dédiée et fournis aux clients via une API. Si le plugin "distance kilométrique" appliqué à ce module doit être fonctionnelle, le module devra permettre d'accueillir d'autres plugins de création de Json de manipulation à partir d'autres types de données (du type attribut ou distance entre 2 objets).

• PROCESSUS 3 (sur le même serveur que le Processus 1)
a) Création d'un Json par client
A partir des objets et relations "lauréats" issues des processus 1 puis 2, ainsi que des Json d'objets et relations préparés dans le processus 1 à partir des modèles de formats, le logiciel cré un Json par client (concaténation des Json d'objets et relations filtrés par la liste de lauréats).
b) Fourniture des Json clients
Les Json précédemment créés seront mis à disposition des clients par un export (vers des plugins de CMS, par exemple) ou par API (destiné à être consultée depuis un widget, par exemple).

* fonction "conditions" : le commanditaire met à disposition la fonction qui permet de retourner true/false à partir de conditions pré-enregistrées par l'utilisateur et passées en variables (parcours du réseau de relations & test des champs des objets parcourus)

** La configuration du client sera enregistrée dans une table dédiée, à ce stade de développement (prototype), il n'est pas attendu un formulaire de configuration (ou bien un formulaire très rudimentaire !).