DocumentationCommerceData Export

Synchroniser les données avec l’export de données SaaS

Dernière mise à jour : 17 juin 2026

Créé pour :

  • {"id":"c66ffd68-0f65-42bb-aa23-b4020f12e0bd"},{"id":"ff6a42d2-313e-452e-93a6-792e4fad9ff8"}

Lorsque vous installez un service Adobe Commerce qui nécessite l’exportation de données, tel que Catalog Service, Live Search ou Product Recommendations, une collection de modules d’exportation de données SaaS est installée pour gérer le processus de collecte de données et de synchronisation.

L’exportation des données SaaS déplace régulièrement les données de produit d’une instance Adobe Commerce vers la plateforme Commerce Services afin de maintenir les données à jour. Par exemple, Recommandations de produits nécessite des informations de catalogue actuelles pour renvoyer avec précision des recommandations aux noms, prix et disponibilité corrects. Pour plus d’informations sur la surveillance du processus de synchronisation, voir Afficher et gérer le processus de synchronisation.

Le diagramme suivant illustre le flux d’exportation des données SaaS.

Collecte de données d'export SaaS et flux de synchronisation pour Adobe Commerce {width="900" modal="regular"}

Lorsque les données du catalogue changent dans Adobe Commerce, la synchronisation passe par ces étapes.

  1. Détection des modifications d’entité - Le système Mview de Magento détecte les modifications de ligne dans les tables de base de données auxquelles vous êtes abonné (par exemple, catalog_product_entity) et écrit les entrées dans une table de journal des modifications.
  2. Indexation des flux - L’indexeur des flux lit le journal des modifications, charge les données d’entité à partir des tables source et assemble les éléments de flux.
  3. Collecte et transformation des données - Les fournisseurs enregistrés dans le schéma de flux et_schema.xml collecter des données de champ.
  4. Déduplication de hachage - Un hachage de contenu est calculé pour chaque élément de flux. Les éléments dont le hachage n’a pas changé depuis la dernière exportation sont ignorés, de sorte que seules les données modifiées sont transmises.
  5. Envoi HTTP - Les éléments de flux sont envoyés par lots HTTP POST authentifiés au service d’ingestion de flux SaaS d’Adobe.
  6. Statut persistant - Le statut de la réponse de l’API est réécrit dans le tableau de flux pour chaque élément.
  7. Reprise en échec - Les éléments dont l’exportation a échoué sont automatiquement repris par une tâche cron planifiée.
NOTE
Pour les déploiements Adobe Commerce Optimizer Connector, SaaS Data Export gère la détection des modifications d’entité et l’assemblage d’alimentation. Le connecteur mappe ensuite les flux au format Catalog Data Ingestion API et les envoie vers Adobe Commerce Optimizer. Voir Pipeline de synchronisation du connecteur pour le contrôle de l’étendue, l’envoi et la gestion des erreurs.
NOTE
Pour garantir une planification fluide et éviter toute perturbation du fonctionnement du site, Adobe recommande d’estimer le volume de données et l’heure de synchronisation avant de démarrer la synchronisation des flux de données. Cette estimation est importante lors de la planification de synchronisations initiales ou de mises à jour de catalogue à grande échelle, telles que des modifications de prix en masse. Pour plus d’informations, voir ​ Estimation du volume de données et de la durée de transmission pour la synchronisation des données

Modes de synchronisation

L’exportation des données SaaS comporte deux modes de traitement des flux d’entités :

  • Mode d’exportation immédiat : dans ce mode, les données sont collectées et envoyées immédiatement au service Commerce en une seule itération. Ce mode accélère la diffusion des mises à jour d’entités au service Commerce et réduit la taille de stockage des tables de flux.

  • Mode d’exportation hérité : dans ce mode, les données sont collectées dans un seul processus. Ensuite, une tâche cron envoie les données collectées aux services commerciaux connectés. Dans les entrées du journal d’exportation de données, les flux qui utilisent le mode hérité sont étiquetés (legacy).

Types de synchronisation

L’exportation de données SaaS prend en charge trois types de synchronisation : synchronisation complète, synchronisation partielle et synchronisation des éléments ayant échoué à une nouvelle tentative.

Synchronisation complète

Après la connexion d’une instance Adobe Commerce au service Commerce, effectuez une synchronisation complète pour envoyer des données de flux d’entités d’Adobe Commerce au service connecté.

NOTE
La synchronisation complète est principalement destinée à la phase d’intégration. Évitez de l’utiliser régulièrement pour éviter la surcharge de la base de données. Après la synchronisation initiale, les modifications en cours sont automatiquement synchronisées à l’aide d’une synchronisation partielle.

Synchronisation partielle partial-sync

Avec une synchronisation partielle, l’exportation de données SaaS envoie automatiquement des mises à jour depuis l’application Commerce, telles que des modifications de nom de produit ou de prix, aux services commerciaux connectés.
Pour que la synchronisation partielle fonctionne, l’application Commerce nécessite la configuration suivante :

Réessayer la synchronisation des éléments ayant échoué retry-failed-items-sync

La synchronisation des éléments en échec de la reprise utilise un processus distinct pour renvoyer les éléments qui n’ont pas pu être synchronisés en raison d’erreurs lors du processus de synchronisation, par exemple une erreur d’application, une interruption de réseau ou une erreur de service SaaS. Les tâches cron *_resend_failed_items du groupe resync_failed_feeds_data_exporter le gèrent automatiquement toutes les 5 minutes.

Traitements cron planifiés

Les groupes cron suivants automatisent le pipeline selon un planning fixe.

Groupe cron
Tâche cron
Objectif
Planning
index
indexer_update_all_views
Traite les logs de modification Mview et déclenche des mises à jour partielles des flux
Toutes les 1 minute
index
indexer_reindex_all_invalid
Effectue une resynchronisation complète pour les index de flux marqués comme « Réindexation requise »
Toutes les 1 minute
resync_failed_feeds_data_exporter
*_resend_failed_items
Détecte les éléments de flux ayant échoué et les soumet à nouveau.
Toutes les 5 minutes
commerce_data_export
saas_data_exporter
Envoie des données pour les flux en mode hérité (commandes, portées)
Toutes les 5 minutes
commerce_data_export
cleanup_deleted_feed_items
Nettoie les éléments de flux supprimés synchronisés après la période de conservation (7 jours)
Tous les jours à 2:00 h

Envoi de flux et gestion des erreurs HTTP feed-submission-and-http-error-handling

Les éléments de flux sont envoyés en tant que lots JSON compressés GZIP authentifiés via HTTP POST. Le tableau suivant montre comment les codes de réponse HTTP sont associés au statut d’exportation et au comportement de reprise.

Code de statut
Réessayer ?
Signification
200
Non
Accepted successfully
400
Non
Données incorrectes ou échec de validation - nécessite une enquête manuelle. var/log/saas-export-errors.log pour plus de détails.
429
Oui
Accès à la limite de débit : réduisez les thread_count dans paramètres de traitement des exportations.
5xx
Oui
Erreur côté SaaS : reprise automatique
2
Oui
La reprise de l’élément est planifiée

Outre les échecs au niveau du HTTP, les erreurs au niveau de l’application, telles que les échecs de traitement local ou les perturbations du réseau, sont également planifiées pour une reprise automatique par les tâches cron *_resend_failed_items.

Surveillez le statut par flux à partir de la page Data Feed Sync Status de l’administration Commerce.

Related Articles
recommendation-more-help
commerce-help-data-export