ניהול גרסאות v1 בפידים באצווה

בפידים באצווה, הגרסה של הישות נקבעת באמצעות השדה dateModified במעטפה של הפיד:

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

לכל הישויות שברשימה dataFeedElement תהיה אותה חותמת זמן, כפי שמפורט במעטפה.

לדוגמה, אתם יכולים ליצור את הפיד הבא עם שתי ישויות:

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

הן ישויות התפריט והמסעדות, והן יוצגו לאחר קבלתן והעיבוד שלהן כל גרסה בנפרד כ-"2018-12-28T06:30:00:123-07:00".

ניהול גרסאות עם עדכונים מצטברים

כששולחים ישות באמצעות עדכוני מלאי, הגרסה מוגדרת באמצעות השדה update_time (במקרה של קריאה להוספה/עדכון) או delete_time (במקרה של מחיקת שיחה). השדות האלה הם אופציונליים, לכן חותמת הזמן שמוגדרת כברירת מחדל מוגדרת למועד שבו Google קיבלה את השיחה.

דוגמה 1: update_time הוגדר באופן מפורש

נניח שהקריאה המצטברת הבאה מתקבלת ב-2018-12-28T06:30:10:123-07:00 למסעדה חדשה לגמרי. זוהי בקשת ה-HTTP POST לישות הזו עם המזהה 'http://www.provider.com/somerestaurant', בהנחה שפיד הנתונים משתמש סכימת מלאי v1:

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

למטה, גוף המטען הייעודי (payload) של JSON מכיל את השדה update_time. הישות עם מזהה "http://www.provider.com/somerestaurant" התוצאה של ישות זו היא מגרסה 6:30:00 ולא כשהיא התקבלה (עשר שניות לאחר מכן ב- 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"
}

דוגמה 2: update_time מוגדר באופן לא מפורש

נניח שהקריאה המצטברת הבאה מתקבלת ב-2018-12-28T06:30:10:123-07:00 למסעדה חדשה לגמרי. זוהי בקשת ה-HTTP POST לישות הזו עם המזהה "http://www.provider.com/somerestaurant", בהנחה שהפיד משתמש ב-v1 סכימת מלאי:

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

למטה, גוף המטען הייעודי (payload) של JSON לא מכיל את השדה update_time. ישות עם המזהה "http://www.provider.com/somerestaurant" ולכן התוצאה גרסת הישות הזו היא 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"
  }
}

ניהול גרסאות בין אצווה לבין המרות מצטברות

ישות שנשלחה ל-Google מעובדת ומוצגת רק אם יש לה את הגרסה העדכנית ביותר . בדרך כלל נדרשים כמה ימים כדי לקבל ישויות שנשלחות באצווה מעובדות, ואילו ישויות שנשלחות דרך ה-API המצטבר מעובדות באופן מיידי.

שיטות מומלצות

• מגדירים את השדות update_time ו-dateModified בנתונים מצטברים ובאצווה, בהתאמה, לפי המועד שבו הישות שונתה במערכות שלכם.
• אם בפיד (קובץ) באצווה רשומים יותר מישות אחת ברמה העליונה (לדוגמה, להתאים בין מסעדות לבין שירותים ותפריטים), ואז לעדכן את חותמת הזמן הנתונים של ישות מתעדכנים.
• בשיחות מצטברות, מומלץ מאוד להגדיר במפורש שדה update_time.
• חשוב מאוד שברגע שמתבצעת קריאה מצטברת, הפיד המתאים גם חותמת הזמן (dateModified) תתעדכן לפני ש-Google תאחזר אותה שוב.

דוגמה

Google מאחזרת את הקובץ הבא בשעה 11:00 ב-28 בדצמבר 2018, כדי מסעדה:

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

הישויות האלה מעובדות בהצלחה ומקבלות גרסאות "2018-12-28T06:30:00-07:00". מכיוון שהעיבוד של פידים באצווה נמשך זמן, בדרך כלל מוצגות יומיים לאחר מכן.

עם זאת, בשעה 13:00, במערכת של השותף יש עדכון לטלפון של המסעדה. ולכן מתקבלת השיחה המצטברת הבאה ש-Google מקבלת בשעה 13:05 (לאחר 5 שניות):

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 מצוין במפורש, והוא גדול יותר (עדכני יותר) מהערך את הגרסה הקודמת (6:30 באותו יום), כך שהישות של המסעדה עכשיו גרסה כ-"2018-12-28T13:00:00-07:00". אבל ישויות התפריט והשירות עדיין בגרסה 2018-12-28T06:30:00-07:00.

הייתה שיחה מצטברת, לכן הפיד המקובץ מתעדכן בהתאם חותמת הזמן המתאימה. בנוסף, השינויים המתאימים מוחלים הישויות הרלוונטיות (מספר הטלפון של הישות של המסעדה עודכן).

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

למחרת (29 בדצמבר 2018) בשעה 23:00, הפיד יאוחזר שוב. המסעדה עדיין יש את אותה גרסה (13:00 ב-28 בדצמבר), ולכן הישות הזו תוסר והגרסה הנוכחית תישמר. עם זאת, הישויות 'תפריט' ו'שירות' עודכן בגרסה חדשה.

חותמות זמן של קובצי Sitemap

כותרת התגובה last-modified ב-sitemap לא משפיעה על הגרסה של הישות. היא משפיעה על מתי האחזור של הפיד על ידי Google.

שיטות מומלצות

• לעדכן את כותרת התשובה רק כשכל הקבצים מעודכנים ומוכנים תאוחזר.
• שימוש מפורש ב-update_time וב-delete_time מצטברות.
• הגדרה של update_time, delete_time ו-dateModified כשהנתונים משתנים בצד שלך.