Niezawodna automatyzacja w n8n – 7 zasad na przykładzie klasyfikatora zamówień z BaseLinkera

Pierwszą automatyzację w n8n da się złożyć w godzinę: wyzwalacz, pobranie danych, zapis. Działa na testowych danych, działa przez tydzień. A potem przychodzi poniedziałek, w którym API zwraca błąd, poprzedni przebieg jeszcze się nie skończył albo ktoś zmienił plik z cennikiem – i automatyzacja po cichu zapisuje złe dane w setkach zamówień.

Różnica między automatyzacją „na pokaz” a taką, której można zaufać, nie leży w samym n8n, tylko w kilku nawykach. Pokażę je na prawdziwym workflow z wdrożenia: klasyfikatorze zamówień dla pakowni sklepu internetowego, który co 5 minut pobiera nowe zamówienia, dopasowuje produkty do katalogu i wag, a wynik zapisuje w polu zamówienia w BaseLinkerze.

1Wszystkie ustawienia w jednym bloczku

Zaraz za wyzwalaczami stoi bloczek Ustawienia. Trzyma wszystko, co może się zmienić: identyfikator pola w BaseLinkerze, adres do powiadomień, progi klasyfikacji, przełącznik „tylko podgląd, bez zapisu”. Pozostałe bloczki czytają wartości stąd, zamiast mieć je wpisane na sztywno.

Efekt jest prosty: gdy klient zmieni pole w BaseLinkerze albo osobę odpowiedzialną za pakowanie, poprawiam jedną wartość, a nie szukam jej w dziesięciu miejscach. Dwa wyzwalacze – co 5 minut i uruchom ręcznie – prowadzą do tego samego miejsca, więc test ręczny działa dokładnie tak jak przebieg produkcyjny.

2Blokada: jeden przebieg naraz

Harmonogram „co 5 minut” nie czeka, aż poprzedni przebieg się skończy. Jeśli baza odpowiada wolniej albo API BaseLinkera zwalnia, dwa przebiegi mogą przetwarzać te same zamówienia jednocześnie – i zapisać je dwa razy albo nadpisać sobie nawzajem wynik.

Dlatego drugim krokiem jest Blokada: na starcie przebieg sprawdza, czy inny nie jest w toku, i jeśli jest – kończy się bez robienia czegokolwiek. Blokada ma też czas wygaśnięcia, żeby jeden przerwany przebieg nie zatrzymał automatyzacji na zawsze.

3Każde źródło danych ma swoje wyjście „Error”

Na zrzucie widać, że bloczki Zamówienia (zapytanie do bazy), Katalog i Wagi mają po dwa wyjścia: Success i Error. To ustawienie n8n, które zamiast przerywać cały workflow przy błędzie, przekazuje go dalej osobną ścieżką.

Dzięki temu wiem nie tylko, że coś poszło nie tak, ale też gdzie: czy baza była niedostępna, czy ktoś usunął arkusz z wagami, czy w katalogu pojawił się wiersz bez kodu produktu. Wszystkie te ścieżki zbiegają się w jednym bloczku Treść błędu, który składa czytelny komunikat.

4Zapisuj tylko to, co się zmieniło

Po Klasyfikacji jest warunek Zapisywać?. Zamówienie trafia do zapisu tylko wtedy, gdy nowy wynik różni się od tego, który już jest w BaseLinkerze. Reszta przechodzi od razu do podsumowania.

Powody są dwa. BaseLinker ogranicza liczbę zapytań do API w ciągu minuty, więc wysyłanie co 5 minut tych samych wartości dla wszystkich zamówień szybko zjadłoby limit. A każdy zbędny zapis to dodatkowy wpis w historii zamówienia i dodatkowe ryzyko, że w razie błędu zepsuje się coś, co było dobre.

5„200 OK” to jeszcze nie sukces

Zapis idzie przez BL zapis pola – zapytanie HTTP do API BaseLinkera. Pułapka polega na tym, że API BaseLinkera odpowiada kodem HTTP 200 także wtedy, gdy operacja się nie udała. Informacja o błędzie jest w treści odpowiedzi, w polu status z wartością ERROR i kodzie błędu.

Workflow, który patrzy tylko na kod HTTP, uzna taki zapis za udany. Dlatego za zapisem stoi osobny bloczek Sprawdź zapis, który czyta odpowiedź i dopiero na jej podstawie kieruje zamówienie do podsumowania albo na ścieżkę błędu.

6Błąd ma być głośny – ale nie co 5 minut

Dolna część workflow to obsługa awarii: Treść błędu → Wysłać mail? → Mail o błędzie → Zatrzymaj z błędem.

• Wysłać mail? pilnuje, żeby przy dłuższej awarii nie dostawać tej samej wiadomości przy każdym przebiegu. Jedna informacja o problemie wystarczy, kolejna dopiero gdy sytuacja się zmieni.
• Mail o błędzie mówi, co się stało, w którym kroku i których zamówień dotyczy – tak, żeby dało się zareagować bez logowania do n8n.
• Zatrzymaj z błędem kończy przebieg jako nieudany. W historii wykonań n8n taki przebieg jest od razu oznaczony na czerwono, zamiast udawać, że wszystko poszło dobrze.

7Podsumowanie każdego przebiegu

Ostatni bloczek, Podsumowanie, zbiera wynik: ile zamówień pobrano, ile zaklasyfikowano, ile zapisano, ile pominięto bez zmian. Normalnie nikt na to nie patrzy. Ale gdy pakowacz mówi „to zamówienie miało złą klasyfikację”, w historii wykonań widać dokładnie, kiedy i z jakim wynikiem było przetwarzane.

Dlaczego n8n, a nie skrypt?

To samo dałoby się napisać w Pythonie i uruchamiać z harmonogramu – i czasem tak robię. n8n wygrywa tam, gdzie automatyzacja ma żyć latami i być utrzymywana także przez kogoś innego:

• przepływ widać na jednym ekranie – łatwo wytłumaczyć go klientowi i nowej osobie,
• historia wykonań z danymi każdego kroku jest wbudowana, nie trzeba pisać własnego logowania,
• nieudany przebieg można ponowić jednym kliknięciem,
• tam, gdzie gotowe bloczki nie wystarczają, wstawia się własny kod JavaScript – jak w bloczkach klasyfikacji na zrzucie.

Lista kontrolna przed uruchomieniem automatyzacji

1. Czy ustawienia są w jednym miejscu, a nie rozsiane po bloczkach?
2. Czy dwa przebiegi naraz mogą coś zepsuć – i czy jest blokada?
3. Czy każde źródło danych ma obsłużony błąd?
4. Czy zapisujesz tylko zmiany?
5. Czy sprawdzasz treść odpowiedzi API, a nie tylko kod HTTP?
6. Czy o błędzie dowie się właściwa osoba – raz, a nie sto razy?
7. Czy po fakcie da się sprawdzić, co automatyzacja zrobiła z konkretnym rekordem?

Jeśli na któreś z tych pytań odpowiedź brzmi „nie”, automatyzacja prędzej czy później zrobi coś, czego nikt nie zauważy na czas.