1С-Битрикс *

Привет, Хабр! Это снова Алиса из KISLOROD. В прошлых частях мы вынесли из Битрикса каталог, корзину, цены и чекаут. Но в любом ecommerce-проекте есть еще одна зона турбулентности — интеграции.

Платежки, ERP, CRM, доставки, SMS, веб-хуки — все это любит тормозить, дублировать запросы и внезапно падать в самый неподходящий момент. Если держать такие вызовы внутри чекаута или админки, проект быстро начинает жить по SLA внешних сервисов.

В этой части разбираем Integration Hub: очереди, веб-хуки, DLQ, идемпотентность и отдельный контур для интеграций, который не блокирует пользователей и не тянет за собой весь чекаут.

Привет, Хабр! Это снова Алиса из сериала про Laravel рядом с Битриксом.  В первой части мы аккуратно подселили Laravel к Битриксу. Во второй — растащили события, авторизацию и тяжелую логику по нормальным сервисам, а в третьей — перестали мучить каталог SQL-запросами и отдали поиск OpenSearch.

Теперь добрались до места, где любой e-commerce начинает показывать характер: корзина и расчет заказа. Это каталог может тормозить незаметно. А вот если корзина начинает чудить — это уже чувствует бюджет.

В прошлой статье про AI-native организации я писал, что AI-native — это не компания, в которой всем выдали доступ к LLM и поставили несколько ботов в мессенджер. Ключевой переход начинается когда компания умеет описывать свою работу так, чтобы ее можно было исполнять, проверять, передавать по маршруту и постепенно делегировать отдельные шаги AI-агентам.

Эта статья — про один из таких практических шагов. Я хочу рассказать, как мы у себя в компании автоматизировали процессное управление на базе BPMN 2.0 моделей, Camunda и Битрикс24 и получили операционный контур, в котором процесс — это не регламент и не картинка BPMN, а исполняемый маршрут с задачами, контекстом, переменными процесса и передачей контекста между шагами.

Если вы разрабатываете на Битрикс24 и поддерживаете несколько окружений — тест, стейдж, прод — вы знаете эту боль. Настроил воронку, добавил пользовательские поля, написал робота с десятком условий, всё это поправил в карточке, назначил права. А потом нужно повторить то же самое на проде. Руками. Забыв половину.

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

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

Мы прошли этот путь и в итоге написали набор Version Builder'ов для модуля sprint.migration, покрывающих основные сущности CRM Битрикс24. В этой статье — о самой задаче, подходе и подводных камнях.

Пишите в личку по вопросам.

Bitrix24 и amoCRM — две доминирующие CRM в России — отправляют email принципиально разным образом, но имеют общую проблему: ни одна из них не показывает, дошло ли письмо до инбокса получателя. Зелёный статус «Письмо отправлено» в карточке сделки означает только то, что SMTP‑сервер получателя принял письмо. Куда оно легло у клиента — спам, входящие, промоакции — CRM не знает.

В статье:

На первый взгляд миграция из Kaiten в Bitrix24 выглядит как обычная интеграционная задача: прочитать данные из одного REST API и записать в другой REST API.

Но это впечатление быстро проходит, когда начинаешь переносить не демо-доску, а живую проектную систему.

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

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

В этой статье расскажу, как мы построили мигратор на Python, где помог асинхронный подход, почему маппинг ID оказался центральной частью архитектуры, какие ограничения обнаружились в коробочном Bitrix24 и почему часть задач пришлось решать не только через REST API, но и через отдельные серверные скрипты.

Репозиторий с кодом: https://github.com/vlikhobabin/kaiten-to-bitrix

Когда CRM в Битрикс24 начинает открывать список сделок по 10 секунд, обычно первым делом подозревают сервер, нагрузку или саму платформу. Но на практике узкое место часто лежит ближе к базе: фильтры по UF-полям без индексов, лишние JOIN, неявный LIKE в ORM, N+1-запросы и обработчики, которые внезапно превращают массовое обновление в нагрузочный тест.

В статье разбираем, как подойти к проблеме системно: включить slow query log, прочитать EXPLAIN, найти реальные причины тормозов и точечно ускорить CRM без миграции и бессмысленного наращивания железа.

В предыдущей статье (как отдавать лиды из Next.js в 1С Битрикс) я показывал outbound‑интеграцию: сайт пишет лид к себе в PostgreSQL, через after() отдаёт его в Битрикс, в строку лида подкладывает bitrix_id. Архитектура работает, пока Битрикс один.

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

Типовая задача на российском рынке: есть публичный сайт (лендинг, маркетплейс, каталог), на нём формы — заявка, регистрация, заявка партнёра. Эти лиды должны попадать в 1С Битрикс, где с ними работает отдел продаж.

Подход "в лоб" выглядит так: в обработчике формы сделать await fetch('https://bitrix.../crm.lead.add', ...) и вернуть пользователю ответ после того, как Битрикс подтвердил создание лида.

Это плохо работает. Битрикс REST API нестабилен по latency — 200 мс в норме, 8 секунд при нагрузке на стороне CRM. Пользователь сайта в это время смотрит на крутилку. Если Битрикс упал или таймаутит — сайт отдаёт ошибку, хотя пользователь форму заполнил корректно.

В этой статье — паттерн, который я использовал на маркетплейсе недвижимости на Next.js 16 + PostgreSQL 16 + 1С Битрикс. Без Redis, без BullMQ, без отдельного воркера. Просто Next.js API route + after() + минимальный HTTP-клиент с retry и таймаутом.

Цифры проекта для контекста: 25 объектов недвижимости в каталоге (отдельная сущность ready_homes оставлена за скобками статьи), 57 API-роутов, PostgreSQL 16.13 на VPS, деплой через systemd + nginx, интеграция с Битрикс — исключительно outbound (сайт → CRM).

Заходят как-то в бар Битрикс24 и Диадок — и быстро выясняется, что работать вместе им пока сложно. Битрикс24 отвечает за сделки и коммуникации, Диадок — за документы и статусы. А бизнесу нужна единая цепочка: документ появился в Диадоке — менеджер сразу видит его в CRM без переключений и ручных сверок.

Мы реализовали такую интеграцию с нуля. Настроили автоматическую передачу документов из Диадока в Битрикс24. Документы создают лиды, а статусы, файлы и история изменений отображаются в CRM.

Привет, Хабр! Расскажу, как мы спасли крупный новостной сайт ugra-news.ru от постоянных падений — без покупки нового железа и переписывания с нуля. Только точечные оптимизации, знание архитектуры Битрикс и немного детективной работы. Приступим.

Часто слышу в IT:

PHP устарел

Bitrix - монолит из 2000-х

На Bitrix невозможно писать нормальную архитектуру

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

За пару лет я сделал с десяток приложений для Маркетплейса Битрикс24 — коннекторы мессенджеров, роботы, iframe-панели. На PHP, TypeScript и Python. Каждый раз одно и то же: документация разбросана, примеры устарели, а реальные подводные камни вылезают только в продакшене.

Эта статья — сборник всего, что я хотел бы знать перед тем, как начать: формат токенов при установке, мультитенантность, обновление OAuth, петля сообщений в коннекторах и ещё десяток граблей с кодом и решениями.

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

Мы разобрали 6 популярных PFM-инструментов (Personal Finance Management), чтобы посмотреть, как именно — на уровне архитектуры и UX — они заставляют пользователя «резать косты» и брать бюджет под контроль.

Привет, Хабр!

В Битрикс24 есть два инструмента автоматизации, которые как будто делают одно и то же. Роботы — настраиваются в CRM на стадиях воронки, срабатывают при переходе сделки между этапами. Бизнес-процессы — настраиваются в визуальном дизайнере, поддерживают ветвления, циклы, переменные и многоэтапные согласования.

Ответ на то, что использовать — очевиден не всегда, потому что возможности частично пересекаются: и робот может отправить письмо, и бизнес-процесс тоже. Но граница между ними большущая.

Разберём, чем роботы и бизнес-процессы отличаются по механике, и на конкретных сценариях покажем, где какой инструмент уместен.

TL;DR

Мигрировал продакшн базу с Supabase на VPS PostgreSQL прямо на работающем проекте — без остановки, без потери данных. Заодно перенёс авторизацию через strangler-подход и убрал Supabase из SSR read-path. Расскажу три инженерных решения с кодом.

Продолжаем серию статей о нашем функциональном и удобном корпоративном портале.

Открытость — часть культуры Sminex. Своё мнение принято высказывать, устаревшие бизнес-процессы — совершенствовать и менять. Любой сотрудник может предложить идею, изменить устаревшие и неэффективные правила и технологии. И не только предложить, но и заработать, если идея соответствует определённым критериям и выгодна компании. Это отличная мотивация для команды. Для реализации на практике работает корпоративный сервис «Идеи». Раньше технической базы для него не было. Всё сводилось к отдельному почтовому ящику и группе сотрудников, координировавших процесс. Единого подхода к подаче идей тоже не было: предложения поступали в свободной форме, не всегда содержали нужную информацию и часто повторялись.

Привет! Миша Васильев на связи, разработчик в команде AI Битрикс24. 

Недавно я написал статью про MCP — протокол для стандартизации работы LLM с внешними инструментами. Там мы разобрали, как это всё устроено, какие возможности даёт и почему это круто.

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

В этой статье я собрал семь основных проблем, с которыми мы столкнулись при разработке MCP-серверов, и объясню, как их избежать (или хотя бы постараться это сделать).

Еще пару лет назад веб жил в простой и понятной модели: есть сайты, есть поисковые роботы, есть пользователи. Роботы приходят, сканируют страницы, кладут их в индекс — дальше начинается привычная борьба за позиции в выдаче. Эта логика десятилетиями определяла, как мы строим сайты, настраиваем SEO и пишем robots.txt.

С появлением LLM-агентов эта модель начала трещать по швам.

В коробочной версии Bitrix24 функция «Авторизоваться под пользователем» является штатной и удобной для администрирования.
Однако в корпоративной среде с требованиями ИБ и compliance она порождает интересную инженерную задачу: где проходит граница прикладной безопасности?

Разбираем архитектуру impersonation, ограничения триггеров БД и попытку реализовать компенсирующие меры на прикладном уровне.