Integrator sprzedaży open source - raport z własnego testu

Różnica wobec BaseLinkera czy Sellasista dotyczy między innymi miejsca uruchomienia i odpowiedzialności za utrzymanie. Sam model hostingu nie rozstrzyga praw do danych. Integrator w abonamencie działa na serwerach dostawcy, a Ty korzystasz z panelu. Integrator o otwartym kodzie instalujesz na swoim serwerze i masz dostęp do bazy oraz kodu źródłowego.

OpenLinker jest projektem na licencji Apache 2.0. W analizowanej 7 sierpnia rewizji znaleźliśmy dziewięć adapterów. Poniższa tabela opisuje deklarowane możliwości kodu z tego dnia, a nie wynik produkcyjnego sprawdzenia wszystkich połączeń.

Zestaw obejmował narzędzia używane na polskim rynku. Obecność adaptera KSeF, kuriera lub marketplace nie potwierdza jednak poprawności każdego dokumentu i scenariusza. Własna próba dotyczyła wyłącznie połączenia z PrestaShop.

W historycznym przeglądzie naliczyliśmy 3021 plików TypeScript, w tym 626 plików testowych. Te liczby opisują rozmiar repozytorium. Nie są pomiarem pokrycia kodu testami ani dowodem, że wszystkie testy przeszły.

Autorzy w README projektu piszą: "Status: alpha, pre-1.0. Expect rough edges; report them." Stan alfa wymaga uwzględnienia błędów, zmian interfejsów i pracy utrzymaniowej przed decyzją o produkcji.

W lokalnej próbie z 7 sierpnia postawienie zajęło około dziesięciu minut od pobrania repozytorium do działającego interfejsu. Środowisko używało WSL2, Dockera 29.6.1, dysku ext4 i miało dostępne około 47 GB RAM. To opis warunków pomiaru, nie minimalne wymagania ani czas wdrożenia produkcyjnego.

W testowanej wersji środowisko programistyczne korzystało z Node 22 i pnpm 10. Uruchomienie przygotowanego demo odbywało się przez Docker Compose, bez osobnej instalacji tych narzędzi na hoście. Aktualny README trzeba przeczytać przed uruchomieniem: tryby developerski i demonstracyjny mogą współdzielić wolumeny, więc nie należy traktować ich jako niezależnych środowisk danych.

Uruchomienie postawiło dziesięć kontenerów: bazę PostgreSQL, Redis na kolejki, MySQL, dwa sklepy testowe oraz osobne procesy interfejsu, API i workera przetwarzającego zadania w tle. Migracje bazy przeszły bez błędu i utworzyły czterdzieści osiem tabel.

API i worker działały jako osobne procesy. Taki podział pozwala oddzielić obsługę interfejsu od zadań w tle, ale nie dowodzi wydajności przy większym obciążeniu. Zwiększanie liczby workerów wymaga sprawdzenia kolejek, współbieżności oraz limitów usług zewnętrznych.

W zakresie lokalnej próby synchronizacja zadziałała. Połączyliśmy testowy PrestaShop i pobraliśmy przygotowany katalog oraz stany magazynowe. Wyniki pochodzą z protokołu KC Mobile z 7 sierpnia 2026 r., rewizja 7bfb46e.

Pojedynczy test połączenia zwrócił poprawną odpowiedź w 27 milisekundach. Nie jest to średni czas synchronizacji ani wynik dla publicznego sklepu. Następnie uruchomiliśmy właściwe pobieranie danych.

Ważniejszy od pierwszego zaciągnięcia jest test tego, co dzieje się przy zmianie. Zmieniliśmy w PrestaShopie ilości trzech wariantów ze 100 na 777 i uruchomiliśmy synchronizację ponownie. Integrator pokazał nowe wartości. Próba nie polegała na zmianie wyłącznie produktu nadrzędnego i automatycznym rozdzieleniu jego stanu na warianty.

W zapisanych czasach aktualizacji wariantów widzieliśmy odstępy około dziesięciu sekund. Nie ustaliliśmy ich przyczyny. Sama deklaracja limitu zapytań nie dowodzi działania wspólnego ogranicznika. Dokument ADR 038 z tej rewizji ma status propozycji i opisuje problem niezależnych pul API oraz workera. Nie można przedstawiać go jako wdrożonej gwarancji limitowania.

Zlecenie synchronizacji całego katalogu rozkłada się wachlarzem na osobne zadania dla każdego produktu. Zamówienia idą niezależną ścieżką. W tej małej próbie 30 zadań zakończyło się bez błędów. Nie sprawdzaliśmy zachowania przy awarii produktu, przerwanym połączeniu ani dużym obciążeniu.

W testowanej rewizji uruchomienie demo nie dawało gotowego, połączonego środowiska. Lista połączeń była pusta, a WooCommerce nie miał produktów przed osobnym zasileniem danymi. W PrestaShopie trzeba było uruchomić usługę sieciową i skonfigurować dostęp do zasobów.

To obserwacje z konkretnej wersji, nie instrukcja bezpośredniej edycji bazy sklepu. Dla kolejnej wersji należy użyć jej dokumentacji i panelu administracyjnego. Środowisko próbne powinno być oddzielone od rzeczywistych danych klientów i połączeń sprzedażowych.

Instalacja nie zastępuje mapowania kategorii, statusów, metod płatności i przewoźników. Zapisz oczekiwany kierunek każdej wymiany danych oraz sposób wycofania błędnej konfiguracji. Do odbioru potrzebny jest nie tylko poprawny import, ale także kontrolowana zmiana i ponowienie operacji. Nasz raport opisuje wykonany fragment tego procesu, nie pełny odbiór produkcyjny.

W próbie trafiliśmy na ograniczenie konfiguracji połączenia WooCommerce: wymagany był HTTPS, a adresy prywatne były odrzucane. Potwierdza to kod walidacji z badanej rewizji.

Ograniczenia adresów są częścią ochrony przed kierowaniem zapytań integratora do wewnętrznych usług. Nie stanowią jednak same w sobie pełnego audytu bezpieczeństwa. Nie należy wyłączać walidacji tylko po to, aby uruchomić połączenie z lokalnym sklepem.

Problem dotyczył naszego prywatnego adresu i konfiguracji, nie każdego serwera testowego. Środowisko przedprodukcyjne może korzystać z poprawnego HTTPS i kontrolowanego dostępu sieciowego. Wymaga to przygotowania bezpiecznego połączenia oraz właściwych uprawnień. W tej próbie nie wykonaliśmy pełnego testu synchronizacji WooCommerce; taki zakres trzeba sprawdzić osobno przed wdrożeniem integratora.

Własna instancja ma sens, gdy odpowiada konkretnemu wymaganiu: kontroli infrastruktury, zmianie logiki lub brakującemu połączeniu. Porównanie z abonamentem musi uwzględniać utrzymanie i odpowiedzialność za awarie. Bez tych danych nie da się rozstrzygnąć, który wariant będzie tańszy.

Własna centralna baza nie oznacza, że wszystkie dane pozostają wyłącznie na Twoim serwerze: integracje przekazują potrzebne informacje do sklepów, marketplace i przewoźników. Brakujący moduł można dopisać do otwartego kodu, ale także SaaS może udostępniać API do własnych rozszerzeń. Na przykład Base publikuje API z metodami integracyjnymi. Różnica dotyczy zakresu kontroli i utrzymania rozwiązania, nie prostego podziału na możliwość lub brak programowania.

W historycznym pomiarze adapter DPD miał 2730 linii kodu oraz 1676 linii testów. Liczby nie określają czasu napisania kolejnego adaptera ani jego pokrycia testami. Wycena wymaga listy operacji, dokumentacji przewoźnika i przypadków odbiorowych.

Warto też sprawdzić, czego w projekcie nie ma. W badanej rewizji adaptery nadawcze obejmowały InPost i DPD Polska. Orlen Paczka i DHL są w kodzie rozpoznawane jako nazwy przewoźników przy przesyłkach z Allegro, ale samo występowanie nazwy nie potwierdzało adaptera do nadawania przesyłek. Aktualny zakres należy ponownie zweryfikować. Jeśli Twoja logistyka stoi na jednym z nich, to jest pozycja do wyceny przed decyzją, a nie po niej.

Licencja Apache 2.0 nie wymaga opłaty licencyjnej. Reszta to projekt wdrożeniowy: infrastruktura, konfiguracja połączeń, mapowanie danych, odbiór i utrzymanie. Pozostają także ewentualne opłaty usług zewnętrznych, z którymi integrator ma pracować.

Porównaj roczny koszt abonamentu z kosztem serwera, aktualizacji, kopii zapasowych, monitoringu i interwencji. Dodaj wdrożenie oraz ewentualny rozwój adaptera. Przy wycenie zapisz liczbę środowisk, odpowiedzialność za odtwarzanie danych i zakres obsługi błędów. Sam brak abonamentu producenta nie rozstrzyga opłacalności.

Jeśli rozważasz ten kierunek, porównanie integratorów pokazuje alternatywy, a opis integracji Apilo przedstawia inny model obsługi WooCommerce. Zakres prac przy własnym rozwiązaniu opisuje wdrożenie integratora open source.

Wdrożenia i migracje można omówić w ramach sklepów internetowych. Napisz do KC Mobile, podając platformę lub adres sklepu oraz cel. Kanały, kurierów i liczbę zamówień dopisz, jeśli je znasz. Pierwszym krokiem będzie określenie wymaganego procesu i zakresu próby, nie założenie, że własny serwer zawsze przyniesie oszczędność.