Если уже есть ESB и iPaaS, зачем e-commerce ещё один слой? Архитектура торговли #02

В первой части мы дошли до неприятной мысли:

подключить системы друг к другу — ещё не значит заставить их работать как одну систему.

API у всех есть.

Wildberries умеет принимать остатки.

Ozon умеет отдавать заказы.

1С умеет обмениваться данными.

WMS знает, что лежит на складе.

PIM знает, как должна выглядеть карточка товара.

CRM знает клиента.

Казалось бы, осталось просто всё соединить.

И здесь возникает вполне разумный вопрос:

А зачем вообще придумывать Commerce Orchestration?

Для интеграций уже существуют ESB, iPaaS, очереди, workflow-системы и десятки готовых коннекторов.

Справедливое замечание.

Поэтому попробуем разобраться без маркетинговых терминов.

Покупатель оформляет товар на Ozon.

В самом простом варианте:

Получили заказ.

Создали его в 1С.

Готово.

Но в реальной системе между этими двумя точками довольно быстро появляется что-то такое:

А теперь несколько вопросов.

Что делать, если товара уже недостаточно?

Какой склад выбрать?

Когда считать остаток уменьшившимся?

Что делать, если склад не подтвердил резерв?

Нужно ли после заказа на Ozon сразу уменьшать остаток на Wildberries?

А если Wildberries в этот момент недоступен?

Сколько раз повторять запрос?

Когда перестать повторять?

Когда позвать человека?

API на эти вопросы не отвечает.

Да.

Классическая интеграционная шина как раз появилась, чтобы не строить вот это:

Вместо множества прямых связей появляется центральный интеграционный слой:

ESB может:

И это уже огромное улучшение по сравнению с point-to-point.

На vc.ru есть отдельный разбор принципа ESB: чем больше систем появляется в компании, тем сложнее поддерживать прямые связи между ними.

То есть проблема известна давно.

Облачные интеграционные платформы сделали тот же подход доступнее.

Берём готовые коннекторы.

Соединяем системы.

Рисуем workflow.

Получаем примерно такое:

И современные iPaaS действительно способны строить очень сложные процессы.

Поэтому будет неправильно сказать:

ESB и iPaaS устарели, теперь всем нужен Commerce Orchestrator.

Нет.

Commerce Orchestration вообще не обязательно является отдельным продуктом.

И вот здесь начинается самое интересное.

Возьмём остаток.

WMS говорит:

stock = 1

Передать эту единицу в интернет-магазин очень легко.

Но означает ли:

stock = 1

что товар действительно можно продавать онлайн?

Не всегда.

Есть хороший пример — кейс COZY HOME на vc.ru.

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

Технически всё просто:

Магазин говорит: 1 ↓ Сайт показывает: 1

Но последняя единица могла:

То есть задача была не:

Как передать остаток 1?

А:

Можно ли при остатке 1 вообще разрешить продажу этого товара онлайн?

Это совершенно другой вопрос.

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

И вот здесь проходит важная граница.

Например:

Как отправить остаток в Ozon?

Например:

API здесь никуда не исчезает.

ESB тоже может остаться.

Очередь остаётся.

Коннекторы остаются.

Но появляется кое-что ещё:

состояние бизнес-процесса и правила его изменения.

Представим склад:

Физически на складе: 10

Две единицы уже зарезервированы.

Ещё одну компания не хочет продавать, чтобы оставить страховой запас.

Получаем:

Но даже семь необязательно отправлять во все каналы.

Например:

Получается:

WMS знает физический факт.

На складе 10.

Inventory logic вычисляет доступность.

Можно продать 7.

Политика канала определяет публикацию.

Ozon должен увидеть 5.

Интеграционный слой доставляет результат.

Отправить 5 в API Ozon.

Вот теперь роли становятся понятнее.

ERP сообщает:

Базовая цена = 4 990 ₽

Но цена на маркетплейсе может рассчитываться примерно так:

Получаем:

Какое значение правильное?

Все.

Они просто означают разные вещи.

Поэтому интеграция:

«Возьми поле price и отправь его дальше»

со временем перестаёт работать.

Сначала кто-то должен решить:

какую именно цену нужно показать именно этому каналу сейчас.

Не как новый класс программного обеспечения.

А как архитектурную ответственность:

Commerce Orchestration — это управление состояниями и бизнес-процессами торговли между несколькими системами и каналами.

То есть не только:

A → B

а:

Термин Order Orchestration давно существует и используется в OMS-системах.

Но похожие процессы возникают практически со всем commerce-доменом.

У каждого такого процесса появляется жизненный цикл.

Может.

Это принципиально важно.

Commerce Orchestration можно реализовать:

Поэтому я бы вообще не ставил вопрос так:

ESB VS Commerce Orchestrator

Правильнее:

Один продукт вполне может реализовывать оба слоя.

Разница здесь не продуктовая, а архитектурная.

Не всё.

Иначе мы просто построим ещё один ERP.

Но несколько вещей он должен понимать.

Заказ не должен перейти в:

RESERVED

если склад не подтвердил резерв.

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

Если одно событие пришло дважды:

ORDER_CREATED

ORDER_CREATED

мы всё равно должны получить:

1 заказ

а не:

2 заказа

Иногда автоматическое решение опаснее ручного.

Например:

ERP: 49 900 ₽

Marketplace: 4 990 ₽

Это может быть ошибкой.

А может быть запланированной акцией.

Иногда лучше:

Заказ — это не HTTP-запрос.

Он может жить:

час.

день.

неделю.

Возврат — ещё дольше.

Поставка — ещё дольше.

За это время:

Но бизнес-процесс не должен исчезнуть.

Поэтому orchestration layer должен уметь помнить:

на каком шаге мы находились и что должно произойти дальше.

Это одна из причин, почему в таких архитектурах появляются durable workflow-системы.

При этом Commerce Orchestration не должен становиться новой системой, в которую мы копируем всё подряд.

ERP по-прежнему может владеть финансовыми данными.

PIM — товарным контентом.

WMS — складом.

CRM — клиентом.

Orchestrator должен знать не всё содержимое этих систем.

Он должен знать:

что должно происходить, когда их состояние меняется.

Конечно нет.

Если инфраструктура выглядит так:

1С + сайт + один маркетплейс

скорее всего, отдельный слой оркестрации только усложнит систему.

Обычной интеграции вполне достаточно.

Но затем появляются:

ERP, PIM, WMS, CRM, Wildberries, Ozon, Яндекс Маркет, Собственный магазин, Розница, Несколько складов, Поставщики.

И количество API перестаёт быть основной проблемой.

Проблемой становится:

кто управляет общим состоянием всей этой конструкции?

Он заставляет мыслить парами:

1С ↔ Wildberries

1С ↔ Ozon

1С ↔ Яндекс Маркет

Но бизнес-процесс не существует парами.

Один заказ может одновременно затронуть:

Поэтому правильный вопрос постепенно меняется.

Не:

Как интегрировать 1С с Ozon?

А:

Что должно произойти во всей торговой системе после того, как на Ozon появился заказ?

Вот это, на мой взгляд, и есть наиболее полезное объяснение Commerce Orchestration.

Допустим, мы создали идеальную оркестрацию.

И тут:

ERP: Цена = 4 990 ₽

PIM сообщает одно.

Pricing Service — другое.

А маркетплейс показывает:

Цена = 4 490 ₽

Кто прав?

То же самое с остатками:

WMS 9

ERP 9

Wildberries 9

Ozon 10

Если разные системы имеют разные версии реальности, никакой хороший workflow сам по себе не скажет, какое состояние нужно восстанавливать.

Для этого сначала нужно определить:

кто вообще владеет каждым типом данных.

Поэтому третья часть будет про Source of Truth:

И почему двусторонняя синхронизация без чётких правил иногда не исправляет ошибки, а автоматически размножает их по всей системе.

Интересно, как это устроено в реальных компаниях.

Если у вас одновременно есть 1С/ERP, склад, несколько маркетплейсов и интернет-магазин:

кто определяет, что должно произойти после нового заказа?

Это один центральный процесс — или логика распределена между 1С, cron, интеграциями и кабинетами площадок?