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

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

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

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

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

Было:

Стало:

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

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

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

Отдаёт номенклатуру, остатки, описание и фотографии товаров.

Принимает остатки, заказы, статусы заказов.

Интернет-магазин

Принимает каталог, товары, уровни скидок.

Отдаёт заказы, пользователей, статусы заказов, остатки по складам.

Microsoft Dynamics

Принимает информацию по клиентам: физики, юрики

Отдаёт уровни скидок, статистику по бонусам.

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

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

В общем виде обмен выглядит так:

Сервер 1С

Единая точка входа для всех методов

WSDL-файл

Soap-сервис на PHP или модуле Битрикс

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

Реализации SOAP есть как на PHP так и у Битрикса. Но модуль битрикса давно не обновлялся, поэтому мы делали сборку на SOAP-PHP.

Планируем дорожную карту

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

1-й этап

Разработка SOAP-сервера для приёма категорий и товаров.

2-й этап

Создание SOAP-клиента для передачи остатков из корзины

3-й этап

Создание SOAP-клиента для передачи клиентов в CRM

4-й этап

Создание SOAP-сервера для приёмки уровней скидок

5-й этап

Создание SOAP-методов для отдачи информации о заказах

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

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

Для реализации безопасного обмена используется два уровня:

Запрос

Валидация Basic Auth на уровне сервера

Валидация по systemID на уровне пакета

Чтобы запрос прошёл, нужно чтобы вместе с передачей 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С.

Обмен с 1С проще всего показать на примере товара

Как описывать обмен для разработчика и не облажаться?

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

Описание порядка обмена по шагам, или в виде UML-диаграммы:

Формат данных из пакета и соответствие записи в БД на стороне магазина:

Пример запроса и ответа в формате обмена:

Суммарно был реализованы следующие направления обмена

Структура каталога

Цены

Заказы

Товары

Остатки

Статусы заказов

SKU

Изображения и pdf

Характеристики товаров

Контуры обмена с Microsoft Dynamics 365

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

Кроме того следим за объёмами их покупок, уровнями скидок.

Обмен с CRM происходит по следующей схеме

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

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

Сервер очередей

Так как все три учетные системы ИМ, 1С и CRM находятся на разных серверах, и обмениваются инфомацией по сети, нужно было предусмотреть минимальный сервер очередей для огранизации отправки повторных сообщений при получении ошибок или сетевой недоступности.

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

Схема работы сервиса

Скрипт слушает все коды ошибок

При возникновении ошибки событие логгируется вместе с методом и записывается в инфоблок с меткой времени

Если метка времени в логе инфоблока по событию старше лимита в настройках, то пробуем отправить повторно

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

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

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

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

Единая структура логгирования событий

Единый формат

Единая машрутизация логов

Единые правила именования по суткам

Сборка мусора (логи старше недели удаляются)

Команда проекта

Руководитель проекта

Дима Хоружко

Архитектор обмена

Дима Хоружко

PHP разработчики

Денис Иванов

Руслан Кадыров

Команда Webcom Media

Татьяна Снитич

Светлана Валяк

Команда клиента

Дмитрий Сенькевич

Владимир Киселев