Przepływ przerwany w połowie zostawia dane w stanie pośrednim. To groźniejsze niż przepływ, który w ogóle się nie uruchomił.
Błędy chwilowe i ponawianie
Automatyczne przy błędach chwilowych, z rosnącym odstępem. Ogranicza większość problemów bez udziału człowieka. Chwilowe znaczy: system docelowy był przez moment niedostępny, przekroczono ograniczenie liczby zapytań, połączenie się zerwało. Powtórzenie po chwili zwykle wystarcza.
Rosnący odstęp między próbami ma znaczenie. Ponawianie bez przerwy dobija system, który już nie nadąża, i zużywa operacje bez efektu. Liczbę prób trzeba ograniczyć — po jej wyczerpaniu sprawa musi trafić do człowieka, a nie krążyć w tle.
Błędy trwałe
Brak uprawnień, nieistniejący rekord, błędne dane, zmieniony interfejs. Ponawianie nic tu nie da — potrzebne jest powiadomienie. Rozróżnienie warto zrobić w samym przepływie: odpowiedź o odmowie dostępu obsłużyć inaczej niż odpowiedź o przeciążeniu. Bez tego przepływ ponawia w nieskończoność coś, co nigdy się nie uda.
Kolejność kroków
Operacje zapisujące jak najpóźniej. Przerwanie przed zapisem jest bezpieczne, po zapisie — nie. Jeśli przepływ ma zapisać w dwóch systemach, warto zacząć od tego, w którym łatwiej cofnąć skutek, i sprawdzić komplet danych, zanim cokolwiek powstanie.
Stan pośredni
Dokument utworzony, powiadomienie niewysłane. Trzeba wiedzieć, jak taki przypadek rozpoznać i dokończyć. Pomaga znacznik ustawiany w systemie źródłowym dopiero po pełnym powodzeniu — wtedy widać, które sprawy zostały obsłużone do końca, a które utknęły.
Druga rzecz to możliwość bezpiecznego powtórzenia. Przepływ, który przed zapisem sprawdza, czy dokument o danym numerze źródłowym już istnieje, można uruchomić ponownie bez obawy o duplikat. To zabezpieczenie jest ważniejsze od samego ponawiania.
Powiadomienie do osoby
Nie do skrzynki ogólnej. Błąd bez adresata pozostaje bez reakcji, dopóki ktoś przypadkiem nie zauważy braku danych po drugiej stronie. Treść powinna wystarczyć do działania: który przepływ, który krok, jakie dane wejściowe, co zrobić dalej. Sam komunikat systemu docelowego rzadko to mówi.
Zapis wykonań
Historia z danymi wejściowymi i wynikiem każdego kroku. Bez niej ustalenie przyczyny jest zgadywaniem. Warto sprawdzić, jak długo platforma tę historię przechowuje, bo problem zgłoszony z opóźnieniem trafia już w pustkę. Sposób obserwacji opisuje tekst o monitorowaniu działania przepływów.
Czego nie da się naprawić obsługą błędów
Przepływ zbudowany na niejasnym procesie będzie zgłaszał wyjątki bez końca, bo reguły nie są rozstrzygnięte. Wtedy problem leży w opisie, a nie w obsłudze awarii — o czym mówi tekst o tym, jak budować przepływy. Osobno warto pamiętać, że większość błędów wychodzi na etapie prób, jeśli te próby obejmą przypadki nietypowe — zakres opisuje tekst o testowaniu przepływów.
