Sklep przyjął i opłacił zamówienie, ale system fakturowy przestał odpowiadać. Czy dane znikną, czy integracja spróbuje ponownie, a może ktoś dowie się o problemie dopiero wtedy, gdy klient upomni się o fakturę?
Przy projektowaniu integracji właśnie ten scenariusz uważam za ważniejszy niż sam moment połączenia dwóch aplikacji. Dobra integracja powinna określać, co dzieje się z danymi podczas awarii, kto jest informowany o problemie i jak proces wraca do normalnego działania.
Awaria jednego systemu nie powinna powodować utraty danych
Załóżmy, że sklep przekazuje dane o opłaconym zamówieniu do programu fakturowego. System faktur chwilowo nie odpowiada. Najgorszy wariant to pojedyncza próba wysłania danych, zapis błędu w technicznym logu i pozostawienie sprawy bez dalszego działania.
W poprawnie zaprojektowanej integracji informacja o zadaniu powinna zostać zachowana. System musi pamiętać: „dla zamówienia 12345 nadal trzeba utworzyć fakturę”.
W praktyce często wykorzystuje się do tego kolejkę, czyli miejsce, w którym operacje czekają na wykonanie. Można ją porównać do tacy z dokumentami: jeśli pracownik odpowiedzialny za ich obsługę jest chwilowo niedostępny, dokumenty nie znikają. Czekają na później.
To ważne szczególnie wtedy, gdy integracja obejmuje kilka aplikacji: sklep, ERP, magazyn, księgowość czy firmę kurierską. Awaria jednego elementu nie powinna powodować utraty informacji o całym procesie.
Ponowienie operacji pomaga, ale nie może tworzyć duplikatów
Jeśli system docelowy jest chwilowo niedostępny, integracja może automatycznie spróbować ponownie. Pierwsza próba może nastąpić po kilkunastu sekundach, kolejna po minucie, następna po kilku minutach.
Ten mechanizm nazywa się często retry, czyli po prostu ponowieniem operacji. Nie każdą sytuację warto jednak obsługiwać w ten sposób.
Brak odpowiedzi serwera może być chwilowy. Z kolei błąd typu „nieprawidłowy NIP” nie zniknie po dziesięciu kolejnych próbach. W takim przypadku zadanie powinno zostać zatrzymane i przekazane do ręcznej obsługi.
Pojawia się też drugi problem. Co, jeśli system fakturowy wystawił fakturę, ale odpowiedź potwierdzająca nie dotarła do sklepu? Kolejna próba mogłaby utworzyć drugi dokument.
Dlatego integracja API powinna potrafić rozpoznać ponowne wykonanie tej samej operacji. Może służyć do tego unikalny numer zamówienia lub operacji. Dzięki temu ponowienie połączenia nie oznacza automatycznie powielenia danych.
Firma musi wiedzieć, że część procesu stanęła
Jednym z częstszych problemów jest sytuacja, w której wszystkie systemy formalnie działają, ale dane przestały przepływać pomiędzy nimi.
Pracownik może zalogować się do sklepu i programu księgowego, monitoring serwerów pokazuje zielone kontrolki, a mimo to od dwóch godzin nie wystawiono żadnej nowej faktury.
Dlatego nie wystarczy monitorować, czy aplikacja lub API odpowiada. Trzeba również monitorować proces biznesowy.
Zamiast komunikatu technicznego:
„API zwraca błąd 503”
osoba odpowiedzialna za sprzedaż powinna zobaczyć raczej:
„18 opłaconych zamówień od ponad 20 minut oczekuje na wystawienie faktury”.
Takie powiadomienie od razu pokazuje skalę i znaczenie problemu.
Nie każdy pojedynczy błąd musi też wywoływać alarm. Jeśli integracja sama naprawia chwilowy problem po kilkunastu sekundach, informowanie pracownika nie ma większego sensu. Alert powinien pojawić się wtedy, gdy automat przestaje sobie radzić albo liczba oczekujących operacji zaczyna rosnąć.
Ręczna interwencja powinna być wyjątkiem, ale musi być możliwa
Nawet dobrze zaprojektowana automatyzacja nie rozwiąże wszystkich przypadków. Czasem dane klienta są błędne, system zewnętrzny zmienił sposób działania albo konkretna operacja wymaga decyzji człowieka.
W takiej sytuacji pracownik powinien móc zobaczyć, które zadanie się nie udało, dlaczego zostało zatrzymane i co może zrobić dalej.
Przykładowa lista może wyglądać tak:
- zamówienie 12345 — system fakturowy niedostępny — ponowienie za 5 minut,
- zamówienie 12346 — błędny NIP — wymagana korekta danych,
- zamówienie 12347 — pięć nieudanych prób — wymagana interwencja.
Nie chodzi o budowanie rozbudowanego panelu do każdej małej integracji. Przy prostych procesach wystarczy raport lub podstawowy ekran administracyjny. Ważne, aby obsługa problemu nie wymagała za każdym razem programisty uruchamiającego ręcznie skrypt na serwerze.
Nie każda integracja wymaga rozbudowanych zabezpieczeń
Odporność na awarie kosztuje. Kolejki, monitoring, alerty i narzędzia do ręcznego ponawiania operacji trzeba zaprojektować, wdrożyć i utrzymywać.
Dlatego poziom zabezpieczeń powinien zależeć od skutków awarii.
Jeżeli raz dziennie synchronizujemy pomocniczy raport, a brak danych można bez problemu uzupełnić następnego ranka, budowanie rozbudowanej infrastruktury może nie mieć ekonomicznego sensu.
Inaczej wygląda proces, w którym setki opłaconych zamówień muszą trafić do magazynu przed godziną 14:00. Godzinna awaria może wtedy przełożyć się na opóźnienie wysyłek i pracę wielu osób.
Dobra architektura nie jest najbardziej skomplikowana. Jest proporcjonalna do ryzyka biznesowego.
7 pytań, które warto zadać wykonawcy integracji
Przy wyborze wykonawcy nie ograniczałbym rozmowy do pytania, czy potrafi połączyć oba API. Znacznie więcej o jakości rozwiązania powiedzą odpowiedzi dotyczące sytuacji awaryjnych.
Warto zapytać:
- Co stanie się z danymi, jeśli drugi system nie będzie działał przez godzinę?
- Czy nieudane operacje będą automatycznie ponawiane i jak długo?
- Jak system zabezpiecza się przed utworzeniem duplikatów?
- Po jakim czasie firma otrzyma informację o problemie?
- Kto dostanie alert i czy będzie on zrozumiały dla osoby nietechnicznej?
- Czy pracownik może samodzielnie ponowić zatrzymaną operację?
- Jak po awarii sprawdzimy, czy wszystkie zaległe dane zostały przetworzone?
Dobra odpowiedź powinna opisywać konkretny scenariusz. „System będzie monitorowany” mówi niewiele. „Po pięciu nieudanych próbach zamówienie otrzyma status wymagający interwencji, a dział obsługi dostanie alert z numerem zamówienia” daje już konkretną informację.
Przed wdrożeniem nowej integracji proponuję więc przeprowadzić prosty test myślowy: co dokładnie wydarzy się, jeśli system docelowy przestanie działać na godzinę?
Jeżeli nie wiadomo, gdzie w tym czasie będą dane, kto zauważy problem i jak później wznowić proces, warto dopracować ten element przed uruchomieniem. Jeśli chcesz zweryfikować istniejącą lub planowaną integrację, dobrym pierwszym krokiem jest przegląd właśnie tych scenariuszy awaryjnych.