Salesforce B2B Commerce: jak ustalić architekturę witryny przed integracją

Firma zamawia nowy mechanizm obliczania kosztów dostawy dla Salesforce B2B Commerce, lecz wykonawca wycenia prace na podstawie doświadczeń z inną witryną sklepową. Po rozpoczęciu okazuje się, że komponenty koszyka, nawigacja i mechanizm składania zamówienia są tu inne. Aby nie kupować integracji dla cudzej architektury, najpierw potwierdź produkt, środowisko uruchomieniowe witryny oraz istniejące punkty rozszerzeń. Poniższa diagnostyka powinna zakończyć się zweryfikowaną kartą architektury konkretnego sklepu.

Poradnik dla kierownika e-commerce i technicznego właściciela działającego sklepu: jak przekazać wykonawcy prawidłowe dane i oddzielić podłączenie usługi od przebudowy witryny.

1. Ustal produkt, a nie nazwę z prezentacji

Napis Salesforce lub Commerce Cloud nie opisuje podstawy technicznej. Salesforce ma różne rozwiązania Commerce, w tym B2B i B2C; wspólny branding nie sprawia, że ich modele programowania są wymienne. Poproś administratora o porównanie zakupionych produktów z faktycznie skonfigurowanym sklepem zamiast zgadywania na podstawie rodzaju kupującego.

Osobny serwis może przekazywać kontakty i zamówienia do Salesforce CRM, a koszyk i katalog utrzymywać na innej platformie. To integracja z CRM, nie dowód korzystania z Salesforce B2B Commerce. Również sprzedaż dealerom nie określa produktu: model biznesowy B2B i nazwa oprogramowania to różne rzeczy. Zapisz w karcie, gdzie powstaje koszyk, kto oblicza sumę i który system przyjmuje zamówienie.

Zbierz nazwę organizacji Salesforce, identyfikator sklepu, adresy środowisk, potwierdzenie produktu i odnośnik do repozytorium. Nie dołączaj haseł, tokenów ani danych kupujących. Rozbieżności między dokumentami a konfiguracją pozostaw otwarte do wspólnej weryfikacji.

2. Ustal runtime witryny na podstawie konfiguracji

Runtime to środowisko, w którym działa interfejs sklepu. Dla witryn B2B Salesforce dokumentuje szablony Lightning Web Runtime (LWR) i Aura. Dla nowych sklepów zaleca B2B LWR. Jeśli organizację włączono do Commerce przed Spring ’23, może być w niej dostępny również szablon B2B Aura. To warunek dostępności szablonu, a nie sposób ustalania runtime konkretnej witryny na podstawie jej wieku.

Szablon i komponenty sprawdzaj łącznie

Niech administrator pokaże szablon właściwego sklepu w narzędziach zarządzania witryną, a programista — odpowiedni projekt i komponenty. LWC oznacza Lightning Web Components, czyli model komponentów interfejsu; LWR to środowisko ich uruchamiania. Obecność LWC w repozytorium sama w sobie nie dowodzi LWR: scenariusz migracji Salesforce opisuje także ponowne wykorzystanie podrzędnych LWC z witryny Aura.

Zrzut ekranu, domena czy szybkość ładowania to słabe dowody. Dla każdego sklepu osobno zapisz datę weryfikacji, szablon, źródło potwierdzenia i osobę odpowiedzialną.

Oddzielny interfejs wymaga drugiej karty architektury

Jeżeli kupujący korzysta z osobnego frontendu, ustal, jaki backend Commerce za nim stoi, gdzie wdrożono interfejs i jak pobiera on dane. Headless opisuje rozdzielenie interfejsu i systemu handlowego, nie nazwę produktu ani gwarancję zgodności. Sprawdź obie części oraz serwer pośredniczący, jeśli występuje. Kontekst uzupełnia artykuł o zasadności architektury headless w sklepie; tutaj zadanie jest węższe — identyfikacja już zainstalowanego rozwiązania.

3. Przygotuj tabelę dowodów i konsekwencji

Karta architektury witryny łączy dowody z decyzją dotyczącą integracji. Stwierdzenie „mamy Lightning” nie wyjaśnia, jaki kod uruchamia obliczenia. Tabela jest formularzem odbioru diagnostyki, a nie automatycznym narzędziem rozpoznawania platformy.

Do każdego wiersza dodaj status „potwierdzone”, „hipoteza” lub „nieustalone” oraz odnośnik do dowodu. Jeśli runtime lub mechanizm checkoutu są nieznane, kolejnym etapem jest analiza, nie stała wycena konektora.

4. Znajdź miejsce obliczeń przed wyborem konektora

W dokumentacji Salesforce mechanizmy integracji checkoutu dla B2B LWR różnią się od checkout subflows Aura. Salesforce zaleca też Commerce extensions do bardziej ukierunkowanych zmian zamiast starszego checkout integrations framework, który nadal jest wspierany. Nie jest to nakaz natychmiastowego przepisania działającego sklepu: najpierw ustal, z czego korzysta i jakie wymagania ma nowa usługa.

Rozrysuj jedno żądanie: działanie kupującego → komponent witryny → obliczenie po stronie serwera → usługa zewnętrzna → wynik w koszyku. Przy każdej strzałce zapisz właściciela, przekazywane dane i zachowanie przy błędzie. Ustal, czy dostawa jest przeliczana po zmianie adresu, kiedy wynik traci aktualność i czy spóźniona odpowiedź może nadpisać nowszy wybór. To pytania do weryfikacji własnej implementacji, a nie uniwersalne cechy Salesforce.

Opisz kontrakt wymiany: identyfikatory produktów, jednostki miary, walutę, adres, kontekst firmy i wersję żądania. Ustal źródło każdej wartości. Jeśli ERP i Commerce inaczej rozumieją opakowanie, zmiana przycisku nie poprawi obliczeń.

5. Nie przedstawiaj migracji Aura → LWR jako integracji

Oficjalny plan przeniesienia sklepu B2B z Aura do LWR przewiduje nowy sklep na odpowiednim szablonie, zastąpienie komponentów Aura przez LWC, przeniesienie konfiguracji i weryfikację przed publikacją. W szczególności koszyk zmienia się z record page na named page, dlatego linki i komponenty nawigacyjne wymagają uwagi. To konkretna zależność, którą łatwo pominąć w wycenie „samego podłączenia dostawy”.

Salesforce opisuje też osobną przestrzeń projektu, która pozwala zachować działającą witrynę Aura podczas prac. Przełóż to na własny plan równoległej weryfikacji: co pozostaje dostępne, gdzie testowany jest nowy sklep i kto zezwala na przełączenie. Zachowanie starej witryny nie oznacza jeszcze gotowej procedury wycofania zmian w zamówieniach: przepływ danych po przełączeniu trzeba zaplanować osobno.

Hipotetyczny przykład: rabat działa, dostawa nie

Przykładowy dystrybutor ma witrynę Aura i własny wybór magazynu w koszyku. Zespół jednocześnie przechodzi na LWR i podłącza przewoźnika. Na nowej stronie zachowano cenę umowną, ale przycisk „do koszyka” prowadzi starą trasą, a wybrany magazyn nie trafia do żądania dostawy. To fikcyjny scenariusz szkoleniowy, nie realizacja GL.ua ani twierdzenie o standardowym błędzie platformy.

Najpierw sprawdza się nawigację i przekazanie magazynu, następnie odpowiedź przewoźnika oraz jej wyświetlanie. Adres, magazyn, produkty i kontekst kupującego muszą odpowiadać temu samemu żądaniu. Poprawna cena nie dowodzi poprawności pozostałej części checkoutu.

6. Przeprowadź test przed uruchomieniem na jednej ścieżce

Test integracji przed uruchomieniem musi odtwarzać ustalony produkt i runtime, a nie sklep demonstracyjny wykonawcy. Przygotuj firmy testowe z różnymi uprawnieniami i kontrolny zestaw produktów bez prawdziwych danych osobowych. W protokole każdego testu zapisz wynik oczekiwany, wynik rzeczywisty i osobę odpowiedzialną za usunięcie rozbieżności.

1. Porównaj kartę architektury ze środowiskiem testowym: produkt, szablon, wersje własnego kodu i konfigurację integracji. Nieporównywalne środowiska nie dowodzą gotowości.
2. Zaloguj się jako kupujący z różnych firm. Sprawdź dostępny katalog i cenę, a następnie odpowiedni kontekst w obliczeniach serwera; warunki innej firmy nie mogą przenikać między sesjami.
3. Przejdź ścieżkę produkt → koszyk → checkout. Zmień ilość, adres i magazyn, jeśli jest przewidziany. Potwierdź aktualizację obliczeń dla bieżącego zestawu danych.
4. W kontrolowanym środowisku odtwórz opóźnienie, niedostępność i błędną odpowiedź usługi zewnętrznej. Sprawdź komunikat dla kupującego, diagnostykę dla wsparcia i dozwolone dalsze działanie.
5. Sprawdź ponowne kliknięcie i powtórne wysłanie po awarii. Potwierdź w dziennikach, że integracja nie utworzyła duplikatu zamówienia ani nie wydała błędnego potwierdzenia.
6. Przejdź ścieżkę na komputerze i urządzeniu mobilnym, w tym bezpośredni link do koszyka i powrót z checkoutu. Przy migracji osobno sprawdź zmienione trasy.
7. Porównaj podsumowanie zamówienia w Commerce i systemie ewidencyjnym, przećwicz przełączenie i procedurę zatrzymania. Zezwól na uruchomienie dopiero po usunięciu krytycznych rozbieżności.

Szerszy proces opisuje materiał o odbiorze i wycofywaniu zmian w sklepie internetowym. Tutaj kluczowym dowodem jest powiązanie testu z faktyczną architekturą.

7. Oceń zależności, koszty i zakresy odpowiedzialności

Termin zależy od dostępu do konfiguracji i kodu, gotowości środowiska testowego, dokumentacji usługi, własnych komponentów i potrzeby migracji runtime. Do zakończenia diagnostyki wyceniaj etapy z wyraźnie wskazanymi niewiadomymi. Harmonogram uruchomienia uzgodnij po sprawdzeniu najbardziej ryzykownego scenariusza.

W budżecie oddziel analizę, prototyp krytycznego obliczenia, zmiany interfejsu, rozszerzenie serwerowe, mapowanie danych, testy, przełączenie i wsparcie. Osobno sprawdź licencje, warunki usług zewnętrznych, środowiska i koszty eksploatacji. Migracja Aura → LWR, jeśli jest potrzebna, ma własny zakres; nie ukrywaj go w cenie konektora. Bez tych danych nie ma uniwersalnej ceny ani gwarantowanego terminu.

Główne ryzyka to błędne rozpoznanie produktu, niepełna inwentaryzacja kodu, wyciek kontekstu między firmami i nieaktualne dane obliczeń. Każdemu przypisz właściciela i kryterium zatrzymania. Bez dostępu do implementacji i odtwarzalnego testowego checkoutu dodanie usługi tylko zwiększy niepewność.

Wynik diagnostyki nie nakazuje zmiany platformy, lecz daje wystarczającą podstawę do wyboru między lokalną modyfikacją, osobną migracją witryny a szerszym przeprojektowaniem. Aby omówić architekturę serwisu i ewentualną alternatywę opartą na Drupalu, przekaż kartę sklepu oraz scenariusz kontrolny przez stronę tworzenia stron GL.ua (Glyanec). To konkretny początek konsultacji, nie obietnica wdrożenia Salesforce ani automatycznej migracji.