Control de versiones v1 en feeds por lotes

En tus feeds por lotes, la versión de una entidad se determina a través del campo dateModified en el sobre del feed:

{
  "@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 */
  ]
}

Todas las entidades que se enumeran en el campo dataFeedElement tendrán la misma marca de tiempo que se indica en el sobre.

Por ejemplo, podrías tener el siguiente feed con dos entidades:

{
  "@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"
      ...
    }
  ]
}

Una vez que se reciban y procesen, las entidades de menú y restaurante tendrán una versión individual como "2018-12-28T06:30:00:123-07:00".

Control de versiones con actualizaciones incrementales

Cuando se envía una entidad con actualizaciones de inventario, la versión se establece a través del campo update_time (en el caso de una llamada de adición o actualización) o del campo delete_time (en el caso de una llamada de eliminación). Dado que estos campos son opcionales, la marca de tiempo predeterminada se establece en el momento en que Google recibió la llamada.

Ejemplo 1: update_time se establece de forma explícita

Supongamos que se recibe la siguiente llamada incremental el 28/12/2018 a las 06:30:10:123-07:00 para un restaurante completamente nuevo. Esta es la solicitud HTTP POST para esa entidad con el ID "http://www.provider.com/somerestaurant", suponiendo que el feed de datos usa el esquema de inventario v1:

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

A continuación, el cuerpo de la carga útil de JSON contiene el campo update_time. La entidad con el ID "http://www.provider.com/somerestaurant" hace que esta entidad tenga la versión 6:30:00 y no la fecha en que se recibió (diez segundos después, a las 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"
}

Ejemplo 2: update_time se establece de forma implícita

Supongamos que se recibe la siguiente llamada incremental el 28/12/2018 a las 06:30:10:123-07:00 para un restaurante completamente nuevo. Esta es la solicitud HTTP POST para esa entidad con el ID "http://www.provider.com/somerestaurant", suponiendo que el feed usa el esquema de inventario v1:

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

A continuación, el cuerpo de la carga útil JSON no contiene el campo update_time. Por lo tanto, la entidad con el ID "http://www.provider.com/somerestaurant" genera que esta entidad tenga la versión 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"
  }
}

Control de versiones entre por lotes e incremental

Una entidad que se envía a Google se procesa y publica solo si tiene la versión más reciente. Ten en cuenta que las entidades que se envían por lotes suelen tardar unos días en procesarse, mientras que las que se envían a través de la API incremental se procesan de inmediato.

Prácticas recomendadas

  • Establece los campos update_time y dateModified en incremental y por lotes, respectivamente, según el momento en que se modificó la entidad en tus sistemas.
  • Si un feed por lotes (archivo) incluye más de una entidad de nivel superior (por ejemplo, vinculas tus restaurantes con servicios y menús), actualiza la marca de tiempo a medida que se actualizan los datos de una entidad.
  • En las llamadas incrementales, te recomendamos que configures de forma explícita el campo update_time.
  • Es fundamental que, una vez que se realice una llamada incremental, la marca de tiempo del feed correspondiente (dateModified) también se actualice antes de que Google la recupere de nuevo.

Ejemplo

Google recupera el siguiente archivo a las 11 a.m. del 28/12/2018 para un restaurante completamente nuevo:

{
  "@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"
      ...
    }
  ]
}

Estas entidades se procesan correctamente y se crean versiones como “2018-12-28T06:30:00-07:00”. Debido a que los feeds por lotes tardan en procesarse, por lo general, se publican 2 días después.

Sin embargo, a la 1 p.m., el sistema del socio tiene una actualización del número de teléfono del restaurante, lo que genera la siguiente llamada incremental, que Google recibe a las 13:05 (5 segundos después):

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"
}

El update_time se proporciona de forma explícita y es mayor (más reciente) que la versión anterior (6:30 a.m. del mismo día), por lo que la entidad del restaurante ahora tiene la versión "2018-12-28T13:00:00-07:00". Sin embargo, las entidades de menú y servicio aún tienen la versión “2018-12-28T06:30:00-07:00”.

Se realizó una llamada incremental, por lo que el feed por lotes se actualiza con la nueva marca de tiempo correspondiente. Además, los cambios correspondientes se aplican a las entidades relevantes (la entidad del restaurante tiene su número de teléfono actualizado).

{
  "@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"
      ...
    }
  ]
}

Al día siguiente (29/12/2018) a las 11 p.m., se vuelve a recuperar el feed. El restaurante todavía tiene la misma versión (1 p.m. del 28 de diciembre), por lo que se descarta esta entidad y se conserva la versión actual. Sin embargo, las entidades de Menú y Servicio se actualizan con una versión nueva.

Marcas de tiempo del mapa del sitio

El encabezado de respuesta last-modified en el mapa del sitio no afecta la versión de una entidad. Afecta cuándo Google recupera el feed.

Prácticas recomendadas

  • Actualiza el encabezado de respuesta solo cuando todos los archivos estén actualizados y listos para recuperarlos.
  • Usa update_time y delete_time de forma explícita en incremental.
  • Establece update_time, delete_time y dateModified en el momento en que cambien los datos.