Cette page a été traduite par l'API Cloud Translation.

Gestion des versions v1 dans les flux groupés

Dans vos flux par lot, la version d'une entité est déterminée via la dateModified dans l'enveloppe du flux:

{
  "@context": "http://schema.googleapis.com",
  "dateModified": "2018-12-28T06:30:00:123-07:00",
  "@type": "DataFeed",
  "dataFeedElement": [
    /* All the items that are part of this feed go here */
  ]
}

Toutes les entités listées dans le champ dataFeedElement auront le même code temporel, comme indiqué dans l'enveloppe.

Par exemple, vous pouvez avoir le flux suivant avec deux entités:

{
  "@context": "http://schema.googleapis.com",
  "@type": "DataFeed",
  "dateModified": "2018-12-28T06:30:00:123-07:00",
  "dataFeedElement": [
    {
      "@type": "Restaurant",
      "@id": "http://www.provider.com/somerestaurant",
      ...
    },
    {
      "@type": "Menu",
      "@id": "http://www.provider.com/somerestaurant/menu/1"
      ...
    }
  ]
}

Une fois reçues et traitées, les entités "menu" et "restaurant" individuellement sous la forme "2018-12-28T06:30:00:123-07:00".

Gestion des versions avec mises à jour incrémentielles

Lors de l'envoi d'une entité à l'aide de mises à jour d'inventaire, la version est définie via le champ update_time (dans le cas d'un appel d'ajout/de mise à jour) ou l'delete_time (dans le cas d'un appel de suppression). Ces champs étant facultatifs, Le code temporel par défaut est défini sur le moment où Google a reçu l'appel.

Exemple 1: paramètre update_time explicitement défini

Supposons que l'appel incrémentiel suivant soit reçu au 2018-12-28T06:30:10:123-07:00 pour un tout nouveau restaurant. Voici la requête HTTP POST associée à cette entité : portant l'ID "http://www.fournisseur.com/somerestaurant", en supposant que le flux de données utilise du schéma d'inventaire v1:

POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json

En dessous, le corps de la charge utile JSON contient le champ update_time. L'entité avec ID "http://www.provider.com/somerestaurant" il en résulte que cette entité soit version 6:30:00 et non à sa réception (dix secondes plus tard dans 6:30:10):

{
// This envelope is to be used for incremental.
  "entity": {
    // Note: "data" is not serialized as a string in our example for readability.
    "data": "[entity in JSON format serialized as a string]",
    "vertical": "FOODORDERING&quot;
  },
  "update_time":"2018-12-28T06:30:00:123-07:00"
}

Exemple 2: Définition implicite de update_time

Supposons que l'appel incrémentiel suivant soit reçu au 2018-12-28T06:30:10:123-07:00 pour un tout nouveau restaurant. Voici la requête HTTP POST associée à cette entité : portant l'ID "http://www.provider.com/somerestaurant", en supposant que le flux utilise la version v1 schéma d'inventaire:

POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json

Dans l'exemple ci-dessous, le corps de la charge utile JSON ne contient pas le champ update_time. La entité portant l'ID "http://www.fournisseur.com/somerestaurant" se traduit par la version de cette entité est 6:30:10:

{
// This envelope is to be used for incremental.
  "entity": {
    //Note: "data" is not serialized as a string in our example for readability.
    "data": "[entity in JSON format serialized as a string]";,
    "vertical": "FOODORDERING"
  }
}

Gestion des versions entre lots et incrémentiels

Une entité envoyée à Google est traitée et diffusée uniquement si elle dispose de la version. Notez que quelques jours sont généralement nécessaires pour que les entités envoyées par lot alors que les entités envoyées via l'API incrémentielle sont traitées immédiatement.

Bonnes pratiques

Définissez les champs update_time et dateModified de manière incrémentielle et par lot. respectivement, en fonction de la date de modification de l'entité dans vos systèmes.
Si un flux (fichier) par lot répertorie plusieurs entités de niveau supérieur (par exemple, associez vos restaurants aux services et aux menus), puis mettez à jour l'horodatage comme suit : les données d'une entité sont mises à jour.
Pour les appels incrémentiels, nous vous recommandons vivement de définir explicitement update_time.
Dès qu'un appel incrémentiel est effectué, le flux correspondant doit impérativement l'horodatage (dateModified) est également mis à jour avant que Google ne le récupère à nouveau.

Exemple

Google récupère le fichier suivant à 11h le 28/12/2018 pour obtenir restaurant:

{
  "@context": "http://schema.googleapis.com",
  "@type": "DataFeed",
  "dateModified": "2018-12-28T06:30:00-07:00",
  "dataFeedElement": [
    {
      "@type": "Restaurant",
      "@id": "http://www.provider.com/newrestaurant",
      ...
    },
    {
      "@type": "Menu",
      "@id": "http://www.provider.com/newrestaurant/menu/1"
      ...
    }
    {
      "@type": "Service",
      "@id": "http://www.provider.com/newrestaurant/service/1"
      ...
    }
  ]
}

Ces entités sont bien traitées et gérées par version : "2018-12-28T06:30:00-07:00". Étant donné que le traitement des flux par lot prend du temps, ces généralement deux jours plus tard.

À 13h, cependant, le système du partenaire a mis à jour le téléphone du restaurant qui entraîne l'appel incrémentiel suivant, que Google reçoit à 13 h 05 (5 secondes plus tard) :

POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json
{
// This envelope is to be used for incremental.
  "entity": {
    //Note: "data" is not serialized as a string in our example for readability.
    "data": "[entity in JSON format serialized as a string]",
    "vertical": "FOODORDERING"
  },
  "update_time":"2018-12-28T13:00:00-07:00"
}

La valeur update_time est fournie explicitement et est supérieure (plus récente) que la dans la version précédente (à 6 h 30 le même jour), l'entité "restaurant" est désormais version 2018-12-28T13:00:00-07:00. Toutefois, les entités de menu et de service ont toujours la version "2018-12-28T06:30:00-07:00".

En raison d'un appel incrémentiel, le flux par lot est mis à jour le code temporel correspondant. De plus, les modifications correspondantes sont appliquées les entités concernées (le numéro de téléphone du restaurant est mis à jour).

{
  "@context": "http://schema.googleapis.com",
  "@type": "DataFeed",
  "dateModified": "2018-12-28T13:00:00-07:00",
  "dataFeedElement": [
    {
      "@type": "Restaurant",
      "@id": "http://www.provider.com/newrestaurant",
      ...
    },
    {
      "@type": "Menu",
      "@id": "http://www.provider.com/newrestaurant/menu/1"
      ...
    }
    {
      "@type": "Service",
      "@id": "http://www.provider.com/newrestaurant/service/1"
      ...
    }
  ]
}

Le jour suivant (29/12/2018) à 23h, le flux est de nouveau récupéré. Le restaurant a toujours la même version (à 13h le 28 décembre), cette entité est donc supprimée et la version actuelle est conservée. Cependant, les entités Menu et Service sont mis à jour avec une nouvelle version.

Codes temporels du sitemap

L'en-tête de réponse last-modified du sitemap n'a pas d'incidence sur le d'une entité. Elle détermine le moment où Google récupère le flux.

Bonnes pratiques

Mettez à jour l'en-tête de réponse uniquement lorsque tous les fichiers sont à jour et prêts à peut être récupérée.
Utilisez explicitement update_time et delete_time de façon incrémentielle.
Définissez update_time, delete_time et dateModified sur le moment où les données changent. de votre côté.