Обмен данными. Часть 1. Типовые архитектурыЛюбой владелец интернет-магазина в процессе создания или в процессе эксплуатации обязательно столкнется с вопросом обмена данными между магазином и бухгалтерскими программами, сторонними сайтами или веб-приложениями, которые для единообразия будем называть «системой учета». Поскольку все вопросы обмена данными, будь сайт создан на Amiro.CMS или на любой другой системе управления, практически одинаковы, попробуем рассмотреть их в данном обзоре, разделенном на 3 части:
Прежде всего, следует выделить бизнес-задачи по синхронизации между сайтом и системой учета. Это актуализация данных о:
Архитектуры решенияДля того, чтобы понять, какую архитектуру требуется реализовать в конкретном случае, рекомендуется продумать требуемые процессы: где создавать товары, в какой момент производить обмен информацией о заказах, где изменять статус заказа, где учитывать остатки и т. п. Для этого рассмотрим типовые архитектуры решений. Типовые архитектурыНа практике реализуемая архитектура решения чаще всего зависит от «размера» бизнеса:
Исходя из этого, можно выделить следующие типичные архитектуры, которые будем иллюстрировать схемами перемещения данных:
Тем не менее, следует понимать, что возможны и прочие варианты обмена данными, зависящие от желаемых бизнес-процессов, происходящих на сайте. Например, не ведется учет остатков (не нужно резервирование товаров и списание остатков) или заказы не требуют проверки и есть только оплата онлайн, следовательно, заказ попадает в систему учета только после получения оплаты. Однако, не всегда планируемые бизнес-процессы реализуемы. Например, владельцы сайтов считают реализуемыми архитектуры где состав заказа изменяется и на сайте, и в системе учета, что может привести к коллизиям и потере данных (или неоправданном значительном усложнении и удорожании решения). Поэтому, помимо создания бизнес-процессов, необходимо учитывать и технические факторы, в частности, производительность сайта, поскольку очевидно, что обмен данными — это ресурсоёмкая и долгая операция. Выполнять полную синхронизацию данных в часы высокой нагрузки сайта — суть потеря производительности сайта, что влечет низкую скорость генерации страниц сайта и потерю пользователей. Следовательно, финальное решение о будущем обмене должно приниматься перед его созданием в тандеме: владелец сайта и технический специалист, настраивающий обмен. Динамика обменаЧтобы принять решение, на какой стороне, какие работы проводить, и какие данные куда следует передавать, следует процессы рассматривать в динамике. В качестве подсказки мы предлагаем использовать таблицу, отмечая, какая составляющая магазина изменяется на сайте, а какая в системе учета. Рассмотрим пример требуемых бизнес-процессов, и на их основе заполним таблицу. Задача. Товары будут создаваться путем импорта с 2 сайтов поставщиков. Дополнение информации о товаре будет производиться на сайте контент-менеджерами вручную. Пользователи регистрируются на сайте и делают заказы. Менеджер, отвечающий за состав заказа, созванивается с клиентом и на сайте изменяет заказ (добавляет / удаляет позиции, изменяет количество товаров, изменяет адрес доставки и т.п.). Подтвержденный менеджером заказ получает статус «проверен» и выгружается с систему учета. На сайте остатки товара изменяются в соответствии с выгруженным заказом. В системе учета также происходит резервирование остатков товаров. Заказ получает статус «ожидает оплаты» если оплата, например, идет безналичным расчетом. После получения оплаты, менеджер в системе учета выставляет статус «оплачен», и заказ уходит в службу комплектации и доставки, после чего происходит списание остатков товаров. Далее статус заказа изменяется в процессе доставки (отправлен, доставлен и т.п.). Все изменения статуса заказа отражаются на сайте, чтобы их мог отследить пользователь. Все актуализированные остатки и цены выгружаются из системы учета на сайт 1 раз в сутки. Товары выгружаются в Яндекс.Маркет. Полученная архитектура изображена на рисунке: Рассмотрим заполненную таблицу, соответствующую процессу, описанному выше (статусы заказов, используемые в различных системах управления сайтом могут отличаться от использованных в данной таблице). Плюсом в ней отмечено, откуда берутся изменения (например, пользователи создаются на сайте, поэтому в строке "пользователи" стоит плюс именно в столбце "сайт"):
Следует отметить, что с точки зрения производительности сайта, нет необходимости синхронизировать остатки и цены в режиме реального времени, достаточно производить актуализацию 1 раз в сутки. Выводы
Автор «Угол Зрения»
Ваш комментарий
|