Приклад умовний. У компанії-дистриб’юторі керівник погодив заявку на закупівлю, і система автоматизації надсилає її в ERP як замовлення постачальнику. ERP замовлення зберігає, але з’єднання обривається раніше, ніж відповідь доходить до інтеграції. У журналі процесу з’являється «тайм-аут».
Простих реакцій дві, і обидві погані. Можна натиснути «повторити» й отримати друге замовлення в того самого постачальника. Можна позначити задачу як збій, і тоді співробітник заведе замовлення вручну, тобто знову друге.
Закупівля зірвалася? Не обов’язково. Передачу завершено? Поки не перевірено. Тайм-аут говорить лише про те, що відповідь не надійшла.
Сам механізм дубліката під час повторного надсилання ми коротко описували в статті про заявки в CRM. Тут розберемо, як побудувати передачу так, щоб невідомий результат не перетворювався ні на дублікат, ні на втрачене замовлення.
Тайм-аут означає «невідомо»
Для випадку, коли відповіді немає, операція передачі повинна мати окремий стан: не «успіх» і не «помилка», а «результат невідомий». Поки операція в ньому перебуває, створювати нове замовлення не можна, а вважати закупівлю зірваною зарано.
Важливо домовитися й про те, що вважається завершенням. «Готово» в цій операції означає: замовлення в ERP створено, і його номер отримано. Це не означає, що постачальник прийняв замовлення, товар приїхав або рахунок оплачено. Ці кроки мають власні підтвердження.
Що потрібно операції ще до надсилання
Постійний ідентифікатор операції
Ідентифікатор присвоюють один раз, у момент погодження заявки, і він не змінюється під час повторів. Якщо інтеграція на кожній спробі генерує новий номер, для ERP кожна спроба виглядає новим замовленням. Новий ідентифікатор потрібен лише справді новому замовленню.
Погоджена версія даних
Разом з ідентифікатором збережіть ту версію замовлення, яку погодили: постачальника, позиції, кількості, ціни. Якщо заявку змінили після погодження, це вже інша версія, і питання про надсилання вирішують заново. Повтор має передавати саме те, що було погоджено.
Захист від повторів на боці ERP
Якщо API вашої ERP підтримує ключ ідемпотентності, передавайте в ньому ідентифікатор операції й дотримуйтеся правил цієї системи. Такі ключі можуть мати обмежений строк зберігання, а повтор із тим самим ключем, але з іншими даними можуть відхилити.
Якщо такої підтримки немає, записуйте ідентифікатор операції в саме замовлення, наприклад у поле зовнішнього номера документа, якщо воно є. Тоді за ним можна буде шукати. Зважайте: поле з назвою «ключ ідемпотентності» саме собою нічого не гарантує. Важить те, що система насправді робить під час повтору, і це треба перевірити на тестовому стенді, а не лише прочитати в документації.
Transactional outbox: намір надіслати не повинен загубитися
Друга пастка — усередині вашої власної системи. Процес виконує дві дії: позначає в себе «замовлення надіслано» і справді надсилає запит до ERP. Якщо збій станеться між ними, ви отримаєте одне з двох: позначка є, а надсилання не було, або надсилання було, а позначки немає.
Шаблон transactional outbox розв’язує це так. В одній транзакції локальної бази зберігаються і новий стан заявки, і запис «треба надіслати замовлення» в окрему таблицю, яку й називають outbox. Надсиланням займається окремий процес: він бере записи з outbox, передає їх до ERP і фіксує результат. Якщо він впаде посередині, запис нікуди не дінеться й буде оброблений знову.
Це має зворотний бік: той самий запис може бути надісланий більше ніж один раз. Тому outbox працює лише разом із захистом від повторів на боці одержувача або зі звіркою, про яку йдеться нижче.
Шаблон підходить, коли процес має власну базу даних, якою ви керуєте. Якщо автоматизацію зібрано в хмарному конструкторі без такої бази, потрібен аналог: надійне місце, де намір надіслати фіксується до надсилання й не зникає під час збою.
«Не знайдено» ще не означає «не створено»
Після тайм-ауту природно зазирнути в ERP і пошукати замовлення з вашим ідентифікатором. Але порожній результат пошуку не доводить, що замовлення немає:
- пошук може відставати від запису: документ уже збережено, але його ще не видно в списку чи звіті;
- пошук може бути неповним: шукали не за тим полем або під обліковим записом, якому не видно документів іншого складу чи юрособи;
- перший запит може ще виконуватися: перевірка випереджає операцію, яка поки не завершилася.
Тому перевірка після тайм-ауту шукає за ідентифікатором операції, під обліковим записом із доступом до всіх потрібних документів, і повторюється через погоджений інтервал. Якщо й після цього результат не вдається підтвердити в жоден бік, операція залишається в стані «невідомо». Тихий повтор із новим ідентифікатором у такій ситуації — найкоротший шлях до дубліката.
Три результати, які не перетинаються
Кожна операція передачі має завершитися рівно одним із трьох результатів.
- Підтвердження отримано. ERP повернула номер замовлення, інтеграція перевірила, що замовлення існує і перебуває в очікуваному стані. Номер збережено поруч з ідентифікатором операції.
- Відповідь утрачено, замовлення знайдено. Звірка знайшла замовлення за ідентифікатором операції. Операцію пов’язують із цим замовленням і закривають, нове замовлення не створюється.
- Результат підтвердити не вдалося. Операція переходить до відповідального за відновлення разом із доказами: що надіслано, коли, з яким ідентифікатором і що показали перевірки. Відповідальний вирішує, що робити далі, і записує своє рішення.
Звіт про передачі краще будувати за цими трьома результатами, а не за схемою «успіх або помилка». Тоді третій результат видно як окрему роботу, і він не губиться серед інших збоїв.
Відповідальний і регулярна звірка
Третій результат має ім’я
Відповідальний за відновлення — конкретна людина або роль, наприклад керівник закупівель чи адміністратор облікової системи. Йому потрібна черга, де видно ідентифікатор операції, погоджену версію, спроби, результати перевірок і наступну дію. Повний доступ до всіх даних ERP для цього не потрібен. Домовтеся й про те, як швидко він розбирає чергу. Це залежить від того, наскільки терміново постачальник має отримати замовлення.
Звірка за розкладом
Крім розбору окремих випадків, потрібна регулярна звірка, тобто задача, яка порівнює операції на вашому боці з документами в ERP і шукає:
- операції, які надто довго залишаються в стані «надіслано» або «невідомо»;
- замовлення в ERP з вашим ідентифікатором, не прив’язані до жодної операції;
- два замовлення з одним ідентифікатором: ознака того, що захист від повторів не спрацював.
Однозначні випадки, як у другому результаті, звірка може закрити сама. Усе інше потрапляє до черги відповідального.
Рахунки постачальників: той самий випадок
Та сама логіка потрібна під час проведення вхідних рахунків. Якщо з’єднання обірвалося після того, як ERP уже зберегла рахунок, повторне створення без перевірки дасть дублікат документа. Постійний ідентифікатор, пошук за ним і три результати працюють тут так само, як із замовленнями.
Чек-лист перед запуском
- Операція має ідентифікатор, який присвоюють у момент погодження і який не змінюється під час повторів.
- Погоджена версія даних зберігається, і повтор надсилає саме її.
- Відомо, як ERP обробляє повтор: ключ ідемпотентності та строк його зберігання або пошук за зовнішнім номером.
- Намір надіслати фіксується разом зі зміною стану: через outbox або його аналог.
- У процесі є стан «результат невідомий», окремий від успіху й помилки.
- Перевірка після тайм-ауту шукає за ідентифікатором операції, з достатніми правами й повтором через інтервал.
- Кожна операція завершується одним із трьох результатів, і звіт будується за ними.
- Призначено відповідального за відновлення, і він має чергу з доказами.
- Регулярна звірка знаходить завислі операції, неприв’язані замовлення й дублікати.
- У тестовому середовищі підтвердження навмисно втрачено, і відновлення знайшло наявне замовлення, а не створило нове.
З чого почати
Візьміть одну передачу, наприклад «погоджена заявка стає замовленням постачальнику», і дайте відповідь на два запитання: що доводить, що передача відбулася, і хто відповідає за результат, коли доказів немає. Потім додайте стан «невідомо», призначте відповідального й проведіть на тестовому стенді один тест із втраченим підтвердженням. Решту стрілок на схемі процесу перевіряють так само.
Якщо хочете так перевірити одну зі своїх передач в ERP, опишіть її нам, і ми разом розберемо, що зараз відбувається у вас під час тайм-ауту.