Новое в блогах


Техноблог HTTPS и Amiro.CMS  1
Техноблог Обновление цен в каталоге интернет-магазина через CSV-файл 
Техноблог Подключаем и используем модуль «SEO Шаблоны»  1
Техноблог Использование модуля «Валюты» в интернет-магазине импортных товаров 
Личный опыт История от «Интер Электрик», #ОбновлениеЗаРассказ 
Личный опыт История от АвтоТехЦентр Субару Медведково, #ОбновлениеЗаРассказ 

Теги



Обмен данными. Часть 1. Типовые архитектуры

Любой владелец интернет-магазина в процессе создания или в процессе эксплуатации обязательно столкнется с вопросом обмена данными между магазином и бухгалтерскими программами, сторонними сайтами или веб-приложениями, которые для единообразия будем называть «системой учета». Поскольку все вопросы обмена данными, будь сайт создан на Amiro.CMS или на любой другой системе управления, практически одинаковы, попробуем рассмотреть их в данном обзоре, разделенном на 3 части:

  1. Определение решаемых бизнес-задач. Рассмотрение типичных архитектур решения
  2. Особенности реализации обмена в Amiro.CMS
  3. Настройка экспорта в Яндекс.Маркет

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

  1. товарах (конентная составляющая: описания, изображения и прочие свойства товара)
  2. остатках товаров
  3. ценах
  4. статусе заказов
  5. составе заказов
  6. покупателях

Архитектуры решения

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

Типовые архитектуры

На практике реализуемая архитектура решения чаще всего зависит от «размера» бизнеса:

  1. от количества товарных позиций
  2. от количества заказов
  3. от количества сайтов
  4. от числа администраторов системы (менеджеров, контент-менеджеров)
  5. от прав доступа администраторов (если их несколько)

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

  1. Решение «малый бизнес» (один сайт, один менеджер, средняя посещаемость). Система учета используется только для построения отчетности:
    • Товары редактируются на сайте
    • Покупатели создаются на сайте
    • Состав заказов изменяется на сайте
    • Статусы заказов изменяются на сайте
    • Остатки учитываются на сайте
    • Обмен: товары, заказы и остатки передаются из сайта в систему учета

  1. Решение «средний бизнес» (один или несколько сайтов, один или несколько менеджеров, контент-менеджеры, высокая посещаемость). Система учета – для учета заказов и остатков:

    • Товары редактируются на сайте
    • Покупатели создаются на сайте
    • Состав заказов изменяется на сайте
    • Статусы заказов изменяются в системе учета
    • Остатки учитываются в системе учета
    • Обмен: товары и заказы передаются из сайта в систему учета, статусы заказов и остатки из системы учета на сайт

  1. Решение «крупный бизнес» (один или несколько сайтов, несколько менеджеров, контент-менеджеры, очень высокая посещаемость). Система учета – для управления ассортиментом, учета заказов и остатков:
    • Товарный ассортимент редактируется в системе учета, контентная составляющая (описание, изображения и т.п.) ведется на сайте
    • Покупатели создаются на сайте
    • Состав заказов изменяется в системе учета
    • Статусы заказов изменяются в системе учета
    • Остатки учитываются в системе учета
    • Обмен: товары, заказы и остатки передаются из системы учета на сайт; из сайта в систему учета только первичный состав заказа

    Тем не менее, следует понимать, что возможны и прочие варианты обмена данными, зависящие от желаемых бизнес-процессов, происходящих на сайте. Например, не ведется учет остатков (не нужно резервирование товаров и списание остатков) или заказы не требуют проверки и есть только оплата онлайн, следовательно, заказ попадает в систему учета только после получения оплаты. 

    Однако, не всегда планируемые бизнес-процессы реализуемы. Например, владельцы сайтов считают реализуемыми архитектуры где состав заказа изменяется и на сайте, и в системе учета, что может привести к коллизиям и потере данных (или неоправданном значительном усложнении и удорожании решения). Поэтому, помимо создания бизнес-процессов, необходимо учитывать и технические факторы, в частности, производительность сайта, поскольку очевидно, что обмен данными — это ресурсоёмкая и долгая операция. Выполнять полную синхронизацию данных в часы высокой нагрузки сайта — суть потеря производительности сайта, что влечет низкую скорость генерации страниц сайта и потерю пользователей. Следовательно, финальное решение о будущем обмене должно приниматься перед его созданием в тандеме: владелец сайта и технический специалист, настраивающий обмен.

    Динамика обмена

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

    Рассмотрим пример требуемых бизнес-процессов, и на их основе заполним таблицу.

    Задача. Товары будут создаваться путем импорта с 2 сайтов поставщиков. Дополнение информации о товаре будет производиться на сайте контент-менеджерами вручную. Пользователи регистрируются на сайте и делают заказы. Менеджер, отвечающий за состав заказа, созванивается с клиентом и на сайте изменяет заказ (добавляет / удаляет позиции, изменяет количество товаров, изменяет адрес доставки и т.п.). Подтвержденный менеджером заказ получает статус «проверен» и выгружается с систему учета. На сайте остатки товара изменяются в соответствии с выгруженным заказом. В системе учета также происходит резервирование остатков товаров. Заказ получает статус «ожидает оплаты» если оплата, например, идет безналичным расчетом. После получения оплаты, менеджер в системе учета выставляет статус «оплачен», и заказ уходит в службу комплектации и доставки, после чего происходит списание остатков товаров. Далее статус заказа изменяется в процессе доставки (отправлен, доставлен и т.п.). Все изменения статуса заказа отражаются на сайте, чтобы их мог отследить пользователь. Все актуализированные остатки и цены выгружаются из системы учета на сайт 1 раз в сутки. Товары выгружаются в Яндекс.Маркет.

    Полученная архитектура изображена на рисунке:


    Рассмотрим заполненную таблицу, соответствующую процессу, описанному выше (статусы заказов, используемые в различных системах управления сайтом могут отличаться от использованных в данной таблице). Плюсом в ней отмечено, откуда берутся изменения (например, пользователи создаются на сайте, поэтому в строке "пользователи" стоит плюс именно в столбце "сайт"):

    Операция
    Сайт Система учета Примечание
    Создание товара     Товары попадают не из системы учета, а из третьей системы — сайта поставщика
    Товар     Опубликованные товары должны выгружаться в систему учета
    Пользователь     Пользователь не выгружается в систему учета пока он не сделал заказ. Информация о пользователе выгружается в момент выгрузки заказа из сайта в систему учета
    Заказ (создание), статус «принят»     Новый заказ не выгружается в систему учета
    Заказ (изменение состава), статус «проверен»     Заказ со статусом «проверен» выгружается в систему учета. На сайте изменяются остатки товаров, присутствующих в заказе
    Получение оплаты, заказ получает статус «оплачен»     Новый статус заказа попадает на сайт
    Отправка товара, заказ получает статус «отправлен»     Новый статус заказа попадает на сайт
    Остаток товара     Новое значение количества товаров попадает на сайт
    Цена товара  
    При изменении цены в системе учета, она попадает на сайт

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

    Выводы

    1. Формулирование задачи обмена данными — это описание бизнес-процессов: кто и где производит изменение данных товаров, заказов, остатков) и в какой момент происходит синхронизация. Именно точность постановки задачи обмена определяет удобство получаемого решения. Только владелец бизнеса может определить желаемые бизнес-процессы.
    2. Существуют типовые архитектуры, зависящие от количественных характеристик (количество товаров, заказов, пользователей) и уровня разделения прав администраторов. Однако, не всегда типовая архитектура удобна в конкретной бизнес-задаче, поэтому вполне допустимо использование и других архитектур.
    3. Финальное решение должно учитывать и технические особенности сайта, что накладывает некоторые ограничения на исходные требования к бизнес-процессам.
    4. Результатом данной работы по построению схем обмена будет Техническое Задание по обмену данными.

    Автор «Угол Зрения»

    Студия «Угол зрения» является ведущим разработчиком нестандартного функционала для Амиро.CMS. Специалисты студии ведут блог об эффективном использовании системы управления, который полезен не только владельцам сайтов и интернет-магазинов, но и техническим специалистам, создающим сайты на Амиро.CMS - в блоге раскрывается опыт создания сайтов и полезных функциональных решений. Получить информацию о новых публикациях можно подписавшись на рассылку в профиле автора.

    [12.02.15]  
    Рейтинг: 5 (голосов: 3)
    Комментировать

    Теги: интернет-магазининтеграцияAPIПрограммирование
     
    Вернуться к списку
    Ваш комментарий