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-впровадження чи автоматичного перенесення.