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 par le champ dateModified de 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 répertoriées dans le champ dataFeedElement auront le même horodatage, comme indiqué dans l'enveloppe.

Par exemple, vous pouvez créer 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çus et traités, les entités de menu et de restaurant ont toutes deux la version "2018-12-28T06:30:00:123-07:00".

Gestion des versions avec mises à jour incrémentielles

Lorsque vous envoyez 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 le champ delete_time (dans le cas d'un appel de suppression). Ces champs étant facultatifs, l'horodatage par défaut est défini sur la date de réception de l'appel par Google.

Exemple 1: heure de mise à jour explicitement définie

Supposons que l'appel incrémentiel suivant soit reçu à 2018-12-28T06:30:10:123-07:00 pour un tout nouveau restaurant. Voici la requête HTTP POST pour cette entité portant l'ID "http://www.provider.com/somerestaurant", en supposant que le flux de données utilise le 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. Avec l'ID "http://www.provider.com/somerestaurant", la version de cette entité est 6:30:00 et non lorsqu'elle a été reçue (dix secondes plus tard à 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"
  },
  "update_time":"2018-12-28T06:30:00:123-07:00"
}

Exemple 2: update_time définie implicitement

Supposons que l'appel incrémentiel suivant soit reçu à 2018-12-28T06:30:10:123-07:00 pour un tout nouveau restaurant. Voici la requête HTTP POST pour cette entité avec l'ID "http://www.provider.com/somerestaurant", en supposant que le flux utilise le 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

Ci-dessous, le corps de la charge utile JSON ne contient pas le champ update_time. L'entité portant l'ID "http://www.provider.com/somerestaurant" entraîne donc la gestion des versions 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 les traitements par lot et les versions incrémentielles

Une entité envoyée à Google est traitée et diffusée uniquement si elle dispose de la dernière version. Notez que le traitement des entités envoyées par lot prend généralement quelques jours, tandis 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 par lot (fichier) répertorie plusieurs entités de niveau supérieur (par exemple, si vous associez vos restaurants avec des services et des menus), mettez à jour l'horodatage à mesure que les données d'une entité sont actualisées.
Pour les appels incrémentiels, nous vous recommandons vivement de définir explicitement le champ update_time.
Une fois un appel incrémentiel effectué, il est impératif de mettre à jour l'horodatage de flux correspondant (dateModified) avant que Google ne le récupère à nouveau.

Exemple

Google récupère le fichier suivant à 11h le 28/12/2018 pour un tout nouveau 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 traitées correctement et gérées par la version "2018-12-28T06:30:00-07:00". Le traitement des flux par lot prend du temps, c'est pourquoi ils sont généralement diffusés deux jours plus tard.

Toutefois, à 13h00, le système du partenaire a mis à jour le numéro de téléphone du restaurant, ce qui entraîne l'appel incrémentiel suivant, que Google reçoit à 13h05 (cinq 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"
}

L'élément update_time est fourni explicitement et est supérieur (plus récent) que la version précédente (6:30 du même jour). L'entité de restaurant a donc la version "2018-12-28T13:00:00-07:00". Toutefois, la version des entités de menu et de service est toujours "2018-12-28T06:30:00-07:00".

Un appel incrémentiel a été effectué. Le flux par lot est donc mis à jour avec le nouvel horodatage correspondant. En outre, les modifications correspondantes sont appliquées aux entités concernées (le numéro de téléphone de l'entité 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 à nouveau récupéré. Le restaurant possède toujours la même version (13h le 28 décembre). Cette entité est donc supprimée et la version actuelle est conservée. Toutefois, les entités Menu et Service sont mises à jour avec une nouvelle version.

Codes temporels du sitemap

L'en-tête de réponse last-modified dans le sitemap n'affecte pas la version d'une entité. Elle a une incidence sur le moment de la récupération du flux par Google.

Bonnes pratiques

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