Nie wszystkie dane wymagają synchronizacji z taką samą częstotliwością — stany magazynowe warto aktualizować częściej niż na przykład opisy produktów.

Na czym polega ta usługa

Konfiguracja obejmuje ustawienie odpowiedniej częstotliwości i priorytetów synchronizacji poszczególnych rodzajów danych między sklepem a magazynem.

Dla kogo ma sens

Usługa jest przydatna dla firm, u których obecna synchronizacja danych jest zbyt rzadka, zbyt częsta lub nieodpowiednio priorytetyzowana.

Ile to trwa

Konfiguracja harmonogramu synchronizacji mieści się z reguły w standardowym czasie do 3 dni.

Warunki

Diagnoza wstępna i wycena są bezpłatne, a usługa objęta jest gwarancją do 12 miesięcy.

Dlaczego jednolity interwał dla wszystkich danych prowadzi do przeciążeń

Wielu przedsiębiorców prowadzących sprzedaż wielokanałową (ang. omnichannel, czyli równoległe prowadzenie sprzedaży w sklepie internetowym, na portalach aukcyjnych i w magazynie stacjonarnym) zakłada, że wszystkie informacje powinny być przesyłane w jednym, stałym rytmie. W praktyce próba synchronizowania całego katalogu towarowego co kilkadziesiąt sekund wywołuje poważne problemy z wydajnością całego środowiska informatycznego.

Pełna synchronizacja (ang. full sync, czyli procedura jednoczesnego przesyłania wszystkich kartotek towarowych, stanów magazynowych, cenników, opisów, atrybutów oraz powiązanych zdjęć) wymaga przetworzenia dużej liczby rekordów w relacyjnej bazie danych. Jeśli operacja ta jest wykonywana zbyt często, dochodzi do nadmiernego obciążenia procesora (CPU) oraz pamięci operacyjnej (RAM) serwera bazodanowego, takiego jak Microsoft SQL Server, PostgreSQL lub MySQL. W konsekwencji pracownicy biurowi oraz magazynierzy korzystający z systemów ERP (ang. Enterprise Resource Planning, czyli oprogramowania do kompleksowego zarządzania zasobami przedsiębiorstwa, takiego jak Subiekt GT, Subiekt nexo, Comarch ERP Optima, WAPRO Mag, Symfonia czy enova365) doświadczają spowolnień i zawieszania się programu podczas wystawiania faktur, tworzenia dokumentów przyjęcia zewnętrznego (PZ) lub wydań magazynowych (WZ).

Drugim poważnym zagrożeniem jest przekraczanie limitów narzucanych przez platformy handlowe oraz platformy e-commerce. Mechanizm ograniczania liczby żądań (ang. rate limiting, czyli techniczna blokada nakładana przez serwer docelowy na maksymalną dopuszczalną liczbę zapytań do interfejsu programistycznego API w jednostce czasu) sprawia, że serwery sklepowe lub marketplace zaczynają odrzucać połączenia i zwracać błędy komunikacji. W efekcie najważniejsze dane, w tym informacje o nowo opłaconych zamówieniach, nie trafiają do realizacji na czas. Rozwiązaniem jest rozbicie procesów wymiany danych na niezależne strumienie o zróżnicowanych częstotliwościach i priorytetach wykonania.

Priorytetyzacja danych i optymalne częstotliwości wymiany informacji

Prawidłowo skonfigurowany harmonogram opiera się na kategoryzacji przesyłanych informacji według ich wpływu na ciągłość procesów handlowych oraz stopnia obciążenia bazy danych i łącza sieciowego.

Stany magazynowe i dostępność asortymentu:

Jest to obszar o najwyższym priorytecie operacyjnym. Zbyt długie odstępy między aktualizacjami liczby dostępnych sztuk prowadzą do zjawiska nadmiernej sprzedaży (ang. overselling, czyli sytuacji, w której klient kupuje w sklepie internetowym towar, którego fizycznie nie ma już na magazynie). W przypadku stanów magazynowych stosuje się synchronizację różnicową (ang. delta sync, czyli przesyłanie wyłącznie tych pozycji, w których zaszła jakakolwiek zmiana ilościowa od ostatniego cyklu). Zalecany interwał wynosi zazwyczaj od 1 do 5 minut lub następuje w czasie zbliżonym do rzeczywistego (ang. near real-time) w oparciu o triggery bazodanowe (procedury automatycznie wykrywające modyfikację rekordu w bazie ERP).

Nowe zamówienia i rezerwacje towarowe:

Pobieranie zamówień z platform sprzedażowych (takich jak BaseLinker, WooCommerce, PrestaShop, Magento, Shopify czy Allegro) wymaga wysokiej częstotliwości. Standardowy interwał wynosi od 2 do 10 minut. Sprawne wprowadzenie zamówienia do systemu ERP pozwala na natychmiastowe utworzenie dokumentu rezerwacji (np. zamówienia od klienta ZK), co automatycznie pomniejsza stan dyspozycyjny towaru i chroni przed jego powtórną sprzedażą na innym kanale handlowym.

Ceny towarów, promocje i waluty:

Cenniki nie ulegają tak dynamicznym zmianom jak stany magazynowe w ciągu dnia. Przesyłanie informacji o cenach standardowych, rabatach i promocjach konfiguruje się zazwyczaj w cyklach od 30 do 60 minut. W przypadku planowanych akcji marketingowych lub masowej zmiany cennika w dziale handlowym proces ten może być również wyzwalany ręcznie na żądanie (ang. on-demand) przez uprawnionego użytkownika.

Kartoteki produktowe, opisy, parametry i zdjęcia:

Dane asortymentowe charakteryzują się dużą objętością bajtową, szczególnie gdy zawierają pliki graficzne w wysokiej rozdzielczości oraz rozbudowane formatowanie HTML w opisach. Przesyłanie tych danych w ciągu dnia roboczego może niepotrzebnie obciążać łącze internetowe i blokować zasoby bazy danych. Z tego względu pełną synchronizację kartotek konfiguruje się w oknie nocnym (poza godzinami pracy biura i magazynu) lub w trybie selektywnym, obejmującym wyłącznie nowo dodane towary.

Dane kontrahentów i dokumenty rozliczeniowe:

Wymiana informacji o płatnościach, fakturach oraz paragonach elektronicznych odbywa się w trybie przetwarzania wsadowego (ang. batch processing, czyli grupowania wielu transakcji w jedną paczkę danych). Interwał wynosi zazwyczaj od kilkunastu minut do kilku godzin, w zależności od przyjętego w przedsiębiorstwie modelu księgowania.

Warianty architektury wymiany danych i modele harmonogramowania

W zależności od możliwości technicznych posiadanego oprogramowania magazynowego oraz silnika sklepu internetowego stosuje się różne modele architektury wymiany informacji.

Model odpytywania cyklicznego (ang. polling):

W tym układzie integrator w stałych odstępach czasu wysyła zapytania do bazy danych lub interfejsu API z pytaniem o nowe rekordy. Aby model ten działał wydajnie, zapytania muszą korzystać ze znaczników czasu modyfikacji (ang. timestamp, czyli pola przechowującego datę i godzinę ostatniej zmiany) oraz odpowiednich indeksów w bazie danych. Pozwala to na pobieranie jedynie ułamka danych zamiast skanowania całych tabel.

Model sterowany zdarzeniami (ang. event-driven):

Wykorzystuje mechanizm powiadomień sieciowych (ang. webhooks, czyli automatyczne wywołanie adresu URL przez system źródłowy w momencie wystąpienia konkretnego zdarzenia, na przykład złożenia nowego zamówienia przez kupującego). Model ten eliminuje konieczność ciągłego odpytywania serwera, zapewniając natychmiastowe przekazanie informacji przy minimalnym zużyciu zasobów.

Kolejki zadań i buforowanie komunikatów:

W przypadku intensywnej sprzedaży liczba zdarzeń może gwałtownie wzrosnąć. Wdrożenie kolejki komunikatów (ang. message queue, czyli bufora pośredniczącego, takiego jak RabbitMQ lub Redis) pozwala na kolejkowanie operacji i ich płynne, sekwencyjne przetwarzanie. Zapobiega to sytuacji, w której nagły napływ dużej liczby zamówień jednocześnie blokuje bazę danych programu magazynowego.

Harmonogramowanie hybrydowe:

Najbardziej stabilne środowiska łączą zalety kilku rozwiązań. Zamówienia pobierane są natychmiast za pomocą webhooków, stany magazynowe aktualizują się w krótkich cyklach różnicowych, natomiast raz na dobę w godzinach nocnych uruchamiana jest synchronizacja uzgadniająca (ang. reconciliation sync), która porównuje całe bazy danych i koryguje ewentualne drobne niespójności powstałe w ciągu dnia.

Najczęstsze błędy przy samodzielnej konfiguracji harmonogramów

Niewłaściwe ustawienie parametrów wymiany danych często prowadzi do powtarzających się awarii i błędów w stanach towarowych.

Nakładanie się cykli synchronizacji (ang. process overlapping):

Jest to jeden z najgroźniejszych błędów konfiguracyjnych. Występuje wtedy, gdy zadanie synchronizacji zostaje zaplanowane na przykład co 60 sekund, podczas gdy przetworzenie dużej paczki danych zajmuje 90 sekund. Jeśli integrator nie posiada mechanizmu blokady jednoczesnego uruchomienia (ang. mutex lub pliku znacznikowego lockfile informującego, że poprzedni proces wciąż trwa), system uruchamia drugą kopię zadania. Dwa procesy zaczynają równolegle modyfikować te same tabele w bazie danych, co wywołuje zakleszczenia, błędy integralności i gwałtowny wzrost obciążenia serwera.

Brak synchronizacji różnicowej:

Przesyłanie całej bazy asortymentowej liczącej kilkadziesiąt tysięcy pozycji przy każdym uruchomieniu harmonogramu niepotrzebnie marnuje zasoby sieciowe i pamięć serwera. Bez filtrowania po dacie ostatniej modyfikacji proces synchronizacji trwa zbyt długo i destabilizuje pracę całego środowiska IT.

Nieuwzględnienie limitów zapytań API:

Zbyt agresywny harmonogram wysyłania żądań do zewnętrznych platform handlowych prowadzi do nałożenia tymczasowej blokady konta przez serwery marketplace. Skutkuje to kodem błędu HTTP 429 (Too Many Requests) i brakiem aktualizacji stanów przez kilkadziesiąt minut lub nawet kilka godzin.

Pętle wzajemnej aktualizacji (ang. update loops):

Błąd w logice integracji polegający na tym, że zmiana stanu magazynowego wysłana ze sklepu do programu ERP zostaje zarejestrowana jako modyfikacja rekordu w ERP. Następnie harmonogram wysyłający dane z ERP do sklepu interpretuje tę modyfikację jako nową informację i przesyła ją z powrotem do sklepu. W ten sposób powstaje niekończąca się pętla generująca tysiące zbędnych zapytań.

Brak monitoringu i powiadomień o błędach:

Często zdarza się, że harmonogram ulega zawieszeniu w tle na skutek chwilowego braku łączności internetowej, a właściciel firmy dowiaduje się o awarii dopiero po kilku dniach, gdy kupujący zaczynają zgłaszać brak wysyłki towaru. Brak automatycznych powiadomień o błędach (ang. error alerting) uniemożliwia szybką reakcję.

Kiedy problem nie tkwi w harmonogramie, lecz w bazie danych lub infrastrukturze

Nie każde opóźnienie w synchronizacji wynika ze złego ustawienia interwałów czasowych. Często źródło problemu leży głębiej, w konfiguracji sprzętowej lub bazodanowej.

Zakleszczenia transakcyjne (ang. deadlock):

Sytuacja w silniku bazy danych Microsoft SQL Server, w której dwa niezależne procesy (np. pracownik wystawiający dokument w programie Subiekt lub Comarch Optima oraz integrator zapisujący nowe zamówienie ze sklepu) blokują sobie nawzajem dostęp do tych samych zasobów tabelarycznych. Silnik bazy danych jest zmuszony do przymusowego przerwania jednego z procesów (tzw. deadlock victim), co skutkuje błędem zapisu danych po stronie integratora.

Brak indeksów w bazie danych:

Jeśli tabele przechowujące kartoteki towarowe i historię zmian nie posiadają odpowiednich indeksów bazodanowych (struktur przyspieszających wyszukiwanie rekordów, np. indeksów B-drzewa), każde zapytanie integratora zmusza serwer do pełnego przeszukiwania całej tabeli (ang. table scan). Przy kilkuset tysiącach pozycji w magazynie czas odpowiedzi bazy drastycznie rośnie.

Niespójne identyfikatory asortymentowe:

Błędy w kodach EAN (ang. European Article Number, czyli unikalnych kodach kreskowych) lub zduplikowane symbole SKU (ang. Stock Keeping Unit, czyli wewnętrzne kody towarowe) powodują, że integrator nie może jednoznacznie dopasować produktu ze sklepu do kartoteki w programie magazynowym. Prowadzi to do powtarzania zapytań, generowania błędów w dziennikach zdarzeń i pomijania synchronizacji określonych pozycji.

Ograniczenia łącza i opóźnienia sieciowe (ang. latency):

W firmach korzystających z lokalnego serwera bazy danych i łączących się z chmurowym sklepem internetowym wąskim gardłem bywa niestabilne łącze internetowe lub niska prędkość wysyłania danych (ang. upload). Powoduje to przekraczanie limitów czasu oczekiwania na odpowiedź (ang. timeout) i przerywanie transmisji.

Etapy profesjonalnej konfiguracji i optymalizacji harmonogramów

Prawidłowe wdrożenie harmonogramu wymiany danych wymaga metodycznego podejścia i analizy specyfiki działalności handlowej danego przedsiębiorstwa.

Audyt przepływu informacji i wolumenu sprzedaży:

Analizujemy liczbę produktów, średnią liczbę zamówień na dobę, szczytowe godziny aktywności kupujących oraz strukturę bazy danych programu magazynowego (np. Subiekt GT, Subiekt nexo, Comarch ERP Optima, Comarch ERP XL, WAPRO Mag, Symfonia, enova365, RAKS).

Segmentacja strumieni danych i dobór interwałów:

Rozdzielamy procesy na niezależne wątki robocze. Konfigurujemy krótkie pętle dla stanów magazynowych i zamówień, średnie dla cen oraz dedykowane okna nocne dla pełnej synchronizacji kartotek towarowych i zdjęć.

Konfiguracja mechanizmów zabezpieczających i buforowania:

Wdrażamy blokady procesów (mutex), aby wyeliminować ryzyko nakładania się cykli. Konfigurujemy politykę ponawiania prób (ang. retry policy) z wykładniczym opóźnieniem czasowym (ang. exponential backoff), co zabezpiecza integrację przed chwilowymi przerwami w dostępie do sieci.

Optymalizacja zapytań i indeksacja bazy danych:

Sprawdzamy zapytania wysyłane przez integratora do silnika SQL. W razie potrzeby dodajemy brakujące indeksy na kolumnach dat modyfikacji, co skraca czas wykonywania zapytań z kilkunastu sekund do kilku milisekund.

Uruchomienie monitoringu i testy obciążeniowe:

Konfigurujemy rejestrowanie zdarzeń (logowanie) oraz mechanizmy alertów informujących o ewentualnych błędach transmisji. Przeprowadzamy testy symulujące wysokie obciążenie, upewniając się, że praca integratora nie spowalnia codziennych operacji personelu w biurze i magazynie.

Najczęściej zadawane pytania (FAQ)

Jak często powinny aktualizować się stany magazynowe w sklepie internetowym?

Dla większości sklepów optymalny interwał wynosi od 1 do 5 minut przy zastosowaniu synchronizacji różnicowej (przesyłanie tylko pozycji, w których zmieniła się ilość). Pozwala to utrzymać aktualną dostępność towaru na wielu kanałach sprzedaży bez przeciążania serwera bazy danych.

Dlaczego program magazynowy w biurze zwalnia podczas działania integratora?

Spowolnienie wynika zazwyczaj z wykonywania zbyt częstych, nieoptymalnych zapytań do bazy danych Microsoft SQL Server lub braku odpowiednich indeksów. Gdy integrator odpytuje bazę o całą kartotekę produktów, blokuje tabele, uniemożliwiając pracownikom płynne wystawianie dokumentów sprzedażowych i magazynowych.

Co oznacza błąd HTTP 429 pojawiający się w logach integracji?

Błąd HTTP 429 (Too Many Requests) oznacza przekroczenie dopuszczalnego limitu zapytań narzuconego przez interfejs programistyczny API platformy sprzedażowej lub marketplace (np. Allegro). Wskazuje to na zbyt agresywny harmonogram odpytywania, który wymaga zmniejszenia częstotliwości zapytań lub wprowadzenia mechanizmu kolejkowania.

Czy można synchronizować zamówienia natychmiast po ich złożeniu przez klienta?

Tak, jest to możliwe przy wykorzystaniu architektury sterowanej zdarzeniami (webhooks). Sklep internetowy lub platforma handlowa natychmiast po złożeniu zamówienia wysyła powiadomienie do integratora, który tworzy rezerwację w systemie ERP, eliminując potrzebę ciągłego odpytywania serwera.

Jak zabezpieczyć system przed nakładaniem się kolejnych cykli synchronizacji?

Stosuje się mechanizm blokad programowych (ang. mutex lub pliki lockfile). Przed rozpoczęciem pracy integrator sprawdza, czy poprzedni proces został zakończony. Jeśli zadanie wciąż trwa, nowe uruchomienie zostaje wstrzymane lub odłożone w czasie, co zapobiega dublowaniu procesów i zawieszaniu bazy danych.

Prawidłowy harmonogram jako fundament stabilnego handlu wielokanałowego

Właściwe skonfigurowanie harmonogramu synchronizacji danych eliminuje ryzyko zablokowania sprzedaży, zapobiega powstawaniu rozbieżności magazynowych i gwarantuje komfortową pracę personelu na systemach ERP. Precyzyjny dobór priorytetów i interwałów czasowych pozwala na stabilne skalowanie sprzedaży wielokanałowej bez konieczności ponoszenia kosztów na niepotrzebną rozbudowę infrastruktury serwerowej.

22 378 48 09

Harmonogram synchronizacji — częstotliwość i priorytety wymiany danych