Как интегрировать ERP с сайтом: три подхода на любой случай
Анна Кожевина, аккаунт-директор scrum-студии «Сибирикс», о трех способах решения распространенной задачи.
Все самое важное в интернет-магазине — каталог, товары, цены, остатки, пользователи, скидки — обычно подгружается на сайт или в мобильное приложение из ERP-системы клиента. Но в нашей многолетней практике еще не было случая, когда мы обошлись бы штатным импортом — выгрузили и загрузили данные «как есть». Иногда случается, что данные о товарах хранятся не только в самой ERP. Таких систем может быть несколько, при этом каждая со своими настройками и форматами данных. Вариантов много, но мы обобщим их в три больших категории и рассмотрим, какие решения пригодятся в каждом случае.
Когда ERP — много
Эта ситуация характерна для франчайзинговых сетей с большим числом партнеров, каждый из которых использует свои ИТ-решения.
В чем сложность
Например, у франчайзинговой компании Fitness Formula в каждом регионе присутствия есть свой партнер со своей собственной ERP. Чаще это 1С, но не всегда. Таких партнеров у компании более 40, и каждому нужно интегрироваться с общим сайтом, чтобы синхронизировать данные по остаткам, цены и другие локальные параметры, но при этом изолировать данные о заказах конкретного региона от других юрлиц. 40 интеграций — это запредельно много, долго и дорого.
Что делать
Оптимальный вариант — хранить данные о товарах (характеристики, описания и изображения) в единой мастер-базе. Редактировать и создавать товары может только суперадминистратор — роли и права доступа можно настроить в админке сайта.
Каждый партнер прописывает в своей ERP артикулы из мастер-базы и определяет для каждого товара цены и остатки на складе — эта информация будет отображаться на сайте для конкретного региона.
Если у вас есть планы по развитию франчайзинговой сети, сразу предупредим — для таких проектов привычный многим Битрикс не подходит. Его админ-панель не позволяет настраивать доступ к заказам по регионам. Придется выстраивать систему на фреймворках, библиотеках с открытым исходным кодом. Лучше всего подходит Laravel.
Когда ERP одна, а складов — много
Так обычно работают торговые сети с собственными филиалами — продукция хранится на разных складах и разных торговых точках, но весь учет ведется в одной ERP.
В чем сложность
Например, у аптечной сети «Амурфармация» каждая аптека — это склад со своими остатками, а иногда и со своими ценами и акциями. При этом на сайте нужно отображать остатки с учетом того, что покупатели не только заказывают товары онлайн, но и приобретают их в физических аптеках.
Что делать
Придется настроить импорт остатков, цен, транзакций и данных бонусной системы из аптек с оптимальной частотой, например, каждые 20 секунд. Но если не предпринять дополнительных действий, система не будет успевать «разбирать» ответы от десятков торговых точек и обновлять информацию на сайте. Здесь пригодится такой инструмент, как «сервер очередей».
Когда ERP обращается к сайту для передачи остатков, нужно перехватить ее файл, разделить его на части (пачки) и отправить на сервер очередей, который запускает обработку этих файлов параллельно в несколько потоков. Если поочередное выполнение кода заняло бы, скажем, 10 минут, то его параллельное выполнение пройдет в 10 раз быстрее.
За счет такой схемы данные на сайт импортируются быстрее: процесс идет параллельно и многопоточно, с учетом разных городов с разными ценами и акциями в своих аптеках.
Когда ERP — одна, но это SAP
Один только факт использования на проекте SAP уже обещает много интересного и нестандартного: из этой системы можно выгрузить только номенклатуру (справочники, товары и их свойства), причем в строго определенном порядке. Данные о ценах и остатках чаще всего хранятся в дополнительной учетной системе. Так же, как и изображения товаров.
Особенно интересно работать с этой ERP в проектах для франчайзинговых сетей, когда на едином сайте нужно постоянно держать актуальную информацию по каждому магазину.
В чем сложность?
Например, франчайзинговая сеть магазинов «Империи Сумок» хранит информацию о товарах в ERP SAP, развернутой на собственном сервере. Данные о ценах и остатках хранятся в системе Domino, а изображения товаров — в папке на отдельном сервере.
Менять или дорабатывать что-либо в самой ERP нельзя. Система сконфигурирована и настроена под бизнес-процессы, а данные из нее поступают не только на сайт, но и в другие подсистемы. Любые изменения — риск нарушить работу всей компании.
Чтобы сформировать карточку товара на сайте, нужно собрать данные сразу из трех мест:
● забрать файл SAP-системы, который хранится на сервере заказчика (и обновляется там каждые 2 минуты);
● забрать XML-файл с ценами и остатками из системы Domino — он выгружается раз в сутки;
● забрать изображения товаров из папки, которая хранится на другом сервере заказчика — новые файлы раз в сутки выгружаются в отдельную папку и импортируются на сайт.
Что делать?
Чтобы аккуратно перенести все данные о товарах из трех разных мест на сайт, их нужно прежде всего синхронизировать — для этого лучше использовать серверную утилиту rSYNC и уже упомянутый ранее сервер очередей.
rSYNC позволяет максимально ускорить процесс обмена постоянно меняющимися данными: с ее помощью можно подключиться к нужной папке на другом сервере и моментально забрать оттуда нужный файл.
Поскольку данные меняются постоянно, импорт нужен не разовый, а тоже — постоянный. Система, выстроенная в «Империи сумок», забирает данные из SAP каждые 5 минут, данные об остатках и ценах получает из Domino раз в сутки (сопоставляя информацию о товаре с его ценой по артикулу), и раз в сутки импортирует новые изображения на сайт.
Как работает импорт файлов с серверов заказчика на сайт с помощью серверной утилиты rSYNC на проекте «Империя Сумок»
Если товаров в каталоге много (в этом кейсе их было больше 100000, а разных ценовых предложений по товарам — больше 1,5 млн), импорт придется ускорять с помощью сервера очередей — выполнять запросы параллельно.
Поскольку для SAP крайне важна последовательность импорта, а сервер очередей выхватывает произвольные куски из общего объема импортируемых данных, придется писать отдельный программный код, который следит за параллельно-последовательным импортом, чтобы задачи можно было ставить в очередь. Именно за счет сервера очередей ежедневный сбора данных из трех систем можно сократить с 5 часов до 10 минут.
Итого
● Если ERP на проекте — много, нет смысла импортировать данные отдельно из каждой: это долго и дорого. Вместо этого нужно максимально унифицировать процесс. Да, это повлечет некоторые переделки на стороне заказчика, но оно того точно стоит: больше порядка, больше предсказуемости и меньше времени на обмен данными.
● Если ERP одна, но какие-то данные собираются в нее из нескольких источников (например, физических точек продаж), файл с данными для импорта на сайт наверняка будет увесистым и неповоротливым. Спасет сервер очередей и Service Worker-ы, которые переварят этого слона по частям.
● Если ERP нельзя дорабатывать, а данные берутся не только из нее, да еще и лежит все это на физическом сервере заказчика и выгружается в виде файлов — подойдет серверная утилита (например, rSYNC) для шустрого получения всех этих файлов разом и сервер очередей для их быстрой обработки.
.
