Kako v n8n ujeti napako, preden avtomatizacija odpove v tišini

|Avtor: Uredništvo QUASA|5 min branja| 1
Kako v n8n ujeti napako, preden avtomatizacija odpove v tišini

V n8n nastavite ločen delovni tok z vozliščem Error Trigger in ga v nastavitvah povezane avtomatizacije izberite kot Error workflow. Ob neuspešni samodejni izvedbi lahko ta tok pošlje opozorilo; navodila n8n za Error Trigger opisujejo tudi pomembno mejo: ročni zagon osnovnega toka opozorilnega toka ne sproži.

Opozorilo naj pove, kateri tok je odpovedal, v katerem vozlišču in s kakšno napako. Nato ločite prehodno motnjo od napake, ki zahteva popravek, ter omejite ponavljanje. Pred ponovnim pošiljanjem e-pošte ali ustvarjanjem zapisa preverite še izid prejšnjega poskusa: neuspešna izvedba lahko vsebuje dejanje, ki je v ciljni storitvi že uspelo.

Kako povezati ločen tok za napake

Ustvarite nov delovni tok, na začetek postavite Error Trigger, za njim pa vozlišče za pripravo sporočila in vozlišče za njegovo dostavo. Tok shranite. V osnovnem toku odprite Options, nato Settings, v polju Error workflow izberite shranjeni opozorilni tok in nastavitev shranite. Isti opozorilni tok lahko dodelite več avtomatizacijam, zato v sporočilo vključite ime izvornega toka.

Za preskus pripravite samodejno sprožen preskusni tok z vozliščem Stop And Error in mu dodelite isti Error workflow. Ko se preskusna izvedba ustavi, preverite, ali je opozorilo prispelo in ali ga prejme prava oseba. Zagon z ročnim gumbom za izvajanje ni ustrezen preskus Error Triggerja; pomembno je, da napaka nastane v samodejni izvedbi.

Če napako obravnavate v samem osnovnem toku, določite, kaj pomeni uspeh te veje. Nadaljevanje po napaki je smiselno, kadar je nadomestni korak res opravil zahtevano delo ali je poslal svoje opozorilo. Sicer lahko tok doseže konec, čeprav sporočilo ni bilo poslano ali zapis ni nastal, zato ločeni tok za neuspešne izvedbe ne dobi razloga za odziv.

Kaj mora povedati opozorilo

Error Trigger v n8n iz podatkov o neuspešni izvedbi pripravi opozorilo z imenom toka, vozliščem in sporočilom napake.

V sporočilu navedite ime delovnega toka, zadnje izvedeno vozlišče in sporočilo napake. Če sta na voljo, dodajte povezavo do izvedbe in njen identifikator, da prejemnik odpre pravi zapis v zgodovini. Pri napaki sprožilnega vozlišča se osnovni tok še ni izvedel, zato lahko identifikator in povezava manjkata; predloga sporočila mora ostati razumljiva tudi v tem primeru.

Opozorilo naj omogoči odločitev o naslednjem dejanju. Napaka pri preverjanju vhodnih podatkov zahteva drug odziv kot nedosegljiva zunanja storitev. Časovna omejitev pri pošiljanju e-pošte pa lahko pusti nejasen izid: zahteva je morda dosegla ponudnika, odgovor pa se ni vrnil v n8n. V takem primeru oznaka »neuspešno« v zgodovini še ne pove, ali je prejemnik sporočilo dobil.

Preverite tudi pot samega opozorila. Če osnovni tok in opozorilni tok uporabljata isto nedosegljivo storitev, lahko odpove še dostava obvestila. Za pomembno avtomatizacijo izberite drug kanal oziroma predvidite nadomestno dostavo. Tako napaka v glavnem toku ne ostane skrita zgolj zato, ker je odpovedala tudi pot do prejemnika opozorila.

Kdaj ponoviti vozlišče in kdaj vključiti človeka

Za kratkotrajne motnje uporabite nastavitev Retry On Fail na ustreznem vozlišču, ne na celotni avtomatizaciji. Opis nastavitev vozlišč n8n loči ponavljanje od možnosti On Error: Stop Workflow ustavi tok, Continue ga nadaljuje, Continue (using error output) pa napako preda naslednjemu vozlišču. Če želite, da po izčrpanih poskusih posreduje ločeni opozorilni tok, neuspeha ne skrijte z nadaljevanjem brez obravnave.

Število poskusov in premor med njimi omejite glede na dejanje ter pravila ciljne storitve. Kratka motnja povezave lahko mine; napačne poverilnice, manjkajoč obvezen podatek ali neveljaven naslov se s čakanjem praviloma ne popravijo. Takšne napake pošljite v pregled skupaj z dovolj podatki, da je mogoče popraviti vhod, dostop ali nastavitev.

Odločitev o ponovitvi sprejmite tudi glede na posledico, ne samo glede na besedilo napake. Branje podatkov je običajno lažje varno ponoviti kot ustvarjanje naročila ali pošiljanje sporočila. Kadar ciljne storitve po nejasnem odgovoru ne morete vprašati, ali je dejanje uspelo, samodejno ponavljanje zadrži in primer predajte človeku.

Kako preprečiti dvojno e-pošto in podvojene zapise

Ponovljeno dejanje v n8n uporabi isti stabilni ključ in ohrani en zapis namesto dveh.

Pri ročni ponovitvi neuspešne izvedbe n8n uporabi shranjeno stanje. Navodila n8n za ponovitev izvedbe pojasnjujejo, da se dokončana vozlišča ne izvajajo znova, neuspešno vozlišče pa ponovno obdela vse svoje shranjene vhodne elemente, tudi tiste, ki jih je pred napako morda že obdelalo. Če je odpovedalo vozlišče Execute Sub-workflow, se podtok pri ponovitvi začne od začetka.

Za zapis določite stabilen ključ poslovnega dejanja, na primer identifikator naročila skupaj z vrsto opravila. Isti ključ mora spremljati prvi poskus in vse ponovitve; identifikator posamezne izvedbe n8n za to ni primeren, ker opisuje poskus, ne naročila. Kjer ciljna zbirka ali storitev to omogoča, naj zapis z obstoječim ključem posodobi ali vrne, namesto da ustvari novega. Preverjanje in ustvarjanje naj bosta v ciljnem sistemu povezana z enoličnostjo ključa, sicer lahko sočasna poskusa oba ugotovita, da zapisa še ni.

Pri e-pošti je meja strožja. Zapis, da je bilo sporočilo poslano, pomaga le, če je zanesljivo povezan z odgovorom ponudnika. Če je ponudnik sporočilo sprejel, n8n pa odgovora ni prejel, lahko naslednji poskus ustvari dvojnik; če označite pošiljanje kot končano prezgodaj, ga lahko izpustite. Kjer ponudnik ne omogoča preverjanja pošiljke ali idempotentnega zahtevka, nejasen izid pošljite v pregled.

V zavihku Executions izberite konkretno neuspešno izvedbo šele po odpravi znanega vzroka. Če ste spremenili potek, izberite Retry with currently saved workflow; če želite uporabiti prvotno različico, izberite Retry with original workflow. Pred potrditvijo preverite ciljna dejanja neuspešnega vozlišča in podtoka. Nov zagon iz sprožilca je drugačna odločitev od ponovitve shranjene izvedbe, saj lahko ponovno doseže tudi prej dokončane korake.

Kako zaznati opravilo, ki obstane brez napake

Error Trigger se odzove na neuspeh izvedbe. Opravilo lahko ostane v čakanju, se ne sproži ob pričakovanem dogodku ali konča po veji, ki ni opravila poslovnega dela. Za takšne primere določite opazen znak dokončanja, na primer stanje obdelanega naročila ali zabeležen rezultat pošiljanja. Znak naj pripada opravilu, ne zgolj uspešnemu statusu tehnične izvedbe.

Ločen časovno sprožen nadzorni tok lahko poišče opravila, ki po dogovorjenem roku še nimajo tega znaka, in pošlje opozorilo za pregled. Rok določite glede na običajno trajanje konkretnega procesa, da legitimnega čakanja ne označite kot odpovedi. Pred ponovitvijo takega opravila preverite njegov stabilni ključ in stanje v ciljni storitvi: odsoten zaključni znak še ne pomeni, da prejšnji poskus ni povzročil zunanjega dejanja.

Preberite tudi:

Deli:

Naročite se na naše e-novice

Najnovejše novice o Web3, UI in kriptovalutah neposredno v vaš e-poštni predal.

0