Kolejki i ponowienia faksu bez pętli oraz zgubionych dokumentów
Ponowienie ma sens tylko wtedy, gdy system zna przyczynę błędu i potrafi zachować historię jednego zadania. Przy niejednoznacznym wyniku automatyzację trzeba zatrzymać i uzgodnić stan.
Kolejka wirtualnego faksu pełni dwie role: wyrównuje różnicę między tempem napływu zadań a możliwościami transmisji oraz zachowuje pracę podczas chwilowych problemów. Źle zaprojektowana może jednak wielokrotnie wysłać ten sam dokument, ukryć częściowe powodzenie albo przetrzymywać zadanie, którego nie da się wykonać.
Każde zadanie ma stan i historię prób
Utworzenie zadania, oczekiwanie, aktywna transmisja, wynik próby i decyzja o zamknięciu powinny być osobnymi zdarzeniami. Kolejna próba nie usuwa poprzedniej. Dzięki temu wiadomo, czy użytkownik zlecił wysyłkę raz, a system próbował kilka razy, czy powstały niezależne zlecenia.
Identyfikator powinien przechodzić przez konektor, platformę i system spraw w zakresie obsługiwanym przez integracje. Jeśli każdy system generuje własny identyfikator, utrzymuj tabelę korelacji. Nie polegaj na nazwie pliku ani samym numerze, bo dwa legalne dokumenty mogą mieć tę samą nazwę i odbiorcę.
Podziel błędy według następnego działania
Błąd przejściowy może uzasadniać ponowienie po kontrolowanej przerwie. Błąd trwały zwykle wymaga poprawy danych, uprawnień lub dokumentu. Błąd wewnętrzny platformy może wymagać eskalacji, a nie kolejnego połączenia. Wynik niejednoznaczny oznacza, że nie ma wystarczających danych, by uznać transmisję za zakończoną albo nieudaną.
Słownik powinien mapować surowy kod dostawcy na kategorię, zachowując oryginalny kod do diagnostyki. Nie grupuj wszystkich timeoutów razem. Przerwa przed zestawieniem i utrata końcowego potwierdzenia po przesłaniu stron tworzą inne ryzyko duplikatu.
Kiedy automatyczne ponowienie jest zabronione
Zatrzymaj automatyzację, gdy system mógł przekazać część albo całość dokumentu, lecz nie zna finału, gdy użytkownik zmienił plik lub odbiorcę, gdy upłynął sensowny termin biznesowy albo gdy numer wymaga ponownej weryfikacji. Właściciel sprawy powinien zobaczyć dotychczasowe próby i wybrać dalszy krok zgodnie z procedurą.
Ogranicz ponowienia według procesu, nie stałej z internetu
Nie istnieje jedna właściwa liczba prób i odstęp dla każdego zastosowania. Ustal limit według pilności, godzin odbiorcy, ryzyka duplikatu, czasu ważności dokumentu i warunków usługi. Zapisz rosnące odstępy lub inne reguły, ale pokaż użytkownikowi plan oraz możliwość kontrolowanego zatrzymania.
Kolejka powinna mieć termin wygaśnięcia zadania. Dokument, którego wykonanie po określonym czasie nie ma już sensu, nie może nagle zostać wysłany po długiej awarii. Wygaśnięcie nie usuwa śladu; zmienia stan i kieruje sprawę do właściciela.
Duplikat rozpoznawaj ostrożnie
Klucz idempotencji może zapobiec utworzeniu kilku zadań po ponownym wysłaniu tego samego żądania przez API. Powiązanie odbiorcy, kontrolowanego identyfikatora pliku i procesu pomaga wskazać możliwy duplikat. Nie kasuj go jednak automatycznie tylko na podstawie skrótu treści — identyczny formularz może być prawidłowo wysyłany ponownie w innej sprawie.
System powinien pokazać podobieństwo i kontekst, a zasada organizacji rozstrzygnąć, czy kolejne zlecenie jest powtórką techniczną, poprawką czy nowym działaniem. Usunięcie duplikatu także jest zdarzeniem audytowym.
Kontroluj pojemność i kolejność
Monitoruj liczbę zadań oczekujących, wiek najstarszego, tempo napływu i wykonania, udział błędów według kategorii, czas do ręcznego przeglądu i wielkość kolejki niejednoznacznej. Sam średni czas może ukrywać dokument, który utknął znacznie dłużej.
Priorytet powinien wynikać z procesu, nie z tego, który użytkownik częściej klika „ponów”. Zmiana priorytetu wymaga uprawnienia i logu. Zabezpiecz kolejkę przed sytuacją, w której jedno wadliwe zadanie blokuje wszystkie kolejne.
Wydziel również kolejkę do ręcznego wyjaśnienia. Trafiają do niej zadania po wyczerpaniu dozwolonych prób, z nierozpoznanym kodem, konfliktem danych albo wynikiem niejednoznacznym. Samo przeniesienie nie rozwiązuje problemu: potrzebne są alarm, termin reakcji i właściciel. Zamknięcie wymaga opisanej decyzji, a nie usunięcia wpisu z widoku.
Zaprojektuj wejście przychodzące pod kątem powtórek
Nadawca może ponowić faks, nie wiedząc, czy pierwsza próba dotarła. Platforma może więc utworzyć dwa podobne dokumenty bez wspólnego identyfikatora po stronie nadawcy. Oznacz możliwe powtórzenie, porównaj strony oraz metadane i pokaż je osobie klasyfikującej. Nie łącz automatycznie dokumentów, jeśli mogły zawierać drobną, ale ważną poprawkę.
Po przypisaniu do systemu spraw zachowaj odwołanie do obu zadań i decyzję o tym, który dokument jest używany. Dzięki temu późniejszy audyt nie interpretuje usuniętej kopii jako zagubionej transmisji.
Po awarii wykonaj uzgodnienie przed wznowieniem
Zatrzymaj nowe automatyczne ponowienia, pobierz stan z platformy i porównaj go z systemem źródłowym oraz docelowym. Utwórz listy: zakończone i zapisane, zakończone bez rekordu docelowego, oczekujące, trwałe błędy, wynik niejednoznaczny oraz możliwe duplikaty. Przypisz właścicieli i dopiero wtedy zdecyduj o wznowieniu.
Przetestuj również awarię podczas transmisji, utratę potwierdzenia, niedostępność systemu spraw oraz ponowne dostarczenie zdarzenia przez integrację. Test powinien wykazać, że jedna awaria nie tworzy ani cichej straty, ani lawiny powtórek.
Połącz kolejkę z mapą przepływu
Źródła techniczne warstwy transmisyjnej: ITU-T T.30, ITU-T T.38. Zasady kolejkowania, ponowień i uzgodnienia są wzorcem projektowym, który należy zweryfikować w dokumentacji oraz testach konkretnej usługi.