Processus de données / 06
Transformer JSON et XML en un modèle cible fiable.
Les données sont techniquement lisibles mais restent rejetées. Noms de champs, types ou structures ne correspondent pas à l’application cible. Nous développons des mappings traçables qui traitent aussi les valeurs vides, les cas particuliers et les évolutions du format source.
La situation initiale
Une syntaxe valide ne garantit pas la cohérence métier.
Une interface XML fournit des articles avec des attributs et des espaces de noms. La cible attend des objets JSON, des chaînes explicites et un tableau contenant toutes les variantes. Un élément XML unique doit produire le même type cible que plusieurs éléments.
Nous définissons séparément le contrat source, le contrat cible et les règles de transformation. Les valeurs obligatoires, nulles et les chaînes vides reçoivent une signification métier ; les nombres et les dates ne sont pas modifiés par une conversion systématique en texte.
Ce que DataSource prend en charge
Chemins de champs, types et validation.
Modéliser
Recenser les champs, attributs, listes et références. Traiter les espaces de noms XML à partir de leur URI, sans dépendre uniquement de préfixes librement choisis.
Transformer
Implémenter le mapping, la conversion des types et la normalisation sous forme de règles versionnées. Préserver explicitement la précision décimale, les identifiants et les fuseaux horaires.
Valider
Vérifier le format source et le contrat cible. Les règles métier complètent JSON Schema ou XML Schema ; signaler les cas invalides avec un chemin de champ explicite.
Scénario technique / Exemple illustratif
Un article XML devient un objet clairement typé.
Exemple illustratif avec un espace de noms et un identifiant sous forme de chaîne. Le préfixe p est interchangeable ; l’URI de l’espace de noms détermine l’association. Le prix reste volontairement une chaîne décimale.
Données d’exemple et règles proposées. Les interfaces et règles métier concrètes seront examinées pour votre projet.
<p:product xmlns:p="urn:example:catalog" id="004218">
<p:price currency="EUR">49.90</p:price>
</p:product>
→ {
"sku": "004218",
"price": "49.90",
"currency": "EUR"
}Gestion des erreurs, sécurité et exploitation
Traiter explicitement les écarts de schéma.
Sécurité du parseur
Désactiver les entités XML externes et les ressources externes non contrôlées. Limiter la taille, la profondeur et le nombre d’éléments ; les données importées ne sont pas des programmes de confiance.
Changement de version
Documenter ensemble la version du mapping et le schéma source. Vérifier les nouveaux champs obligatoires sur des données de test représentatives et déployer de manière contrôlée.
Contexte de l’erreur
Indiquer l’enregistrement concerné et le chemin du champ. Utiliser les payloads sensibles uniquement dans des canaux de diagnostic protégés et expressément autorisés.
Questions métier
Les détails qui comptent avant la mise en œuvre.
JSON · XML · Espaces de noms · Types de données · Mapping · Schéma
La conversion est-elle sans perte ?
Uniquement avec un modèle convenu. XML comporte des attributs, des espaces de noms et du contenu mixte ; JSON ne les représente pas automatiquement de façon équivalente.
Faut-il toujours un schéma ?
Un contrat vérifiable est essentiel. Un schéma formel est utile, mais ne remplace pas des règles telles que la validité des références d’articles ou des transitions d’état.
Que deviennent les champs inconnus ?
Selon le contrat, ils sont ignorés, conservés ou rejetés. Ce comportement est défini explicitement avant la mise en production.
Pour la clarification technique
Partir de votre processus concret.
Préparez des exemples sources anonymisés, le schéma cible, les définitions des champs et les cas problématiques. Une structure de liste vide, à un élément et à plusieurs éléments facilite la vérification.
Le premier échange clarifie les accès disponibles, la responsabilité des données et un premier flux limité. Nous convenons ensuite du périmètre, des responsabilités et des conditions.
Des exemples anonymisés suffisent pour commencer. Merci de ne pas envoyer de mots de passe, tokens ou données personnelles de production dans la première demande.
Problématiques associées
La prochaine connexion dans son contexte.
Automatiser les imports CSV
Le fichier arrive chaque jour. Quelqu’un corrige les colonnes, l’importe et vérifie ensuite les messages d’erreur. DataSource transforme cette tâche récurrente en un import documenté avec des règles explicites pour les données incomplètes ou erronées.
Intégration REST API
La documentation est disponible et une requête de test fonctionne. Au quotidien, des données manquent pourtant ou des doublons apparaissent. DataSource relie votre API REST au processus métier concret et prévoit aussi les réponses qui n’arrivent pas.
Automatiser les processus de données produit
L’ERP fournit les données de référence, le PIM les textes et un fournisseur les caractéristiques techniques. Les listes manuelles ne relient ces informations que temporairement. Nous créons un flux défini du champ de référence à l’export validé pour chaque canal.