Почему интеграции создают дубли и что с этим делать

• Интеграции

К вопросам по статье

Одна отправка не всегда означает один запрос

Две одинаковые сделки могут появиться после одной отправки формы: CRM сохранила первую, но ответ потерялся, и обработчик повторил запрос. Другая ситуация — клиент действительно заказал две услуги. Прежде чем включать удаление дублей, выясните, какой из этих случаев произошёл: от этого зависит, что сохранять и как исправлять интеграцию.

Поэтому правило «получили запрос — создали сделку» подходит не для любого процесса. Поведение при повторе нужно обсуждать до реализации, а не после появления дублей в рабочей базе.

Повтор и новое обращение — разные вещи

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

Полезно разделить идентификатор события, клиента и бизнес-операции. Тогда система сможет повторно обработать доставку одного события и одновременно сохранить новое обращение того же человека.

Согласуйте правила сопоставления

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

Разберите дубль по четырём разным идентификаторам

Возьмите пару спорных карточек. Сравните не только телефон и текст, но и источник, номер заказа, идентификатор события и время попыток. Если технических связей нет, сходства полей недостаточно для автоматического удаления. Сначала разберите один случай вместе с менеджером и разработчиком; правило для оставшейся базы должно следовать из этого разбора.

Нужны четыре уровня: человек или организация, бизнесовое обращение, событие изменения и техническая доставка. Их идентификаторы могут приходить из разных систем. Важно сохранять связь, а не заменять все уровни одним полем «внешний ID». Тогда повтор доставки возвращает прежний результат, новое событие обновляет нужный объект, а новое обращение существующего клиента создаёт отдельную рабочую задачу.

Для интервью с владельцем процесса полезно подготовить по одному примеру каждого уровня. Не нужны реальные контакты: достаточно обезличенных записей с понятной последовательностью. Команда должна договориться, какие различия создают новое действие, а какие лишь повторяют уже принятое. Только после этого можно выбирать ключи и способ хранения.

Составьте карту возникновения повторов

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

Эти источники требуют разных проверок. Блокировка кнопки уменьшает случайные клики, но не защищает обмен между серверами. Запоминание входящего события помогает распознать доставку, но не всегда предотвращает повторное внешнее действие после аварии. Инструкция оператору полезна, однако не заменяет способ найти результат неизвестной попытки.

Особенно опасен разрыв «CRM создала объект — отправитель не узнал». Если повтор снова вызывает создание, появляется дубль. Если повтор всегда игнорируется, исходная задача может остаться без известного результата. Требование должно включать возможность сопоставить неизвестную попытку с уже созданной записью и продолжить маршрут без нового обязательства.

Паспорт события для задания на интеграцию

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

Разделите принятие события и выполнение действия

Получить запрос, проверить его, сохранить для обработки и создать объект в CRM — разные результаты. Если обработчик сообщает окончательный успех до надёжного принятия, сбой может потерять событие. Если ждёт завершения длинной внешней операции без учёта контракта поставщика, отправитель может считать доставку неуспешной и повторять её.

Один из вариантов архитектуры — отдельная запись входящего события с состоянием обработки. Она позволяет видеть очередь, повторять временный отказ и разбирать постоянную ошибку. Однако само наличие очереди не обеспечивает единственность эффекта. Нужно определить, как два параллельных исполнителя делят работу и как сохраняется связь с внешним результатом.

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

Бизнес-процесс разбора повторной заявки

У разбора три возможных итога. Повтор одной операции связывают с прежним результатом. Новую потребность сохраняют отдельно по принятому правилу. Неоднозначное совпадение передают ответственному, оставляя сведения об обеих попытках. Это правило сначала проверяют на подготовленных примерах; включать его сразу для удаления рабочей истории нельзя.

В этом процессе владелец продаж определяет, когда обращение новое. Аналитик описывает правила сопоставления. Разработчик реализует согласованную обработку. Поддержка разбирает неизвестный результат по связи идентификаторов. Менеджер не обязан понимать технические заголовки, но должен видеть, что заявка принята, объединена по правилу или ожидает решения.

Выход — одна объяснимая рабочая запись для одного намерения и сохранённая история повторов. Контрольный вопрос: сможет ли другой сотрудник показать, почему здесь одна карточка, а в похожем случае две? Если ответ зависит от памяти автора интеграции, правило ещё недостаточно оформлено для эксплуатации.

Диагностический пример неизвестного результата

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

Усложним пример: через час тот же человек отправляет такую же форму по другой задаче. Совпадают имя, телефон и текст. Это может быть новая потребность. Если правило отсечения использует только совпадение полей, бизнес потеряет обращение. В контрольной выборке нужно отдельно обозначить, чем новая операция отличается от технического повтора первой.

Третий вариант — два обработчика получают одну доставку почти одновременно. Проверка «сначала поискали ключ, потом записали» без согласованной защиты способна дважды увидеть отсутствие результата. Приёмка смотрит окончательное число объектов, а не два локальных сообщения «проверка пройдена». Такой тест обнаруживает ошибки, которых не видно при последовательном ручном нажатии.

Не всякую ошибку нужно повторять

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

Нужно определить предел ожидания, порядок увеличения промежутков и маршрут после исчерпания автоматических попыток. Значения зависят от контракта внешнего сервиса и допустимого времени работы бизнеса. Бесконечный фоновый повтор может скрывать проблему неделями. Немедленный ручной повтор всей партии, напротив, способен размножить неизвестные результаты.

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

Порядок событий и устаревшие обновления

Повтор — не единственная причина неверных карточек. Создание, изменение и отмена могут поступить с задержкой. Если применять всё в порядке получения без оценки смысла, старое обновление вернёт отменённый заказ в активное состояние. Нужны правила версии, допустимых переходов и разрешения противоречий.

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

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

Матрица приёмки защиты от дублей

Срок хранения истории повторов

Журнал обработанных событий не обязан расти бесконечно, но срок нельзя выбирать только по свободному месту. Нужно понять, как долго источник способен повторять доставку, когда оператор может вручную запустить её заново и какие события ещё требуют разбора. После удаления ключа старый повтор может выглядеть новым — это важная граница гарантии.

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

Внешние сервисы имеют собственные условия. Например, Stripe описывает идемпотентные запросы и связь повторов с ключом. Эти правила нужно читать для конкретного API: наличие похожего заголовка в другой системе не означает одинаковое поведение. GitHub отдельно рекомендует учитывать идентификатор доставки webhook. Примеры документации не приписывают эти платформы вашим проектам, а показывают, какие контракты следует изучать.

Что демонстрирует реальную компетенцию интегратора

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

В кейсе Маткласса я подтверждал доставку по контрольным сделкам в amoCRM. При проверке повторов нужен следующий вопрос: сколько конечных записей относится к одной попытке и чем доказана эта связь? Это применение метода проверки, а не утверждение, что у Маткласса реализованы все механизмы очередей, ключей и восстановления, описанные в статье.

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