automatyzacja po transakcji

Automatyzacja po transakcji to sekwencja działań uruchamiana samoczynnie zaraz po zarejestrowaniu zakupu przez klienta.

Uruchomienie procesu po potwierdzeniu zakupu

Automatyzacja po transakcji oznacza zestaw czynności wykonywanych przez system po zarejestrowaniu zakupu. Punktem wyjścia może być utworzenie zamówienia, potwierdzenie płatności przez operatora albo zmiana statusu na „opłacone”. Te zdarzenia nie są równoważne. Zamówienie może istnieć przed otrzymaniem pieniędzy, a płatność może zostać odrzucona, anulowana lub zwrócona. Dlatego poprawnie zaprojektowany proces powinien reagować na jednoznaczne zdarzenie biznesowe, zgodne z regułami konkretnego systemu sprzedażowego.

Informacja o transakcji może zostać przekazana do innego modułu przez wywołanie API, komunikat w kolejce albo webhook. Webhook jest żądaniem HTTP wysyłanym automatycznie do wskazanego adresu po wystąpieniu zdarzenia. Odbiorca powinien zweryfikować autentyczność komunikatu, odczytać identyfikator zamówienia oraz sprawdzić jego aktualny stan. Nie należy traktować samego żądania jako dowodu, że płatność została skutecznie rozliczona, ponieważ komunikat może być opóźniony, powtórzony lub dostarczony w nieprawidłowej kolejności.

Przekazywanie danych do kolejnych systemów

Po potwierdzeniu transakcji automatyzacja może przekazać dane do systemu magazynowego, modułu fakturowania, narzędzia obsługi zamówień albo usługi wysyłkowej. Zakres danych powinien być określony przez umowę interfejsu programistycznego, czyli API. Typowy komunikat zawiera identyfikator zamówienia, pozycje, ilości, ceny, walutę, status płatności oraz informacje potrzebne do realizacji dostawy. Każde pole powinno mieć jasno zdefiniowany typ, format i znaczenie. Szczególnej uwagi wymagają kwoty pieniężne, ponieważ zaokrąglanie liczb zmiennoprzecinkowych może powodować różnice między wartością zamówienia a wartością zapisaną w systemie księgowym.

Przepływ danych powinien być odporny na częściową awarię. Jeżeli płatność została zatwierdzona, lecz system magazynowy chwilowo nie odpowiada, zdarzenie nie może zostać utracone. Stosuje się w tym celu kolejkę komunikatów, trwały zapis zdarzenia lub tabelę zadań oczekujących. Mechanizm ponawiania powinien rozróżniać błędy przejściowe, takie jak chwilowy brak połączenia, od błędów trwałych, na przykład nieprawidłowego identyfikatora produktu. Po przekroczeniu ustalonej liczby prób komunikat powinien trafić do osobnej kolejki błędów lub zostać oznaczony do ręcznej kontroli.

Idempotencja, kolejność i kontrola wykonania

Jedno zdarzenie może zostać dostarczone więcej niż raz. Odbiorca automatyzacji powinien więc obsługiwać je idempotentnie, czyli ponowne przetworzenie tego samego komunikatu nie powinno utworzyć drugiej rezerwacji, drugiej wysyłki ani kolejnego obciążenia. Najczęściej wykorzystuje się unikalny identyfikator zdarzenia lub połączenie identyfikatora zamówienia z typem operacji. Przed wykonaniem działania system sprawdza, czy dany identyfikator został już zapisany jako obsłużony. Sprawdzenie i zapis powinny być objęte transakcją bazodanową albo innym mechanizmem zapewniającym spójność.

Ważna jest również kolejność zdarzeń. Informacja o anulowaniu może dotrzeć przed informacją o potwierdzeniu płatności, mimo że w systemie źródłowym wystąpiła później. Automatyzacja powinna korzystać z wersji rekordu, znacznika czasu nadanego przez system źródłowy lub aktualnego odczytu statusu, zamiast ślepo stosować komunikaty w kolejności ich dostarczenia. Należy rejestrować wynik każdej operacji: czas rozpoczęcia, czas zakończenia, identyfikator transakcji, nazwę wykonanej czynności oraz kod błędu. Log nie powinien zawierać pełnych danych uwierzytelniających ani poufnych tokenów.

Diagnostyka działania automatyzacji na komputerze

Problemy z automatyzacją po transakcji mogą wynikać zarówno z oprogramowania, jak i z samego środowiska pracy. Diagnostyka obejmuje sprawdzenie połączenia sieciowego, poprawności adresu endpointu, certyfikatu TLS, konfiguracji zapory, synchronizacji czasu oraz dostępności aplikacji uruchamiającej proces. Różnica czasu między komputerem a serwerem może powodować odrzucanie podpisanych żądań lub błędną ocenę ważności tokenu. Jeżeli automatyzacja działa jako zadanie cykliczne, trzeba dodatkowo sprawdzić harmonogram, uprawnienia konta oraz to, czy proces nie kończy się natychmiast po uruchomieniu.

W praktyce pomocne jest prześledzenie jednej transakcji od zdarzenia źródłowego do rezultatu końcowego. Należy porównać identyfikator zamówienia w systemie sprzedażowym, logu webhooka, kolejce oraz systemie odbiorczym. Pozwala to ustalić, czy problem wystąpił podczas wysłania komunikatu, jego uwierzytelnienia, walidacji danych, zapisu w bazie czy wykonania operacji końcowej. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, dlatego w przypadku problemów ze sprzętem wykorzystywanym do obsługi takich procesów możliwe jest rozpoczęcie od diagnostyki urządzenia i środowiska systemowego.