Обмен Битрикс – своя ERP

Ход работ

Ситуация у клиента на начало работ:

• Собственная разработка ERP в закрытом контуре.
• Старый сайт с доработанным стандартным обменом Битрикс. На сайте около 40 инфоблоков, в каждом из которых в среднем по 70 свойств.
• Текущий обмен очень требователен к ресурсам, и, чтобы обновить цены на сайте, нужно очень много времени, несмотря на производительные серверы.
• Планируется разработка нового сайта, о котором пока ничего не известно.

На старте представители заказчика описали свои требования к обмену, и в результате нескольких созвонов мы сформировали два предложения:

1. Сделать REST методы на сайте
2. Или сделать “монолитный” обмен

Список требований:

• Возможность полного обмена с поиском и удалением ненужных товаров.
• Возможность неполного обмена.
• Формат данных обмена “JSON”.
• Проверка текущего статуса обмена.
• Сайт ничего не должен “знать” о ERP.
• Обмен должен быть обособлен от сайта.
• Доступ будет ограничен на уровне операционной системы.

На бумаге всё выглядело хорошо, оценили работы, разработчики ERP описали поля формата. Развернули сайт в тестовой среде. Начали писать обмен.

Оказалась, система ERP тоже модернизируется, и новая структура каталога товаров в ERP будет отличаться от той, с которой мы работаем. А также назрела необходимость и новым сайтом заняться. Ещё созвон, решаем, что будем писать обмен для новой структуры и нового сайта. Это несколько даже облегчило нам задачу. Например, инфоблоков стало не великое множество, а один – это сильно упрощает нам разработку.

Снова разворот сайта, настройка Git-сервера и вперёд – в разработку!

Теперь о технической части

Можно было сделать API на сайте, но клиент настоял на отдельном интерфейсе для обмена. Мы не против. Делаем второй сайт в рамках многосайтовости Битрикс.

Весь сервис обмена делаем модулем Битрикса и устанавливаем его через админку.

Пишем обмен папками, потом свойствами, тут заказчик вспоминает, что надо бы навести порядок. Раньше было много разных инфоблоков со своим свойством, например, “цвет”, теперь же все совпадающие по сути свойства должны объединиться в одно свойство. Так родилась подзадача сделать “маппинг свойств”. Технически все решения не сложные, но имели много нюансов. Например, свойство “количество чего-либо” могло приходить как число и как строка, и как список. Сделали промежуточную таблицу, контент-менеджеры заказчика за несколько бессонных ночей отсортировали и отобрали все свойства, всем установили одинаковые типы и прописали символьные коды – герои!

Новые свойства теперь грузятся в промежуточную таблицу, и только потом в 1С-Битрикс.

Дальше обмен товаров: создание, изменение и удаление. Несмотря на то, что обычно не найденные в обмене товары деактивируются, требованием было удаление таких товаров.

Проблем не возникало, кроме некоторых методов D7, которые до сих пор не до конца работают или ссылаются на старые методы.

Сам обмен написан, делаем интерфейсы для создания обмена – помещения его в очередь, получения статуса обмена по его ID – и вешаем обработчик запуска на CRON. Вуаля, готово!

Осталось написать обширную документацию для заказчика и будущих поколений разработчиков, исправить ошибки (их почти не было) и красиво уйти в отпуск!