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

Gestion des versions v1 dans les flux de traitement par lot

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 disposer du 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 sont gérées individuellement sous 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). Étant donné que ces champs sont facultatifs, l'horodatage par défaut est défini au moment où Google reçoit l'appel.

Exemple 1: set_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 restaurant entièrement nouveau. Voici la requête HTTP POST de cette entité associée à l'identifiant "http://www.provider.com/somerestaurant&sup", si 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. L'entité dont l'ID est "http://www.provider.com/somerestaurant" aboutit à la gestion des versions de cette entité, soit "6:30:00", et non lors 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

Supposons que l'appel incrémentiel suivant soit reçu le 28/12/2018T06:30:10:123-07:00 pour un restaurant entièrement nouveau. Voici la requête HTTP POST de cette entité associée à l'ID "http://www.provider.com/somerestaurant&sup", si 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

En dessous, le corps de la charge utile JSON ne contient pas le champ update_time. L'entité associée à l'identifiant "http://www.provider.com/somerestaurant&quot" aboutit donc à la gestion des versions de cette entité, telle que 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 lots et les tâches 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 de manière incrémentielle et par lot, 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 à des services et des menus), mettez à jour l'horodatage à mesure que les données d'une entité sont mises à jour.
Dans les appels incrémentiels, nous vous recommandons vivement de définir explicitement le champ update_time.
Il est impératif de mettre à jour l'horodatage du flux correspondant (dateModified) avant que Google ne récupère un nouvel appel.

Exemple

Google récupère le fichier suivant à 11h le 28/12/2018 pour un 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 en tant que versions 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, 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 (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"
}

L'élément update_time est fourni explicitement et est plus récent (plus récent) que la version précédente (6h30 le même jour). L'entité du restaurant est donc désormais la version "2018-12-28T13:00:00-07:00". Cependant, la gestion des versions du menu et des entités de service continue d'être définie comme "2018-12-28T06:30:00-07:00".

En cas d'appel incrémentiel, le flux par lot est 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é 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 (13 décembre du 28 décembre). Par conséquent, cette entité est supprimée et la version actuelle est conservée. Toutefois, les entités de menu et de service sont mises à jour avec une nouvelle version.

Horodatages de 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 récupéré 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 façon incrémentielle.
Définissez update_time, delete_time et dateModified sur le moment où les données changent de votre côté.