Cette page donne la marche à suivre pour intégrer une nouvelle source de données, en plusieurs étapes:
- Définition des attentes / Écriture de tests automatisés
- Implémentation du parseur
- Mise à disposition des données pour la chaine de traitement
- Publication des données sur le web
- Pré-traitement des données pour l'apprentissage et la génération de listes
- Détection des fichiers pour population automatique du
batch
à importer
La plupart de ces étapes auront pour effet d'enrichir les fonctionnalités de la commande sfdata
, en modifiant le code source du dépôt signaux-faibles/opensignauxfaibles.
Pré-requis:
-
Se procurer des données d'exemple depuis cette source + la documentation de leur format
-
Vérifier que cette source de données n'est pas déjà supportée, ou redondante avec une source déjà supportée (cf Description des données, Tableau des types de fichiers supportés et liste
registeredParsers
deopensignauxfaibles
) -
Choisir un identifiant unique mais reconnaissable (ex:
paydex
,sirene_ul
...) qui sera utilisé pour nommer le parseur, grouper les fichiers de ce type dans lebatch
et pour identifier la source d'erreurs éventuelles de parsing dans le Journal
Étapes recommandées:
-
Constituer un jeu de données concis et anonymisé (mais réaliste et représentatif) qui sera utilisé pour tester le bon fonctionnement du parseur et du reste de la chaine de traitement sur ces données. Exemple:
lib/paydex/testData/paydexTestData.csv
-
Inclure ces données de test dans le
batch
detest-import.sh
. Nous allons laisser le test échouer, jusqu'à ce que le parseur soit opérationnel. (cf dernière étape de la section suivante) Exemple: ajout d'un fichierpaydex
dans la propriété"files"
Ces premières étapes vont permettre de mesurer notre avancement pendant l'implémentation du parseur, en observant les résultats de chaque itération, après avoir exécuté tests/test-import.sh
.
Étapes recommandées:
-
Écrire un test unitaire pour définir les données attendues en sortie du parseur, après lecture du jeu de données de test constitué à l'étape précédente. Ce test passera une fois que le parseur sera correctement implémenté. Exemple:
"should parse a valid row"
défini pour le parseurpaydex
-
Définir le type
struct
en sortie du parseur, sans oublier d'implémenter les méthodesKey()
,Scope()
etType()
associées. Exemple: typePaydex
-
Écrire le parseur en implémentant les méthodes attendues par l'interface
marshal/parser.go
puis définir une variable publique contenant une instance de ce parseur. Exemple: instance depaydexParser
-
Ajouter l'instance du parseur dans
registeredParsers
. Exemple: association de l'instancepaydex.ParserPaydex
à l'identifiantpaydex
-
Exécuter
go generate ./...
,make
puistests/test-import.sh --update
pour inclure danstests/output-snapshots/test-import.golden.txt
les données parsées depuis le jeu de données de test. Si nécéssaire, effectuer des modifications du parseurs puis ré-exécuter ces commandes.
Une fois le parseur fonctionnel et correctement testé, nous allons documenter les données qu'il intègre puis rendre ces données exploitables par les commandes sfdata public
et sfdata reduce
.
Étapes recommandées:
-
Ajouter une section dans
description-donnees.md
pour décrire la source des données. Exemple: ajout de la documentation des données Ellisphere -
Ajouter la source dans la liste des fichiers supportés, de
processus-traitement-donnees.md
. Exemple: ajout de la sourcepaydex
dans la liste -
Pour permettre la validation des données importées en base de données ainsi que pour garantir l'alignement de leur structure (en sortie du parseur) avec les types qui seront manipulés en TypeScript/JavaScript par la chaine de traitements, écrire un fichier JSON Schema dans le répertoire
validation
et le référencer dans la listetypesToCompare
devalidation/validation_test.go
. -
Générer les types TypeScript (
js/GeneratedTypes.d.ts
) à l'aide de la commandego generate ./...
puis exécutergo test ./...
pour s'assurer que le fichier JSON Schema est aligné avec la structure en sortie du parseur. -
Ajouter un champ pour la nouvelle source de données dans le type
EntrepriseBatchProps
ouEtablissementBatchProps
dejs/RawDataTypes.ts
. Utiliser l'identifiant de la source de données en guise de clé et le type TypeScript correspondant, celui qui a été ajouté àjs/GeneratedTypes.d.ts
dans l'étape précédente. Dans les documents de la collectionRawData
, cette propriété contiendra les données de la nouvelle source, classées parhash
. Exemple: ajout depaydex: ParHash<EntréePaydex>
dans le typeEntrepriseBatchProps
Note: cet ajout aura pour effet de rendre incomplets les jeux de données employés par des tests d'intégration définis dans les répertoires
js/public/
etjs/reduce.algo2/
. Nous allons compléter ces données de tests dans les étapes suivantes.
La publication de données sur l'application web de Signaux Faible commence par l'exécution d'une opération map-reduce sur la collection RawData
appelant des fonctions TypeScript.
Dans la section précédente, nous avons documenté le type des entrées de données introduites de manière à ce qu'elles soient manipulables depuis ces fonctions, tout en bénéficiant de la vérification statique de l'intégrité de ces données.
Il ne nous reste donc plus qu'à tester la présence et la validité de ces entrées, puis à les intégrer dans les fonctions de l'opération map-reduce appelée public
.
Étapes recommandées:
-
Compléter le test d'intégration "public.map() retourne toutes les propriétés d'entreprise (ou d'établissement) attendues sur le frontal" défini dans
js/public/ava_tests.ts
, en ajoutant àrawEntrData
(ourawEtabData
) la propriété rattachant des données de test au nom de la source de données. Exemple: ajout depaydex
àrawEntrData
. -
Implémenter l'intégration des entrées de données dans la fonction
map()
du map-reducepublic
, dans le fichierpublic/map.ts
. Exemple: intégration du champpaydex
dansmap()
Note: Si l'intégration prend un nombre considérable de lignes de code, ne pas hésiter à l'extraire dans une fonction séparée, définie dans un fichier dédié. Exemple:
public/diane.ts
. Dans ce cas, ne pas oublier d'inclure cette fonction dans l'espace de nomsf
, défini dansfunctions.ts
. Exemple: inclusion deraison_sociale
danspublic/functions.ts
- Pour transpiler et empaqueter les fonctions en JavaScript puis mettre à jour les clichés (snapshots et golden masters) de résultats attendus de tests automatisés, exécuter
./test-all.sh --update-snapshots
.
La génération de liste de détection et l'apprentissage permettant ces prévisions s'appuie sur des variables pré-traitées par l'exécution d'une opération map-reduce sur la collection RawData
appelant des fonctions TypeScript.
Plus haut, nous avons documenté le type des entrées de données introduites de manière à ce qu'elles soient manipulables depuis ces fonctions, tout en bénéficiant de la vérification statique de l'intégrité de ces données.
Il ne nous reste donc plus qu'à tester la présence et la validité de ces entrées depuis l'opération map-reduce appelée reduce.algo2
, puis à les intégrer dans les fonctions appelées par cette opération.
Étapes recommandées:
-
Compléter le test d'intégration "algo2.map() retourne les propriétés d'entreprise (ou d'établissement) attendues par l'algo d'apprentissage" défini dans
js/reduce.algo2/algo2_tests.ts
, en ajoutant àrawEntrData
(ourawEtabData
) la propriété rattachant des données de test au nom de la source de données. Exemple: ajout depaydex
àrawEntrData
. -
Implémenter l'intégration des entrées de données dans la fonction
map()
du map-reducereduce.algo2
, dans le fichierreduce.algo2/map.ts
. Exemple: intégration du champpaydex
dansmap()
Note: Si l'intégration prend un nombre considérable de lignes de code, ne pas hésiter à l'extraire dans une fonction séparée, définie dans un fichier dédié. Exemple:
reduce.algo2/entr_paydex.ts
. Dans ce cas, ne pas oublier d'inclure cette fonction dans l'espace de nomsf
, défini dansfunctions.ts
. Exemple: inclusion deentr_paydex
dansreduce.algo2/functions.ts
-
Recommandé: écrire des tests unitaires pour documenter les traitements effectués et éviter les régressions. Exemple:
reduce.algo2/entr_paydex_tests.ts
-
Exporter un type
Variables
constitué des propriétéssource
,computed
ettransmitted
, afin de générer de manière automatique la documentation des variables fournies à l'algorithme (js/reduce.algo2/docs/variables.json
). Exemple: description des champs calculés et transmis deentr_paydex
.
Note: Le commentaire JSDoc de chaque champs sera automatiquement extrait comme description de ce champ, au moment de la génération de
variables.json
. Exemple: commentaire JSDoc du champstatut_juridique
deentr_paydex
- Pour transpiler et empaqueter les fonctions en JavaScript puis mettre à jour les clichés (snapshots et golden masters) de résultats attendus de tests automatisés, exécuter
./test-all.sh --update-snapshots
.
La nouvelle source de donnée est désormais supportée par toute la chaine d'intégration couverte par la commande sfdata
.
Pour faciliter l'intégration régulière de données, nous pouvons à présent faire en sorte que la commande prepare-import
reconnaisse automatiquement les fichiers permettant d'importer ces données.
Étapes recommandées:
-
Ajouter le(s) nom(s) de fichier(s) de test dans le test de bout en bout de
prepare-import
(main_test.go
). Exemple: intégration d'un fichier paydex de test -
Ajouter dans le test unitaire
TestExtractFileTypeFromFilename
quelques exemples de noms que pourraient avoir les fichiers issues de la nouvelle source de données, pour assurer que ces noms seront systématiquement reconnus parprepare-import
. Exemple: ajout de noms de fichierssirene
etpaydex
. -
Implémenter la détection du type de données à partir du nom du fichier (exemple: détection
paydex
par une expression régulière), ou à partir des métadonnées associées (exemple: détectionbdf
depuis la métadonnéegoup-path
). -
Vérifier que tous les tests passent, et mettre à jour les clichés (snapshots et golden masters) de résultats attendus par les tests automatisés, en exécutant
make test-update
.