Блог

03.02.14

Обмен данными. Часть 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. Результатом данной работы по построению схем обмена будет Техническое Задание по обмену данными.

    Все записи

    Комментарии

    Нет комментариев

    Правильный угол зрения на природу сайтостроения
    (383) 310-63-21

    Заказать звонок

    ФИО:*
    Телефон:*
    Комментарий(вопрос):*


    * Обязательные поля

    Личный кабинет
    Каталог модулей
    Случайные модули
    Популярные модули
    Динамические ссылки
    2,990 руб.

    Модуль позволяет динамически заменять указанные в тексте слова на ссылки.

    Похожие товары
    2,990 руб.

    Модуль позволяет выводить в карточке товара похожие по свойствам товары.

    Отзывы
    Политика конфиденциальности    Контакты    Карта сайта    Вакансии    Вопрос-ответ    Оплата     Мобильная версия
    Работает на: Amiro CMS