Správné umístění cyklovače nebo terminace v rámci akce zásadně ovlivňuje, jak se systém chová při výskytu chyby.
Z hlediska spolehlivosti je proto nezbytné rozumět tomu, kdy se cyklus naplánuje, kdy se zastaví a co se stane, pokud dojde k chybě v průběhu akce.

1. Cyklovač na začátku akce

Cyklovač umístěný na začátku akce se vyhodnocuje ještě před provedením jakéhokoli jiného kroku.
Pokud je jeho podmínka splněna, akce se okamžitě zaregistruje jako opakovaná úloha v plánu serveru. To má zásadní důsledek:
jestliže později během běhu akce nastane chyba (např. neúspěšné volání API, chybějící data, přetížení databáze apod.), server úlohu znovu spustí podle plánu — i s chybou, která nebyla odstraněna.
Akce se tedy může spouštět opakovaně v chybovém stavu, dokud:

cyklovač nezjistí, že jeho podmínka už neplatí, nebo



správce akci ručně neukončí, případně



nezasáhne omezovač cyklovače, který limituje maximální počet opakování.

Tento typ chování je vhodný pouze tam, kde dočasná chyba může sama pominout (např. výpadek služby, dočasné zpoždění dat).
V opačném případě může dojít k nekonečnému opakování chybných běhů.

2. Cyklovač uvnitř nebo na konci akce

Pokud je cyklovač umístěn až po hlavních fázích akce, vyhodnocuje se až po jejich dokončení.
V případě, že v předchozí části akce dojde k chybě, cyklovač se vůbec nespustí – tudíž se nenaplánuje nový běh. To je z hlediska bezpečnosti výhodné – systém se automaticky zastaví při chybě a nevytváří další úlohy, které by selhávaly.
Nevýhodou je, že se tím přeruší i proces, který by se jinak mohl po odstranění drobné chyby sám obnovit.

3. Terminace a reakce na chyby

U terminací ( act:termination) je chování jednoznačnější.
Terminace je vyhodnocována až po úspěšném dokončení celé fáze.
Pokud dojde k chybě před terminací, další běh akce se nenaplánuje. Tím je zaručeno, že se systém nikdy nedostane do smyčky opakovaných chyb.
Terminace je proto ideálním řešením pro akce, které musí mít jasně řízený konec a kde je nepřípustné samovolné zacyklení (např. importy, generování faktur, mazání dat apod.).

4. Praktický příklad: Import dat z API

Uvažujme akci, která importuje nová data z externí služby (např. CRM nebo fakturačního systému).
Akce má několik fází:

Načtení seznamu záznamů ke zpracování.



Odeslání požadavku na API.



Zpracování odpovědi a zápis do databáze.

Varianta A – cyklovač na začátku akce

Cyklovač vyhodnotí, že ve zdroji existují nové položky → akce se naplánuje k opakování každých 5 minut.
Pokud API přestane odpovídat, každé další spuštění skončí chybou, ale úloha se dál opakuje.
Bez omezovače by takto běžela do nekonečna, generovala logy a zatěžovala server.

Varianta B – cyklovač na konci akce

Akce se spustí, proběhne načtení i zpracování.
Pokud během volání API dojde k chybě, cyklovač na konci se již neprovede → další běh se nenaplánuje.
Po odstranění chyby je nutné akci spustit ručně nebo ji nechat znovu spustit plánovačem.

Varianta C – terminace

Akce se provede v plném rozsahu, a pokud všechna volání API proběhnou bez chyb, terminace na konci fáze naplánuje jedno další spuštění (např. po 10 minutách).
Pokud dojde k chybě v libovolném kroku, terminace se nevyhodnotí a nový běh se nenaplánuje.
Tím se zabrání nekonečnému cyklu, ale zároveň se zachová kontrola nad pravidelným zpracováním.

5. Doporučení pro návrh a testování

Cyklovač používej pouze v akcích, které musí běžet opakovaně a automaticky, např. pravidelné dávkové zpracování nebo synchronizace.



Při umístění cyklovače na začátek vždy definuj omezení počtu cyklů a zajisti, že chyba v průběhu akce nezpůsobí opakované spouštění.



Terminace je vhodnější pro procesy, které se mají po chybě zastavit a čekat na ruční zásah.



Testuj chování při simulovaných chybách, zejména u akcí s externími službami, aby se potvrdilo, že nedochází k nežádoucímu opakování.



Pro klíčové akce zvaž kombinaci s interním alertem (např. e-mail o chybě v joblogu), aby byla chyba včas detekována a cyklus mohl být bezpečně zastaven.