Elektroniczne kanały sprzedaży¶

Powiązane artykuły¶

Wstęp¶

Niniejsza dokumentacja opisuje genezę, założenia, architekturę, rozwiązania, oraz wzorce na standardowe wyzwania realizowane podczas procesu tworzenia integracji z elektronicznymi kanałami sprzedaży (platformami sprzedażowymi), jak ich wdrażania w instancjach poszczególnych klientów.

Geneza¶

Dzisiaj każda firma dystrybucyjna, handlowa realizuje swoje procesy obsługi klienta za pomocą elektronicznych kanałów sprzedaży. W Sente już wielokrotnie realizowaliśmy integrację systemu Teneum z takimi systemami sprzedaży. Zazwyczaj za pomocą EDE, budowaliśmy dedykowane mechanizmy do importu zamówień, eksportu statusów, dokumentów, eksportu towarów, cenników, dostępności towarów. Za każdym razem wykorzystywana była inna technologia integracyjna (jak. np. integracja z PrestaShop). W trakcie tych integracji powstało kilka różnych podejść do kwestii technicznej, jak taką integrację realizować. Każda miałą swoje zalety, ale również wady. Na pewno fakt, żę każda integracja byłą inna, generował wiele wyzwań wdrożeniowych. Nie było też takich rozwiązań integracyjnych w ramach standardu systemu Teneum.

Stąd potrzeba przygotowania jednego modułu integracyjnego, jednej architektury, która by zebrała doświadczenia z wcześniejszych integracji, i aby powstało rozwiązanie, które pozwoli za pomocą analogii budować kolejne mechanizmy integracyjne z kolejnymi platformami, oraz na etapie wdrożenia pozwoli w podobny sposób dostosowywać te integracje do szczegółowych wymagań danego klienta.

Założenia¶

Na bazie powyższego powstał moduł Elektronicznych Kanałów Sprzedaży w obszarze HiD (Handel i Dystrybucja). Moduł był projektowany przy następujących założeniach:

Moduł powinien obsługiwać w podobny, analogiczny sposób dowolną platformę sprzedażową (technologicznie). Każda kolejna platforma (albo jej wersja API) powinna być łatwo “podłączana” do modułu, poprzez implementację jedynie warstwy “tłumaczenia” pomiędzy strukturami danego API a strukturami modułu EKS, bez implementacji JAKIEJKOLWIEK logiki biznesowej wewnętrznej HiD’a.
Moduł powinien posiadać swego rodzaju API, warstwę abstrakcji, udostępniającą uniwersalne struktury i metody do importu/eksportu danych z modułu,aby każda platforma (integracja z każdą platformą, owa “warstwa tłumaczenia”) mogła skorzystać z gotowego zestawu narzędzi komunikacyjnych z HID.
Procedury integracyjne (import zamówienia, eksport towaru, eksport statusu), jeśli realizują tą samą logikę biznesową, powinny być jedne dla kilku kanałów sprzedaży, nawet jeśli komunikacja się odbywa z kilkoma różnymi platformami i (jeden proces - jeden kod)
Administrator po stronie klienta powinien mieć możliwość SAMODZIELNEGO monitorowania, kontroli, i reagowania (udrażniania) procesów przepływu danych pomiędzy HID a platformą sprzedaży.
Integracja powinna być odporna na tymczasową niedostępność systemu lub błędy przetwarzania komunikatów.
Ponowne przetworzenie komunikatów w których wystąpiły błędy przetwarzania (np. deadlocki, błędy logiczne) nie powinno generować koniecznośći powtórzenia transmisji z platforma sprzedaży (lokalne cache komunikatów).
Możliwa do implementacji komunikacja dwustronna (chociaż trudna i nie zalecana) w obrębie zamówień
Z punktu widzenia administratora (nie programisty)

a. jasny klarowny status danego zamówienia, z informacją o rodzaju błędu jaki wystąpił podczas jego synchronizacji

b. możliwość ręcznego ponowienia danego procesu (importu/eksportu zamówienia, eksportu towaru itd), z możliwością poprawienia treści komunikatu zarówno na poziomie komunikatu biznesowego, jak i komunikatu WebAPI do platformy.

c. automatyczne powiadomienia monitorujące zgodność danych pomiędzy danymi HiD a platformą sprzedażową.
Z punktu widzenia wdrożeniowca

a. klarowny sposób modyfikowania procedur importu/eksportu danych tak, aby w miarę możliwości modyfikować określony fragment kodu, a nie całość procesu standardowego.

b. możliwość dowolnego przeciążenia standardowych metod i napisania własnych, na podstawie standardowych, i aby upgrade tego nie rozwalał.

c. możliwość realizacji własnej integracji z nową platformą sprzedażową.

d. możliwość dowolnej adaptacji warstwy “tłumaczenia” pomiędzy EKS a platformą sprzedaży

e. możliwość przekazania w EKS API dodatkowych danych, których standard tego API nie przewidział, a które u danego klienta są konieczne do przekazania pomiędzy adapterem a EKS.

f. szybka diagnoza co poszło nie tak w wymianie danych, jaka jest przyczyna błędu. Podgląd w dane które podlegają wymianie. Możliwość powtórzenia komunikatu z ręczną modyfikacją danych.

Główne pojęcia¶

ELEKTRONICZNY KANAŁ SPRZEDAŻY (skrót: kanał) - kanał sprzedaży z punktu widzenia biznesowego. To określona witryna, konto na marketplace, itp. W ramach kanału określamy

a. politykę cenową

b. zakres dostępnych towarów

c. dostępność towarów

d. słowniki tłumaczeń

e. reguły stosowania zamówień w kanale w zależności od postaci zamówienia w HID

f. zestaw procedur importu/eksportu pomiędzy HiD a strukturami uniwersalnymi EKS z których korzysta adapter

g. częstotliwości automatycznej synchronizacji danych

Główny obiekt biznesowy modułu to ECOMCHANNELS - tabela kanałów sprzedaży, w którym też są wszystkie ważniejsze funkcje logiki biznesowej tego modułu.

Uwaga: Kanał sprzedaży to nie to samo co platforma sprzedaży, czy konto w platformie. Możemy mieć jedno konto, a w ramach niego np. 3-4 sklepy, do tego Allegro, Amazon itd. Domyślna konfiguracja jest taka, że wtedy mamy tyle kanałów co witryn/marketplace’ów. To nam zapewnia elastyczność. Oczywiście, można też zrobić konfigurację 1:1 - jeden kanał do całości platformy, a towary.cenniki/dostępności w kanałach już zarządzać po stronie platformy. To już decyzja projektowa w ramach wdrożenia.

ADAPTER - adapter zgodnie z filozofią EDA, czyli obiekt biznesowy, realizujący tłumaczenie struktur danych ( i nic więcej) pomiędzy fizycznym drajwerem komunikacyjnym (który jest zależny w 100% od API danej platformy sprzedaży), a interfejsem modułu EKS (struktury uniwersalne i metody, jakie służą do importu/exportu danych pomiędzy modułem EKS. Z jednej strony udostępnia metody EDA aby moduł EKS mógł wywoływać pewne procesy wymiany danych, z drugiej strony używa metod i struktur drajwera aby realizować fizyczną wymianę danych.

W ramach projektu powstał adapter wirtualny ECOMADAPTERCOMMON, implementacja adaptera dla konkretnej platformy sprzedażowej).

DRIVER - driver zgodnie z filozofią EDA, czyli fizyczna warstwa transportowa. W 99% to po prostu projekt c# typu biblioteka, podłączana dynamicznie do serwera Neosa (plugin), który za pomocą standardowego w VS generatora interfejsu do wskazanego WebAPI generuje struktury strong-type do danego WebAPI danej platformy (np. IAI, Magento, Baselinker). Wystarczy podać punkt dostępowy do API (instancja jakiegoś sklepu), i to zazwyczaj wystarcza VS do wygenerowania całego kodu projektu. Założenie - ZERO ręcznej modyfikacji. Potrzebujemy jedynie tych struktur i metod w postaci strong-type C# jakie udostępnia dane WebAPI. I te metody i struktury wykorzystujemy pisząc kod w ADAPTERZE.
KONEKTOR - konektor zgodnie z filozofią EDA, czyli określona konfiguracja danego adaptera. W konfiguracji konektora wskazujemy np. adres, login, hasło do API. Możemy jednym adapterem (klasą), jednym drajwerem obsługiwać kilka kont administracyjnych np. w IAI czy Baselinkerze. W ramach konfiguracji KANAŁU wskazujemy jakim KONEKTOREM odbywa się komunikacja danego KANAŁU. Domyślnie każdy KONEKTOR realizuje swoją komunikację w jednej kolejce fizycznej.
INTERFEJS EKS - struktury i metody modułu EKS, z których korzystają adaptery do realizacji procesów importu/eksportu danych. Takie wewnętrzne API. Metody są udostępniane jako handlery EDA, dzięki czemu przetwarzanie może się odbywać asynchronicznie w ramach zdefiniowanych kolejek fizycznych/logicznych. Struktury to np. EComOrderInfo, eComInventoryInfo, ECom OrderInfo itd. Są zdefiniowane w obiekcie ECOMSTDMETHODS. Mogą być więc rozszerzane przez
METODY PRZETWARZANIA - obiekt biznesowy zawierający wszystkie metody biznesowe przetwarzające struktury HiD na struktury uniwersalne EKS. Standardowe metody są zaimplementowane w obiekcie ECOMSTDMETHODS. W ramach wdrożenia wystarczy odziedziczyć po tym obiekcie, wskazać ten obiekt w danym KANALE i wtedy całość wymiany w danym kanale będzie realizowana za pomocą metod tego obiektu.
TABELE POŚREDNIE STATUSOWE - tabele ECOMORDERS, ECOMINVENTORIES itd. - pokazujące status synchronizacji danego elementu z danym kanałem sprzedaży, przechowujące dane kluczowy HID\<-\ kanał sprzedaży. W interfejsie służą też to uruchamiania ręcznego procesów i podglądu komunikacji w EDA.

Konfiguracja kanału sprzedaży w aplikacji Teneum¶

Aby wyświetlić wszystkie kanały sprzedaży (aktywne/nieaktywne) przejdź do zakładki Sprzedaż, a następnie wybierz przycisk Konfiguracja -\ Sprzedaż -\ Kanały sprzedaży. Otworzy się okno z listą wszystkich kanałów sprzedaży.

Dodanie nowego kanału sprzedaży¶

Przechodzimy do okna Konfiguracja kanałów, następnie klikamy przycisk Dołącz. Wpisujemy nazwę kanału sprzedaży oraz wybieramy konektor ze słownika. W zakładce Ogólne wybieramy Obiekt z metodami synchronizacji, który został przygotowany do pracy z daną witryną. Domyślnym obiektem z metodami synchronizacji jest obiekt o nazwie „ECOMSTDMETHODS”.

Szczegółowa konfiguracja kanału sprzedaży¶

W zakładce Ogólne klikamy przycisk z ikoną koła zębatego.

Otworzy się okno z dalszą konfiguracją kanału, gdzie należy uzupełnić:

- Typ zamówień,

- Rejestr nowych zamówień,

- Rejestr pobranych poprawnie zamówień – prawidłowo pobranie zamówienie trafi do wybranego rejestru,

- Klient detaliczny – każde importowanie zamówienie złożone przez klienta, który nie jest firmą będzie przypisane do wybranego klienta detalicznego,

- Produkt nieznany – każdy towar zaimportowany razem z zamówieniem, który nie występuje w Teneum będzie przypisany do wybranego produktu nieznanego,

- Atrybuty towaru do wysłania – cechy towaru wysłane podczas pierwszego eksportu towaru na witrynę,

- Atrybuty towaru do aktualizacji – cechy towaru wysłane podczas aktualizacji towaru,

- Nowy towar od razu widoczny na witrynie? – podczas ręcznego dodania towaru zostanie od razu wyeksportowany na witrynę (jeśli opcja zaznaczona),

- Klient do wyliczenia cen – klient z którego zostanie pobrany cennik.

Aby wyświetlić wszystkie dostępne atrybuty towaru jakie możemy wysłać na witrynę należy kliknąć przycisk z ikoną „i”.

Konfiguracja synchronizacji automatycznej¶

Aby skonfigurować automatyczną synchronizację należy w zakładce „Synchronizacja automatyczna” ustawić interwał wybranej opcji.

Dostępne opcje automatycznej synchronizacji:

- pobieranie zamówień,

- wysyłkę statusów zamówień,

- synchronizację towarów,

- wysyłkę zmienionych cen,

- wysyłkę zmienionych stanów magazynowych,

- synchronizację stanów towarów.

Konfiguracja weryfikacji:¶

Aby skonfigurować automatyczną wysyłkę raportów spójności zamówień należy:

- wybrać ilość dni wstecz badanej spójności zamówień,

- interwał wysyłki

- adresy e-mail na które zostaną wysłane raporty (adresy e-mail rozdzielamy średnikiem).

Konfiguracja listy statusów:¶

Przechodzimy do zakładki „Lista statusów”, klikamy przycisk Dołącz. Należy uzupełnić:

- Opis – status wyświetlany w Teneum,

- Symbol – symbol statusu po stronie kanału sprzedaży,

- Kolejność – kolejność sprawdzenia statusu przez Teneum od największej wartości do najmniejszej. Jeśli filtr wyliczenia spełniony ustaw status i wysłanie go na witrynę,

- Filtr wyliczenia – warunek, kiedy dany status może być ustawiony.

Konfiguracja słownika konwersji¶

Przechodzimy do zakładki „Słownik konwersji”, klikamy „Dołącz”. Należy uzupełnić:

- Typ – nazwa z tabeli w której zapisana jest wartość w HID,

- Pole – nazwa pola w tabeli, która przechowuje taki sam typ wartości jaki zwracany jest z kanału sprzedaży. Jeśli nie wpiszemy nazwy kolumny to domyślnie skorzysta z kolumny z kluczem głównym,

- Wartość w HID – wartość z wcześniej wybranej kolumny,

- Wartość w kanale sprzedaży – wartość przekazywana z kanału sprzedaży.

Przykładowa konfiguracja sposobu dostawy dla kuriera DPD:

- Typ – SPOSDOST,

- Pole – zostawiamy puste, ponieważ korzystamy z kolumny z kluczem głównym,

- Wartość w HID – kurierowi DPD w Teneum odpowiada REF 18,

- Wartość w kanale sprzedaży – kurierowi DPD w kanale sprzedaży odpowiada wartość 51.

Aktywacja/Dezaktywacja kanału sprzedaży:¶

Przechodzimy do okna Konfiguracja kanałów, następnie wybieramy kanał sprzedaży i klikamy przycisk Konfiguruj. Jeśli chcemy aktywować kanał przechodzimy do zakładki Ogólne, zaznaczamy opcję Aktywny? i klikamy przycisk Zapisz.

Sprawdzenie błędów wymiany danych w monitorze EDA:¶

Jeśli wystąpią problemy podczas np. importu zamówień lub eksportu towaru możemy sprawdzić co poszło nie tak w monitorze EDA. Aby wyświetlić monitor EDA należy przejść do zakładki “Administrator”, następnie wybrać przycisk “EDA” i opcję “Monitor EDA”. Wyświetli się następujące okno:

Kolumna “Identyfikator” informuje nas, którego zamówienia lub towaru lub innej rzeczy dotyczy dany komunikat np ORD1_57 dotyczy zamówienia z kanału 1 o ID 57.

Jeśli podczas próby odpalenia okna monitora dostaniemy błąd to najprawdopodobniej jest źle skonfigurowana baza Postgres, która jest odpowiedzialna za przechowywanie komunikatów związanych z EDA. Konfiguracja bazy Postgres znajduje się w zakładce “EDA” w pliku smd w folderze Neos.

Wybierając przycisk “Wyślij ponownie” możemy ponowić próbę wysłania komendy. Podczas ponownej próby wysłania komendy możemy zmienić zawartość jej komunikatu.

Aby wyświetlić szczegóły błędu należy kliknąć dwukrotnie w komunikat z czerwonym wykrzyknikiem. W opcjach dodatkowych jest opcja “Zdarzenia z bazy danych”. Znajdują się tam zdarzenia, które są wywoływane przez triggery w bazie danych np. podczas zmiany na zamówieniu trigger uruchamia zdarzenie, żeby status zamówienia uległ zmianie. Zdarzenia te przetwarzane są co jakiś czas. Zdarzenia wykonane poprawnie znikną z listy, a w monitorze EDA pojawią się komendy, które dane zdarzenie wywołało (będzie widać, czy komendy wykonały się poprawnie, czy zgłosiły błąd). Zdarzenie, które nie wykonało się poprawnie zostaje na liście z czerwonym wykrzyknikiem (można odczytać błąd).

Każda komenda zawiera komunikat jaki przekazała. Można go zobaczyć w prawym rogu okna: