Ingestion par lots

Vos flux de données permettent vous rendez votre restaurant, vos services et votre menu disponibles dans l'option "Commandes de bout en bout".

Ce document explique comment héberger vos inventaires de bac à sable et de production, et comment utiliser l'ingestion par lots. pour mettre à jour votre inventaire dans l'onglet "Commandes" de bout en bout.

Environnements de flux de données

Trois environnements de flux de données sont disponibles pour le développement de votre intégration:

Environnement du flux	Description	Ingestion par lots
Bac à sable	Environnement de test pour le développement de votre flux	Obligatoire
Production	Environnement de production de l'inventaire que vous souhaitez lancer.	Obligatoire

Hébergement de flux de données

Pour que la commande de bout en bout traite vos flux de données de production et de bac à sable par lot vous devez héberger vos fichiers de flux de données sur Google Cloud Storage, Amazon S3 ou HTTPS à l'aide d'un un sitemap.

Nous vous recommandons d'héberger les flux de données pour vos environnements de bac à sable et de production. séparément. Cette approche vous permet d'effectuer des développements et des tests dans votre environnement de flux de bac à sable. avant de déployer les modifications en production.

Par exemple, si vous utilisez Google Cloud Storage comme option d'hébergement, vous disposez des options suivantes : chemins:

• Flux bac à sable:gs://foorestaurant-google-feed-sandbox/
• Flux de production:gs://foorestaurant-google-feed-prod/

Pour héberger votre inventaire, procédez comme suit:

1. Générez les fichiers de votre flux de données.
2. Choisissez une solution d'hébergement.
3. Hébergez vos flux de données.
4. Veillez à mettre à jour régulièrement vos fichiers de flux de données. Les flux de données de production doivent être mis à jour tous les jours.

Pour en savoir plus sur la création d'un flux d'inventaire, consultez la documentation Restaurant Service et Menu entités, ainsi que Créer un flux de données .

Consignes relatives aux fichiers de flux de données

Un fichier, qui peut contenir plusieurs entités, ne doit pas dépasser 200 Mo. Le premier niveau les entités Restaurant, Service et Menu, ainsi que leurs enfants, ne doivent pas dépasser 4 Mo au total.

Remarque:Nous vous recommandons d'inclure tous les restaurants, services et menus associés dans le même fichier de flux de données, avec un fichier pour chaque emplacement de marchand. Pour Par exemple, si vous avez 8 000 établissements marchands, générez 8 000 fichiers. Un fichier distinct pour chaque la position du marchand peut faciliter le débogage et l'intégration.

Choisir une solution d'hébergement

Le tableau suivant répertorie les options d'hébergement de vos flux de données et la façon dont ces hôtes fonctionnent avec Commande de bout en bout:

	Amazon S3	Google Cloud Storage	HTTPS avec un sitemap
Identifiants et accès	Fournissez à Google les informations suivantes: ID de clé d'accès Clé d'accès secrète Chemins d'accès à vos répertoires S3 de production et de bac à sable et à marker.txt . Le chemin d'accès doit commencer par s3://. Le bucket S3 doit inclure les informations suivantes: Fichiers de flux de votre inventaire. marker.txt, qui contient un code temporel utilisé pour l'extraction. Exemple de fichier marker.txt: 2018-12-03T08:30:42.694Z	Fournissez à Google les chemins d'accès à vos répertoires de buckets de production et de bac à sable, et marker.txt. Les chemins d'accès doivent commencer par gs://. Ajoutez le compte de service fourni par votre consultant Google en tant que lecteur de votre bucket Cloud Storage. Pour en savoir plus sur le contrôle des accès à Google Cloud Storage (GCS), consultez Google Console Cloud Platform: définir des autorisations sur un bucket Le bucket GCS doit inclure les informations suivantes: Fichiers de flux de votre inventaire. marker.txt, qui contient un code temporel utilisé pour l'extraction. Exemple de fichier marker.txt: 2018-12-03T08:30:42.694Z	Fournissez à Google les informations suivantes: Identifiants de votre authentification de base Chemin d'accès aux chemins d'accès aux sitemaps de production et de bac à sable. Le chemin d'accès doit commencer par https://. Protocole: vous devez rendre vos fichiers de flux disponibles via HTTPS, et non via HTTP. Sécurité: Google vous recommande vivement de protéger vos fichiers de flux hébergés avec Authentification de base.
Comment Google détermine-t-il les fichiers à récupérer ?	Liste de répertoires de tous les fichiers du bucket.	Liste de répertoires de tous les fichiers du bucket.	URL individuelles des fichiers répertoriés dans le sitemap.
Comment Google sait que les fichiers sont prêts à être récupérés	Après avoir généré vos flux de données, mettez à jour le fichier marker.txt avec le code temporel le plus récent.	Après avoir généré vos flux de données, mettez à jour le fichier marker.txt avec le code temporel le plus récent.	Après avoir généré vos flux de données, mettez à jour l'en-tête de réponse last-modified de votre sitemap.xml avec le dernier code temporel.
Limites pour les fichiers	Nombre maximal de fichiers: 100 000. Votre bucket Amazon S3 doit contenir moins de 100 000 fichiers au total.	Nombre maximal de fichiers: 100 000. Votre bucket Google Cloud Storage doit contenir moins de 100 000 fichiers au total.	Nombre maximal de fichiers: 100 000. Le nombre de chemins d'accès dans votre fichier XML de sitemap doit être inférieur à 100 000.

Connecter vos flux de données pour l'ingestion par lots

Une fois vos flux hébergés, vous devez les associer à votre projet dans le Centre Actions. La la configuration initiale des flux de production s'effectue sur la page Tâches d'intégration. Plus tard la configuration des flux de production et de bac à sable peut être mise à jour à tout moment sur la page Configuration > Flux par tout utilisateur du portail disposant d'un d'administration. L'environnement Sandbox est utilisé à des fins de développement et de test, tandis que les flux de production sont présentés aux utilisateurs.

Si vous hébergez vos flux de données avec Amazon S3

1. Dans le Centre d'actions, accédez à Configuration > Flux.

2. Cliquez sur Edit (Modifier), puis remplissez le formulaire Update Feed (Mettre à jour le flux) :

   • Mode d'envoi du flux:définissez Amazon S3.
   • Fichier de repère:indiquez l'URL du fichier marker.txt.
   • Fichiers de données:indiquez l'URL du bucket S3 contenant les flux de données.
   • ID d'accès:saisissez l'ID de clé d'accès IAM disposant des autorisations de lecture à partir de S3. ressources.
   • Access Key (Clé d'accès) : saisissez la clé d'accès secrète IAM disposant d'autorisations de lecture à partir de S3. ressources.
3. Cliquez sur Envoyer.
4. Au bout d'une à deux heures, vérifiez si l'ingestion par lots récupère vos fichiers de flux.

Si vous hébergez vos flux de données avec Google Cloud Storage

1. Dans le Centre d'actions, accédez à Configuration > Flux.

2. Cliquez sur Edit (Modifier), puis remplissez le formulaire Update Feed (Mettre à jour le flux) :

   • Mode d'envoi du flux:à définir sur Google Cloud Storage.
   • Fichier de repère:indiquez l'URL du fichier marker.txt.
   • Fichiers de données:indiquez l'URL du bucket GCS contenant les flux de données.
3. Cliquez sur Envoyer.
4. Un compte de service est créé pour accéder à votre bucket GCS. Le nom du compte se trouve dans Configuration > Flux après les tâches d'intégration sont terminés. Ce compte de service doit disposer du rôle "Lecteur des anciens objets Storage". Ce rôle permet être accordé au compte de service sur la page IAM de la console Google Cloud.
5. Au bout d'une à deux heures, vérifiez si l'ingestion par lots récupère vos fichiers de flux.

Si vous hébergez vos flux de données via HTTPS

1. Dans le Centre d'actions, accédez à Configuration > Flux.

2. Cliquez sur Edit (Modifier), puis remplissez le formulaire Update Feed (Mettre à jour le flux) :

   • Mode de diffusion du flux:définissez la valeur sur HTTPS.
   • Fichier sitemap:indiquez l'URL du fichier sitemap.xml.
   • Nom d'utilisateur:saisissez les identifiants du nom d'utilisateur pour accéder au serveur HTTPS.
   • Mot de passe:saisissez le mot de passe permettant d'accéder au serveur HTTPS.
3. Cliquez sur Envoyer.
4. Au bout d'une à deux heures, vérifiez si l'ingestion par lots récupère vos fichiers de flux.

Exemples de chemins

Le tableau suivant contient des exemples de chemins pour chacune des options d'hébergement:

	Amazon S3	Google Cloud Storage	HTTPS avec un sitemap
Chemin	s3://foorestaurant-google-feed-sandbox/	gs://foorestaurant-google-feed-sandbox/	https://sandbox-foorestaurant.com/sitemap.xml
Fichier de repères	s3://foorestaurant-google-feed-sandbox/marker.txt	gs://foorestaurant-google-feed-sandbox/marker.txt	Non applicable

Plans de site pour l'hébergement HTTPS

Respectez les consignes suivantes lorsque vous définissez des sitemaps:

• Les liens de votre sitemap doivent pointer vers les fichiers eux-mêmes.
• Si votre plan de site contient des références à un fournisseur de services cloud au lieu de votre propre nom de domaine, assurez-vous que le début des URL, comme https://www.yourcloudprovider.com/your_id, sont stables et propres à votre job par lot.
• Veillez à ne pas importer de sitemaps partiels (comme une importation partielle des données). Faire Google n'ingérera donc que les fichiers du sitemap, ce qui entraînera l'infiltration de votre inventaire et peut entraîner le blocage de l'ingestion de votre flux.
• Assurez-vous que les chemins d'accès aux fichiers référencés dans le sitemap ne changent pas. Par exemple, ne utilisez la référence de sitemap https://www.yourcloudprovider.com/your_id/10000.json mais aussi en faisant référence à https://www.yourcloudprovider.com/your_id/20000.json demain.

Exemple de sitemap

Voici un exemple de fichier sitemap.xml servant à diffuser des fichiers de flux de données:

Exemple 1: Entités regroupées par marchands (recommandé).

XML

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url>
   <loc>https://your_fulfillment_url.com/restaurant_1.ndjson</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
 <url>
   <loc>https://your_fulfillment_url.com/restaurant_2.ndjson</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
 <url>
   <loc>https://your_fulfillment_url.com/restaurant_3.ndjson</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
</urlset>

Exemple 2: Entités regroupées par types

XML

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url>
   <loc>https://your_fulfillment_url.com/restaurant.json</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
 <url>
   <loc>https://your_fulfillment_url.com/menu.json</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
 <url>
   <loc>https://your_fulfillment_url.com/service.json</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
</urlset>

Remarque:Le seul champ obligatoire pour un sitemap de bout en bout de commande est loc.

Mettre à jour vos flux de données

Une fois vos flux de données connectés, Google recherche des mises à jour une fois par heure, mais nous n'ingérons que tous les flux de données lorsque les fichiers marker.txt ou sitemap.xml ont été modifiées. Nous vous demandons de mettre à jour vos flux de données une fois par jour pour éviter que votre inventaire ne soit obsolète.

Pour indiquer que les flux de données ont été modifiés et sont prêts pour l'ingestion par lots, mettez à jour champ de métadonnées de l'objet last-modified du fichier marker.txt (pour GCP et S3) ou l'en-tête de réponse last-modified du fichier sitemap.xml. Google utilise ces valeurs pour déterminer la fraîcheur d'un flux de données.

Pendant l'ingestion du flux par lot,

• Nouvelles entités qui n'existent pas dans l'inventaire de bout en bout de vos commandes actuel et qui n'en comportent pas sont insérées.
• Entités déjà présentes dans l'inventaire pour lesquelles il n'existe aucune erreur ingestion et ont un dateModified plus récent que le l'entrée actuelle ou, en l'absence de dateModified, l'heure de début de l'ingestion du flux est plus récente que l'entrée actuelle doivent être mis à jour, sinon ils seront marqués comme non actualisés.
• Entités qui faisaient partie d'un flux précédent et qui ne sont plus incluses dans le flux par lot en cours de traitement est supprimé, à condition qu'il n'y ait pas de fichier dans le flux.

Le code temporel ou l'en-tête de réponse last-modified ne doivent être mis à jour qu'après que toutes les données sont générés et mis à jour. Limiter l'exécution des tâches par lot qui mettent à jour vos flux de données une fois par jour. Vous pouvez également prévoir un intervalle d'au moins trois heures entre chaque tâche par lot. Si vous ne suivez ces étapes, il se peut que Google récupère des fichiers obsolètes.

Remarque:last-modified est différent de la gestion des versions d'entités. last-modified se déclenche lorsque le lot est récupéré et n'a aucun impact sur le la version de l'entité.