Todos los retos

Reto 09

Que los pedidos del restaurante sigan adelante

Recupera todos los pedidos válidos de restaurantes desde una API paginadaUn servicio que divide un resultado grande en páginas numeradas e indica al workflow si existe otra página. – un servicio que divide un resultado grande en páginas numeradas – incluso cuando limita las peticiones o falla de forma inesperada.

AvanzadoComplejidad:Tiempo: 45–60 min

Tu tarea

Recupera todos los pedidos de la API suministrada, supera los fallos temporales y separa los pedidos válidos de los datos que no se pueden procesar con seguridad.

Tu tarea extra

Procesa los pedidos válidos uno por uno y calcula su importe total conjunto. Excluye los pedidos rechazados del total. Registra diagnósticos útiles si la API sigue fallando después de todos los reintentosNuevos intentos realizados después de un fallo temporal de una petición..

Ejemplos de uso

  • Una plataforma de reparto debe importar pedidos aunque la API de sus restaurantes no sea fiable temporalmente.
  • Un equipo de operaciones necesita seguir procesando los pedidos válidos sin perder los registros rechazados.
  • Una sincronización nocturna debe recuperarse de los límites de frecuenciaRechazos temporales cuando un servicio recibe demasiadas peticiones; este recurso usa el estado HTTP 429. – rechazos temporales por demasiadas peticiones – sin producir resultados incompletos.

Antes de empezar

  1. 01

    Regístrate en n8n Cloud o abre un espacio de trabajo de n8n existente y crea un workflow nuevo.

  2. 02

    Usa la API de pedidos inestable preparada para este reto. Esta URL normal devuelve al azar una página correcta, una respuesta 429 por límite de frecuencia o un error 500 de servidor que admite reintento; no añadas un parámetro scenario mientras construyes.

  3. 03

    Crea una Data Table llamada rescued_orders para los pedidos válidos, otra llamada rejected_orders para los datos rechazados junto con el motivo del rechazo y – para la tarea extra – api_failure_diagnostics para los detalles de reintentos agotados.

  4. 04

    No se necesita ninguna cuenta externa, clave API ni otra credencial. Cuando el workflow esté terminado, añade `&scenario=success`, `&scenario=rate_limit` o `&scenario=server_error` a la URL para forzar cada respuesta y después quítalo. Un fallo forzado se repite en cada intento, así que también muestra qué ocurre cuando se agotan todos los reintentos.

Qué debe hacer el workflow

  1. 01

    Sigue la información de paginación de la API y recupera los 25 pedidos sin crear manualmente una petición separada para cada página.

  2. 02

    Reintenta las respuestas temporales 429 y 500, guarda los 24 pedidos válidos y no pierde los pedidos que tuvieron éxito antes de que fallara otra petición.

  3. 03

    Rechaza ORD-1013, registra un motivo de validaciónComprobaciones de que los campos obligatorios existen y usan tipos de datos seguros antes de guardar un registro. claro y demuestra el workflow frente a respuestas correctas, limitadas por frecuencia y con los reintentosNuevos intentos realizados después de un fallo temporal de una petición. agotados.

Solución

Ver la respuesta del reto de workflow

Muestra el workflow completo solo cuando quieras compararlo con el tuyo.

Enviar como resuelto

¿Listo para enviar?

Envía el reto cuando el equipo tenga un workflow funcional que mostrar.

Solución

¿Mostrar la solución del workflow?

Esto mostrará el workflow completo de este reto. ¿Seguro que quieres continuar?

Revisión del mentor

Busca a un mentor y pídele que revise tu workflow.

Muéstrale el workflow funcionando. Cuando lo apruebe, recoge el globo de este reto.