Условный пример: интернет-магазин отправил заказ в рабочую систему. Ответ не пришёл вовремя. Сотрудник нажал повтор, и менеджер увидел два заказа. Сеть подвела один раз, а работы добавилось дважды.
Проблема не обязательно требует менять CRM — систему управления отношениями с клиентами. Сначала полезно проверить поведение интеграции, то есть обмена данными между программами. Кнопка «Повторить» должна означать продолжение одной операции, а не создание новой по памяти сотрудника.
Тайм-аут не сообщает, что произошло
Если время ожидания истекло, отправитель знает только одно: он не получил понятный ответ. Запрос мог не дойти, мог выполниться, а мог ещё обрабатываться.
Поэтому перед повторной записью нужно искать фактический результат по устойчивому идентификатору исходной операции. Имя клиента и сумма недостаточны: один человек вправе оформить два одинаковых заказа. А две доставки одного запроса не должны создавать два заказа.
Разделяйте номер исходного заказа, идентификатор конкретного события и версию изменения. Одна и та же карточка может изменяться много раз. Если считать дублем всё с её номером, интеграция начнёт терять законные обновления.
Что означает «безопасно повторить»
Полезный принцип называется идемпотентностью: повтор того же действия не создаёт второй бизнес-результат. Это требование к реализации обмена, а не универсальный переключатель Битрикс24.
Исполнитель должен объяснить, где сохраняется ключ операции, как фиксируется результат и что произойдёт, если одинаковые запросы придут одновременно. Простая проверка «сначала поиск, потом создание» может оказаться недостаточной: два обработчика успеют одновременно ничего не найти.
Для операции создания зафиксируйте связь между исходным заказом и полученной карточкой. Для обновления согласуйте, как отличать свежие данные от запоздавшей версии. Повтор не должен откатывать подтверждённое состояние назад.
У очереди тоже есть правила
Официальная документация Битрикс24 рекомендует надёжно сохранять входящее событие перед успешным ответом, а тяжёлую обработку выполнять отдельно. В ней также указано, что обычное событие Битрикс24 не отправляется повторно при аварийном ответе обработчика. Не стройте восстановление на предположении «платформа всё пришлёт ещё раз».
При этом собственная очередь интеграции может повторить обработку после сбоя. Именно здесь важно не создавать результат дважды. Число попыток, паузы, обработка постоянных ошибок и уведомление ответственного должны быть определены заранее.
Не повторяйте бесконечно запрос с неправильными данными или недостаточными правами. Сначала требуется устранить причину, затем проверить состояние и решить, какую операцию продолжать.
Проверьте три неприятных момента
- Получатель сохранил заказ, но ответ потерялся: повтор возвращает найденный результат.
- Два обработчика получили одну операцию одновременно: появляется один заказ.
- Старая версия изменения пришла после новой: актуальные данные не затираются.
Используйте учебные записи и согласуйте безопасные условия испытания. Журнал должен помогать найти операцию, время, попытку и результат без публикации паролей, токенов или лишних данных клиента.
Как обсудить доработку
Если одна из сторон — Битрикс24, проверьте доступность REST API, то есть программного интерфейса обмена, и нужные права по условиям вашего портала. Возможности второй программы нужно проверять отдельно. Само наличие двух API ещё не обеспечивает защиту от повторов.
Для бизнеса в Кыргызстане начните с одного воспроизводимого случая: исходная операция, её номер и фактический результат в обеих системах. На странице разработки REST API QQDev можно обсудить правила повторов и журналирование для вашего обмена. Менять работающую систему ради одной кнопки заранее не требуется.