Перейти к содержимому
RKTSocial
ИТ-разработка

Как связать сайт, Telegram-бота и систему учёта

Передача по событию против выгрузки по расписанию, что делать при недоступности принимающей системы, защита от задвоения, единый идентификатор обращения и что логировать.

3 минуты чтенияКоманда RKTSocial

Сайт собирает заявки, бот принимает обращения, учёт ведётся в третьем месте. Каждый инструмент работает, а вместе они дают расхождение: в системе учёта заявок меньше, чем пришло, и никто не может сказать, где потерялись.

Разберём, как устроена передача данных и где она рвётся.

Два способа передачи

По событиюПо расписанию
Когда срабатываетСразу при появлении записиРаз в N минут
ЗадержкаСекундыДо интервала запуска
Поведение при сбое приёмникаЗапись может потерятьсяПодхватится в следующий раз
НагрузкаРавномернаяПиками
СложностьВыше: нужны повторыНиже
Когда выбиратьНужна скорость реакцииДанные не срочные

Для заявок скорость критична — менеджер должен увидеть обращение сразу. Значит, передача по событию, но с механизмом повторов, иначе преимущество превращается в потери.

Что происходит при недоступности приёмника

Самое важное место интеграции и самое часто пропускаемое. Принимающая система бывает недоступна: обновление, сбой, истёкший доступ, превышен лимит запросов.

Заявка → попытка передать → ошибка
                                    ↓
                          Что произошло дальше?

  Плохо:   ошибка записана в лог, заявка потеряна
  Хорошо:  заявка сохранена локально,
           поставлена в очередь на повтор,
           отправлено уведомление ответственному

Правило простое: источник должен сохранять запись у себя до подтверждения приёма. Если запись существует только в момент передачи, любой сбой означает потерю.

Защита от задвоения

Обратная сторона повторов. Типичный сценарий: запись передалась, ответ не дошёл из-за таймаута, источник повторил — в системе две одинаковые заявки.

Решается единым идентификатором обращения, который создаёт источник и передаёт вместе с данными.

  1. Источник присваивает записи идентификатор при создании.
  2. Передаёт его при каждой попытке — включая повторы.
  3. Приёмник проверяет: запись с таким идентификатором уже есть?
  4. Если есть — подтверждает приём и ничего не создаёт.
  5. Если нет — создаёт и подтверждает.

Эта схема делает повторную отправку безопасной: сколько бы раз ни пришёл один и тот же запрос, запись создастся один раз. Без неё приходится выбирать между потерями и дублями.

Про то, как разбирать дубли, которые всё-таки возникли по другим причинам, — отдельный материал.

Что передавать

Минимальный набор, без которого приёмная сторона бесполезна:

  • идентификатор обращения — для защиты от задвоения;
  • источник — сайт, бот, конкретная форма или рекламная кампания;
  • время создания в источнике, а не время передачи;
  • контактные данные в нормализованном виде;
  • содержание — что человек написал или выбрал;
  • служебные метки, если они есть: кампания, страница, откуда пришёл.

Третий пункт объясняет расхождения в отчётах: если фиксировать время передачи, то заявки, пролежавшие в очереди, окажутся в отчёте не за тот период.

Что логировать

Без журнала разобраться в расхождении невозможно: обе стороны будут утверждать, что у них всё в порядке.

ЗаписыватьЗачем
Факт и время каждой попытки передачиПонять, отправляли ли вообще
Код ответа приёмникаОтличить отказ от таймаута
Идентификатор обращенияСвязать записи на обеих сторонах
Номер попыткиУвидеть, что повторы работают
Итог: подтверждено или в очередиНайти зависшие записи

Персональные данные в журнал не пишут. Достаточно идентификатора, по которому запись находится в системе.

Что проверить перед запуском

  1. Заявка доходит и создаётся корректно — базовый случай.
  2. Приёмник выключен — заявка сохранилась и встала в очередь.
  3. Приёмник включили — очередь разобралась сама, без ручного вмешательства.
  4. Повторная отправка того же обращения не создала вторую запись.
  5. Обязательные поля не пустые с обеих сторон.
  6. Время в приёмнике совпадает со временем создания в источнике.
  7. При исчерпании повторов пришло уведомление человеку.

Пункты 2–4 — те самые, которые обычно не проверяют. Именно они отличают работающую интеграцию от такой, которая тихо теряет заявки раз в месяц.

Что запомнить

  • Для заявок нужна передача по событию, но обязательно с повторами.
  • Источник хранит запись до подтверждения приёма.
  • Единый идентификатор обращения делает повторы безопасными.
  • Передавать нужно время создания, а не время отправки.
  • Проверять надо сценарии сбоя, а не только успешный путь.

Куда сводить обращения из всех источников — в материале о едином центре заявок. Что выбрать для приёма обращений — сайт или бот.

Читайте также