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

Gestion des versions v1 dans les flux par lot

Dans vos flux par lot, la version d'une entité est déterminée par le champ 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 de menu et de restaurant seront individuellement versionnées sous la forme "2018-12-28T06:30:00:123-07:00".

Gestion des versions avec des mises à jour incrémentielles

Lorsque vous envoyez une entité à l'aide de mises à jour de l'inventaire, la version est définie via le champ update_time (en cas d'appel d'ajout/de mise à jour) ou le champ delete_time (en cas d'appel de suppression). Étant donné que ces champs sont facultatifs, le code temporel par défaut est défini sur le moment où Google a reçu l'appel.

Exemple 1: update_time défini explicitement

Supposons que l'appel incrémentiel suivant soit reçu le 28/12/2018T06: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 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

Ci-dessous, le corps de la charge utile JSON contient le champ update_time. L'entité associée à l'ID "http://www.provider.com/somerestaurant" est versionnée en 6:30:00 et non au moment de sa réception (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éfini implicitement

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é avec l'ID "http://www.provider.com/somerestaurant" est donc versionnée comme suit : 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 versions par lot et incrémentielles

Une entité envoyée à Google n'est traitée et diffusée que 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 en incrément et par lot, respectivement, en fonction de la date à laquelle l'entité a été modifiée dans vos systèmes.
Si un flux par lot (fichier) liste plusieurs entités de niveau supérieur (par exemple, vous associez vos restaurants à des services et des menus), mettez à jour le code temporel lorsque les données d'une entité sont modifiées.
Dans 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 que le code temporel du flux correspondant (dateModified) soit également mis à jour avant que Google ne l'extraie à nouveau.

Exemple

Google extrait le fichier suivant à 11h le 28/12/2018 pour un restaurant entièrement nouveau:

{
  "@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 avec succès et sont versionnées sous la forme "2018-12-28T06:30:00-07:00". Étant donné que le traitement des flux par lot prend du temps, ils sont généralement diffusés deux jours plus tard.

À 13h, cependant, le système du partenaire met à 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"
}

update_time est fourni explicitement et est supérieur (plus récent) que la version précédente (6h30 du même jour). L'entité restaurant est donc désormais versionnée sous la forme "2018-12-28T13:00:00-07:00". Toutefois, les entités de menu et de service sont toujours versionnées en tant que "2018-12-28T06:30:00-07:00".

Un appel incrémental a été effectué. Le flux par lot est donc mis à jour avec le nouveau code temporel correspondant. De plus, 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 lendemain (29/12/2018) à 23h, le flux est à nouveau extrait. Le restaurant a toujours la même version (13h du 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 des sitemaps

L'en-tête de réponse last-modified du sitemap n'a aucune incidence sur la version d'une entité. Elle affecte le moment où le flux est extrait 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é.