Architektura e-commerce w branży wyrobów metalowych

W e-commerce B2B cena rzadko jest taka sama dla wszystkich, a ścieżka zakupowa nie musi zaczynać się od koszyka. W globalnej firmie z branży wyrobów metalowych ceny zależą od klienta, wynegocjowanych warunków i wielkości zamówienia. Handlowcy muszą przygotowywać oferty w terenie, a klienci na całym świecie oczekują szybkiego dostępu do informacji o produktach i stanach magazynowych.

Globalna platforma B2B musi pogodzić procesy dostosowane do poszczególnych klientów z ERP, który pozostaje źródłem prawdy. Opisana architektura obejmuje tożsamość i role firmowe, wycenę na żądanie, oferty przygotowywane przez handlowców, dostęp offline z tabletów i regionalne modele odczytu na Azure. Dowiedz się, jak zapewnić szybki dostęp regionalny, zachowując spójność zamówień i cen z ERP.

Kontekst

Klient jest hurtownikiem i producentem wyrobów metalowych sprzedającym firmom na całym świecie. Jedynym istniejącym systemem jest ERP połączony z magazynem; to w nim znajdują się produkty, cenniki, klienci, limity kredytowe, stany magazynowe i zamówienia. Ceny nie są publiczne: katalog można przeglądać po zalogowaniu, a cena zależy od firmy, jej grupy cenowej, wolumenu i negocjacji. W systemie działają trzy role: przedstawiciel handlowy przygotowujący oferty dla klientów na tablecie, także w terenie bez połączenia; firma B2B z wieloma użytkownikami i wewnętrznym podziałem na kupujących i zatwierdzających; oraz menedżer e-commerce zarządzający katalogiem i widocznością. Klienci logują się przez SSO, najczęściej własnym kontem firmowym. Globalna sprzedaż wymaga szybkiego odczytu katalogu, cen i stanów magazynowych w każdym regionie, mimo że jeden ERP działa w jednym miejscu.

Całość działa na Azure. W przeciwieństwie do branży modowej, gdzie architekturę kształtowały skala i obsługa wielu rynków, tutaj dominują trzy wyzwania:

• ceny indywidualne dla klientów, obliczane na żądanie, których nie można buforować z wyprzedzeniem jak cennika dla całego rynku;
• ERP jako jedyne źródło prawdy, wolny i pojedynczy, wobec globalnych klientów oczekujących odpowiedzi w milisekundach;
• proces sprzedaży prowadzony przez człowieka (oferta handlowca, zatwierdzenie, odroczona płatność) zamiast samoobsługowego koszyka i płatności online.

Platforma B2B: kontekst systemu

Platforma B2B jako jeden system na Azure. Klienci i pracownicy hurtowni logują się przez Microsoft Entra, a ERP z magazynem pozostaje źródłem prawdy o produktach, cenach, stanach magazynowych, limitach kredytowych i zamówieniach.

Rysunek 1. Diagram C1 - Kontekst systemu: platforma B2B

Tożsamość, organizacje i role

Tożsamość obsługuje Microsoft Entra w trzech wariantach: Entra ID dla pracowników hurtowni (handlowcy, menedżer e-commerce), z Conditional Access wymuszającym MFA i zgodne z zasadami urządzenie zarządzane przez Intune; Entra B2B collaboration dla dużych klientów logujących się własnym kontem firmowym przez federację, z MFA i odbieraniem dostępu odchodzącym pracownikom po ich stronie; Entra External ID dla małych firm bez własnego IdP, z samodzielną rejestracją i weryfikacją przez menedżera e-commerce. BFF weryfikuje tokeny od trzech wystawców i mapuje atrybut tenant/oid na organizację w silniku commerce, gdzie znajduje się właściwy model B2B: firma, jej użytkownicy, role kupującego i zatwierdzającego, grupa cenowa, limit kredytowy. Handlowiec nie ma osobnej tożsamości klienta; loguje się własnym kontem, a BFF wystawia sesję „w imieniu firmy X” z pełnym audytem tego, kto co złożył i dla kogo.

Tożsamość i role B2B: struktura

Trzech wystawców tokenów Microsoft Entra: Entra ID dla pracowników hurtowni, Entra B2B collaboration dla dużych klientów logujących się przez federację z własnym IdP oraz Entra External ID dla mniejszych firm. BFF weryfikuje wszystkie trzy i mapuje tid/oid na Organization, natomiast model B2B (organizacje, użytkownicy, role) znajduje się w silniku commerce.

Rysunek 2. Diagram: struktura tożsamości i ról B2B

Handlowiec działający w imieniu firmy

Handlowiec loguje się do Entra ID, a po sprawdzeniu przypisania do firmy BFF wystawia sesję z dwiema tożsamościami: actor = handlowiec, subject = firma.

Rysunek 3. Diagram: handlowiec działający w imieniu firmy, sekwencja act-as

Ceny i oferty

Cena jest obliczana na żądanie przez silnik cenowy na podstawie cennika bazowego w ERP, grupy cenowej firmy, progów ilościowych i wynegocjowanych rabatów; wynik jest buforowany w Azure Cache for Redis osobno dla firmy i produktu, z krótkim TTL, i unieważniany przez zdarzenie zmiany cennika z ERP. Użytkownik anonimowy nie widzi cen ani dostępności. Zamiast koszyka i checkoutu centralnym procesem jest oferta: handlowiec lub kupujący tworzy ofertę z pozycjami w jednostkach hurtowych (kg, metry bieżące, sztuki, palety, z minimalnymi ilościami), handlowiec może obniżyć cenę w ramach swojego limitu rabatowego, powyżej progu oferta trafia do menedżera do zatwierdzenia, a klient akceptuje ofertę, która staje się zamówieniem. Płatność jest odroczona: silnik commerce sprawdza limit kredytowy w ERP przy akceptacji, a fakturowanie i rozliczenie odbywają się w ERP. Przed akceptacją zamówienia eksportowego system uruchamia weryfikację sankcji i kontrolę eksportu, ponieważ wyroby metalowe mogą podlegać ograniczeniom dotyczącym podwójnego zastosowania.

Integracja z ERP i regionalne modele odczytu

ERP nie może być odpytywany synchronicznie przy każdej wizycie klienta: jest pojedynczy, wolny i stanowi pojedynczy punkt awarii. Architektura stosuje CQRS: ścieżka zapisu (zamówienie, akceptacja oferty, sprawdzenie limitu) prowadzi do ERP przez warstwę antykorupcyjną i outbox na Azure Service Bus, a ścieżkę odczytu obsługują modele odczytu replikowane do regionów. Zmiany w ERP (produkt, cena bazowa, stan magazynowy, limit) są publikowane jako zdarzenia w temacie Service Bus, a konsumenci budują widoki tylko do odczytu w Azure Cosmos DB, z zapisem w regionie ERP (West Europe) i odczytem w regionach klientów (East US, Southeast Asia). Indeks wyszukiwania według parametrów technicznych (gatunek, wymiar, norma, tolerancja) jest utrzymywany w Azure AI Search w każdym regionie. Azure Front Door kieruje użytkownika do najbliższego regionu, gdzie działają storefront, BFF, Redis i modele odczytu, natomiast silnik commerce z bazą PostgreSQL i silnik cenowy działają w regionie ERP, ponieważ potrzebują spójnych zapisów transakcyjnych; Cosmos DB nie przechowuje ofert ani zamówień. Klient widzi stany magazynowe sprzed kilku sekund, a ostateczna weryfikacja stanów i limitu odbywa się przy akceptacji oferty w regionie zapisu.

Platforma B2B: kontenery na Azure

Region zapisu (West Europe) z pełnym zestawem usług, transakcyjną bazą PostgreSQL, Service Bus i adapterem ERP przez Private Link oraz regiony odczytu (×N) z własnym storefrontem, BFF i lokalnymi modelami odczytu. Zapisy zawsze trafiają do regionu zapisu, a zdarzenia z Service Bus budują projekcje w Cosmos DB i AI Search replikowane do regionów odczytu.

Rysunek 4. Diagram C2 - Kontenery: platforma B2B na Azure

Aplikacja na tablet dla handlowca

Handlowiec pracuje w magazynie, na targach i u klienta, często bez połączenia, dlatego aplikacja jest offline-first: lokalna baza SQLite przechowuje katalog, cennik firmy, do której przypisany jest handlowiec, oraz robocze oferty, a synchronizacja z BFF odbywa się po odzyskaniu połączenia, z rozwiązywaniem konfliktów na poziomie oferty. Logowanie przez MSAL z brokerem Microsoft Authenticator zapewnia SSO z innymi aplikacjami firmowymi, a Intune wymusza szyfrowanie urządzenia i PIN oraz pozwala zdalnie usunąć dane cenowe po zgubieniu tabletu. BFF udostępnia osobny kontrakt dla tabletu: pakiet danych offline (pełny cennik firmy, katalog z parametrami) zamiast lekkich odpowiedzi dla pojedynczych ekranów stosowanych w branży modowej. Aplikacja jest zbudowana w React Native i współdzieli warstwę UI ze storefrontem.

Komponenty Azure

• Azure Front Door + WAF: globalny brzeg sieci, routing do najbliższego regionu, buforowanie zasobów statycznych
• Azure Kubernetes Service w każdym regionie: storefront, BFF; w regionie zapisu dodatkowo silnik commerce, silnik cenowy i procesy budujące projekcje
• Azure Database for PostgreSQL Flexible Server: transakcyjna baza silnika commerce, region zapisu
• Azure Cache for Redis w każdym regionie: pamięć podręczna cen dla poszczególnych firm, sesje, odpowiedzi BFF
• Azure Cosmos DB: wyłącznie modele odczytu, projekcje ze zdarzeń; odczyt w wielu regionach, zapis w jednym; bez danych transakcyjnych
• Azure AI Search w każdym regionie: wyszukiwanie według parametrów technicznych
• Azure Service Bus: tematy i subskrypcje dla zdarzeń ERP oraz outbox zamówień
• Adapter ERP i projekcje modeli odczytu: procesy robocze na AKS w regionie zapisu
• Private Link / ExpressRoute: prywatne połączenie sieciowe z ERP
• Microsoft Entra ID, B2B collaboration, External ID: tożsamość pracowników i klientów
• Intune: zarządzanie urządzeniami mobilnymi (MDM) dla tabletów
• Azure Key Vault + Managed Identity: sekrety bez kluczy w kodzie
• Azure Blob Storage z zasadą niezmienności: certyfikaty materiałowe, faktury, dokumenty ofertowe
• Azure Monitor + Application Insights: telemetria OTel

Platforma B2B: wdrożenie na Azure

Fizyczny widok kontenerów C2. W regionie zapisu (West Europe) działa pełny klaster AKS z usługami PaaS dostępnymi wyłącznie przez prywatne punkty końcowe w VNet; regiony odczytu (×N) mają tylko storefront, BFF, Redis oraz repliki Cosmos DB i AI Search. Front Door kieruje ruch do najbliższego regionu, zapisy zawsze trafiają do West Europe, a ERP łączy się przez ExpressRoute lub VPN z Private Link.

Rysunek 5. Diagram: wdrożenie platformy B2B na Azure

Podsumowanie

Globalna platforma e-commerce B2B musi obsługiwać indywidualne ceny, oferty przygotowywane przez handlowców i szybki dostęp do informacji o produktach oraz stanach magazynowych w różnych regionach. Architektura zachowuje ERP jako źródło prawdy, wykorzystując regionalne modele odczytu i narzędzia offline do obsługi klientów i handlowców na całym świecie.