تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يسمح خادم بروتوكول النقل الآمن للملفات (SFTP) للخلاصة العامة بتحميل أنواع خلاصات متعددة إلى
خادم SFTP واحد لكل بيئة. سيشرح هذا الدليل كيفية استخدام
خادم SFTP العام وسيقدّم روابط إلى الدليل المناسب
للخلاصة المعنيّة التي تخطّط لاستخدامها.
يعتمد خادم SFTP العام على وجود عمليتَي تحميل منفصلتَين:
ملف الوصف: يصف نوع الخلاصة التي سيتم
تحميلها
ملفات الخلاصة: محتوى الخلاصة الفعلية
تنظيم حقل الوصف
يتم تحميل ملف الوصف لإعلام نظامنا بنوع الخلاصة التي تحمّلها. يتيح لنا ذلك التحقّق من صحة الخلاصة ومعالجتها بشكل صحيح. يجب تحميل ملف الوصف قبل محتوى الخلاصة، ويجب أن يستوفي متطلبات التسمية التالية:
يجب استخدام امتداد الملف .filesetdesc.json لملف الوصف.
يجب أن يكون اسم ملف كل وصف فريدًا ولا يمكن إعادة استخدامه في عمليات التحميل المختلفة. ننصح
بتضمين الطابع الزمني لإنشاء الخلاصة واسم الخلاصة في اسم الملف.
مثال: offers_1524606581.filesetdesc.json
يجب أن يسرد كل ملف وصفي جميع ملفات البيانات في آخر خلاصة لاسم الخلاصة ذي الصلة.
message FilesetDescriptor {
// The timestamp at which this feed was generated, in Unix time format
// (seconds since the epoch). (required)
int64 generation_timestamp = 1;
// Identifies the name of this feed. (required)
string name = 2;
// Paths (relative to the dropbox root) specifying data files included in this
// feed. (required)
repeated string data_file = 3;
}
تشمل القيم المحتمَلة للحقل name ما يلي:
في ما يلي مثال على ملف وصفي بتنسيق JSON لخلاصة عروض تتضمّن شذرتَين:
بعد تحميل ملف الوصف، عليك تحميل جميع ملفات الخلاصة
لنوع بيانات الخلاصة المطابق لملف إعدادات الخلاصة الذي يحمل اسمًا من تحديد
ملف الوصف. يجب أن تتطابق أسماء الملفات ومواقع المسارات (النسبية ضمن
خادم SFTP) تمامًا مع ما تم تضمينه في الحقل
data_file. إذا كان أي ملف غير متوفّر أو يحمل اسمًا غير صحيح أو
تم تحميله إلى موقع مختلف، لن تتم
معالجة الخلاصة بأكملها.
يجب أن تتوافق محتويات ملفات بيانات الخلاصة هذه مع المواصفات ذات الصلة
بالخلاصة التي تم تحديدها في ملف الوصف.
يجب أن يكون اسم كل ملف خلاصة فريدًا ولا يمكن إعادة استخدامه في عمليات التحميل المختلفة. ننصحك
بتضمين الطابع الزمني لإنشاء القسم ورقم الجزء (رقم التعريف المتزايد) في اسم الملف.
مثال: offers_1524606581_1.json
أحجام ملفات الخلاصة ومعدّل تكرار التحميل
يجب أن يكون حجم ملف الخلاصة أقل من 200 ميغابايت (بعد الضغط).
يجب ألا يزيد حجم كل ملف بيانات غير مضغوط عن 2 غيغابايت.
لن تحتاج معظم عمليات الدمج إلى استخدام شريحة واحدة فقط. يجب استخدام
أقل عدد ممكن من الشرائح. يمكن إنشاء 1,000 شريحة كحد أقصى لكل خلاصة.
لا يلزم إرسال السجلّات الفردية المُرسَلة في شريحة واحدة باستخدام رقم الشريحة نفسه في الخلاصات المستقبلية.
للحصول على أداء أفضل، قسِّم البيانات بالتساوي بين الأجزاء، لجعل حجم كل
ملف من أجزاء البيانات متشابهًا.
استخدِم gzip لضغط الخلاصات إذا لزم الأمر. ومع ذلك، عليك إجراء ذلك لكل
جزء من الخلاصة.
تحديد المشاكل وحلّها وتصحيح الأخطاء
بعد تحميل ملفاتك (ملفّا الوصف والخلاصة)، انتقِل إلى
لوحة بيانات سجلّ الخلاصات
(المستندات)
في "بوابة الشركاء" (انتقِل إلى السجلّ > الخلاصات) لمتابعة مستوى تقدّم نقل الخلاصة.
ابحث عن name الذي أدخلته في ملف الوصف في عمود "اسم الخلاصة" للعثور على خلاصتك.
بعد نقل الخلاصة (عندما تكون الحالة Success أو Fail)، يمكنك النقر على
صفها للاطّلاع على تفاصيل الأخطاء والتحذيرات.
تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Using the Generic SFTP Server\n\nThe Generic feed SFTP server allows for multiple feed types to be uploaded to a\nsingle SFTP server per environment. This guide will walk through how to use the\nGeneric SFTP server and provide links to the appropriate guide for the respective\nfeed that you are planning to use.\n| **Warning:** This guide does **not** apply to the Merchants, Services, or Availability SFTP servers. It only applies to the Generic SFTP server.\n(Please refer to the [Exporting Feeds (end-to-end)](/actions-center/verticals/reservations/waitlists/integration-steps/export-feeds) or [Feeds (starter)](/actions-center/verticals/reservations/waitlists/integration-steps/feeds) section of the documentation).\n\n\u003cbr /\u003e\n\n| **Note:** You must be approved for each feed type that you will be uploading. If you upload a feed type that is not approved for your integration, the feed will not be processed. If you are unsure of which feed types apply to your integration, please reach out to your Actions Center contact.\n| **Warning:** You may need to reset your ssh key to enable uploads to the Generic feed SFTP server. To do so, please refer to [Partner Portal feed configuration](https://partnerdash.google.com/apps/reservewithgoogle/configuration/feeds?env=sandbox) ([documentation](/actions-center/verticals/reservations/waitlists/partner-portal/testing/feeds)).\n\nThe Generic SFTP server relies on there being two separate uploads:\n\n1. **Descriptor file:** describes what feed type you will be uploading\n2. **Feed file(s):** the content of the actual feed\n\n| **Note:** If you make an upload to the generic SFTP server and do not see any corresponding entry in the Partner Portal that may mean that your descriptor file was not uploaded or has an incorrect file name. For help debugging this issue please reach out to your Actions Center contact.\n\n### Structuring the descriptor field\n\nThe descriptor file is uploaded to inform our system of what feed type you\nare uploading. This allows us to validate and process the feed correctly. The\ndescriptor file should be uploaded before the feed contents and must follow\nthese naming requirements:\n\n- You must use the `.filesetdesc.json` file extension for the descriptor file.\n- Each descriptor filename must be unique and can't be re-used across uploads. We recommend including the generation timestamp and feed name in the filename.\n - Example: offers_1524606581.filesetdesc.json\n- Each descriptor file must list all data files in the latest feed for the relevant feed name.\n\n```scdoc\nmessage FilesetDescriptor {\n // The timestamp at which this feed was generated, in Unix time format\n // (seconds since the epoch). (required)\n int64 generation_timestamp = 1;\n\n // Identifies the name of this feed. (required)\n string name = 2;\n\n // Paths (relative to the dropbox root) specifying data files included in this\n // feed. (required)\n repeated string data_file = 3;\n}\n```\n\nPossible values for the `name` field include:\n\nAn example JSON descriptor file for an offers feed with two shards is\navailable below: \n\n```scdoc\n{\n \"generation_timestamp\": 1524606581,\n \"name\": \"promote.offer\",\n \"data_file\": [\n \"offers_1524606581_1.json\",\n \"offers_1524606581_2.json\"\n ]\n}\n```\n\n### Structuring the feed content\n\nAfter uploading the descriptor file, you will then upload all of the feed files\nfor the feed data type corresponding to the feed configuration file named by\nyour descriptor file. The file names and path locations (relative within the\nSFTP server) must exactly match what was included within the\n`data_file` field. If any file is missing, improperly named, or\nuploaded to a different location then the entire feed will not be\nprocessed.\n\nThe contents of these feed data files must conform to the relevant spec of\nthe feed that was specified in the descriptor file.\n\n\nEach feed file filename must be unique and cannot be re-used across uploads. We recommend\nincluding the generation timestamp and the shard number (incremental id) in the filename.\n\n- Example: offers_1524606581_1.json\n\n### Feed file sizes and upload frequency\n\n- Keep feed file size below 200 MB (after compression).\n- Each decompressed data file size should be less than 2 GB.\n- Most integrations will only need to use a single shard. You should use as few shards as possible. There is a maximum of 1000 shards per feed.\n- Individual records sent in one shard don't need to be sent in the same shard number in future feeds.\n- For better performance, split data evenly among the shards, to make all the shard files similar in size.\n- If necessary, use gzip to compress feeds. However, do so for each individual feed shard.\n\n### Troubleshooting and debugging\n\n\nAfter uploading your files (descriptor and feed files) head to the\n[Feed History dashboard](https://partnerdash.google.com/apps/reservewithgoogle/dashboards/feeds?env=sandbox)\n([documentation](/actions-center/verticals/reservations/waitlists/partner-portal/dashboards/feeds-dashboard))\non the Partner Portal (navigate to **History \\\u003e Feeds**) to follow the progress of your feed ingestion.\n\n\nLook for the `name` you have input in the descriptor file in the \"Feed name\" column to find your feed.\n\n\nOnce the feed is ingested (status is `Success` or `Fail`) you can click on\nits row to see the details of the errors and warnings."]]