Questa pagina è stata tradotta dall'API Cloud Translation.

Versionamento v1 nei feed batch

Nei feed batch, la versione di un'entità viene determinata tramite il campo dateModified nell'involucro 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 */
  ]
}

Tutte le entità elencate nel campo dataFeedElement avranno lo stesso timestamp, come indicato nell'involucro.

Ad esempio, potresti avere il seguente feed con due entità:

{
  "@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 volta ricevute ed elaborate, sia le entità menu che quelle del ristorante verranno singolarmente versionate come "2018-12-28T06:30:00:123-07:00".

Controllo delle versioni con aggiornamenti incrementali

Quando invii un'entità utilizzando gli aggiornamenti dell'inventario, la versione viene impostata tramite il campo update_time (nel caso di una chiamata di aggiunta/aggiornamento) o il campo delete_time (nel caso di una chiamata di eliminazione). Poiché questi campi sono facoltativi, il timestamp predefinito è impostato sul momento in cui Google ha ricevuto la chiamata.

Esempio 1: update_time impostato esplicitamente

Supponiamo che la seguente chiamata incrementale venga ricevuta il 28-12-2018 alle ore 06:30:10:123-07:00 per un ristorante completamente nuovo. Di seguito è riportata la richiesta POST HTTP per l'entità con ID "http://www.provider.com/somerestaurant", supponendo che il feed di dati utilizzi lo schema di 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

Di seguito, il corpo del payload JSON contiene il campo update_time. L'entità con ID "http://www.provider.com/somerestaurant" viene associata alla versione 6:30:00 e non al momento della ricezione (dieci secondi dopo alle 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"
}

Esempio 2: update_time impostato in modo implicito

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

Di seguito, il corpo del payload JSON non contiene il campo update_time. L'entità con ID "http://www.provider.com/somerestaurant" avrà quindi la versione 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"
  }
}

Controllo delle versioni tra batch e incrementale

Un'entità inviata a Google viene elaborata e pubblicata solo se è nella versione più recente. Tieni presente che in genere sono necessari alcuni giorni per elaborare le entità inviate tramite batch, mentre le entità inviate tramite l'API incrementale vengono elaborate immediatamente.

Best practice

Imposta i campi update_time e dateModified in incrementale e batch, rispettivamente, in base a quando l'entità è stata modificata nei tuoi sistemi.
Se un feed batch (file) elenca più di un'entità di primo livello (ad esempio, associ i tuoi ristoranti a servizi e menu), aggiorna il timestamp man mano che i dati di un'entità vengono aggiornati.
Nelle chiamate incrementali, ti consigliamo vivamente di impostare esplicitamente il campo update_time.
È fondamentale che, una volta effettuata una chiamata incrementale, venga aggiornato anche il timestamp (dateModified) del feed corrispondente prima che Google lo recuperi di nuovo.

Esempio

Google recupera il seguente file alle 11:00 del giorno 28-12-2018 per un ristorante completamente nuovo:

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

Queste entità vengono elaborate correttamente e sono versionate come "2018-12-28T06:30:00-07:00". Poiché l'elaborazione dei feed batch richiede tempo, solitamente vengono pubblicati 2 giorni dopo.

Alle 13:00, però, il sistema del partner aggiorna il numero di telefono del ristorante, il che genera la seguente chiamata incrementale, che Google riceve alle 13:05 (5 secondi dopo):

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

Il valore update_time viene fornito in modo esplicito ed è maggiore (più recente) della versione precedente (06:30 dello stesso giorno), pertanto l'entità del ristorante ora è nella versione "2018-12-28T13:00:00-07:00". Tuttavia, le entità di menu e servizio sono ancora con versione "2018-12-28T06:30:00-07:00".

È stata effettuata una chiamata incrementale, pertanto il feed batch viene aggiornato con il nuovo timestamp corrispondente. Inoltre, le modifiche corrispondenti vengono applicate alle entità pertinenti (l'entità del ristorante ha il numero di telefono aggiornato).

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

Il giorno successivo (29-12-2018) alle 23:00, il feed viene recuperato di nuovo. Il ristorante ha ancora la stessa versione (13:00 del 28 dicembre), quindi questa entità viene eliminata e viene conservata la versione corrente. Tuttavia, le entità Menu e Servizio vengono aggiornate con una nuova versione.

Timestamp delle sitemap

L'intestazione di risposta last-modified nella sitemap non influisce sulla versione di un'entità. Influisce su quando il feed viene recuperato da Google.

Best practice

Aggiorna l'intestazione di risposta solo quando tutti i file sono aggiornati e pronti per essere recuperati.
Utilizza esplicitamente update_time e delete_time in incremental.
Imposta update_time, delete_time e dateModified in base a quando i dati cambiano da parte tua.