Przepływy: przy zapisie czy według harmonogramu?
- Przepływy przy zapisie działają w żądaniu zapisującym — relacje i obiekty następcze często nie są jeszcze ustawione.
- Przepływy harmonogramu oddzielają interfejs i pracę, ale wymagają Cron, obserwacji i idempotencji.
- Błędne modelowanie objawia się pustymi e-mailami, wiszącymi żądaniami lub podwójnymi działaniami — nie abstrakcyjnym błędem teorii.
Przepływy pracy w SuiteCRM (historycznie Advanced Open Workflow) pozwalają wykonywać warunkowe działania na poziomie modułu. W praktyce rzadziej zawodzą przez silnik, częściej przez błędne założenia dotyczące momentu, w którym dane są kompletne, a relacje ustawione. Artykuł przybliża decyzję architektoniczną — z pomocą decyzyjną, porównaniem cykli życia i listą testów.
Jaki typ przepływu pasuje do Twojego przypadku?
Dwa pytania — jedna rekomendacja. Nie zastępuje testów środowiska próbnego, ale filtruje najczęstszy błędny wybór.
Odpowiedni dla obliczeń lub zmian statusu tego samego rekordu, bez zależnych relacji i zauważalnego oczekiwania.
1. Dwa cykle życia — synchroniczny i asynchroniczny
Zamiast abstrakcyjnych definicji przyjrzyjmy się przebiegowi rzeczywiście doświadczanemu przez użytkownika i system:
Cykl życia przy zapisie
- 1 Użytkownik klika Zapisz
- 2 Trwa żądanie HTTP — przeglądarka czeka
- 3 Walidacja i hooki Before-Save
- 4 Zapis bazy danych (INSERT/UPDATE)
- 5 Przepływ przy zapisie: ewentualnie e-maile, webhooki, kolejne zapisy
- 6 Odpowiedź do przeglądarki
Cykl życia harmonogramu
- 1 Użytkownik zapisuje — szybka odpowiedź
- 2 Interfejs znów dostępny
- 3 Oddzielone czasowo: Cron/Worker
- 4 Zadanie odczytuje bieżący stan bazy (relacje zwykle już istnieją)
- 5 Działania partiami bez blokowania interfejsu
- 6 Ustaw znacznik statusu/idempotencji
2. Skrócona pomoc decyzyjna
| Pytanie projektowe | Raczej przy zapisie | Raczej harmonogram |
|---|---|---|
| Powiązany rekord powstaje dopiero po zapisie? | niekorzystne | odpowiednie |
| Użytkownik potrzebuje natychmiast widocznego pola/odpowiedzi? | odpowiednie | opóźnione |
| Zewnętrzne API z zauważalnym opóźnieniem? | ryzykowne w żądaniu | lepiej |
| Duże ilości / nocne przebiegi? | nieodpowiednie | planuj z filtrami |
3. Trzy pułapki architektury
Iluzja panelu podrzędnego
Identyfikator głównego rekordu może już istnieć podczas zapisu, podczas gdy powiązane rekordy paneli podrzędnych są zapisywane później w transakcji lub w kolejnym kroku. Przepływ przy zapisie oczekujący kontaktu przy ofercie nie znajdzie go, mimo że użytkownik właśnie ustawił powiązanie w interfejsie. Środek zaradczy: Harmonogram lub świadomy drugi krok, gdy relacja na pewno jest czytelna.
Rekurencyjna pętla bez końca
Przepływ zmienia pole → ponownie uruchamia zapis → przepływ działa ponownie → aż do limitu czasu lub pamięci. Szczególnie podstępne, gdy warunek i cel zapisu dotyczą tego samego pola. Środek zaradczy: jawny znacznik przetwarzania, warunki sprawiające, że drugi przebieg nic nie robi, bez zbędnych zapisów w łańcuchu.
Nieograniczony przebieg harmonogramu
Przepływ harmonogramu bez ścisłych filtrów daty/statusu po latach eksploatacji może dotykać ogromnych zasobów historycznych przy każdym przebiegu Cron. System nagle zwalnia, choć przepływ zawsze był taki sam. Środek zaradczy: ścisłe kryteria wyboru, status już przetworzone, obserwacja czasu wykonania i obciążenia.
4. Gotowość wdrożenia: protokół testowy do odhaczenia
Uruchomienie produkcyjne bez tych pięciu dowodów to działanie po omacku — niezależnie od wybranego wyzwalacza.
Lista kontrolna środowiska testowego
Ta Workflow Engine w AgenticUltimate opiera się na modelowaniu wizualnym, symulacji i zatwierdzaniu wersji — aby przepływy nie trafiały niezauważone do produkcji. Biznesowy wybór między zapisem a harmonogramem pozostaje decyzją architektoniczną; symulacja nie zastępuje żadnej z pięciu kontroli powyżej.
Workflow Engine ↗5. Granice artykułu
Brak gwarancji dla każdej poprawki SuiteCRM i każdej konfiguracji własnych hooków. Zalecenia są heurystykami architektury opartymi na typowych błędach — decydują testy Twojej instancji.