Разработка интернет-магазина и интеграций для Abamet-shop.ru

Компания «Абамет» более 25 лет осуществляет поставки металлообрабатывающего оборудования. По сегодняшний день остается единственной компанией в своём сегменте, которая дает возможность заказать, оплатить онлайн и получить доставку. Весь жизненный цикл продажи автоматизирован.

В рамках перехода компании с SAP на новую связку ERP + CRM нужно было встроить интернет-магазин в существующие бизнес-процессы и обеспечить стабильный обмен данными между 1С, Microsoft Dynamics и сайтом.

• Спроектировать архитектуру обмена между интернет-магазином, 1С (ERP) и Microsoft Dynamics (CRM).
• Реализовать обмен данными по протоколу SOAP.
• Настроить передачу каталога, товаров, цен, остатков и SKU между системами.
• Обеспечить обмен заказами, статусами заказов и данными клиентов.
• Реализовать систему идентификации сущностей между несколькими базами данных.
• Настроить безопасный обмен с двухуровневой проверкой доступа.
• Разработать поэтапную дорожную карту внедрения интеграций.  

Обновление структуры и автоматизация процессов

Переработали структуру каталога, обновили навигацию и совместно с клиентом пересобрали вложенность разделов. Также разработали новый визуальный стиль и адаптировали под него остальные разделы сайта.

Однако проект не ограничился обновлением дизайна — основной фокус сместился на автоматизацию процессов, поэтому кейс в большей степени про развитие системы, а не про новые шаблоны.  

Планируем архитектуру проекта

В 2019 решили уходить от старой системы SAP на новую связку ERP+CRM. В качестве систем интеграции были выбраны 1C как ERP, и Microsoft Dynamics как CRM.

За данную связку отвечал интегратор «Корус Консалтинг». Нашей задачей было внедрить в эти процессы интернет-магазин.  

Обмен по протоколу SOAP

SOAP — устоявшийся протокол обмена, который часто используется для интеграций с 1С вместо более свободного REST.

В отличие от REST, в SOAP используется единая точка входа, а маршрутизация методов описывается WSDL-файлом — XML-документом со структурой и описанием методов.

SOAP можно реализовать как на PHP, так и средствами Битрикс. Поскольку модуль Битрикс давно не обновлялся, в проекте использовали реализацию на SOAP-PHP.  

При построении сложных обменов главное правильно начать. Нужно строить обмен от базового. Логичнее всего в магазине было начать именно с каталога, и потом добавлять к нему всё остальное.

1. Разработка SOAP-сервера для приёма категорий и товаров.
2. Создание SOAP-клиента для передачи остатков из корзины
3. Создание SOAP-клиента для передачи клиентов в CRM
4. Создание SOAP-сервера для приёмки уровней скидок
5. Создание SOAP-методов для отдачи информации о заказах

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

Защита и унификация обмена между тремя системами

Чтобы запрос прошёл, нужно чтобы вместе с передачей xml-пакета у системы был правильный basic auth заголовок. Если заголовок корректный, система проверяет валидность ключа обмена. Если ключ в пакете некорректный запрос отбраковывается.  

Защита и унификация обмена между тремя системами

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

Каждая сущность обмена описывалась например так:

ID_ERP:d1f5d2ce-4732-11e9-8dac-005056032acc

ID_CRM:752df240-ff4a-e911-a83c-000d3ab2daff

ID_IM:513-404-10e

ID_SAP:513-404-10E

Это удобно, так как при обмене, например товаром, каждая система знает, какой объект к ней пришел.  

Контуры обмена с 1С

1С хранит информацию о каталоге, при этом не только о товарах, но о категориях, об уровнях вложенности, а так же SEO-описания для категорий. Кроме того, 1С отвечает и за бух. учет, поэтому информация о заказах поступает из ИМ напрямую в 1С.  

Как описывать обмен без ошибок

ТЗ нужно разделить на три части (вырезки и рабочего ТЗ):

• Описание порядка обмена по шагам, или в виде UML-диаграммы
• Формат данных из пакета и соответствие записи в БД на стороне магазина
• Пример запроса и ответа в формате обмена  

Работа с клиентскими данными

CRM отвечает за работу с клиентами компании. Между магазином и системой передаются данные о физических и юридических лицах, объёмах покупок и уровнях скидок.

Разница в логике хранения

Основная сложность интеграции — различия в структуре данных.

В Битрикс покупатель — это одна сущность и одна запись в базе, а тип клиента (физлицо или юрлицо) определяется на уровне заказа через профиль покупателя.

В CRM иерархия сложнее: существует сущность компании, внутри которой может быть любое количество клиентов.

Решение

Чтобы не менять существующую схему хранения, разработали скрипт, который расширяет данные пользователей и передаёт их в унифицированном виде. Далее CRM самостоятельно распределяет компании и клиентов как отдельные сущности.  

Очередь сообщений для обмена между системами

Поскольку интернет-магазин, 1С и CRM находятся на разных серверах и обмениваются данными по сети, понадобился минимальный сервер очередей. Его задача — повторная отправка сообщений при ошибках или временной недоступности систем.

Готовые решения вроде RabbitMQ оказались избыточными для этой задачи, поэтому реализовали собственный скрипт и агента для работы с пакетами сообщений.

Как работает механизм

• скрипт отслеживает коды ошибок обмена;
• при ошибке событие логируется вместе с методом и временем;
• данные записываются в инфоблок;
• если время события превышает заданный лимит, выполняется повторная отправка сообщения.  

Класс работы с логами

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

Как функции выполняет класс работы с логами

• Единая структура логгирования событий
• Единый формат
• Единая машрутизация логов
• Единые правила именования по суткам
• Сборка мусора (логи старше недели удаляются)