brak powiązania webhooka z konkretną kampanią

Brak powiązania webhooka z konkretną kampanią to usterka uniemożliwiająca powiązanie zdarzenia z wysyłką, której dotyczy.

Na czym polega brak powiązania webhooka z kampanią

Brak powiązania webhooka z konkretną kampanią oznacza, że system odebrał zdarzenie, ale nie potrafi jednoznacznie ustalić, której wysyłki lub kampanii ono dotyczy. Webhook jest mechanizmem przekazania informacji do innego systemu za pomocą żądania HTTP, najczęściej metodą POST. W treści takiego żądania powinny znajdować się dane pozwalające rozpoznać zdarzenie, na przykład identyfikator kampanii, identyfikator wiadomości, typ zdarzenia oraz czas jego wystąpienia. Jeżeli identyfikator jest nieobecny, pusty, nieaktualny albo nie pasuje do żadnej kampanii, odbiorca nie może poprawnie przypisać informacji do wysyłki.

Problem nie musi oznaczać awarii samego połączenia sieciowego. Serwer może zwrócić kod HTTP 200, a mimo to aplikacja może nie przetworzyć zdarzenia logicznie, ponieważ odebrany dokument JSON nie zawiera wymaganego pola albo zawiera wartość o nieprawidłowym formacie. W praktyce rozróżnia się więc błąd transportu, taki jak brak odpowiedzi serwera, od błędu semantycznego, w którym żądanie dotarło do celu, lecz jego znaczenie nie może zostać ustalone.

Identyfikator kampanii, payload i reguły routingu

Powiązanie webhooka z kampanią opiera się na zgodności danych wysyłanych przez nadawcę z konfiguracją odbiorcy. Nadawca może przekazywać identyfikator kampanii bezpośrednio w obiekcie JSON, na przykład jako pole campaign_id, albo umieszczać go w adresie URL, parametrze zapytania lub nagłówku HTTP. Odbiorca musi znać dokładną lokalizację tej wartości i stosować tę samą konwencję nazewniczą. Pole campaignId, campaign_id i id_campaign mogą oznaczać podobną informację dla człowieka, ale dla programu są różnymi nazwami pól, jeżeli kod nie przewiduje ich równoważnego traktowania.

Do utraty powiązania dochodzi między innymi po usunięciu kampanii, zmianie jej identyfikatora, skopiowaniu konfiguracji webhooka z innego środowiska albo przekierowaniu zdarzeń do niewłaściwego endpointu. Błąd może również powstać wtedy, gdy testowy webhook korzysta z danych produkcyjnych lub odwrotnie. W takim przypadku żądanie jest technicznie poprawne, lecz identyfikator wskazuje obiekt, którego nie ma w aktualnej bazie danych. Podobny skutek daje obcięcie wartości podczas serializacji JSON, przekazanie identyfikatora jako liczby zamiast tekstu albo dodanie niewidocznych znaków, takich jak spacja na końcu ciągu.

Reguła routingu powinna po odebraniu zdarzenia wyszukać kampanię na podstawie stabilnego klucza i sprawdzić, czy znaleziony obiekt jest aktywny oraz czy należy do właściwego nadawcy. Sam adres webhooka nie zawsze wystarcza do identyfikacji kampanii, ponieważ jeden endpoint może obsługiwać wiele kampanii. Bez dodatkowego klucza system może odrzucić zdarzenie, przypisać je do domyślnej kampanii albo pozostawić je w kolejce błędów. Ostatnie dwa zachowania są szczególnie ryzykowne, ponieważ mogą stworzyć pozór poprawnego działania przy jednoczesnym zaburzeniu statystyk wysyłki.

Ślady diagnostyczne w żądaniu i logach aplikacji

Diagnostykę należy rozpocząć od porównania konfiguracji webhooka z rzeczywistym żądaniem HTTP zapisanym w logach lub narzędziu monitorującym. Należy sprawdzić metodę żądania, adres endpointu, nagłówki, typ zawartości oraz pełną strukturę danych JSON, bez pomijania pól identyfikacyjnych. Istotne jest ustalenie, czy problem występuje dla wszystkich zdarzeń, czy tylko dla jednej kampanii albo jednego typu zdarzenia, na przykład dostarczenia wiadomości, odbicia adresu lub rezygnacji z subskrypcji.

W logach powinny znaleźć się co najmniej: czas odebrania żądania, identyfikator żądania, typ zdarzenia, przekazany identyfikator kampanii, wynik wyszukania kampanii oraz końcowy status przetwarzania. Komunikat w rodzaju „webhook received” potwierdza tylko odebranie połączenia, a nie prawidłowe przypisanie danych. Większą wartość diagnostyczną ma informacja wskazująca, że pole identyfikatora było nieobecne, miało pustą wartość, nie przeszło walidacji albo nie znalazło odpowiadającego rekordu. Przy analizie należy także porównać identyfikator zdarzenia z identyfikatorem wiadomości, ponieważ te wartości opisują różne obiekty i nie powinny być używane zamiennie.

Jeśli nadawca ponawia dostarczenie tego samego webhooka, system może zapisać kilka kopii zdarzenia. Dlatego przydatny jest unikalny identyfikator zdarzenia oraz mechanizm idempotencji, czyli przetwarzania powtórzonego żądania najwyżej raz. Nie rozwiązuje to braku identyfikatora kampanii, ale ogranicza ryzyko wielokrotnego zaksięgowania tego samego zdarzenia po naprawieniu konfiguracji. Należy również sprawdzić, czy kolejka, filtr lub warstwa pośrednia nie usuwa pola przed przekazaniem danych do modułu odpowiedzialnego za wyszukanie kampanii.

Naprawa konfiguracji i weryfikacja poprawnego przypisania

Usunięcie problemu wymaga wskazania jednego, uzgodnionego sposobu identyfikowania kampanii oraz zastosowania go po obu stronach integracji. Najpierw trzeba ustalić, który identyfikator jest źródłem prawdy, gdzie jest przechowywany i w jakim formacie ma być przekazywany. Następnie należy poprawić mapowanie pól, adres endpointu lub konfigurację konkretnej kampanii. Jeżeli kampania została skopiowana, trzeba zweryfikować, czy webhook nie zachował identyfikatora obiektu z poprzedniej konfiguracji.

Po zmianie konfiguracji należy wykonać kontrolne zdarzenie w bezpiecznym zakresie i potwierdzić cały przebieg: odebranie żądania, odczyt identyfikatora, wyszukanie kampanii, zapis zdarzenia oraz aktualizację właściwych statystyk. Sam kod odpowiedzi HTTP nie jest wystarczającym potwierdzeniem. Trzeba sprawdzić również log aplikacji i rekord wynikowy. Warto przetestować osobno różne typy zdarzeń, ponieważ jeden typ może zawierać identyfikator kampanii, a inny może wymagać dodatkowego mapowania.

Warszawskie Pogotowie Komputerowe wykonuje naprawę laptopów, komputerów PC i ich podzespołów, a w przypadku problemów z działaniem aplikacji można rozpocząć od zebrania komunikatów błędów, konfiguracji integracji oraz informacji o tym, kiedy wystąpiło zdarzenie. Takie dane pomagają odróżnić błąd programu od niezgodnego mapowania lub nieaktualnej konfiguracji. Diagnoza powinna obejmować także sprawdzenie połączenia sieciowego, działania procesu odbierającego webhooki i poprawności zapisu danych, bez zakładania z góry, że przyczyną jest uszkodzenie sprzętu.