Битрикс24: доработки без потери обновлений

Глава 7 руководства «Вайбкодинг в 1С и Битрикс24». Общие главы — про постановку задачи и проверку кода — там же.

Коротко

В Битрикс24 та же развилка, что в 1С: есть способ быстрый и есть способ, который переживёт обновление. Помощник по умолчанию предлагает быстрый.

И ещё одно, что надо понять до первой задачи: облачный Битрикс24 и коробочный — это разные истории. В облаке своего серверного кода нет вообще, там только внешние запросы и приложения. В коробке можно почти всё, и именно там легко сломать обновления.

Что можно в облаке

Если у вас облачный портал, доступны три способа что-то автоматизировать.

• Вебхуки. Самый быстрый вход. Получаете адрес с ключом и обращаетесь к порталу обычными сетевыми запросами: создать сделку, найти контакт, добавить задачу. Помощник с этим справляется хорошо, потому что это обычная работа с сетевым интерфейсом.
• Приложения. Полноценный способ: своя авторизация, встраивание в интерфейс, права. Дольше, но правильно, если решение пойдёт не одному клиенту.
• Роботы и бизнес-процессы. Настраиваются мышкой, кода не требуют. Прежде чем писать код, проверьте, не закрывается ли задача здесь: это самый дешёвый в поддержке вариант.

Что можно в коробке и где ловушка

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

Правило одно: свой код живёт в отдельной папке для доработок, а не в системных файлах. Всё, что положено в системные папки, будет затёрто при обновлении. Не «может быть затёрто», а будет.

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

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

Обработчики событий вместо правки чужого кода

Основной приём, который делает доработки безопасными. Вместо того чтобы менять существующую функцию, вы подписываетесь на событие: «когда создаётся сделка — сделай вот это».

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

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

Как отличить хороший совет от плохого

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

Ситуация 1. «Нужно, чтобы при создании сделки уходило уведомление».
Короткий путь: найти файл, где обрабатывается создание сделки, и дописать туда вызов. Переживёт до первого обновления.
Правильный: подписаться на событие создания сделки, обработчик положить в папку для локальных доработок. Системный код не тронут.

Ситуация 2. «Надо изменить поведение стандартного компонента».
Короткий путь: отредактировать сам компонент. Это гарантированная потеря правок при обновлении.
Правильный: скопировать компонент в свою папку и дорабатывать копию, либо обойтись параметрами и шаблоном. Оригинал остаётся оригиналом.

Ситуация 3. «Нужно свести данные с внешней системой».
Короткий путь: писать напрямую в таблицы базы. Работает быстро и ломает целостность данных: платформа не узнает об изменениях, кеши останутся старыми.
Правильный: только через штатный программный интерфейс. Медленнее, зато данные остаются согласованными.

Один вопрос, который проверяет любой совет

Прежде чем принять код, спросите себя: что произойдёт с этой правкой при обновлении платформы?

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

Тот же вопрос можно задать прямо помощнику: «переживёт ли это обновление и где именно лежит файл». Отвечает он честно — просто сам по себе об этом не думает.

Свои случаи из практики стоит собирать отдельно: где помощник предложил править системный файл и чем это закончилось. Такие разборы читают внимательнее любых общих рекомендаций.

Где помощник ошибается на Битрикс24

• Устаревшие примеры. Платформа старая, в интернете много кода десятилетней давности. Помощник его знает и предлагает.
• Путает облако и коробку. Даёт серверный код тому, у кого облако, где выполнять его негде.
• Выдуманные методы интерфейса. Как и в 1С: имя правдоподобное, метода нет. Проверяется по документации разработчика.
• Игнорирует ограничения на частоту запросов. Код работает на десяти записях и упирается в лимит на тысяче.
• Не думает о правах. Вебхук выполняется от имени создавшего его пользователя. Помощник напишет код, который увидит больше, чем должен видеть конечный пользователь.

Безопасность вебхуков

Короткий, но обязательный раздел.

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

Порядок выбора решения

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

1. Закрывается роботом или бизнес-процессом? Настройте, кода не надо.
2. Нужен обмен с внешней системой? Вебхук.
3. Решение пойдёт нескольким клиентам или встраивается в интерфейс? Приложение.
4. Коробка и нужна своя логика внутри? Обработчик события в папке для доработок.
5. Правка системного файла? Не делайте. Если кажется, что иначе никак, — вернитесь к пункту 4 и опишите задачу подробнее.

← Все девять глав руководства