Feeds listos

Los feeds proporcionan tus datos de inventario a Actions Center. Esta carga diaria del protocolo de transferencia de archivos segura (SFTP) actualiza todos los datos de los comercios, los servicios y los horarios disponibles. Los feeds especifican qué comercios admites, su disponibilidad y las funciones especiales necesarias para confirmar que Google muestre tu inventario correctamente. Los feeds se suben a los buzones de SFTP que se configuran cuando proporcionas tu clave SSH en Configuración.

Debes completar las siguientes tareas de Feeds Ready antes de pasar al servidor de reservas:

Las tareas se marcarán como completadas y se pondrán de color verde después de que subas tus feeds correctamente. Revisa la documentación vinculada para completar cada tarea específica del hito.

Para que tu integración de extremo a extremo de Reservas de restaurantes funcione correctamente, debes proporcionar cargas automáticas diarias del feed de comercios, el feed de servicios y el feed de disponibilidad. Tu infraestructura de feeds automatizados debe proporcionar tu inventario completo.

Tipos de feed

Las integraciones de extremo a extremo de Reservas de restaurantes requieren los siguientes feeds y sus frecuencias de carga:

Feed Descripción Frecuencia Muestra
Comerciante Describe a tus comercios. Una vez cada 24 horas Ejemplo de feed de comercios
Servicios Describe los servicios de tus comercios. Una vez cada 24 horas Ejemplo de feed de servicios
Disponibilidad Describe los horarios disponibles para los servicios de tus comercios. Se debe proporcionar una cobertura mínima de 30 días. Para extender la cobertura a 90 días, comunícate con el equipo de asistencia de Google a través del formulario de contacto del Centro de acciones. Una vez cada 24 horas Ejemplo de feed de disponibilidad

Los formatos de los feeds se describen con la sintaxis del búfer de protocolo 3, pero puedes subir tus feeds en el formato JSON correspondiente. Consulta los ejemplos de feeds para ver el formato JSON. Te recomendamos que subas los feeds en formato JSON.

Convenciones de nomenclatura y metadatos

Nombres del archivo

Si usas fragmentación, los feeds que subas deben tener nombres únicos que especifiquen el tipo y el recuento de feeds. Una marca de tiempo para la generación del feed satisface el requisito de unicidad del nombre del archivo del feed.

Estructura: {feed_name}_{timestamp_epoch}_{shard_nunber}_{total_shard}.json

Ejemplo: availability_feed_1574117613_001_of_002.json.gz

Cómo definir IDs

Cuando definas IDs para tus comercios o cualquier otro atributo que requiera un ID, te recomendamos que uses UIDs o UUIDs. Puedes proporcionar tu propia solución alfanumérica, siempre y cuando los IDs sigan siendo distintos en toda tu plataforma.

Metadatos

Cuando creas feeds, el atributo generation_timestamp debe reflejar el momento en que se extrajeron los datos de la base de datos. Si se reutiliza este valor en varios feeds, se pueden producir errores de procesamiento.

Los valores de nonce, que son números aleatorios o no repetitivos, deben ser únicos en todos los tipos de feeds y no se pueden reutilizar. El valor debe coincidir en todos los archivos del feed fragmentado específico.

Tamaño del archivo del feed

Cómo fragmentar los archivos de feeds

Según tu inventario, es posible que sea necesario fragmentar o dividir los feeds en varios archivos. Es posible que tus feeds necesiten fragmentación en las siguientes condiciones:

  • El feed comprimido con gzip supera los 200 MB para un archivo.
    • Ejemplo: El feed de disponibilidad generado es de 1 GB. Debe fragmentarse en cinco o más fragmentos separados.
  • El inventario del socio se distribuye en diferentes sistemas o regiones, lo que dificulta la conciliación del inventario.
    • Ejemplo: El socio tiene inventario de EE.UU. y la UE que se encuentra en sistemas separados. Es posible que el feed se genere con dos fragmentos. Una para EE.UU. y otra para la UE con el mismo valor de nonce y generation_timestamp.

Para obtener más información, consulta los tutoriales y las prácticas recomendadas para fragmentar archivos de feeds.

Un feed puede estar compuesto por varios archivos llamados fragmentos. Para determinar el tamaño de los feeds, sigue estos lineamientos:

  • Fragmentación de feed sugerida:
    • Feed de comercios: Un fragmento
    • Feed de servicios: Un fragmento
    • Feed de disponibilidad: Menos de 20 fragmentos Si tienes una justificación comercial que requiere más de la cantidad especificada, comunícate con el equipo de asistencia para obtener más instrucciones.
  • Tamaño de los archivos del feed y fragmentación:
    • El tamaño de cada archivo debe ser inferior a 200 MB después de la compresión. Usa varios fragmentos si es necesario.
    • No es necesario que los registros individuales que se envían en un Shard se envíen en el mismo Shard en futuros feeds.
    • Para obtener un mejor rendimiento, divide los datos de manera uniforme entre los Shards a fin de que todos tengan un tamaño similar.
    • Si es necesario, usa gzip para comprimir los feeds JSON de texto sin formato para cada fragmento de feed individual.

Comprime los archivos de feed

Cualquier archivo JSON o PB3 se puede comprimir con gzip antes de subirlo. Esto puede reducir significativamente el tamaño de los bytes de los feeds diarios.

Cada archivo de fragmento debe comprimirse con gzip y subirse de forma individual, como gzip*.json. Los fragmentos de feeds comprimidos deben terminar en .json.gz o .pb3.gz.

Sube los feeds a tu buzón de SFTP

Después de generar los feeds de Merchant, Service y Availability, puedes subirlos al entorno de zona de pruebas o de producción a través del buzón de SFTP. El dropbox SFTP se configura cuando proporcionas tu clave SSH en Configuración. El servidor SFTP de Google está disponible en sftp://partnerupload.google.com, en el puerto 19321.

Google revisa y valida los archivos de feeds en cuanto se suben al buzón de SFTP. Si el feed está fragmentado en varios archivos, se procesan después de que subes el último archivo. Si tu feed contiene errores, recibirás un correo electrónico con los códigos de error del feed. Los errores impiden que se ingieran los comercios, los servicios o la disponibilidad definidos. Después de que se validan los feeds, pueden transcurrir hasta 24 horas hasta que aparezcan en el frontend.