Koszty i umowy
Część cyklu: Platformy automatyzacji
Zapobieganie powtarzaniu tych samych operacji
Ustal identyfikator sprawy, sprawdzaj skutek poprzedniej próby i testuj ponowienie po błędzie, aby ograniczyć duplikaty rekordów i wiadomości.
Aby automatyzacja nie wykonała tej samej operacji dwa razy, rozpoznawaj zdarzenie i sprawdzaj skutek poprzedniej próby. Wyłączenie ponawiania nie wystarcza: to samo zgłoszenie może dotrzeć ponownie, pracownik może ręcznie uruchomić przepływ, a potwierdzenie z systemu docelowego może nie dotrzeć mimo wykonanego działania.
Określ skutek, który nie może się powtórzyć
Zapisz osobno, czy chronisz utworzenie rekordu, wysłanie wiadomości czy zmianę statusu. Ponowny odczyt może być nieszkodliwy, a ponowne wysłanie wiadomości już nie. Dla każdej czynności ustal identyfikator pozwalający odróżnić ponowienie od nowej sprawy.
Załóżmy, że formularz nadaje zgłoszeniu identyfikator A42, a przepływ ma utworzyć jedną sprawę w systemie docelowym. Klucz kontroli może łączyć A42 z rodzajem działania „utwórz sprawę”. Sam adres e-mail klienta nie wystarczy, bo jedna osoba może zgłosić dwie różne sprawy. Jeśli późniejsza poprawka ma aktualizować rekord, potrzebuje odrębnego oznaczenia zmiany. To przykład projektowy, nie opis wdrożenia.
Ustal wynik przed ponowieniem
Przed utworzeniem rekordu poszukaj jego odpowiednika po stabilnym identyfikatorze. Jeśli istnieje, porównaj stan i ustal, czy próbę zakończyć, czy wykonać aktualizację. Rejestr prób powinien odróżniać „rozpoczęto”, „potwierdzono wynik” i „wynik niepewny”. Przy niepewnym wyniku najpierw sprawdź system docelowy. Automatyczne powtórzenie polecenia może stworzyć drugi rekord.
Gdy system docelowy wymusza unikalność identyfikatora albo obsługuje klucz idempotencji, może zapobiec ponownemu wykonaniu skutku. Mechanizm i jego ograniczenia zależą od systemu. Na przykład Stripe obsługuje klucze idempotencji przy żądaniach POST, ale może usunąć zapisany klucz po upływie co najmniej 24 godzin; późniejsze użycie usuniętego klucza jest traktowane jak nowe żądanie.
Nie jest to funkcja każdej platformy automatyzacji. Jeśli system docelowy nie zapewnia takiej ochrony, wcześniejszy odczyt rekordu może nie wystarczyć przy równoczesnych uruchomieniach: obie próby mogą odczytać brak rekordu przed zapisem.
Idempotentność w różnych systemach – porównanie funkcji
- Stripe
- Obsługuje klucze idempotencji przy żądaniach POST; klucz jest usuwany po 24 godzinach.
- Microsoft Azure (Event Sourcing)
- Wspiera zapis zdarzeń z unikalnymi identyfikatorami; umożliwia odzyskiwanie stanu bez powtórzeń.
- Zapier
- Obsługuje replay zdarzeń, ale nie zapewnia automatycznej idempotentności — wymaga ręcznej kontroli.
- Power Automate
- Wymaga implementacji własnych mechanizmów kontrolnych; testowanie chmurzowych przepływów pomaga wykryć duplikaty.
Sprawdź trudne momenty
Na bezpiecznych danych próbnych sprawdź cztery sytuacje: dwa identyczne zdarzenia po kolei, dwa niemal równoczesne uruchomienia, przerwę po zapisie przed otrzymaniem potwierdzenia oraz ręczne ponowienie po poprawce. Za każdym razem policz skutki w systemie docelowym, a nie tylko wpisy w historii przepływu.
Zakres ponowienia zależy od platformy i użytej funkcji. Przed ponowieniem sprawdź, które kroki zostaną wykonane ponownie, w tym te, które wcześniej zakończyły się powodzeniem. Operator powinien więc przed ponowieniem znać identyfikator sprawy i stan wykonanych działań.
Kryterium przyjęcia: ponownie dostarczone zdarzenie daje jeden zamierzony skutek, a nowa, odrębna sprawa nadal może zostać obsłużona. Przy niepewnym wyniku wstrzymaj ponawianie do czasu sprawdzenia.
