Sklep zgłosił opłacenie zamówienia, integracja odpowiedziała sukcesem, ale magazyn nie otrzymał zlecenia. Każdy z tych komunikatów może być prawdziwy. Opisuje tylko inny etap. W automatyzacji trzeba więc ustalić, co zostało przyjęte, co przetworzone i jaki skutek potwierdzono w systemie docelowym.
API jest sposobem komunikacji aplikacji. Webhook pozwala jednej usłudze powiadomić drugą o zdarzeniu. Samo ich połączenie nie daje jeszcze gwarancji poprawnego procesu. W ramach integracji systemów projektujemy także znaczenie zdarzeń, reguły ponowień i obsługę sytuacji, w których odpowiedź nie wróciła.
Przyjęcie wiadomości nie kończy zadania
Rozdziel potwierdzenie odbioru zdarzenia od zakończenia pracy, którą ono uruchamia. Integracja może najpierw zapisać wiadomość w kolejce, a dopiero później utworzyć rekord. Jeśli panel pokazuje sukces po pierwszym etapie, użytkownik powinien wiedzieć, co ten status oznacza. Inaczej monitoring będzie chwalił drogę do poczekalni.
Dokumentacja GitHub dotycząca webhooków zaleca między innymi weryfikację pochodzenia i przetwarzanie dostaw w sposób odpowiadający ich charakterowi. Szczegóły trzeba odczytać w dokumentacji konkretnej usługi. Nie zakładaj, że każdy dostawca ma identyczne zasady ponawiania lub kolejności zdarzeń.
Przy projektowaniu źródeł danych i integracji zachowaj identyfikator zdarzenia i powiązanej sprawy. Dzięki temu można przejść od wiadomości do wyniku w aplikacji docelowej. Potwierdzenie powinno dać się sprawdzić niezależnie od podsumowania przygotowanego przez model AI.
Zaprojektuj drugą próbę przed pierwszą awarią
Połączenie może zerwać się po wykonaniu operacji, ale przed odesłaniem potwierdzenia. Ponowienie w ciemno może wtedy utworzyć drugi rekord. Potrzebujesz reguły rozpoznania wcześniejszego wykonania oraz przechowania wyniku operacji. Techniczny sposób zależy od możliwości systemu docelowego.
W automatyzacji zapisów na szkolenia ponowione zdarzenie płatności nie powinno tworzyć kolejnego konta. Przy obiegu faktur z AI drugi import nie powinien dopisywać drugiego dokumentu do rozliczenia. Ten sam mechanizm komunikacyjny może więc wymagać różnych kontroli skutku biznesowego.
Zwróć uwagę także na spóźnione zdarzenia. Powiadomienie o wcześniejszym statusie nie powinno bez sprawdzenia cofnąć nowszego stanu sprawy. W razie wątpliwości aplikacja może ponownie odczytać stan z uzgodnionego źródła albo przekazać rozbieżność do wyjaśnienia. Sama data odebrania wiadomości nie zawsze opisuje kolejność zdarzeń w procesie.
Zaprojektuj również odpowiedź na przerwanie operacji zbiorczej. Jeżeli aplikacja miała utworzyć kilka powiązanych rekordów, pokaż, które powstały, a które czekają na wykonanie. Nie zakładaj, że cofnięcie jednej czynności usuwa wszystkie jej skutki. Wiadomość mogła już dotrzeć do odbiorcy. W takim przypadku proces potrzebuje działania korygującego i wyjaśnienia, zamiast technicznej obietnicy powrotu do stanu sprzed całej próby.
AI powinna dostać wąsko opisane narzędzie
Jeżeli model korzysta z integracji, oddziel propozycję wywołania od jego wykonania. Aplikacja powinna sprawdzić dopuszczalne parametry, tożsamość i zakres działania. To, że model zwrócił poprawną strukturę danych, nie dowodzi jeszcze, że operacja jest uprawniona ani że wskazał właściwą sprawę.
Przy działaniach wymagających zgody zastosuj zatwierdzanie konkretnego działania AI. Kontrola powinna dotyczyć także narzędzi dostępnych po drodze. Agent z prawem przygotowania szkicu nie powinien otrzymać drugiego połączenia pozwalającego ominąć ograniczenie i wysłać dokument.
Klucze usług i dane uwierzytelniające trzymaj poza adresami URL, kontekstem modelu i logami. Dane firmowe potrzebne do zadania przekazuj wyłącznie w zatwierdzonym środowisku i zakresie, z ustalonym dostępem i zasadami zapisu; ogranicz ich kopiowanie do logów. Uzgodnij przechowywanie sekretów, zakres konta technicznego i możliwość odebrania dostępu. Te ustalenia należą do projektu integracji, nawet jeżeli użytkownik widzi tylko prosty przycisk w aplikacji.
Sprawdź proces przy powtórzeniu i przerwaniu
Odbiór powinien obejmować powtórzoną dostawę, brak odpowiedzi i nieprawidłowy podpis zdarzenia. Dodaj przypadek, w którym jeden z kilku systemów przyjął zmianę, a następny jej nie wykonał. Dokumentacja wzorca Saga w AWS opisuje koordynację kroków i działań kompensujących; w konkretnym wdrożeniu trzeba ustalić, które skutki można odwrócić.
W monitoringu automatyzacji pokaż etap zatrzymania oraz bezpieczny następny krok. Archifutura może połączyć tę warstwę z projektowanym przepływem pracy. Rezultat powinien pozwalać odpowiedzieć użytkownikowi, co wykonano i co pozostało, zamiast ogłaszać ogólną awarię całego procesu.
Ustal, kto może ponowić operację z panelu oraz jakie informacje zobaczy przed decyzją. Zapisz wynik także wtedy, gdy ponowienie niczego nie zmieniło, bo wcześniejsza próba została już rozpoznana. To użyteczne potwierdzenie poprawnego zabezpieczenia, nie kolejny błąd. Podczas odbioru poproś operatora o wyjaśnienie takiej sprawy bez otwierania kodu. Powinien móc wskazać dokument, próbę i końcowy stan.
Źródła i dokumentacja
Materiały sprawdzone przy opracowaniu tekstu. Przy wyborze usługi lub technologii potwierdzamy warunki dla konkretnego projektu.
