[PaaS uniquement]{class="badge informative" title="S’applique uniquement aux projets Adobe Commerce on Cloud (infrastructure PaaS gérée par Adobe) et aux projets On-premise."}

Pipeline de synchronisation du connecteur

Basée sur SaaS Data Export, la Adobe Commerce Optimizer Connector mappe les données collectées par les indexeurs de SaaS Data Export au format requis par le Catalog Data Ingestion API de Adobe Commerce Optimizer et gère l’authentification, l’envoi par lots et le contrôle de synchronisation basé sur la portée. Les sections ci-dessous décrivent le fonctionnement de cette synchronisation.

Contexte connexe :

  • Découvrez la valeur commerciale de l’intégration, ses fonctionnalités clés et son architecture dans la rubrique Commerce Optimizer Connector présentation.

  • Pour les noms de package de module, les points d’entrée de l’API de flux et les chemins d’accès aux clés de configuration, consultez la référence ​ Connector ​

Fonctionnement de la synchronisation

Le diagramme suivant montre la synchronisation des données de Adobe Commerce à Commerce Optimizer à travers le Adobe I/O Gateway.

Diagramme de synchronisation de haut niveau du connecteur ​ {width="800" 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é — (toutes les 1 min) Une tâche cron (indexer_reindex_all_invalid) détecte Adobe Commerce modifications d’entité et déclenche la SaaS Data Export, qui assemble les éléments de flux.
  2. Transformation — Le Commerce Optimizer Connector récupère les flux assemblés, mappe Adobe Commerce entités et les portées aux formats requis par l’API Commerce Optimizer et prépare la payload pour la transmission.
  3. Transmission — Les données transformées sont envoyées via HTTP POST (/v1/catalog/<feed name>) via le Adobe I/O Gateway à Commerce Optimizer, qui valide et conserve les flux entrants.
  4. Conserver les résultats — Conserver le statut de réponse de l’API dans les tableaux de flux.
  5. Reprise en cas d’échec (toutes les 5 minutes) — Une tâche cron distincte (*_resend_failed_items) détecte tous les éléments de flux ayant échoué et les soumet à nouveau par le biais du même pipeline.

Traitements cron planifiés

Les tâches cron suivantes automatisent le pipeline selon un planning fixe.

Groupe cron
Tâche cron
Objectif
Planning
index
indexer_update_all_views
Écoute les mises à jour des entités, assemble les éléments de flux et conserve le statut du flux
Toutes les 1 minute
index
indexer_reindex_all_invalid
Effectuer 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
Recherche les éléments de flux ayant échoué et les soumet à nouveau à Commerce Optimizer
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

L’extension SaaS Data Export gère la collecte de flux et le suivi des statuts. Le calque de connecteur mappe les entités et les étendues au format requis par l’API Commerce Optimizer et les envoie via POST /v1/catalog/<feed name>.

Conditions requises

Contrôle de synchronisation basé sur la portée

Le module CommerceOptimizerScopeMapper lit les paramètres d’exportation par site web et par magasin et les applique lors de la collecte et de l’envoi des flux.

  • Étendues activées exportez les données selon la planification delta normale.
  • Les désactivées sont exclues du pipeline.
    Les entités précédemment synchronisées sont supprimées de Commerce Optimizer lors de la prochaine exécution cron.

Si les problèmes de synchronisation n’affectent qu’une seule source de catalogue ou un seul catalogue de prix, consultez Data not sync.

Pour plus d’informations sur la personnalisation de la portée de synchronisation, voir Personnalisation de la configuration d’exportation des portées Commerce.

Calendrier et surveillance

Scénario
Synchronisation standard
Mises à jour régulières du catalogue
1 à 2 cycles de synchronisation delta (~1 à 2 minutes pour l’indexation, plus l’envoi)
Échecs transitoires
Reprise toutes les 5 minutes
Synchronisation complète pour les catalogues volumineux
De quelques minutes à quelques heures

Surveillez le statut par flux à partir de la page Data Feed Sync Status de l’administration Commerce. Voir Vérifier que la synchronisation des données fonctionne.

Envoi du flux et gestion des erreurs

Le processus FeedSubmitter gère les appels Catalog Data Ingestion API.

  1. Sépare les éléments de mise à jour des éléments de suppression (différents points d’entrée de l’API).
  2. Les appels mettent à jour et suppriment les points d’entrée indépendamment.
  3. Fusionne les résultats de statut par élément en une seule réponse.

Fusion du code d’état HTTP

Lorsque les appels de mise à jour et de suppression renvoient des codes d’état différents, FeedSubmitter combine les résultats comme suit.

Met à jour le résultat
Supprime le résultat
Résultat final
200
200 ou aucun
200 succès
200
400
200 avec erreurs de suppression
400
400
400 erreurs fusionnées
autres frais
autres frais
RÉESSAYABLE
Type d’erreur
Comportement
400
Les éléments répertoriés dans le champ errors de réponse apparaissent dans l’administration et nécessitent une attention particulière. Les autres éléments du lot sont repris.
5xx
Reprise par les tâches cron *_feed_resend_failed_items spécifiques au flux dans le groupe resync_failed_feeds_data_exporter.
recommendation-more-help
commerce-help-aco-connector