Всем привет! Меня зовут Артем, я старший разработчик в ИНТЕРВОЛГЕ. Наконец дошли руки рассказать про «обмен с 1С с нуля». 

Типовой интернет-магазин состоит из двух частей: сайт и учетная система. Редко когда это цельный софт. 

В статье речь пойдет о написании с нуля обмена сайта и 1С. 

Напомню, что типовым обменом называют готовый функционал для передачи данных между учетной системой и сайтом. Битрикс и 1С имеют готовую интеграцию в модуле Интернет-магазин, вся настройка может быть произведена без участия программиста. Модуль позволяет производить обмен большинством типовых сущностей  (склады, товары, цены, остатки, заказы, пользователи, справочники). Это решение подходит для 99% сайтов, которым нужна выгрузка и синхронизация данных между 1С и сайтом. 

Когда же может понадобиться нетиповой обмен? 

Если есть готовое решение, которое работает и покрывает большинство потребностей, что может пойти не так?

Варианты:

1. Не устраивает скорость обновления данных и реакция. Речь именно о том, что обмен справляется за разумное время, но заказчику хочется быстрее.
   Часто ждут пресловутый «реалтайм».

2. Бизнес-логика настолько специфична, что типовой обмен не вписывается. Например, когда «каждый физический экземпляр товара это уникальный артикул», или «все позиции у нас заказные, ничего типового не продаем» или «цена зависит от объема отгрузок в прошлом месяце».

3. Типовой обмен не справляется в часы пиковой нагрузки. Черная пятница, вечер 14 февраля могут стать причиной головной боли программистов и операторов.

4. Особый софт. Не для всех 1С из коробки есть готовый модуль интеграции. Иногда часто дело в том что 1С очень старая, и очень доработанная.

Решать первые 2 пункта переписыванием обмена — плохая идея. Нужно смотреть на конкретные вводные и решать, почему так вышло, и что можно исправить в бизнес-логике, а не в обмене.

Пункты 3 и 4 – более весомые аргументы в пользу написания обмена с нуля, тут даже доработкой типового обмена не всегда получается обойтись. Поэтому это явные триггеры, что вам стоит задуматься о самописном обмене, либо использовать готовые нетиповые решения.

Разберем конкретный пример.

Наш пример самописной интеграции 

Для кого все писалось: международная компания Levenhuk, производитель оптического оборудования с собственной сетью продаж в 14 странах.

Как следствие – много языков, много версий, оптовые и розничные сайты. А в сердце всего этого старая, но бодрая и полезная 1С (когда-нибудь мы расскажем о проекте перехода на свежую версию).

На старте были старые самописные, мультиязычные сайты (b2c) и 1С. Развивать и поддерживать самописные сайты было некому. Были нужны новые языковые версии, новые фичи и еще куча всего. Было решено сделать новые сайты на Битрикс – проверенная платформа с кучей подрядчиков в России, где работает бэк-офис компании.

У старых сайтов была самописная интеграция между 1С и админкой на Django (postgre в качестве контентной БД). В этой админке заполнялись характеристики товаров, картинки, описания на всех доступных языках и прочий контент для отображения на сайтах.

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

После исследования 1С было предложено 2 варианта: 

1. Обмен в формате CommerceML (xml), фактически повторение стандартных технологий обмена.

2. Обмен с использованием веб-сервисов (REST API).

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

Пришли к выводу, что для текущей конфигурации целесообразно разработать  модуль обмена, а не адаптировать типовой модуль для УТ. Обмен решили делать с использованием REST API, так как мы сами сможем подобрать удобный, понятный и простой формат данных.

Кроме того, стратегически нам казалось (и практика это подтвердила), что REST-обмен будет проще в развитии и будет более готов к нагрузкам.

В нашем случае сайт выступает в роли сервера, принимающего запросы, а 1С в качестве клиента, забирающего или отправляющего какие либо данные.

Что значит сделать обмен с нуля

Новые языковые сайты на БУС b2b. 

Обновленные языковые сайты на БУС b2c (замена старым).

Интеграцию 1С и всех сайтов.

Перетащить все переводы и данные по товарам из postgre в БД новых сайтов.

Устройство REST-обмена

Сам обмен потребовал реализации передачи в двух направлениях довольно большого набора данных со связями между ними.

Упрощенно можно сказать что разработка обмена с нуля требует:

• разработки на уровне API почти-CRUD-методов для каждой сущности (в реальности не все методы нужны, например почти не используется Read, Update и Create сливаются в один, и крайне редко применяется удаление, чаще деактивация через Update);

• реализация многих видов обмена (полного, изменениями, реалтайм, обогащающего) с применением этого API.

Работа эта лишь на первый взгляд проста. Всего было реализовано несколько десятков REST-методов на стороне сайта и 9 больших процедур на стороне 1С:

• ВыгрузкаСпискаСкладов;

• ВыгрузкаСпискаТиповЦен;

• ВыгрузкаСтруктурыКаталогаТоваров;

• ВыгрузкаКаталогаТоваров (этот метод используется для частичной, и для полной выгрузки)

• ВыгрузкаКонтрагентов;

• ВыгрузкаВзаиморасчетов;

• ЗагрузкаДанныхДополнительныхСправочников;

• ВыгрузкаЗаказовИз1СНаСайт;

• ЗагрузкаЗаказовССайтаВ1С.

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

Отдельные хитрые задачи (кстати, хорошо решенные в стандартном модуле) – Настройка дерева групп для сопоставления в двух системах и Синхронизация справочников между системами.

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

Структура систем и потоки данных

У каждого сайта свой каталог товаров, свои способы доставок и оплат, свои интеграционные фиды, свои api для сторонних клиентов.

В итоге мы сделали 2 сайта (b2b и b2c), а каждая новая языковая версия это отдельный «фронт-сайт».

Каждый языковой сайт работает с своим каталогом. Т.е. сколько языковых версий сайта столько и каталогов.

Данные, которыми мы обмениваемся это:

• Структура разделов каталогов (под каждый сайт своя).

• Типы цен.

• Товары.

• Пользователи.

• Склады.

• Заказы.

Наиболее интересным выглядят обмен товарами и ценами. На стороне 1С были реализованы следующие импорты:

• Полный импорт с ценам и остатками (импортируются все товары из 1С).

• Полный импорт без цен с остатками (собрать цены в 1С достаточно длительный процесс, т.к. только к нам на сайт импортируется 66 типов цен, поэтому импорт цен сделали опциональным). 

• Импорт товаров по изменениям (без цен/с ценами). Выгружаются только товары у которых изменились данные в 1С. 

• Импорт только измененных цен.

Как все начиналось

Написать импорт пользователей, заказов, структуры каталогов было довольно просто. Нам присылают json в оговоренном формате, мы добавляем или обновляем данные.

Первые трудности начались с товарами.

В первом варианте импорта товаров из 1С весь процесс создания и обновления данных о товаре происходил прямо на хите обращения 1С к сайту. 1С присылала данные по товару сразу для всех сайтов, поэтому нужно было сохранить и обновить эти данные для всех языковых каталогов.

По мере увеличения количества сайтов, время затрачиваемое на сохранение товаров/остатков/цен стало расти и это нас не устраивало. 

Кроме того, была хитрая логика по группировке товаров в карточке, а следовательно нужно было на том же хите вычислить какие sku необходимо сгруппировать в 1 товар. Помимо этого для наполнения товаров нужно было подтянуть из контентной базы данных картинки, характеристики, описания. Обновление описаний и характеристик происходило на кроне и выглядело мягко говоря не очень оптимизировано и красиво. Первый вариант реализации обновления брал пачку товаров и обновлял, вне зависимости от того изменились данные в контентной БД или нет.

Немного усовершенствуем наш обмен

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

Какой из брокеров использовать зависит от типа и целей задачи. В нашем случае выбрали ActiveMQ, хотя у нас был опыт работы и с RabbitMQ, и c Gearman. Выбор был довольно произвольный, честно скажу.

Что поменялось:

Теперь, когда 1С присылает нам данные по товарам, мы записываем json с данными о товарах, который пришел, в ActiveMQ и говорим 1С, что “все ок, мы позже это обработаем”. Каждая запись в ActiveMQ это пачка товаров только для 1 каталога.

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

Итоговая схема обновления данных получилась такая:

• Воркер товаров. Создает/обновляет базовую информацию о товаре, а также сохраняет остатки.

• Воркер цен сохраняет только цены.

• В результате после обработки rest данных мы получаем некрасивый товар (есть остатки, цены, название но нет описания, картинок, названия на нужном языке)

• Каждый rest воркер сообщает продюсеру sku, о том, что из 1С пришли какие то изменения на товар х. Продюсер добавляет это sku в очередь на обновление данных о sku. 

• Воркер обновления данных sku. Задача этого воркера наполнить sku, свойствами (для умного фильтра), найти на нужном языке название sku. Данные о свойствах и названиях хранятся в контентной БД.

После обновления мы получаем sku с картинами и свойствами, для которого осталось создать товар. Каждое sku передается двум продюсерам, продюсер обычных товаров и продюсер цветных/языковых товаров. 

Создание товаров

В бизнес-логике клиента есть 2 типа товаров:

1. Простой товар, 1 sku к 1 товару.

2. Цветной/языковой или цветной и языковой одновременно, несколько 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 часов не столь страшна, а перевод на очереди и подготовка к высоким нагрузкам будут проще чем в случае стандартного обмена.