Tutorial по обмену сайта с 1С. Часть вторая: зачем и как писать свой обмен с нуля на очередях и REST API

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

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

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

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

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

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

Варианты:

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

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

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

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

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

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

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

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

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

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

схема самописной интеграции 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-обмена

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

пример Rest обмена

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

интеграционная схема 1с и двух сайтов

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

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

  • Типы цен.

  • Товары.

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

  • Склады.

  • Заказы.

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

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

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

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

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

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

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

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

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

интеграция 1с через rest-обмен

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

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

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

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

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

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

Теперь, когда 1С присылает нам данные по товарам, мы записываем json с данными о товарах, который пришел, в ActiveMQ и говорим 1С, что “все ок, мы позже это обработаем”. Каждая запись в 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 часов не столь страшна, а перевод на очереди и подготовка к высоким нагрузкам будут проще чем в случае стандартного обмена.

Оцените статью
10.01.2023
Понравилась статья?
Поделитесь ссылкой с друзьями и коллегами!

Статьи по теме

12.01.2023
Tutorial по обмену с 1С. Часть пятая: Наш опыт настройки 1000 и 1 обмена В своей предыдущей статье я начала раскрывать тему того, как правильно настраивать обмен между крупными сайтами и B2B-системами на Битрикс с системами учет...
10.01.2023
Tutorial по обмену с 1С. Часть четвертая: Обмен через промежуточную базу данных В 2022 году на долю маркетплейсов приходится более 65% рынка онлайн-продаж в секторе B2C. На сегодняшний день площадки занимают основную долю рынка электро...
10.01.2023
Tutorial по обмену с 1С. Часть третья: Выжимаем максимум из стандарта. Что мы хотели бы знать 1000 проектов назад Всем привет! Я Дина, ведущий разработчик личных кабинетов и ecom-систем в ИНТЕРВОЛГЕ. Мы не делаем тривиальных проектов. Все что я буду описывать ниже – ун...
10.01.2023
Tutorial по стандартному и нестандартному обмену сайта с 1С. Часть первая: стандартный обмен и его хитрости Имею желание купить дом, но не имею возможности. Имею возможность купить козу, но не имею желания. к/ф «Кавказская пленница» ...
10.01.2023
Как мы CRM Битрикс24 с кучей всего интегрировали У нас был сложный сайт с личным кабинетом клиентов, устаревшая, переписанная 1С-ка, десяток маркетинговых сервисов, и телефония на Asterisk. Единств...

Мы работаем по одному из двух форматов:

  • аренда команды (от 2 человек, не менее 3 месяцев);
  • итерации с фиксированной ценой (1-3 месяца длительностью).

ИНТЕРВОЛГА предоставляет:

  • регулярные онлайн-планерки с заказчиком;
  • квалифицированных специалистов;
  • организованную команду (находятся в одном помещении, что упрощает решение рабочих вопросов);
  • полную прозрачность и регулярность отчетов о результатах.

Для доработок и развития мы предлагаем формат 100 часов в месяц. Что можно сделать за это время:

  • новые нетиповые страницы или раздел;
  • 2 отчета с индивидуальными настройками;
  • 3-5 веб-сервисов интеграции;
  • замудренный калькулятор и т.п.

Поддержка «чтобы все работало как часы» стоит 45 тысяч рублей в месяц и описана тут.

Хочешь получать лучшие статьи от INTERVOLGA раз в месяц?
Подпишись на рассылку — спамить не будем