Aller au contenu

Feed Inspector

Statut

CONTRACT / GUIDE OPÉRATEUR

Le Feed Inspector désigne la capacité d'inspection read-only utilisée pour comprendre un feed sans lui accorder de droit d'exécution Runtime.

Cette page décrit ce contrat opératoire. Elle ne doit pas être utilisée seule pour conclure qu'une commande WP-CLI littérale particulière est enregistrée. Vérifier l'aide réellement disponible avant exécution.

Pourquoi le Feed Inspector existe

L'industrialisation d'un marchand doit commencer par l'observation des données réelles, pas par une activation Runtime ni par un patch.

Le Feed Inspector sert à répondre à des questions comme :

  • le fichier ou endpoint source est-il lisible ?
  • quelles familles de produits sont réellement présentes ?
  • les identifiants nécessaires existent-ils ?
  • les catégories et attributs sont-ils exploitables ?
  • quelles anomalies sont propres au marchand ?
  • le feed est-il suffisamment compris pour envisager une intégration ?

Il applique la règle : observer avant de modifier.

PREPARED n'est pas ACTIVE

Point essentiel pour la maintenance : un marchand présent dans ccx_feeds_registry() peut être PREPARED sans être actif dans le Runtime.

L'autorité d'activation Runtime reste :

CCX_ACTIVE_FEEDS
        +
ccx_feed_runtime_active_feeds()

Le Feed Inspector peut lire un feed PREPARED à des fins d'analyse sans lui accorder :

  • de planification ;
  • de synchronisation automatique ;
  • de worker Runtime ;
  • de droit d'écriture métier ;
  • de statut ACTIVE.

Ne jamais confondre « inspectable » avec « activé ».

Position dans l'architecture

source marchande
    ↓
téléchargement / spool d'inspection éventuel
    ↓
parsing ou lecture technique
    ↓
Feed Inspector / Read Service
    ↓
rapport et évidences
    ↓
décision humaine

Le Feed Inspector ne devient ni le Pipeline, ni le Runtime, ni un Write Service.

Effets autorisés

L'inspection est read-only sur la vérité métier et les projections.

Elle peut néanmoins avoir des effets techniques explicitement nécessaires à la lecture, par exemple :

  • effectuer une requête réseau vers la source marchande ;
  • télécharger une copie dans un spool temporaire ;
  • créer un artefact local de rapport lorsque l'opérateur le demande explicitement.

Ces effets techniques ne doivent pas être assimilés à une activation ou à une écriture métier.

Ce qu'il doit observer

Selon le feed, l'inspection peut relever :

  • volume de lignes ;
  • format et encodage ;
  • colonnes ou clés disponibles ;
  • taux de champs vides ;
  • exemples d'identifiants (EAN, SKU, MPN, identifiant marchand) ;
  • catégories source ;
  • prix et disponibilité lorsqu'ils existent ;
  • URLs et médias ;
  • anomalies de parsing ;
  • répétitions ou valeurs manifestement bruitées.

Les KPI utiles dépendent du marchand et de la verticale. Ils ne doivent pas être inventés par l'Adapter CLI.

Workflow recommandé

1. vérifier que le marchand est enregistré
2. vérifier son statut PREPARED / ACTIVE
3. inspecter la source en lecture
4. produire un baseline
5. isoler les anomalies
6. comparer avec les contrats génériques et verticaux
7. simuler les corrections éventuelles
8. seulement ensuite décider d'une évolution

Pour un marchand PREPARED, l'étape 8 n'implique pas automatiquement son activation.

Diagnostic d'un feed

La source ne répond pas

Vérifier d'abord :

  • URL ou mécanisme source ;
  • DNS/réseau ;
  • authentification éventuelle ;
  • redirections ;
  • format retourné.

Ne pas modifier le Pipeline pour compenser un simple problème d'accès.

Le fichier est lisible mais mal parsé

Comparer le format réel avec l'Adapter/importeur concerné : séparateur, encodage, noms de colonnes, JSON/XML, compression, etc.

Les données sont lisibles mais insuffisantes

Documenter ce qui manque. Ne pas fabriquer de fausse évidence pour forcer une résolution ou une activation.

Les KPI semblent mauvais après un ancien patch

Repartir d'un échantillon ou d'une source fraîche lorsque l'état historique peut avoir été contaminé par des transformations antérieures.

Garde-fous

Le Feed Inspector ne doit jamais :

  • activer un feed ;
  • modifier CCX_ACTIVE_FEEDS ;
  • écrire une projection ;
  • déclencher une synchronisation complète par simple inspection ;
  • corriger silencieusement les données source ;
  • transformer un feed PREPARED en ACTIVE ;
  • faire porter des règles spécifiques au marchand au Domain Core générique.

Sortie utile à une transmission

Un rapport d'inspection doit permettre à un futur mainteneur de retrouver :

  • le marchand et la source inspectée ;
  • la date et le contexte ;
  • le statut PREPARED/ACTIVE observé ;
  • le volume analysé ;
  • les champs disponibles ;
  • les anomalies principales ;
  • des exemples reproductibles ;
  • les prochaines vérifications ;
  • la conclusion : aucune action, adaptation, simulation, ou étude d'activation.

Invariants

  1. Inspection ne signifie pas activation.
  2. PREPARED ne signifie pas ACTIVE.
  3. La lecture métier reste non destructive.
  4. Les effets techniques nécessaires à l'inspection sont documentés séparément.
  5. Le Feed Inspector produit des évidences, pas des décisions métier.
  6. L'activation Runtime est décidée par les mécanismes d'autorité prévus, jamais par l'outil d'inspection.

Voir aussi