Всем привет! Меня зовут Артем, я старший разработчик в ИНТЕРВОЛГЕ. Наконец дошли руки рассказать про «обмен с 1С с нуля».
Типовой интернет-магазин состоит из двух частей: сайт и учетная система. Редко когда это цельный софт.
В статье речь пойдет о написании с нуля обмена сайта и 1С.
Напомню, что типовым обменом называют готовый функционал для передачи данных между учетной системой и сайтом. Битрикс и 1С имеют готовую интеграцию в модуле Интернет-магазин, вся настройка может быть произведена без участия программиста. Модуль позволяет производить обмен большинством типовых сущностей (склады, товары, цены, остатки, заказы, пользователи, справочники). Это решение подходит для 99% сайтов, которым нужна выгрузка и синхронизация данных между 1С и сайтом.
Когда же может понадобиться нетиповой обмен?
Если есть готовое решение, которое работает и покрывает большинство потребностей, что может пойти не так?
Варианты:
Не устраивает скорость обновления данных и реакция. Речь именно о том, что обмен справляется за разумное время, но заказчику хочется быстрее.
Часто ждут пресловутый «реалтайм».Бизнес-логика настолько специфична, что типовой обмен не вписывается. Например, когда «каждый физический экземпляр товара это уникальный артикул», или «все позиции у нас заказные, ничего типового не продаем» или «цена зависит от объема отгрузок в прошлом месяце».
Типовой обмен не справляется в часы пиковой нагрузки. Черная пятница, вечер 14 февраля могут стать причиной головной боли программистов и операторов.
Особый софт. Не для всех 1С из коробки есть готовый модуль интеграции.
Иногдачасто дело в том что 1С очень старая, и очень доработанная.
Решать первые 2 пункта переписыванием обмена — плохая идея. Нужно смотреть на конкретные вводные и решать, почему так вышло, и что можно исправить в бизнес-логике, а не в обмене.
Пункты 3 и 4 – более весомые аргументы в пользу написания обмена с нуля, тут даже доработкой типового обмена не всегда получается обойтись. Поэтому это явные триггеры, что вам стоит задуматься о самописном обмене, либо использовать готовые нетиповые решения.
Разберем конкретный пример.
Наш пример самописной интеграции
Для кого все писалось: международная компания Levenhuk, производитель оптического оборудования с собственной сетью продаж в 14 странах.
Как следствие – много языков, много версий, оптовые и розничные сайты. А в сердце всего этого старая, но бодрая и полезная 1С (когда-нибудь мы расскажем о проекте перехода на свежую версию).
![схема самописной интеграции 1С схема самописной интеграции 1С](https://habrastorage.org/getpro/habr/upload_files/1f5/704/65e/1f570465e76c4a7940419edccc94fd24.png)
На старте были старые самописные, мультиязычные сайты (b2c) и 1С. Развивать и поддерживать самописные сайты было некому. Были нужны новые языковые версии, новые фичи и еще куча всего. Было решено сделать новые сайты на Битрикс – проверенная платформа с кучей подрядчиков в России, где работает бэк-офис компании.
У старых сайтов была самописная интеграция между 1С и админкой на Django (postgre в качестве контентной БД). В этой админке заполнялись характеристики товаров, картинки, описания на всех доступных языках и прочий контент для отображения на сайтах.
Старая 1С, написанная практически с нуля, не поддерживает обмен, да еще и уникальна настолько, что потребовались недели для изучения всех механизмов и подводных камней.
После исследования 1С было предложено 2 варианта:
Обмен в формате CommerceML (xml), фактически повторение стандартных технологий обмена.
Обмен с использованием веб-сервисов (REST API).
Первый вариант подразумевал доработки на стороне 1С и минимум доработок на стороне сайта. Но он оказался настолько болезненным для 1С, что от него отказались. Тестирование функционала модуля обмена показало, что требуется исправление множества ошибок. Причина — отсутствие необходимых объектов конфигурации.
Пришли к выводу, что для текущей конфигурации целесообразно разработать модуль обмена, а не адаптировать типовой модуль для УТ. Обмен решили делать с использованием REST API, так как мы сами сможем подобрать удобный, понятный и простой формат данных.
Кроме того, стратегически нам казалось (и практика это подтвердила), что REST-обмен будет проще в развитии и будет более готов к нагрузкам.
В нашем случае сайт выступает в роли сервера, принимающего запросы, а 1С в качестве клиента, забирающего или отправляющего какие либо данные.
Что значит сделать обмен с нуля
Новые языковые сайты на БУС b2b.
Обновленные языковые сайты на БУС b2c (замена старым).
Интеграцию 1С и всех сайтов.
Перетащить все переводы и данные по товарам из postgre в БД новых сайтов.
Устройство REST-обмена
Сам обмен потребовал реализации передачи в двух направлениях довольно большого набора данных со связями между ними.
![пример Rest обмена пример Rest обмена](https://habrastorage.org/getpro/habr/upload_files/756/37d/b92/75637db921aeb53f5953165af755aea3.jpeg)
Упрощенно можно сказать что разработка обмена с нуля требует:
разработки на уровне API почти-CRUD-методов для каждой сущности (в реальности не все методы нужны, например почти не используется Read, Update и Create сливаются в один, и крайне редко применяется удаление, чаще деактивация через Update);
реализация многих видов обмена (полного, изменениями, реалтайм, обогащающего) с применением этого API.
Работа эта лишь на первый взгляд проста. Всего было реализовано несколько десятков REST-методов на стороне сайта и 9 больших процедур на стороне 1С:
ВыгрузкаСпискаСкладов;
ВыгрузкаСпискаТиповЦен;
ВыгрузкаСтруктурыКаталогаТоваров;
ВыгрузкаКаталогаТоваров (этот метод используется для частичной, и для полной выгрузки)
ВыгрузкаКонтрагентов;
ВыгрузкаВзаиморасчетов;
ЗагрузкаДанныхДополнительныхСправочников;
ВыгрузкаЗаказовИз1СНаСайт;
ЗагрузкаЗаказовССайтаВ1С.
Все эти методы вызывают API на стороне сайта. Сама логика обмена такая же как в стандартном модуле – инициатива на стороне учетной системы. Технически ничего не мешает поднять веб-сервис в 1С, но практически это нужно относительно редко, и по соображениям безопасности так стараются не делать.
Отдельные хитрые задачи (кстати, хорошо решенные в стандартном модуле) – Настройка дерева групп для сопоставления в двух системах и Синхронизация справочников между системами.
Потребовалось создание регламентных процедур, объектов данных, логов, мониторингов и прочего «обвеса».
Структура систем и потоки данных
У каждого сайта свой каталог товаров, свои способы доставок и оплат, свои интеграционные фиды, свои api для сторонних клиентов.
В итоге мы сделали 2 сайта (b2b и b2c), а каждая новая языковая версия это отдельный «фронт-сайт».
Каждый языковой сайт работает с своим каталогом. Т.е. сколько языковых версий сайта столько и каталогов.
![интеграционная схема 1с и двух сайтов интеграционная схема 1с и двух сайтов](https://habrastorage.org/getpro/habr/upload_files/07d/8bc/7f7/07d8bc7f794b7c08c120db1acd3d03f0.jpeg)
Данные, которыми мы обмениваемся это:
Структура разделов каталогов (под каждый сайт своя).
Типы цен.
Товары.
Пользователи.
Склады.
Заказы.
Наиболее интересным выглядят обмен товарами и ценами. На стороне 1С были реализованы следующие импорты:
Полный импорт с ценам и остатками (импортируются все товары из 1С).
Полный импорт без цен с остатками (собрать цены в 1С достаточно длительный процесс, т.к. только к нам на сайт импортируется 66 типов цен, поэтому импорт цен сделали опциональным).
Импорт товаров по изменениям (без цен/с ценами). Выгружаются только товары у которых изменились данные в 1С.
Импорт только измененных цен.
Как все начиналось
Написать импорт пользователей, заказов, структуры каталогов было довольно просто. Нам присылают json в оговоренном формате, мы добавляем или обновляем данные.
Первые трудности начались с товарами.
В первом варианте импорта товаров из 1С весь процесс создания и обновления данных о товаре происходил прямо на хите обращения 1С к сайту. 1С присылала данные по товару сразу для всех сайтов, поэтому нужно было сохранить и обновить эти данные для всех языковых каталогов.
![интеграция 1с через rest-обмен интеграция 1с через rest-обмен](https://habrastorage.org/getpro/habr/upload_files/4af/445/fc9/4af445fc9344202324a40b47e971adce.png)
По мере увеличения количества сайтов, время затрачиваемое на сохранение товаров/остатков/цен стало расти и это нас не устраивало.
Кроме того, была хитрая логика по группировке товаров в карточке, а следовательно нужно было на том же хите вычислить какие sku необходимо сгруппировать в 1 товар. Помимо этого для наполнения товаров нужно было подтянуть из контентной базы данных картинки, характеристики, описания. Обновление описаний и характеристик происходило на кроне и выглядело мягко говоря не очень оптимизировано и красиво. Первый вариант реализации обновления брал пачку товаров и обновлял, вне зависимости от того изменились данные в контентной БД или нет.
Немного усовершенствуем наш обмен
Если вы столкнулись с проблемой обработки больших объемов данных и этот процесс можно распараллелить, то вам могут в этом помочь брокеры сообщений. Если вы еще с ними не знакомы, то их можно грубо описать так: это программа, которая умеет принимать какие либо сообщения, сохранять в указанную очередь эти самые сообщения и отдавать или рассылать эти сообщения.
Какой из брокеров использовать зависит от типа и целей задачи. В нашем случае выбрали ActiveMQ, хотя у нас был опыт работы и с RabbitMQ, и c Gearman. Выбор был довольно произвольный, честно скажу.
Что поменялось:
Теперь, когда 1С присылает нам данные по товарам, мы записываем json с данными о товарах, который пришел, в ActiveMQ и говорим 1С, что “все ок, мы позже это обработаем”. Каждая запись в ActiveMQ это пачка товаров только для 1 каталога.
Также, мы на этапе передачи данных серверу очередей можем проверить, входит ли конкретный товар в языковой каталог, если нет, то он исключается из пачки.
![обмен через ActiveMQ обмен через ActiveMQ](https://habrastorage.org/getpro/habr/upload_files/53e/175/70d/53e17570de4e93b432f4f4ec04ba3260.png)
Итоговая схема обновления данных получилась такая:
![схема обновления данных с 1С схема обновления данных с 1С](https://habrastorage.org/getpro/habr/upload_files/9aa/163/0bb/9aa1630bbfb83cfe7386bc7c68ca11ce.jpeg)
Воркер товаров. Создает/обновляет базовую информацию о товаре, а также сохраняет остатки.
Воркер цен сохраняет только цены.
В результате после обработки rest данных мы получаем некрасивый товар (есть остатки, цены, название но нет описания, картинок, названия на нужном языке)
Каждый rest воркер сообщает продюсеру sku, о том, что из 1С пришли какие то изменения на товар х. Продюсер добавляет это sku в очередь на обновление данных о sku.
Воркер обновления данных sku. Задача этого воркера наполнить sku, свойствами (для умного фильтра), найти на нужном языке название sku. Данные о свойствах и названиях хранятся в контентной БД.
После обновления мы получаем sku с картинами и свойствами, для которого осталось создать товар. Каждое sku передается двум продюсерам, продюсер обычных товаров и продюсер цветных/языковых товаров.
Создание товаров
В бизнес-логике клиента есть 2 типа товаров:
Простой товар, 1 sku к 1 товару.
Цветной/языковой или цветной и языковой одновременно, несколько sku к 1 товару.
Воркеры, которые создают товары, называются mapper’ы (потому что склеивают sku в товар).
Простой воркер: Получает на вход пачку (обычно 100) sku. И под каждое sku создает товар и привязывает sku к товару. Так же находит общую картинку (обычно это та же самая, что и у sku), детальное описание, символьный код для url, файлы привязанные к товару, обзоры и прочее.
Цветной/языковой воркер: продюсер для цветных/языковых товаров находит сгруппированные по языкам или по цветам sku и отправляет воркеру пачку sku, которые должны быть привязаны к 1 товару. Там проходят те же манипуляции, что и с обычным товаром.
Числа и трудозатраты
Размеры каталогов теоретически небольшие ~3000 sku.
Но каждый язык хранится как отдельный товар.
На текущий момент запущено 7 языковых версий. Соответственно нам нужно обновить ~21000 товаров. Благодаря возможности регулировать количество воркеров полный импорт для всех каталогов занимает не более 30 минут.
На реализацию первого варианта обмена у нас ушло ~200 ч на стороне сайта и ~100ч на стороне 1С.
Рефакторинг и перевод импорта на сервер очередей занял порядка 150 ч.
Вывод
Если вы можете обойтись без разработки обмена с нуля – обойдитесь. Не стоит увлекаться велосипедами.
Но если проект требует – смело делайте. Не бойтесь уйти от XML-формата и разработать в сумме под 50 методов обмена. Светлая голова и прямые руки позволят вам получить хорошо работающий результат.
Общая трудоемкость в 500 часов не столь страшна, а перевод на очереди и подготовка к высоким нагрузкам будут проще чем в случае стандартного обмена.