Questa pagina è stata tradotta dall'API Cloud Translation.

Controllo delle versioni v1 nei feed batch

Nei feed collettivi, la versione di un'entità viene determinata tramite il campo dateModified nella busta 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, indicato nella busta.

Ad esempio, il seguente feed potrebbe contenere 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"
      ...
    }
  ]
}

Sia il menu che le entità del ristorante, una volta ricevuti ed elaborati, vengono sottoposti singolarmente al controllo delle versioni 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 (in caso di chiamata di aggiunta/aggiornamento) o il campo delete_time (in caso di 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 in modo esplicito

Supponiamo che la seguente chiamata incrementale venga ricevuta al numero 2018-12-28T06:30:10:123-07:00 per un ristorante completamente nuovo. Ecco la richiesta POST HTTP per quell'entità con ID "http://www.provider.com/someristorante", supponendo che il feed di dati utilizzi lo schema dell'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/someristorante" comporta il controllo della versione 6:30:00 di questa entità e non il momento in cui è stata ricevuta (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 implicitamente

Supponiamo che la seguente chiamata incrementale venga ricevuta al numero 2018-12-28T06:30:10:123-07:00 per un ristorante completamente nuovo. Ecco la richiesta POST HTTP per l'entità con ID "http://www.provider.com/someristorante", supponendo che il feed utilizzi lo schema dell'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 non contiene il campo update_time. Di conseguenza, l'entità con ID "http://www.provider.com/someristorante" comporta il controllo delle versioni di questa entità come 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 incrementali

Un'entità inviata a Google viene elaborata e gestita solo se dispone della versione più recente. Tieni presente che l'elaborazione delle entità inviate tramite batch generalmente richiede alcuni giorni, mentre le entità inviate tramite l'API incrementale vengono elaborate immediatamente.

best practice

Imposta i campi update_time e dateModified in modo incrementale e batch, rispettivamente, in base alla data in cui l'entità è stata modificata nei tuoi sistemi.
Se in un feed batch (file) sono elencate più entità di primo livello (ad esempio, associ i tuoi ristoranti a servizi e menu), aggiorna il timestamp quando vengono aggiornati i dati di un'entità.
Per le 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 del feed corrispondente (dateModified) prima che Google lo recuperi di nuovo.

Esempio

Google recupera il seguente file alle 11:00 del 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 vengono utilizzate come versione come "2018-12-28T06:30:00-07:00". Poiché l'elaborazione dei feed batch richiede tempo, in genere vengono pubblicati due giorni dopo.

Alle 13:00, tuttavia, il sistema del partner aggiorna il numero di telefono del ristorante, che comporta 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 esplicitamente ed è superiore (più recente) rispetto alla versione precedente (6:30 dello stesso giorno), pertanto l'entità del ristorante viene ora versione come "2018-12-28T13:00:00-07:00". Tuttavia, il menu e le entità del servizio hanno ancora il controllo delle versioni come "2018-12-28T06:30:00-07:00".

È stata eseguita una chiamata incrementale, quindi il feed batch viene aggiornato con il nuovo timestamp corrispondente. Inoltre, le modifiche corrispondenti vengono applicate alle entità pertinenti (il numero di telefono dell'entità ristorante è 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 la versione corrente viene mantenuta. Tuttavia, le entità Menu e Servizio vengono aggiornate con una nuova versione.

Timestamp della Sitemap

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

best practice

Aggiorna l'intestazione della risposta solo quando tutti i file sono aggiornati e pronti per essere recuperati.
Usa esplicitamente update_time e delete_time in incrementale.
Imposta update_time, delete_time e dateModified per la modifica dei dati.