Черга недоставлених повідомлень у n8n: вправа з вибіркового повторного надсилання
Редакційна вправа з чергою недоставлених повідомлень у n8n: збережіть невдалі записи, повторно надішліть виправлені дані у WireMock і звірте кількість запитів.
Перевірено за наведеними джерелами .
Редакційна вправа: завдання та межі
Побудуйте в n8n чергу недоставлених повідомлень, яка зберігає синтетичні записи після невдалої обробки разом із причинами та ідентифікаторами кореляції, а потім вручну повторно надішліть лише виправлений запис. Порівняйте кількість запитів у WireMock, щоб перевірити, що для раніше успішних і невибраних записів не надходять додаткові запити. Це редакційна вправа; її реалізацію та очікувані результати тут не запускали й не перевіряли.
Вам потрібні середовище n8n із Data Tables, базові знання REST і наданий ведучим сервер WireMock, доступний із n8n. Data Tables підтримують збереження даних між робочими процесами в одному проєкті та умовні операції з рядками. Вони підходять для невеликих і помірних обсягів даних, мають обмеження сховища на рівні інстансу й за замовчуванням доступні учасникам проєкту.
Виконуйте обробку вручну та послідовно: вимкніть автоматичні повторні спроби запитів і не допускайте одночасного редагування таблиць. Одночасні зміни можуть призвести до неузгодженості під час посторінкового читання Data Tables. Паралельне відновлення, автоматичне повторне надсилання, розгортання у виробничому середовищі та гарантії обробки рівно один раз виходять за межі вправи. На нашу думку, вправа з відновлення з навмисно вузькими межами корисніша за рішення, яке виглядає готовим до експлуатації, але має незрозумілі гарантії.
Sources: n8n-docs/docs/build/work-with-data/data-tables.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.datatable/rows.md at main · n8n-io/n8n-docs · GitHub, Running as a Standalone Process | WireMock
Підготуйте записи та детермінований імітатор
Використовуйте наведений нижче авторський набір тестових даних із POST-запитами та тілами у форматі JSON. Установіть X-Correlation-ID рівним ID запису. Попросіть ведучого налаштувати точне зіставлення тіл JSON для цих відповідей, а також резервну відповідь 400 із {"reason":"fixture mismatch"}. Це авторські вхідні дані вправи й очікувані відповіді.
| Запис / заголовок | Шлях | Початкове тіло | Початкова відповідь | Виправлене тіло / відповідь |
|---|---|---|---|---|
| A | /orders/A | {"quantity":1} | 201; {"accepted":true} | Без виправлення |
| B | /orders/B | {"quantity":0} | 422; {"reason":"quantity must be positive"} | {"quantity":2}; 201; {"accepted":true} |
| C | /orders/C | {"quantity":3} | 503; {"reason":"simulated outage"} | Без виправлення |
WireMock підтримує зіставлення заголовків і тіл запитів. n8n підтримує власні заголовки та тіла JSON, хоча надане джерело конфігурації — це код HTTP Request V3 у гілці master, а не зафіксований реліз. У цій вправі заголовок кореляції ідентифікує запити для підрахунку; він не реалізує ідемпотентність.
Sources: n8n/packages/nodes-base/nodes/HttpRequest/V3/Description.ts at master · n8n-io/n8n · GitHub, Request Matching | WireMock
Зберігайте невдалі записи в черзі недоставлених повідомлень n8n
Для цієї черги недоставлених повідомлень у n8n створіть Data Table failures із полями correlationId, path, originalPayloadJson, replayPayloadJson, failureReason, httpStatus, status і replayOutcome. Для початкових результатів, зокрема успішних, ведіть окрему таблицю outcomes. Ці поля — редакційна схема; умовні операції вставлення, отримання й оновлення є задокументованими можливостями, а не гарантіями транзакційного повторного надсилання.
Побудуйте робочий процес збереження невдалих записів у наведеному порядку. Перш ніж писати вирази, перевірте фактичні вихідні дані вузлів: немає гарантії, що гілка помилок збереже початкові бізнес-дані.
- Збережіть ID, шлях і початковий JSON кожного запису перед HTTP Request.
- Надішліть тестовий запит з увімкненим Include Response Headers and Status і вимкненим Never Error.
- Установіть On Error у Continue (using error output) та явно під’єднайте цей вихід.
- Перевірте обидва виходи: класифікуйте успішні відповіді у звичайній гілці, а тестові HTTP-помилки 422 і 503 — у гілці помилок.
- Зіставте фактично доступні поля HTTP-статусу та причини, відновивши збережені ID й дані через коректне зв’язування елементів. Зупиніться, якщо не вдається відновити статус, причину або початкові дані тестової відповіді; не вгадуйте шляхи до полів.
- Обробляйте транспортні помилки окремо, оскільки вони можуть не мати HTTP-відповіді. Записуйте кожен початковий результат; додавайте невдалі записи зі status failed, їхніми даними й непорожньою причиною.
Для пов’язаних вхідних елементів n8n документує $('Preserve input').item.json за умови, що така назва вузла й зв’язування елементів коректні. Зв’язування одного вхідного елемента з одним вихідним підтримує послідовну схему цієї вправи, але нові елементи або зміна їхньої кількості можуть порушити зв’язок. Якщо дані відсутні, ми б зупинили виконання, а не підставляли перший елемент зі змішаного пакета.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.datatable/rows.md at main · n8n-io/n8n-docs · GitHub, HTTP Request | Nodes | n8n Docs, n8n-docs/docs/build/understand-workflows/workflow-components/work-with-nodes.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/build/work-with-data/reference-data/reference-previous-nodes.md at main · n8n-io/n8n-docs · GitHub, How items link through workflows | Build | n8n Docs
Виправте B і повторно надсилайте лише придатні рядки
Перевірте збережену причину та початкові дані B. Установіть replayPayloadJson у {"quantity":2}, залишивши originalPayloadJson без змін. Не вибирайте C. Перед повторним надсиланням збережіть кількість запитів для A, B і C за допомогою POST /__admin/requests/count із тілами на кшталт {"method":"POST","urlPath":"/orders/A","headers":{"X-Correlation-ID":{"equalTo":"A"}}}; для B і C узгоджено замініть відповідні значення.
Побудуйте окремий робочий процес із ручним запуском, який отримує лише запис із correlationId B та status failed. Надішліть його виправлені дані за збереженим шляхом із тим самим заголовком. Збережіть налаштування Include Response Headers and Status, залиште Never Error вимкненим, вимкніть автоматичні повторні спроби й під’єднайте Continue (using error output) до обробника невдалих запитів. Перевірте обидва виходи та зіставте їхні фактичні поля статусу й причини, як під час збереження невдалих записів. Лише після перевірки підтвердженої відповіді 201 оновіть status цього рядка на replayed і запишіть результат. У разі невдачі збережіть причину й залиште рядок доступним для перевірки.
Після успіху повторіть той самий відбір: він не повинен повернути жодного придатного рядка B і не повинен надіслати жодного запиту. На нашу думку, критерії придатності мають бути в умовах отримання даних, де їх можна перевірити до будь-якого виклику цільової системи.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.datatable/rows.md at main · n8n-io/n8n-docs · GitHub, n8n/packages/nodes-base/nodes/HttpRequest/V3/Description.ts at master · n8n-io/n8n · GitHub, HTTP Request | Nodes | n8n Docs, n8n-docs/docs/build/understand-workflows/workflow-components/work-with-nodes.md at main · n8n-io/n8n-docs · GitHub, Request Matching | WireMock, Verifying | WireMock
Перевірте кількість запитів і обміркуйте невизначеність
Повторіть ідентичні запити підрахунку та порівняйте результати зі збереженими початковими значеннями. Перевірка WireMock залежить від журналу запитів у пам’яті: скидання, вимкнення журналювання або видалення записів роблять порівняння недійсним.
Також перед повторним надсиланням збережіть кількість запитів із виправленим тілом, надіславши {"method":"POST","urlPath":"/orders/B","headers":{"X-Correlation-ID":{"equalTo":"B"}},"bodyPatterns":[{"equalToJson":{"quantity":2}}]} до /__admin/requests/count на вашому сервері WireMock. Повторіть підрахунок після повторного надсилання: очікуваний приріст — один, а після відбору вже повторно надісланого B — нуль. Збережіть і ширший запит для B, щоб додаткові запити з будь-якими даними залишалися видимими.
Звірте кожен записаний статус відповіді та причину з тестовим набором: початковий A повинен мати 201, початковий B — 422 із quantity must be positive, початковий C — 503 із simulated outage, а виправлений B — 201. Будь-яку відповідь 400 із fixture mismatch, відсутню причину або неочікувану відповідь вважайте проваленою перевіркою. Використовуйте наведені нижче очікувані перевірки як критерії завершення.
Якщо перевірка не проходить, перш ніж продовжувати, перевірте зіставлення в імітаторі, гілки збереження невдалих записів і зв’язування даних. Поміркуйте: що станеться, якщо цільова система прийме B, але записати успіх не вдасться? Ця вправа з чергою недоставлених повідомлень у n8n демонструє вибіркове спрямування запитів у зазначених межах; відновлення у виробничому середовищі також потребує обробки невизначених результатів з урахуванням цільової системи, відповідального за відновлення та політики зберігання даних.
Sources: n8n-docs/docs/build/understand-workflows/workflow-components/work-with-nodes.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/build/work-with-data/reference-data/reference-previous-nodes.md at main · n8n-io/n8n-docs · GitHub, Request Matching | WireMock, Verifying | WireMock
