Salesforce B2B Commerce: как определить архитектуру витрины до интеграции

Компания заказывает новый расчёт доставки для Salesforce B2B Commerce, но исполнитель оценивает работу по опыту другой витрины. После старта выясняется: компоненты корзины, навигация и механизм оформления заказа здесь другие. Чтобы не покупать интеграцию для чужой архитектуры, сначала подтвердите продукт, среду выполнения витрины и действующие точки расширения. Ниже — диагностика, результатом которой должен стать проверенный паспорт конкретного магазина.

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

1. Определите продукт, а не название в презентации

Надпись Salesforce или Commerce Cloud не описывает техническую основу. У Salesforce есть разные Commerce-решения, в том числе B2B и B2C; общий брендинг не делает их модели разработки взаимозаменяемыми. Попросите администратора сверить приобретённые продукты с фактически настроенным магазином, а не угадывать по типу покупателя.

Отдельный сайт может передавать контакты и заказы в Salesforce CRM, но иметь корзину и каталог на другой платформе. Это интеграция с CRM, а не доказательство использования Salesforce B2B Commerce. Продажа дилерам тоже не определяет продукт: бизнес-модель B2B и название программного решения — разные вещи. В паспорте запишите, где создаётся корзина, кто рассчитывает сумму и какая система принимает заказ.

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

2. Установите runtime витрины по конфигурации

Runtime — это среда, в которой работает интерфейс магазина. Для B2B-витрин Salesforce документирует шаблоны на Lightning Web Runtime (LWR) и Aura. Для новых магазинов рекомендуется B2B LWR. Если организацию подключили к Commerce до Spring ’23, в ней также может быть доступен B2B-шаблон Aura. Это условие доступности шаблона, а не способ определить runtime конкретного сайта по его возрасту.

Шаблон и компоненты проверяют вместе

Пусть администратор покажет шаблон именно нужного магазина в средствах управления сайтом, а разработчик — соответствующий проект и компоненты. LWC означает Lightning Web Components, то есть модель компонентов интерфейса; LWR — среда их выполнения. Наличие LWC в репозитории само по себе не доказывает LWR: в миграционном сценарии Salesforce описывает и повторное использование дочерних LWC из Aura-витрины.

Скриншот, домен или скорость загрузки — слабые доказательства. Для каждого магазина отдельно зафиксируйте дату проверки, шаблон, источник подтверждения и ответственного.

Отдельному интерфейсу нужен второй паспорт

Если покупатель работает с отдельным frontend, установите, какой Commerce-backend стоит за ним, где развёрнут интерфейс и как он получает данные. Headless описывает разделение интерфейса и торговой системы, а не название продукта или гарантию совместимости. Проверьте обе части и промежуточный сервер, если он есть. Для контекста уместен материал о целесообразности headless-архитектуры магазина; здесь задача уже — идентифицировать установленное решение.

3. Составьте таблицу доказательств и последствий

Паспорт архитектуры витрины связывает доказательства с решением для интеграции. Формулировка «у нас Lightning» не объясняет, какой код запускает расчёт. Таблица — форма приёмки диагностики, а не автоматический определитель платформы.

Для каждой строки добавьте статус «подтверждено», «гипотеза» или «не установлено» и ссылку на доказательство. Если неизвестны runtime или механизм checkout, следующий этап — исследование, а не фиксированная оценка коннектора.

4. Найдите место расчёта до выбора коннектора

В документации Salesforce механизмы интеграции checkout для B2B LWR отличаются от checkout subflows Aura. Кроме того, Salesforce рекомендует Commerce extensions для более адресных изменений вместо более старого checkout integrations framework, который по-прежнему поддерживается. Это не команда немедленно переписать рабочий магазин: сначала установите, что в нём используется и какие требования у нового сервиса.

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

Опишите контракт обмена: идентификаторы товаров, единицы измерения, валюту, адрес, контекст компании и версию запроса. Определите источник каждого значения. Если ERP и Commerce по-разному понимают упаковку, изменение кнопки не исправит расчёт.

5. Не маскируйте миграцию Aura → LWR под интеграцию

Официальный план переноса B2B-магазина с Aura на LWR предусматривает новый магазин на соответствующем шаблоне, замену Aura-компонентов на LWC, перенос конфигурации и проверку перед публикацией. В частности, корзина меняется с record page на named page, поэтому ссылки и компоненты навигации требуют внимания. Это конкретная зависимость, которую легко упустить в оценке «только подключение доставки».

Salesforce также описывает отдельное пространство проекта для сохранения действующей Aura-витрины во время работы. Превратите это в свой план параллельной проверки: что остаётся доступным, где тестируют новый магазин, кто разрешает переключение. Сохранённая старая витрина ещё не означает готовый откат заказов: движение данных после переключения нужно спланировать отдельно.

Гипотетический пример: скидка есть, доставки нет

Условный дистрибьютор имеет Aura-витрину и собственный выбор склада в корзине. Команда одновременно переходит на LWR и подключает перевозчика. На новой странице сохранилась договорная цена, но кнопка «к корзине» ведёт старым маршрутом, а выбранный склад не попадает в запрос доставки. Это вымышленный учебный сценарий, не кейс GL.ua и не утверждение о стандартной ошибке платформы.

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

6. Проведите предпусковую проверку по одному маршруту

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

1. Сверьте паспорт с тестовой средой: продукт, шаблон, версии собственного кода и конфигурацию интеграции. Несопоставимые среды не доказывают готовность.
2. Войдите как покупатели разных компаний. Проверьте доступный каталог и цену, а затем соответствующий контекст в серверном расчёте; чужие условия не должны переходить между сессиями.
3. Пройдите путь товар → корзина → checkout. Измените количество, адрес и склад, если он предусмотрен. Убедитесь, что расчёт обновился для актуального набора данных.
4. Воспроизведите задержку, недоступность и некорректный ответ внешнего сервиса в контролируемой среде. Сверьте сообщение покупателю, диагностику для поддержки и разрешённое дальнейшее действие.
5. Проверьте повторное нажатие и повторную отправку после сбоя. Подтвердите по журналам, что интеграция не создала дубль заказа и не выдала ошибочное подтверждение.
6. Пройдите маршрут на desktop и mobile, включая прямую ссылку в корзину и возвращение из checkout. Для миграции отдельно проверьте изменённые маршруты.
7. Сопоставьте итог заказа в Commerce и учётной системе, отрепетируйте переключение и процедуру остановки. Разрешение на запуск дайте только после закрытия критических отклонений.

Более широкий процесс описан в материале о приёмке и откате интернет-магазина. Здесь главное доказательство — связь теста с фактической архитектурой.

7. Оцените зависимости, стоимость и границы ответственности

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

В бюджете разделите обследование, прототип критического расчёта, изменения интерфейса, серверное расширение, сопоставление данных, тесты, переключение и поддержку. Отдельно проверьте лицензии, условия сторонних сервисов, среды и эксплуатационные расходы. Миграция Aura → LWR, если она нужна, имеет собственный объём; не прячьте его в стоимости коннектора. Универсальной цены или гарантированного срока без этих данных нет.

Основные риски — ошибочно определённый продукт, неполная инвентаризация кода, утечка контекста между компаниями и устаревшие данные расчёта. Для каждого назначьте владельца и критерий остановки. Без доступа к реализации и воспроизводимого тестового checkout добавление сервиса лишь увеличит неопределённость.

Результат диагностики — не требование переходить на другую платформу, а достаточное основание выбрать между локальной доработкой, отдельной миграцией витрины и более широким перепроектированием. Для обсуждения веб-архитектуры и возможной Drupal-ориентированной альтернативы передайте паспорт магазина и контрольный сценарий через страницу разработки сайтов GL.ua (Глянец). Это предметное начало консультации, а не обещание Salesforce-внедрения или автоматического переноса.