批次擷取

資料動態饋給可讓你在端對端訂餐服務中提供餐廳、服務和菜單。

本文將說明如何代管沙箱和正式環境的商品目錄，以及如何使用批次擷取功能，在訂單端對端中更新商品目錄。

資料動態饋給環境

您可以使用三種資料動態饋給環境進行整合開發：

代管資料動態饋給

為了讓 Ordering End-to-End 以批次攝入的方式處理沙箱和正式版資料動態饋給，您必須將資料動態饋給檔案託管在 Google Cloud Storage、Amazon S3 或 HTTPS 中，並附上網站地圖。

建議您為沙箱和實際工作環境分別代管資料動態饋給。這種做法可讓您在將變更部署至實際工作環境前，先在沙箱動態饋給環境中進行開發及測試。

舉例來說，如果您使用 Google Cloud Storage 做為代管選項，則會有下列路徑：

• 沙箱動態消息： gs://foorestaurant-google-feed-sandbox/
• 製作動態饋給： gs://foorestaurant-google-feed-prod/

如要代管商品目錄，請按照下列步驟操作：

1. 產生資料動態饋給檔案。
2. 選擇託管解決方案。
3. 代管資料動態饋給。
4. 請務必定期更新資料動態饋給檔案。正式版資料動態饋給必須每天更新。

如要進一步瞭解如何建立商品目錄動態饋給，請參閱 Restaurant、Service 和 Menu 實體的說明文件，以及「建立資料動態饋給」一節。

資料動態饋給檔案規範

每個檔案 (可包含多個實體) 的大小不得超過 200 MB。頂層實體 Restaurant、Service 和 Menu 及其子實體的總大小不得超過 4 MB。

選擇代管解決方案

下表列出資料動態饋給的託管選項，以及這些主機如何與端到端訂購服務搭配運作：

連結資料動態饋給以進行批次擷取

主控動態饋給後，您必須在 動作中心中將動態饋給連結至專案。您可以在「新手上路工作」頁面中，完成正式版動態饋給的初始設定。之後，任何具備管理員角色的入口網站使用者都可以隨時前往「設定」>「動態饋給」頁面，更新實際環境和沙箱動態饋給設定。沙箱環境用於開發和測試，而正式版動態消息則會向使用者顯示。

如果您使用 Amazon S3 代管資料動態饋給

1. 在 行動中心中，依序前往「設定」>「動態饋給」。

2. 按一下「編輯」，然後填寫「更新動態饋給」表單：

   • 動態饋給提交方式：設為「Amazon S3」。
   • 標記檔案：提供 marker.txt 檔案的網址。
   • 資料檔案：提供含有資料動態饋給的 S3 值區網址。
   • 存取 ID：輸入具備讀取 S3 資源權限的 IAM 存取金鑰 ID。
   • 存取金鑰：輸入具有讀取 S3 資源權限的 IAM 私密存取金鑰。
3. 按一下「提交」。
4. 一到兩小時後，請檢查批次擷取功能是否擷取動態饋給檔案。

如果您使用 Google Cloud Storage 代管資料動態饋給

1. 在 行動中心中，依序前往「設定」>「動態饋給」。

2. 按一下「編輯」，然後填寫「更新動態饋給」表單：

   • 動態饋給提交方式：設為「Google Cloud Storage」。
   • 標記檔案：提供 marker.txt 檔案的網址。
   • 資料檔案：提供含有資料動態饋給的 GCS 值區網址。
3. 按一下「提交」。
4. 系統會建立服務帳戶，用於存取您的 GCS 值區。完成新手上路工作後，您可以在「設定」>「動態饋給」中找到帳戶名稱。這個服務帳戶需要具備「Storage 舊版物件讀取者」角色。您可以在 Google Cloud 控制台的「IAM」頁面中，將這個角色授予服務帳戶。
5. 一到兩小時後，請檢查批次擷取功能是否擷取動態饋給檔案。

如果您使用 HTTPS 託管資料動態消息

1. 在 行動中心中，依序前往「設定」>「動態饋給」。

2. 按一下「編輯」，然後填寫「更新動態饋給」表單：

   • 動態饋給提交方式：設為「HTTPS」。
   • Sitemap 檔案：提供 sitemap.xml 檔案的網址。
   • 使用者名稱：輸入存取 HTTPS 伺服器的使用者名稱憑證。
   • 密碼：輸入密碼即可存取 HTTPS 伺服器。
3. 按一下「提交」。
4. 一到兩小時後，請檢查批次擷取功能是否擷取動態饋給檔案。

路徑範例

下表列出各個託管選項的路徑範例：

適用於 HTTPS 代管服務的 Sitemap

定義 Sitemap 時，請遵循下列規範：

• Sitemap 中的連結必須指向檔案本身。
• 如果 Sitemap 包含雲端供應商的參照資料，而非您自己的網域名稱，請確保網址開頭 (例如 https://www.yourcloudprovider.com/your_id) 穩定且不重複，且只用於批次工作。
• 請注意，請勿上傳部分網站地圖 (例如在部分資料上傳時)。這樣一來，Google 只會擷取 Sitemap 中的檔案，導致廣告空間層級下降，甚至可能導致動態饋給擷取作業遭到封鎖。
• 請確認 Sitemap 中參照的檔案路徑不會變更。舉例來說，請勿讓 Sitemap 今天參照 https://www.yourcloudprovider.com/your_id/10000.json，但明天參照 https://www.yourcloudprovider.com/your_id/20000.json。

範例 Sitemap

以下是提供資料動態饋給檔案的範例 sitemap.xml 檔案：

範例 1：以商家分組的實體 (建議)。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url>
   <loc>https://your_fulfillment_url.com/restaurant_1.ndjson</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
 <url>
   <loc>https://your_fulfillment_url.com/restaurant_2.ndjson</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
 <url>
   <loc>https://your_fulfillment_url.com/restaurant_3.ndjson</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
</urlset>

範例 2：實體按類型分組。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url>
   <loc>https://your_fulfillment_url.com/restaurant.json</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
 <url>
   <loc>https://your_fulfillment_url.com/menu.json</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
 <url>
   <loc>https://your_fulfillment_url.com/service.json</loc>
   <lastmod>2018-06-11T10:46:43+05:30</lastmod>
 </url>
</urlset>

更新資料動態饋給

連結資料動態饋給後，Google 會每小時檢查一次更新，但只有在 marker.txt 或 sitemap.xml 檔案經過修改時，我們才會擷取所有資料動態饋給。我們建議你每天更新一次資料動態饋給，以免商品目錄過時。

如要指定資料動態饋給已修改，且可供批次攝入，請更新 marker.txt 檔案 (GCP 和 S3 的情況) 的 last-modified 物件中繼資料欄位，或 sitemap.xml 檔案的 last-modified 回應標頭。Google 會根據這些值判斷資料動態饋給的更新頻率。

在批次動態饋給擷取期間，

• 系統會插入目前訂購端到端商品目錄中不存在且沒有任何錯誤的新實體。
• 已存在於廣告空間中的實體，在擷取時不會發生任何錯誤，且 dateModified 要比目前的項目更新，或是在沒有 dateModified 的情況下，動態饋給擷取開始時間要比要更新的目前項目更新，否則會標示為過時。
• 如果動態饋給中沒有檔案層級錯誤，則會刪除先前動態饋給中，但在處理中的批次動態饋給中不再出現的實體。

只有在產生及更新所有資料動態饋給檔案後，才能更新時間戳記或 last-modified 回應標頭。請限制更新資料動態饋給的批次工作，每天只能執行一次。或者，請在每個批次工作之間至少間隔三小時。如果您未採取這些步驟，Google 可能會擷取過時的檔案。