Интеграция для Bitrix — это не «ещё один скрипт обмена», а отдельная подсистема. Если на старте просто «прикрутить выгрузку из 1С», через год получаем дубликаты, битые заказы и вечный хаос в логах. Расскажу, как я подхожу к обмену, чтобы он оставался управляемым.
Сначала — что и зачем гоняем
Перед тем как писать хоть строку кода, я фиксирую в одном небольшом документе:
какие сущности участвуют (товары, цены, остатки, заказы, клиенты), кто источник правды по каждой сущности (1С, CRM или сам Bitrix), в какую сторону идут данные и как часто это должно работать. Частая ошибка — пытаться сделать двустороннюю синхронизацию там, где достаточно понятной схемы «мастер → ведомый». Чем меньше «мастеров», тем проще жить.
Формат данных и точка входа
Я стараюсь не раздувать формат: либо JSON по REST/HTTP, либо штатный CommerceML, если так проще с 1С. Важно, чтобы на стороне Bitrix была одна-две понятные точки входа: отдельный модуль или controller, который принимает запрос, валидирует его и складывает данные в очередь или в промежуточную таблицу.
Прямое создание/обновление заказа или товара из контроллера без промежуточного слоя — путь к тому, что любой глюк в сети превращается в дубликаты и полусохраняемые сущности. Лучше сначала зафиксировать «событие обмена», а потом спокойно дообработать его агентом или скриптом по cron’у.
Идентификаторы и соответствия
Самая большая боль интеграций — идентификаторы. Я сразу договариваюсь, что в Bitrix хранится внешний ключ: например, в пользовательских полях элемента инфоблока, заказа или пользователя лежит UF_1C_ID, UF_CRM_ID или любое другое поле для внешней системы.
Все операции строю вокруг этих айдишников: если прилетел объект с таким внешним ID — обновляем, если нет — создаём. Никакого «по названию» или «по артикулу, если повезёт». Это отдельно облегчает повторную обработку и защищает от дублей.
Повторы и очереди
Сеть падает, 1С тормозит, CRM может факапить ответы — это нормальная жизнь. Поэтому обмен должен быть идемпотентным: один и тот же пакет данных можно применить дважды без вреда. Для этого я или ввожу уникальный идентификатор операции (transaction ID) и храню его у себя, или просто всегда опираюсь на внешний ID сущности и делаю операции «upsert».
Тяжёлые вещи стараюсь прогонять через очередь: записали пакет в свою таблицу, дальше агент/cron берёт по чуть-чуть и обрабатывает. Так нельзя одним запросом повесить весь сайт.
Логи и разбор полётов
Любая интеграция должна уметь честно сказать, что и когда пошло не так. Я завожу отдельную таблицу логов обмена или хотя бы аккуратный журнал в /bitrix/logs, где фиксирую дату, тип операции, ключевые параметры и статус. В идеале — минимально обрезанный запрос/ответ.
Это не для того, чтобы «смотреть красивые логи», а чтобы в момент «1С говорит, что всё выгрузила, а на сайте пусто» можно было за пять минут понять, кто врёт: 1С, сеть или наш код.
Ошибки и бизнес-реакция
Важно заранее договориться с бизнесом, что считаем критичной ошибкой, а что можно пережить до следующего запуска. Например, если не удалось обновить характеристики товара, но цены и остатки приехали — сайт жить может. А вот если не создаются заказы или платежи — это авария.
В коде я разделяю эти уровни: мягкие ошибки просто логирую и перевожу записи в статус «нужно пересмотреть», жёсткие — поднимают алёрт (письмо, сообщение в чат) и останавливают дальнейшую обработку до разбора.
Безопасность и доступ
Так как интеграция обычно торчит наружу, я не оставляю эндпоинты без защиты. Минимум — токен доступа в заголовке или параметре, проверка IP, ограничение по частоте запросов. Если речь про админские операции (создание заказов, изменение цен), не ленюсь прокладывать дополнительный уровень защиты, чтобы через один «битый» токен нельзя было сломать всё.
Итог
Нормальный обмен Bitrix с 1С, CRM и внешними сервисами — это не один магический скрипт, а несколько простых вещей: чёткое понимание, кто за что отвечает, единые внешние ID, идемпотентность операций, очередь вместо «всё сразу», внятные логи и минимальная безопасность. Когда это заложено с самого начала, интеграция перестаёт быть чёрным ящиком и становится обычной частью системы, которую не страшно развивать.
#bitrix #1c #интеграция #php