Home / Blog / Aktualności / Integracja WooCommerce z systemem ERP: jak zapobiec przeciążeniu serwera i błędom timeout

Integracja WooCommerce z systemem ERP: jak zapobiec przeciążeniu serwera i błędom timeout

, Czas czytania: min. , Komentarz(y):0

Integracja sklepu WooCommerce z systemem ERP może znacząco usprawnić obsługę zamówień, produktów, cen i stanów magazynowych. Problem zaczyna się jednak wtedy, gdy wraz ze wzrostem liczby produktów oraz zamówień rośnie również liczba zapytań wykonywanych pomiędzy systemami. Źle zaprojektowana integracja ERP z WooCommerce API może powodować przeciążenia procesora, blokowanie procesów PHP, długie zapytania do bazy danych, błędy 502 i 503, a także charakterystyczne komunikaty 504 Gateway Timeout. Nie zawsze oznacza to, że sklep potrzebuje mocniejszego serwera. Bardzo często źródłem problemu jest sposób, w jaki została zaprojektowana synchronizacja.
Dobra integracja ERP nie powinna polegać na tym, aby WooCommerce wykonał jak najwięcej operacji w jak najkrótszym czasie. Powinna wykonywać tylko te operacje, które są rzeczywiście potrzebne, i odpowiednio rozkładać je w czasie.

Dlaczego integracja ERP może przeciążyć WooCommerce?

WooCommerce działa w środowisku WordPressa, PHP i bazy danych MySQL lub MariaDB. Każda aktualizacja produktu, stanu magazynowego czy zamówienia może więc uruchamiać nie tylko jedno zapytanie do bazy. W tle mogą wykonywać się również:
  • hooki WooCommerce i WordPressa,
  • aktualizacje metadanych produktów,
  • czyszczenie pamięci podręcznej,
  • aktualizacja indeksów wyszukiwarki lub filtrów produktowych,
  • zadania Action Scheduler,
  • wywołania dodatkowych integracji,
  • webhooki wysyłane do innych systemów.
Jeżeli ERP próbuje w jednej chwili zaktualizować kilka czy kilkanaście tysięcy produktów, nawet stosunkowo wydajny serwer może zacząć mieć problemy. Szczególnie niebezpieczny jest model, w którym każda zmiana wykonywana jest osobnym żądaniem HTTP. Przykładowo synchronizacja 10 000 produktów może oznaczać:
  • 10 000 połączeń z API,
  • 10 000 operacji PHP,
  • dziesiątki tysięcy operacji bazodanowych,
  • dodatkowe operacje wykonywane przez wtyczki WooCommerce.
I właśnie tutaj pojawiają się pierwsze timeouty.

Integracja ERP z WooCommerce API – architektura ma znaczenie

Najprostszy wariant integracji wygląda tak:
ERP → REST API WooCommerce → baza danych
Przy niewielkiej liczbie produktów może działać bez problemów. W bardziej rozbudowanym sklepie znacznie bezpieczniejszy jest jednak model:
ERP → warstwa integracyjna → kolejka zadań → WooCommerce API → baza danych
Warstwa integracyjna może sprawdzić dane, porównać zmiany, ograniczyć liczbę żądań oraz rozłożyć synchronizację w czasie. Dzięki temu WooCommerce nie musi przetwarzać całego katalogu jednocześnie.

Nie synchronizuj wszystkiego, jeżeli zmieniło się tylko 50 produktów

Jednym z najczęstszych błędów integracji jest wykonywanie pełnej synchronizacji katalogu niezależnie od tego, ile danych faktycznie się zmieniło. Załóżmy, że sklep posiada 30 000 produktów. W systemie ERP w ciągu ostatniej godziny zmienił się stan magazynowy 120 pozycji. Nie ma powodu, aby ponownie przetwarzać wszystkich 30 000 produktów. Znacznie lepszym rozwiązaniem jest synchronizacja przyrostowa, czyli przesyłanie wyłącznie rekordów zmodyfikowanych od czasu poprzedniego procesu. ERP może przechowywać między innymi:
  • datę ostatniej modyfikacji produktu,
  • numer wersji rekordu,
  • hash danych,
  • status wymagający ponownej synchronizacji.
Warstwa integracyjna porównuje dane i przesyła do WooCommerce tylko rzeczywiste zmiany.
Najtańsze zapytanie do WooCommerce to takie, którego nie trzeba było wykonać.

Synchronizacja stanów magazynowych Subiekt – gdzie najczęściej pojawia się problem?

Dobrym przykładem jest synchronizacja stanów magazynowych Subiekt z WooCommerce. Stan produktu potrafi zmieniać się bardzo często. Jeżeli sklep obsługuje sprzedaż internetową, stacjonarną i dodatkowe kanały marketplace, system ERP może aktualizować magazyn nawet co kilka minut. Błędem byłoby jednak przesyłanie za każdym razem całej kartoteki towarowej. Lepszy model wygląda następująco:
  1. Subiekt wykrywa zmianę stanu magazynowego.
  2. Zmiana trafia do kolejki integracji.
  3. System sprawdza aktualny stan zapisany w WooCommerce.
  4. Aktualizacja wykonywana jest tylko wtedy, gdy wartości rzeczywiście się różnią.
  5. Po poprawnym zapisie zadanie otrzymuje status wykonany.
W przypadku błędu rekord nie powinien blokować całej synchronizacji. Powinien trafić do ponownego przetworzenia.

Kolejkowanie webhooków zamiast wykonywania wszystkiego natychmiast

Drugim bardzo częstym źródłem problemów są webhooki. Webhook pozwala poinformować drugi system o zdarzeniu, np. utworzeniu zamówienia, zmianie jego statusu albo aktualizacji produktu. Problem pojawia się wtedy, gdy odbiorca webhooka próbuje wykonać całą logikę biznesową podczas pojedynczego żądania HTTP. Wyobraźmy sobie, że po złożeniu zamówienia system musi:
  • utworzyć dokument w ERP,
  • sprawdzić klienta,
  • zaktualizować magazyn,
  • wygenerować dokument sprzedażowy,
  • przekazać dane do kolejnego systemu.
Jeżeli wszystko wykonuje się synchronicznie, odpowiedź może trwać kilkanaście lub kilkadziesiąt sekund. Znacznie bezpieczniejsze jest kolejkowanie webhooków. Endpoint odbierający webhook powinien:
  1. odebrać żądanie,
  2. zweryfikować jego poprawność,
  3. zapisać zadanie w kolejce,
  4. możliwie szybko zwrócić odpowiedź HTTP,
  5. przetworzyć właściwą operację asynchronicznie.
Do realizacji kolejki można wykorzystać rozwiązania działające bezpośrednio w WordPressie, takie jak Action Scheduler, albo zewnętrzne systemy kolejkowe i usługi pośredniczące.

Rate limiting REST API – nie wysyłaj wszystkiego naraz

Kolejnym istotnym elementem jest rate limiting REST API, czyli kontrolowanie liczby zapytań wysyłanych w określonym czasie. Nawet jeżeli serwer jest w stanie obsłużyć bardzo dużą liczbę żądań, nie oznacza to, że integracja powinna wykorzystać całą dostępną wydajność. Jeżeli system ERP uruchomi jednocześnie setki requestów, może dojść do:
  • wyczerpania dostępnych procesów PHP,
  • osiągnięcia limitu CPU,
  • dużej liczby równoległych zapytań do MySQL,
  • spowolnienia sklepu dla zwykłych użytkowników,
  • timeoutów integracji,
  • błędów 429, 502, 503 lub 504 – zależnie od infrastruktury.
Znacznie lepiej przetwarzać dane w kontrolowanych paczkach. Przykładowo zamiast uruchamiać 1000 aktualizacji jednocześnie, integracja może wykonywać ograniczoną liczbę operacji, monitorować czas odpowiedzi serwera i dopiero później pobierać kolejną porcję danych. W bardziej zaawansowanym rozwiązaniu tempo synchronizacji może być dynamiczne. Jeżeli czas odpowiedzi WooCommerce zaczyna rosnąć, integrator automatycznie zmniejsza liczbę równoległych operacji.

Batch processing – aktualizuj dane paczkami

Przy dużych katalogach produktowych warto również wykorzystywać przetwarzanie wsadowe. Zamiast wykonywać: 
produkt 1 → request
produkt 2 → request
produkt 3 → request
produkt 4 → request
produkt 5 → request
można grupować dane w mniejsze paczki i przetwarzać je etapami. Wielkość paczki powinna być dopasowana do:
  • wydajności serwera,
  • liczby produktów,
  • złożoności danych,
  • liczby aktywnych wtyczek,
  • czasu potrzebnego na wykonanie pojedynczej aktualizacji.
Nie istnieje jedna optymalna liczba rekordów dla każdego sklepu. Paczka 100 produktów może być niewielka dla jednego środowiska i zbyt duża dla innego.

Obsługa payload JSON – przesyłaj tylko potrzebne dane

Kolejnym elementem wpływającym na wydajność jest obsługa payload JSON. Payload to dane przesyłane pomiędzy systemem ERP a WooCommerce. Jeżeli zmienił się tylko stan magazynowy produktu, nie ma potrzeby przesyłania całej struktury zawierającej opis, zdjęcia, kategorie, atrybuty, ceny i pozostałe metadane. Zamiast dużego payloadu: 
{
    "sku": "ABC-123",
    "name": "Produkt przykładowy",
    "description": "...",
    "categories": [...],
    "images": [...],
    "attributes": [...],
    "regular_price": "299.00",
    "stock_quantity": 15
}
w określonym procesie może wystarczyć: 
{
    "sku": "ABC-123",
    "stock_quantity": 15
}
Mniejszy payload oznacza:
  • mniej danych przesyłanych przez sieć,
  • mniej operacji po stronie integratora,
  • mniejsze ryzyko niepotrzebnego nadpisania danych,
  • łatwiejsze logowanie i debugowanie integracji.

Payload powinien być również walidowany

Integracja nie powinna zakładać, że każda przesłana informacja jest poprawna. Przed wykonaniem aktualizacji warto zweryfikować między innymi:
  • czy SKU lub ID produktu istnieje,
  • czy wymagane pola zostały przesłane,
  • czy wartości mają poprawny typ,
  • czy cena nie jest wartością ujemną,
  • czy stan magazynowy ma oczekiwany format,
  • czy payload nie przekracza zakładanego rozmiaru.
Niepoprawny rekord powinien zostać zapisany w logach i oznaczony jako wymagający sprawdzenia, zamiast powodować zatrzymanie całego procesu.

Retry – nie ponawiaj błędu co sekundę

Timeout nie zawsze oznacza trwałą awarię. Serwer może być chwilowo bardziej obciążony. Może trwać backup, import danych albo inne zadanie systemowe. Dlatego integracja powinna posiadać mechanizm ponawiania operacji. Ale również tutaj łatwo popełnić błąd. Jeżeli po nieudanym requestcie system natychmiast wykona kolejnych dziesięć prób, może jeszcze bardziej obciążyć serwer, który już ma problem. Lepszym rozwiązaniem jest mechanizm exponential backoff, czyli stopniowe wydłużanie czasu pomiędzy kolejnymi próbami. Przykładowo: 
1. próba → natychmiast
2. próba → po 10 sekundach
3. próba → po 30 sekundach
4. próba → po 2 minutach
5. próba → po 10 minutach
Po przekroczeniu określonej liczby prób zadanie może zostać oznaczone jako wymagające ręcznej weryfikacji.

Optymalizacja zapytań cron ma ogromne znaczenie

Wiele integracji WooCommerce działa na podstawie zadań cyklicznych. Co kilka minut uruchamiany jest proces:
Sprawdź ERP → pobierz dane → porównaj → zaktualizuj WooCommerce.
Samo zastosowanie crona nie jest problemem. Problemem może być sposób jego działania. Optymalizacja zapytań cron powinna obejmować przede wszystkim kontrolę tego, czy poprzedni proces został już zakończony. Jeżeli synchronizacja trwa 8 minut, a zadanie uruchamiane jest co 5 minut, po pewnym czasie na serwerze mogą działać jednocześnie dwa lub trzy procesy synchronizacji. W takiej sytuacji wykorzystanie zasobów rośnie lawinowo. Dlatego warto zastosować blokadę procesu, np. mechanizm lock. 
jeżeli synchronizacja działa:
    zakończ nowe zadanie

jeżeli synchronizacja nie działa:
    ustaw blokadę
    wykonaj synchronizację
    usuń blokadę
W przypadku dużych sklepów warto również rozważyć uruchamianie zadań przez rzeczywisty systemowy cron zamiast polegać wyłącznie na WP-Cron wywoływanym przez ruch użytkowników.

Nie pozwól, aby integracja konkurowała z klientami sklepu

Synchronizacja ERP może technicznie działać poprawnie, a jednocześnie pogarszać szybkość sklepu. Wyobraźmy sobie, że pełna aktualizacja katalogu uruchamia się codziennie o godzinie 12:00. Dokładnie wtedy sklep notuje największy ruch. Synchronizacja zaczyna zużywać procesor, pamięć i zasoby bazy danych, a klient otwierający kategorię produktową czeka kilka sekund dłużej. Dlatego cięższe procesy warto planować w godzinach mniejszego ruchu, a procesy wykonywane w ciągu dnia ograniczać do niewielkich synchronizacji przyrostowych.

Logi są obowiązkowe

Jednym z największych problemów źle zaprojektowanych integracji jest brak informacji o tym, co właściwie się wydarzyło. Komunikat: 
Synchronization failed
praktycznie nic nie mówi. Dobry system powinien rejestrować między innymi:
  • czas rozpoczęcia i zakończenia synchronizacji,
  • liczbę przetworzonych rekordów,
  • liczbę pominiętych rekordów,
  • liczbę błędów,
  • kod odpowiedzi HTTP,
  • ID lub SKU problematycznego produktu,
  • czas odpowiedzi WooCommerce API,
  • liczbę wykonanych ponownych prób.
Dzięki temu można szybko odpowiedzieć na pytanie, czy problem znajduje się po stronie ERP, WooCommerce, API czy infrastruktury serwera.

Idempotencja – ten sam request nie może tworzyć dwóch zamówień

To szczególnie ważne przy synchronizacji zamówień. Wyobraźmy sobie, że ERP wysyła zamówienie do WooCommerce lub odwrotnie. System wykonuje operację, ale odpowiedź HTTP nie dociera z powodu timeoutu. Integrator uznaje więc, że operacja się nie udała i wysyła ją ponownie. Jeżeli integracja nie została odpowiednio zabezpieczona, może powstać duplikat. Dlatego proces powinien być idempotentny – ponowne wykonanie tego samego zadania nie powinno powodować utworzenia drugiego obiektu. Można to osiągnąć poprzez przechowywanie:
  • zewnętrznego ID zamówienia,
  • unikalnego identyfikatora operacji,
  • statusu synchronizacji,
  • historii wykonanych requestów.

Mocniejszy serwer nie naprawi złej integracji

Oczywiście odpowiednio wydajne środowisko hostingowe ma znaczenie. WooCommerce z rozbudowanym katalogiem, integracjami ERP i dużym ruchem potrzebuje odpowiednich zasobów CPU, pamięci RAM, szybkiej bazy danych i poprawnie skonfigurowanego PHP. Ale zwiększenie parametrów serwera nie powinno być pierwszym sposobem rozwiązywania problemów. Jeżeli integracja wykonuje 30 000 niepotrzebnych requestów, mocniejszy serwer sprawi jedynie, że będzie wykonywała 30 000 niepotrzebnych requestów szybciej.
Skalowanie infrastruktury ma sens dopiero wtedy, gdy sama architektura integracji została zaprojektowana poprawnie.

Jak powinna wyglądać bezpieczna integracja ERP z WooCommerce?

Przy większym sklepie warto przyjąć kilka podstawowych zasad:
  • synchronizować wyłącznie zmienione dane,
  • wykorzystywać kolejkę zadań,
  • ograniczać liczbę równoległych requestów,
  • przetwarzać duże zbiory danych paczkami,
  • nie wykonywać ciężkich operacji bezpośrednio podczas webhooka,
  • walidować payload JSON,
  • stosować retry z rosnącym odstępem czasowym,
  • blokować możliwość równoległego uruchomienia tego samego crona,
  • monitorować czasy odpowiedzi API,
  • prowadzić szczegółowe logi synchronizacji.

Integracja ERP powinna odciążać firmę, a nie przeciążać sklep

Integracja WooCommerce z systemem ERP może zautomatyzować dużą część codziennej pracy: od synchronizacji magazynu, przez ceny i produkty, aż po obsługę zamówień. Jednocześnie jest to jeden z tych elementów sklepu, które bardzo łatwo zaprojektować w sposób działający poprawnie przy 500 produktach, ale powodujący poważne problemy przy 20 000 czy 50 000 pozycji. Dlatego podczas projektowania integracji ERP z WooCommerce API nie należy patrzeć wyłącznie na to, czy dane poprawnie przechodzą z systemu A do systemu B. Trzeba również odpowiedzieć na pytania:
  • ile operacji wykonujemy,
  • jak często je wykonujemy,
  • czy wszystkie są rzeczywiście potrzebne,
  • co stanie się w przypadku timeoutu,
  • co stanie się po ponowieniu requestu,
  • czy integracja poradzi sobie z kilkukrotnie większą liczbą danych.
To właśnie te elementy decydują o tym, czy integracja będzie działała stabilnie również wtedy, gdy sklep zacznie rosnąć.

FAQ

Dlaczego integracja ERP z WooCommerce powoduje timeout?

Najczęstszymi przyczynami są zbyt duża liczba równoległych requestów, przetwarzanie zbyt dużej ilości danych w jednym procesie, wolne zapytania bazodanowe, przeciążenie PHP albo wykonywanie ciężkich operacji synchronicznie.

Jak często synchronizować stany magazynowe WooCommerce z ERP?

Zależy to od charakteru sprzedaży. W wielu przypadkach zamiast częstych pełnych synchronizacji lepiej zastosować synchronizację przyrostową i przesyłać tylko te produkty, których stan faktycznie się zmienił.

Czy można połączyć WooCommerce z Subiektem?

Tak. Integracja może obejmować między innymi produkty, stany magazynowe, ceny, kontrahentów i zamówienia. Przy większej liczbie produktów szczególne znaczenie ma sposób realizacji synchronizacji stanów magazynowych z Subiektem.

Czy webhook powinien od razu aktualizować ERP?

Nie zawsze. Przy bardziej złożonych procesach bezpieczniej odebrać webhook, zapisać zadanie do kolejki i wykonać właściwą synchronizację asynchronicznie.

Czy WooCommerce poradzi sobie z integracją dużego ERP?

Tak, ale wymaga to odpowiedniej architektury integracji oraz infrastruktury. Kluczowe znaczenie mają kolejkowanie operacji, synchronizacja przyrostowa, kontrola liczby requestów, odpowiednia obsługa błędów i monitorowanie wydajności.

Czy zwiększenie parametrów hostingu rozwiąże błędy timeout?

Może pomóc, jeżeli faktycznym ograniczeniem są zasoby serwera, ale nie rozwiąże problemu źle zaprojektowanej integracji. Najpierw warto sprawdzić liczbę requestów, sposób synchronizacji, zapytania do bazy danych, zadania cron oraz kolejkę operacji.

Zostaw komentarz do artykułu: Integracja WooCommerce z systemem ERP: jak zapobiec przeciążeniu serwera i błędom timeout

Dodaj komentarz

candyweb

Właściciel agencji interaktywnej Candyweb.pl, absolwent studiów magisterskich kierunku informatyka ze specjalnością technologii mobilnych i internetowych Uniwersytetu w Białymstoku. Przeszło 10-letnie doświadczenie komercyjne zdobyte w agencjach reklamowych. Ponad 700 zrealizowanych projektów informatycznych. Pasjonat narzędzi marketingowych, AI i tematyki SEO.