Разработка интернет-магазина и интеграций для Abamet-shop.ru
До:
После:
Планируем архитектуру проекта
В 2019 решили уходить от старой системы SAP на новую связку ERP+CRM. В качестве систем интеграции были выбраны 1C как ERP, и Microsoft Dynamics как CRM.
За данную связку отвечал интегратор «Корус Консалтинг». Нашей задачей было внедрить в эти процессы интернет-магазин.
Обмен по протоколу SOAP
SOAP это старый и сложный протокол обмена который устоялся в 1С, поэтому часто для обменов с 1С используют именно его, а не более свободный по реализации REST.
В общем виде обмен выглядит так:
В отличие от REST на SOAP формируется одна точка входа, а за маршрутизацию методов отвечает специальный WSDL-файл. Это xml-файл который описает методы и их структуру.
Реализации SOAP есть как на PHP так и у Битрикса. Но модуль битрикса давно не обновлялся, поэтому мы делали сборку на SOAP-PHP.
Планируем дорожную карту
При построении сложных обменов главное правильно начать. Нужно строить обмен от базового. Логичнее всего в магазине было начать именно с каталога, и потом добавлять к нему всё остальное.
Этапность строилась таким образом, что после каждого этапа происходила синхронизация баз данных, и пример когда мы делали реализацию передачи заказов, 1С уже понимала какие товары покупает клиент.
Защита и унификация обмена между тремя системами
Для реализации безопасного обмена используется два уровня:
Чтобы запрос прошёл, нужно чтобы вместе с передачей xml-пакета у системы был правильный basic auth заголовок. Если заголовок корректный, система проверяет валидность ключа обмена. Если ключ в пакете некорректный запрос отбраковывается.
Схема идентификации
В процессе задействованы три базы данных, а это значит что у каждой своя структура и логика хранения данных. Чтобы у систем была сквозная синхронизация и единые сущности индентифицировались одинаково, мы хранили все наборы идентификаторов.
Каждая сущность обмена описывалась например так:
Контуры обмена с 1С
1С хранит информацию о каталоге, при этом не только о товарах, но о категориях, об уровнях вложенности, а так же SEO-описания для категорий. Кроме того, 1С отвечает и за бух. учет, поэтому информация о заказах поступает из ИМ напрямую в 1С.
Обмен с 1С проще всего показать на примере товара:
Как описывать обмен для разработчика и не облажаться?
ТЗ нужно разделить на три части (вырезки и рабочего ТЗ):
Описание порядка обмена по шагам, или в виде UML-диаграммы:
Формат данных из пакета и соответствие записи в БД на стороне магазина:
Пример запроса и ответа в формате обмена:
Суммарно был реализованы следующие направления обмена
- Структура каталога
- Товары
- SKU
- Цены
- Остатки
- Изображения и pdf
- Заказы
- Статусы заказов
- Характеристики товаров
Контуры обмена с Microsoft Dynamics 365
CRM в первую очередь работает с клиентам компании. В магазин и из магазина мы передаём информацию о клиентах, как о физ.лицах так и юр.лицах. Кроме того следим за объёмами их покупок, уровнями скидок.
Обмен с CRM происходит по следующей схеме:
Сложность при интеграции с CRM, в особенностях хранения сущеностей в двух системах. В Битрикс покупатель, это единая сущность, и 1 запись в базе данных. А тип покупателя, как физ.лицо или юр.лицо уже определяется на уровне заказа, как профиль покупателя.
В CRM иерархия сложнее, так как есть сущность компания, в неё могут входить любое количество клиентов. Клиент не хотел ломать текущую схему хранения покупателей, поэтому мы написали скрипт который расширял хранимые данные по пользователям, и передавал их в единообразом виде в CRM, где уже система сама распределяла компании и клиентов как разные сущности.
Сервер очередей
Так как все три учетные системы ИМ, 1С и CRM находятся на разных серверах, и обмениваются инфомацией по сети, нужно было предусмотреть минимальный сервер очередей для огранизации отправки повторных сообщений при получении ошибок или сетевой недоступности.
Готовые решения, вроде RabbitMQ слишком громозкие для нашей микрозадачи, поэтому мы написали свой скрипт и агента который работает с пакетами сообщений.
Класс работы с логами
Как функции выполняет класс работы с логами
- Единая структура логгирования событий
- Единый формат
- Единая машрутизация логов
- Единые правила именования по суткам
- Сборка мусора (логи старше недели удаляются)
Кроме реализации самого обмена, важным нюансом было выстроить корректную систему логгирования событий не только для сервера очередей, но и для каждого контура обмена в целом. Сложности с логгированием обычно в том, что неопытные проектировщики оставляют логгирование на откуп разработчику, поэтому можно получить несвязную кучу логов которое копятся годами.