1С-Битрикс *

Большой каталог сам по себе еще не делает интеграцию сложной. В нашем проекте интеграции сайта с 1С сейчас 211 761 позиция номенклатуры. Передать такой объем можно, вопрос скорее в том, сколько ресурсов и времени на это потребуется. Проблемы начинаются позже: когда данные нужно не просто выгрузить, а отобрать, обработать, регулярно обновлять и доставить в другую систему.

Проект работает на связке 1С:Управление торговлей + интернет-магазин на Bitrix. Источником основных данных остается 1С: там находятся номенклатура, склады, цены и остатки, а сайт в основном работает как витрина. В обратную сторону с сайта в 1С приходят заказы.

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

Мы не стали переписывать интеграцию целиком. Архитектура менялась постепенно, по мере того как в production проявлялось очередное ограничение. Сначала оказалось, что тяжелая полная выгрузка конкурирует с оперативными изменениями.

 Когда их развели по времени, уперлись в скорость обработки на стороне сайта. Когда начали разделять большой обмен на отдельные потоки, нашли bottleneck уже внутри 1С. Позже появились новые потребители данных, 1С:Шина и новый вопрос — как контролировать доставку при асинхронной передаче.

Ниже — этот путь в том порядке, в котором мы его проходили с командой ASAP.

«Это ТСПУ РКН, поделать ничего нельзя» — а проблема три месяца ждала в консоли сервера

Время расследования · 2 дня Причин найдено · 3 Команд для победы · 1

Клиент — онлайн-СМИ застройщика федерального уровня, несколько десятков публикаций в день, своя редакция. С июня сайт периодически становился недоступен. Подрядчик, который ведёт техподдержку, прислал такое сообщение:

Работа с файлами в REST API Битрикс24 — та задача, где документация заканчивается ровно там, где начинаются проблемы. Официальные примеры показывают, как загрузить один файл в одно поле. А дальше выясняется, что у crm.item.update и crm.deal.update разные несовместимые форматы, что вложенный base64 через http_build_query уходит в никуда, а сервер при этом честно отвечает «result».

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

Собрал всё в один разбор — шесть подходов с кодом и восемь граблей:

два формата файлового значения, которые нельзя смешивать, и почему при смешении затираются уже прикреплённые файлы;

тихий провал: HTTP 200, в ответе result, поле не обновилось;

useOriginalUfNames=Y, без которого UF_CRM_* молча игнорируются;

downloadUrl приходит с пустым auth= и без подстановки токена не скачивается, а при протухшем токене вместо файла отдаётся HTML-страница с кодом 200;

у одного изображения бывает несколько URL, и часть из них не работает — пришлось делать скоринг вариантов по эвристике.

В конце — таблица «что брать под какую задачу» и чеклист граблей. Двадцать блоков кода, всё из боевых проектов.

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

Меня зовут Михаил Емельянов, я ведущий разработчик в НЛМК ИТ. Команда, в которой я состою, занимается разработкой и поддержкой различных корпоративных информационных систем на базе Битрикс24.

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

- Юридические нюансы: обработка персональных данных по требованиям 152‑ФЗ и внутренних политик безопасности. Стороннему сервису не всегда можно передать всё, что нужно, а иногда это прямо запрещено.

- Стоимость: даже одно недельное мероприятие обходилось достаточно дорого.

- Процессные ограничения: неудобно быстро менять расписание «на лету» во время мероприятия, неидеальная логика резервирования времени приводила к редким, но болезненным коллизиям.

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

Некоторое время назад я писал здесь про антиспам для WordPress — историю о том, как из недоступного клиентам Cloudflare и дырявых бесплатных решений родился свой плагин геоблокировки, а чуть позже — вторую часть с разбором критики и рассказом, что успело поменяться. В конце самой первой статьи была одна проходная фраза: «параллельно ведется разработка аналогичного решения для 1С Битрикс — задача там несколько сложнее архитектурно, но подход тот же». С тех пор модуль доехал до Маркетплейса, обзавелся парой обновлений и первыми покупателями. Расскажу, что получилось — и почему для Битрикса такая защита понадобилась даже раньше, чем для WordPress.

Воронка продаж или любая другая воронка (производства, закупок, HR) в любой CRM всегда начинается с бизнес-аналитики, т.е. надо понять процессы в бизнесе клиента и под них настроить IT инфраструктуру, а не наоборот.

Тыкать пальцами кнопки в Битрикс24 много ума не надо, а вот сделать правильно, именно так как надо клиенту - это и есть специальность интегратора CRM.

Воронка продаж это всегда определение:

Один хакер полтора часа исследовал поддельный Bitrix-сервер: нашёл конфигурацию, извлёк ложные учётные данные базы, попытался выгрузить таблицы и записать PHP-файл.

Другой клиент отправил в открытый Ollama-compatible API 27 тысяч реальных задач. Самый большой промпт содержал 919 тысяч символов. Модели за API при этом не было.

Я три месяца наблюдал за двумя среднеинтерактивными ханипотами — традиционным SCADA/Bitrix-стендом и поддельным AI gateway. В статье разбираю 2,5 млн событий Cowrie, стотысячный MySQL password spray, 183 сохранённых payload, массовую эксплуатацию AI API и MCP-разведку.

Привет, технари, я на Хабре недавно, решил делиться своей экспертизой и общаться с единомышленниками, чтобы иметь окружение схожих себе и обмениваться опытом. Сам своими руками сделал более 70 интеграций Битрикс24 и AmoCRM за 3 года, есть что выложить из опыта.

Отделам продаж постоянно нужны отчеты: конверсии, звонки и так далее, но особо развитым кампаниям надо отчеты уже кастомные, не шаблон. Если брать шаблонные отчеты в Битрикс24, то там кусок фронта достаточно шаблонный, что и обычно для CRM которая «для всех», это же не самописка. Там есть Конструктор отчетов, но там тоже очень много ограничений.

А если РОП или директор по продажам хочет кастомный отчет? В Rest API лезть?

При большом желании можно и в API лезть, но в Битрикс24 есть промежуточный вариант, полушаблон, полукод (кастом) — BI конструктор.

[В статье немеряно скриншотов — прим. НЛО]

Безопасность — неотъемлемая часть конвейера разработки, который работает под высокой нагрузкой и круглые сутки должен быть в состоянии обслуживать много пользователей. 

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

REST Битрикс24 можно удобно использовать из Python — для интеграций, миграций, аналитики и служебных скриптов. 

Разбираем библиотеку a24wh: шесть функций, которые упрощают запросы, пагинацию, batch-вызовы и обработку ошибок.

Четверть века индустрия учётных систем строила экранные формы. Журналы документов, обработки, консоли отчётов, подборы, помощники — всё это считалось главной ценностью продукта: за удобные формы платили, за неудобные ругали внедренцев. Последние полтора года я смотрю, как ИИ-агенты работают с нашей 1С напрямую, без единой открытой формы, — и вижу, что у экранного интерфейса учётных систем осталось немного времени. А следом встаёт вопрос и о самой учётной системе как посреднике между бизнесом и его данными.

Это первая статья цикла: манифест с прогнозом. Во второй будет экономика вопроса и что она сделает с b2b-компаниями, в третьей — подробный кейс, как мы к этому шли.

Кто я и почему об этом пишу Я CTO в b2b-компании: дистрибуция с внешнеэкономической деятельностью, 1С:УТ и 1С:Бухгалтерия, Битрикс24, десятки человек в бэкофисе, десятки тысяч номенклатур, около 28 тысяч контрагентов в справочнике. Мы внедряем мультиагентную систему с виртуальными сотрудниками — сейчас идёт третий этап. За предыдущие полгода на полностью ИИ-автоматизированном пайплайне разработки для 1С выполнено больше тысячи доработок и внедрений 1С + Битрикс24: архитектура учётного контура подготовлена под агентов, и мы перешли к пилотам. Первый виртуальный сотрудник — финансовый аналитик — уже отвечает руководству в чате цифрами из боевой базы.

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

Что такое учётная система, если убрать вежливость Разберём 1С (или любую ERP — SAP и Dynamics устроены так же) на слои:

Недавно мне потребовалось перенести корпоративный портал Bitrix24 на новую BitrixVM.

По документации всё выглядело достаточно просто:

Уже более 10 лет мы сопровождаем Единый официальный сайт органов власти Ханты-Мансийского автономного округа — Югры (admhmao.ru, далее – сайт), в структуру которого входят ещё 36 сайтов органов власти округа. За это время требования к доступности государственных сайтов несколько раз менялись.

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

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

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

За полгода написал ряд интеграций с Битрикс24 в разных архитектурах: приложение для Маркета (PHP, 6 порталов), клиентский расчётный сервис (Node.js + PostgreSQL) и cron-синхронизатор legacy-CRM без UI и без OAuth вообще. Мультитенант везде решён по-разному, и это не случайность, ведь каждая архитектура точно закрывает свою нишу.

Внутри: сравнение трёх способов хранить OAuth-токены под 6+ порталов, разбор пяти неочевидных деталей REST API (oauth.bitrix24.tech-обход, POST vs GET на рефреше, rate limit 2 req/sec, batch на 50, буфер 5 мин), куски кода на PHP и TypeScript.

Отдельная часть — лицензирование через материнский смарт-процесс. У продукта, распределённого по клиентским порталам, нет своего backend’а, поэтому control-plane я вынес на служебный портал агентства: смарт-процесс «Лицензии», бизнес-процесс на изменение счётчика запросов, webhook approve/decline с secret. Такого паттерна в документации Битрикс24 нет — а он работает уже несколько месяцев и не требует ничего сверх штатной функциональности платформы.

Матрица «что выбирать под задачу» в конце.

Понадобилось дать ИИ-ассистентам (Claude Code, Cursor) доступ к данным своего сервиса — мониторы, события, аптайм, — чтобы вопрос «что сейчас в сбое?» можно было задать прямо в чате, а не идти кликать по вкладкам дашборда. Стандартный путь для этого — MCP (Model Context Protocol): сервер декларирует инструменты, и любой MCP-клиент их находит и вызывает.

Официальные примеры и SDK предлагают поднимать отдельный MCP-сервис — с транспортной машинерией, сессиями и SSE-стримингом. Я сделал иначе: один HTTP-хендлер внутри существующего Go-монолита, около 200 строк, без единой новой зависимости. Вечер работы, включая тесты curl-ом.

В статье разбираю: какой минимум JSON-RPC-методов реально требует спека для tools-only сервера (initialize, tools/list, tools/call — и почти всё), почему stateless-режим без Mcp-Session-Id легален по спецификации и что он даёт бесплатно, зачем хранить id запроса как json.RawMessage, как описывать инструменты, чтобы LLM вызывала их правильно, и какие грабли ждут при подключении Claude Code и Cursor. Весь код — из работающего продакшена, сокращён до сути.

Делимся опытом автоматизации реферальной программы: как мы ушли от хаотичного сбора рекомендаций на вакансии и запустили собственный продукт для корпоративного портала — цифровой сервис «Рекомендовать кандидата». В результате увеличили конверсию закрытия вакансий по внутренним рекомендациям до 35%.

Стандартный обмен данными в 1С-Битрикс часто превращается в ночной кошмар: полная выгрузка остатков на больших каталогах может занимать от 1 до 8 часов. Когда бизнес требует обновлять данные каждые 15 минут, штатные методы API и XML-импорт просто перестают справляться.

В этой статье я покажу, как с помощью прямого SQL запроса и временных таблиц в памяти (ENGINE=MEMORY) ускорить импорт в сотни раз. Это реальный кейс с продакшена, который стабильно работает уже 4 года на проекте с миллионом товаров и десятками складов.

Привет, Хабр! Меня зовут Леонид, я ведущий PHP-разработчик в НЛМК ИТ.Наша команда отвечает за сервисы HR-направления на едином корпоративном портале (далее – ЕКП), а также занимается развитием и поддержкой корпоративных сайтов.

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

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

Под катом делюсь обзором своего самописного PHP-фреймворка Gy — попытки сделать легковесного «убийцу» Битрикса весом 350 Кб. Расскажу, как я реализовал вызов компонентов, зачем написал кастомный SQL-движок на текстовых файлах PhpFileSql.

Костыли, велосипеды, 3 года разработки по выходным, 315 коммитов, 14232 строки кода, поддержка практически всех версий PHP и ровно 0 пользователей.