Сайт и ERP живут в разных темпах, и именно поэтому их нельзя просто «связать API»

Пользователь выбирает товар, услугу или конфигурацию.

ERP может требовать:

организацию;

вид операции;

договор;

склад;

тип цены;

налоговую схему;

аналитические разрезы.

Эти детали не должны просачиваться в web-модель.

AMPE ставит между ними контракт, который переводит пользовательское действие в бизнес-операцию ERP.

Это нормально.

Пользовательский путь не обязан ждать завершения всех back-office проверок.

Важно честно разделить состояния:

request accepted;

validation;

processing;

confirmed;

rejected;

requires clarification.

Так интерфейс остаётся быстрым, а бизнес не обещает то, чего ещё не подтвердил.

Если прайс простой и меняется раз в сутки, нет смысла дёргать ERP при каждом просмотре карточки.

Если цена зависит от клиента, договора, объёма и текущих условий, нужна другая модель.

AMPE разделяет:

публичную цену;

персональную цену;

расчётную цену;

подтверждённую цену заказа.

Именно это предотвращает конфликт «на сайте было одно, в ERP получилось другое».

ERP хранит номенклатуру так, как удобно учёту и операциям.

Сайт — так, как удобно выбирать пользователю.

Одна учетная позиция может входить в несколько web-категорий.

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

Поэтому интеграция каталога часто требует отдельной publish-модели, а не прямого копирования справочника.

Номер во frontend.

Внутренний ID интеграции.

Документ ERP.

Это могут быть разные идентификаторы.

Но между ними должна существовать стабильная связь.

Иначе любое повторное сообщение, ручная сверка или возврат быстро превращаются в поиск «какой заказ чему соответствует».

ERP → сайт:

каталог;

цены;

доступность;

персональные условия;

документы;

финансовые статусы;

история заказов.

Сайт → ERP:

заказы;

заявки;

данные клиента;

условия доставки;

выбранные услуги;

подтверждения оплаты;

возвраты или запросы на изменение.

ERP → сайт после исполнения:

подтверждение;

изменение срока;

отгрузка;

закрывающие документы;

финальный статус.

Пользователь хочет узнать персональную цену — возможно, да.

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

Запрашивает историю — данные можно подготовить заранее.

Открывает карточку товара — лучше использовать кэшированный read model.

AMPE проектирует latency по пользовательскому сценарию, а не по одному универсальному стилю интеграции.

Каталог можно продолжить показывать.

Заявку — принять в очередь.

Часть операций — временно ограничить.

Пользователю — показать честное промежуточное состояние.

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

Rate limiting.

Validation.

Authentication.

API gateway.

Integration service.

Очереди.

Кэш.

Эти механизмы нужны не ради архитектурной моды.

Они защищают внутреннюю систему от внешнего профиля нагрузки и позволяют отдельно масштабировать web-слой.

ERP уже могла:

зарезервировать ресурс;

создать закупку;

запустить производство;

выставить документ.

Поэтому сайт должен понимать, какие изменения ещё свободны, какие требуют пересогласования, а какие уже невозможны без отдельного процесса отмены или корректировки.

Пользователь работает с простой web-моделью.

Integration layer переводит её в бизнес-контракт.

ERP применяет внутреннюю логику.

Подтверждённые факты возвращаются наружу.

Для чтения создаются быстрые представления там, где прямой online-доступ к ERP не нужен.

Так сайт остаётся быстрым, а ERP — целостной.

Сайт меньше зависит от внутренней структуры ERP.

ERP не обслуживает каждый page view.

Цена и доступность становятся осмысленнее.

Заказы получают устойчивую сквозную идентичность.

Промежуточные состояния не маскируются под окончательный успех.

Публичный канал лучше переживает частичную недоступность back-office.

И главное — внешний цифровой опыт начинает соответствовать реальной способности компании исполнить обещание.