Урок 6 из 6

Проверка и отладка

5–7 мин

В интеграции поломка выглядит иначе, чем на обычном сайте. Ничего не падает: кнопка нажимается, страница открывается, каталог на месте. Просто лид не появился или цена осталась вчерашней.

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

Посмотрите ответ целиком

Битрикс отвечает всегда: либо данными, либо ошибкой. Ошибка приходит не красным экраном, а обычным ответом с кодом и описанием. Попросите показать его:

Готовый запрос
Покажи полный ответ Битрикса на последний неудачный запрос: код ошибки и описание. Секреты и данные клиентов не выводи.

Описание обычно и содержит ответ, а код помогает понять, где искать.

Четыре причины, из-за которых чаще всего не работает

Не хватает прав. Самая частая. В настройках вебхука не отмечен нужный раздел или у пользователя нет доступа к этим данным. Проверяется за минуту.

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

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

Опечатка в данных. Неверное название поля, лишний символ в адресе, не тот идентификатор. В таких ответах Битрикс обычно прямо называет проблемное место.

Попросите RUFP найти место сбоя

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

Готовый запрос
Найди, на каком шаге возникает ошибка в интеграции. Ничего пока не исправляй. Проверь последовательно: 1. Работает ли сохранённый вебхук: выполни безопасный запрос на чтение и получи список последних контактов. 2. Хватает ли вебхуку прав для операции, которая не сработала. 3. Какой запрос фактически отправляет сайт или обработчик: метод, поля и идентификаторы. Секретные значения не показывай. 4. Какие обязательные поля ожидает мой Битрикс24 и все ли они передаются. 5. Какой полный ответ вернул Битрикс: код ошибки и описание. 6. Что записано об этой попытке в журнале сервера. Для каждого пункта напиши: «проверка пройдена» или «найдена ошибка» и коротко объясни результат. В конце дай один вывод: — на каком шаге произошёл сбой; — какая причина подтверждена; — чем она подтверждается; — какое минимальное исправление нужно сделать. Не выводи адрес вебхука, секреты и данные клиентов.

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

Если агент перечислил несколько возможных причин, но не проверил их и не назвал одну подтверждённую, продолжите тем же чатом:

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

Исправьте только найденную причину

Когда RUFP назвал точный шаг и подтвердил причину, попросите сделать минимальную правку и сразу повторить тот же тест:

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

Так пользователь не угадывает причину по списку, а получает от RUFP проверенный вывод и исправление с повторным тестом. Если диагностика снова остановилась, примените приёмы из урока Что делать, если агент не справился: уменьшите задачу до одного запроса или вернитесь к последнему рабочему варианту.

Чек-лист перед публикацией

  1. Адреса вебхука нет в исходном коде страницы.
  2. Вебхуку отмечены только нужные разделы.
  3. Заявка сохраняется на сервере до отправки в CRM.
  4. Двойное нажатие кнопки не создаёт второй лид.
  5. Повторная синхронизация не задваивает каталог.
  6. Промежуток обновления выставлен под задачу, а не для проверки.
  7. Учебный вебхук заменён на рабочий и проверен; тестовые заявки и товары убраны из Битрикса.

После замены уберите тестовые данные. Заявки с именем «ааа» живут в воронке месяцами и портят статистику отдела продаж.

Итог

  • Ошибка в интеграции выглядит как тишина, а не как поломка: искать нужно в ответах Битрикса.
  • Большинство отказов — это права, обязательные поля, лимиты или опечатка.
  • Если причина не очевидна, RUFP просят пошагово проверить цепочку и назвать подтверждённое место сбоя.
  • Перед публикацией проходят чек-лист и убирают за собой тестовые данные.