Różnica dotyczy przede wszystkim czasu
O godzinie 10:14 redakcja publikuje zmienione dane punktu porad. Witryna musi natychmiast pokazać nowy numer telefonu, wyszukiwarka we własnym portalu powinna odświeżyć indeks, a zrozumiała wersja językowa wymaga późniejszej kontroli merytorycznej. Skutki te należą do tej samej zmiany, ale nie muszą być przetwarzane w tym samym momencie.
Webhook jest wiadomością wysyłaną przez jeden system do drugiego bezpośrednio po zdarzeniu. System redakcyjny informuje na przykład: "Ta strona została opublikowana". System odbierający może następnie pobrać i przetworzyć dokładnie tę treść. Nie czeka na kolejny ogólny przebieg i nie pyta ciągle o nowe zmiany.
W przetwarzaniu wsadowym kilka zadań jest zbieranych i wykonywanych wspólnie. Każdego wieczoru można na przykład sprawdzać wszystkie zmienione danego dnia strony do raportu. Taki przebieg nie jest natychmiastowy, ale można go dobrze zaplanować. Może kolejno przetwarzać duże ilości i udostępnić wynik jako spójne zestawienie. Przetwarzanie ma znany początek i rozpoznawalny koniec.
Webhooki pasują do pojedynczych ważnych zdarzeń
Webhooki są sensowne, gdy szybka reakcja przynosi rozpoznawalną korzyść. Po opublikowaniu ostrzeżenia aplikacja powinna otrzymać tę samą aktualną treść. Po wycofaniu strony powinna ona zniknąć z wewnętrznej wyszukiwarki. Wiadomość powstaje w każdym przypadku na skutek konkretnego działania i dotyczy jasno określonej treści.
Dla redakcji proces ten wydaje się natychmiastowy. Zatwierdza wpis i krótko później widzi nową wersję w połączonym kanale. Szybkości tej nie wolno jednak mylić z gwarantowaną jednoczesnością. Błędy sieci, konserwacja lub przeciążony system odbierający mogą opóźnić przetwarzanie. System musi wytrzymywać takie przerwy.
Nie każda zapisana zmiana powinna uruchamiać webhook. Automatycznie zapisana wersja robocza nie ma jeszcze znaczenia dla publicznej wyszukiwarki. Sensowne zdarzenia opierają się na widocznym znaczeniu: opublikowano, istotnie zaktualizowano, wycofano lub usunięto. Podłączone systemy otrzymują dzięki temu mniej wiadomości i mogą jednoznaczniej obsługiwać ważne zmiany stanu. Wewnętrzne korekty literówek można w razie potrzeby traktować inaczej niż nowe fakty.
Przetwarzanie wsadowe pasuje do dużej ilości i stałych terminów
Większy przebieg jest odpowiedni, gdy wiele treści podlega tym samym zasadom. Organizacja może chcieć każdej nocy sprawdzać wszystkie opublikowane strony pod kątem brakującej daty kontroli. Dla odbiorców niewiele zmienia to, czy wynik pojawi się o 02:00, czy o 02:20. Natychmiastowa wiadomość po każdej drobnej zmianie byłaby w tym przypadku niepotrzebnie kosztowna.
Pełną przebudowę również można świadomie przeprowadzić zbiorczo. Po zmianie systemu wyszukiwania może być konieczne ponowne wczytanie 80 000 stron. Pojedyncze webhooki nie opisywałyby niezawodnie całego zasobu, ponieważ zmiana dotyczy także niezmienionych treści. Przebieg wsadowy zaczyna się od znanej ilości i dokumentuje strony przetworzone pomyślnie.
Stały czas ułatwia planowanie obciążenia. Opisy obrazów, projekty tłumaczeń lub obszerne kontrole jakości wymagają mocy obliczeniowej i usług zewnętrznych. Nocny przebieg może ograniczyć tę pracę bez spowalniania publikacji w systemie redakcyjnym. Jego czas trwania staje się dzięki temu bardziej przewidywalny dla obsługi i usługodawców. Pilne treści nadal potrzebują szybszej drogi, jeśli długie oczekiwanie prowadziłoby do błędnych informacji.
Najpierw decyduje dopuszczalne opóźnienie
Najważniejsze pytanie brzmi: jak długo podłączony system może pokazywać stary stan? Przy ostrzeżeniu przed gwałtowną pogodą minuty mogą mieć kluczowe znaczenie. Przy miesięcznej analizie jakości tekstów jeden dzień zwykle nie stanowi problemu. Jasne określenie czasu pomaga bardziej niż ogólny wymóg, aby każde przetwarzanie odbywało się jak najszybciej.
Następnie liczy się zakres typowej zmiany. Jeśli zazwyczaj publikowana jest jedna strona, webhook może wskazać dokładnie ją. Jeśli regularnie zmieniają się całe zbiory, bardziej przejrzysty jest zaplanowany przebieg. Import nowych lokalizacji zawierający 4 000 wpisów nie powinien bez kontroli uruchamiać 4 000 jednoczesnych działań następczych.
Do decyzji należą również konsekwencje awarii. Jeśli wiadomość zaginie, w aplikacji może pozostać nieaktualny numer telefonu. Jeśli nie powiedzie się raport nocny, redakcja może uruchomić go ponownie rano. Dopuszczalne opóźnienie powinno być wyraźnie uzgodnione dla każdego podłączonego kanału. Im większa bezpośrednia szkoda, tym ważniejsze są szybkie ponowienia, widoczne ostrzeżenia i dodatkowe porównanie całego zasobu.
Wiadomość webhooka pozostaje mała i jednoznaczna
Dobra wiadomość informuje, co się wydarzyło, której treści dotyczy i kiedy powstało zdarzenie. Dochodzą do tego jednoznaczny numer zdarzenia i wersja formatu wiadomości. System odbierający może następnie pobrać pełne aktualne dane przez chroniony interfejs. Wiadomość pozostaje dzięki temu przejrzysta i nie zawiera niepotrzebnie całego artykułu.
Podejście to zapobiega także rozpowszechnianiu starego tekstu przez opóźnioną wiadomość. Załóżmy, że redakcja poprawia ten sam numer telefonu dwa razy w krótkim odstępie. Pierwsza wiadomość z powodu zakłócenia dociera później niż druga. Jeśli system odbierający pobiera aktualny stan, nadal otrzymuje ostatnią zatwierdzoną wersję, a nie treść opóźnionej wiadomości.
Dane osobowe lub poufne nie należą bez potrzeby do wiadomości. Dzienniki, raporty błędów i interfejsy administracyjne często przechowują dane webhooków przez dłuższy czas. W wielu przypadkach wystarczą identyfikator treści i rodzaj zdarzenia. Uprawniony system odbierający pobiera dalsze informacje dopiero wtedy, gdy naprawdę musi je przetworzyć. Również techniczny raport błędu pozostaje dzięki temu wolny od zbędnych treści specjalistycznych.
Powtarzające się wiadomości są normalnym przypadkiem
Jeśli strona odbierająca nie potwierdzi otrzymania wiadomości, system źródłowy wysyła ją ponownie. Pierwsza wiadomość mogła zostać już przetworzona, ale jej potwierdzenie zaginęło. Dlatego system odbierający musi umieć przyjąć to samo zdarzenie kilka razy bez podwójnego publikowania wpisu lub zamawiania tego samego tłumaczenia dwukrotnie.
Pomaga w tym jednoznaczny numer zdarzenia. Jeśli numer został już pomyślnie obsłużony, system może potwierdzić i pominąć powtórzenie. Jest to bardziej niezawodne niż porównywanie czasu lub tytułu. Dwie różne zmiany mogą wystąpić niemal jednocześnie, a tytuł może się zmienić, choć nadal chodzi o tę samą treść.
Kolejność również nie zawsze jest pewna. Wiadomość o publikacji może dotrzeć po wiadomości o późniejszej poprawce. Numery wersji lub bieżące pobieranie treści zapobiegają zwycięstwu starszego stanu. Dla zespołów redakcyjnych oznacza to, że widoczny stan musi być prawidłowy nawet wtedy, gdy techniczne wiadomości podróżują niespokojną drogą. Dlatego sama data odbioru nie może decydować o obowiązującej wersji.
Odbiorca musi sprawdzać pochodzenie
Publicznie dostępny adres webhooka może zasadniczo otrzymywać wywołania także od nieuprawnionych osób. System odbierający nie może więc ufać wiadomości tylko dlatego, że dociera ona oczekiwaną ścieżką. Zwykle stosuje się podpis cyfrowy obliczany z treści i wspólnego tajnego klucza. Odbiorca oblicza go ponownie i porównuje obie wartości.
Przesyłanie odbywa się przez HTTPS, aby treść i dane dostępowe były chronione po drodze. Tajny klucz nie należy do kodu źródłowego, publicznej dokumentacji ani tekstu wiadomości. Jest przechowywany pod ochroną, udostępniany tylko potrzebnym usługom i regularnie odnawiany. Stare klucze muszą tracić ważność po kontrolowanym okresie przejściowym.
Znacznik czasu dodatkowo ogranicza okres akceptowania prawidłowo podpisanej wiadomości. Zapisane wywołanie nie może dzięki temu zostać dowolnie później powtórzone. Odpowiedzi o błędach nie powinny ujawniać napastnikom szczegółów wewnętrznych. Własny zespół nadal zachowuje wystarczające informacje, aby celowo zbadać odrzucony podpis lub nieaktualny format wiadomości. Podejrzane dostępy są ograniczane i rejestrowane w sposób możliwy do prześledzenia do kontroli bezpieczeństwa. Obowiązują przy tym odpowiednie i jasno udokumentowane okresy przechowywania.
Duży przebieg potrzebuje możliwego do prześledzenia stanu
Przy 20 000 stron przebieg wsadowy rzadko kończy się pełnym sukcesem lub całkowitą porażką. Niektóre treści mogą zawierać nieprawidłowe dane, podczas gdy pozostałe są przetwarzane poprawnie. Dlatego przebieg powinien zapisywać dla każdego wpisu, co się udało i co wymaga ponownej próby. Pojedyncza wadliwa strona nie może blokować wszystkich kolejnych.
Trzeba uwzględniać ograniczenia usług zewnętrznych. Interfejs może na przykład zezwalać tylko na określoną liczbę żądań na minutę. Przebieg dzieli wtedy ilość na bezpieczne partie i kontynuuje po przerwie. Zapisuje postęp, aby po ponownym uruchomieniu nie zaczynać od pierwszej strony i nie powtarzać niepotrzebnie już opłaconej pracy.
Dla redakcji zrozumiały wynik jest ważniejszy niż długi techniczny plik dziennika. Musi rozpoznawać właściwy przebieg, liczbę ukończonych treści i strony wymagające pomocy merytorycznej. Komunikat taki jak "37 błędów" nie wystarcza. Przypisanie do tytułu strony, adresu i konkretnego powodu zmienia błąd w zadanie możliwe do wykonania. Pomyślne powtórzenia znikają następnie z otwartego widoku redakcyjnego.
Zaplanowany przebieg często uzupełnia webhooki
Webhooki i przetwarzanie wsadowe nie wykluczają się wzajemnie. Portal informacyjny może natychmiast zgłaszać nowe artykuły do swojej wyszukiwarki, a nocą porównywać cały zasób. Szybka droga utrzymuje aktualność ważnych zmian. Zaplanowany przebieg znajduje zdarzenia brakujące z powodu zakłócenia, błędnego ustawienia lub tymczasowo wyłączonego systemu odbierającego.
Zrozumiała wersja językowa również może wymagać obu rytmów. Gdy zmienia się strona specjalistyczna, webhook natychmiast tworzy zadanie dla odpowiedniej redakcji. Sprawdzona wersja nie jest automatycznie zastępowana. Dzienny raport dodatkowo pokazuje wszystkie otwarte zadania, ich terminy i treści, w których brakuje połączenia ze stroną źródłową.
Kluczowe jest jednoznaczne źródło obowiązującego stanu. Webhook zgłasza zmianę, a regularne porównanie potwierdza bieżący zasób. Jeśli oba źródła podają różne dane, nie może przypadkowo wygrać proces wykonany jako ostatni. System publikujący pozostaje nadrzędny, a systemy podłączone dostosowują do niego swój stan. Reguła ta musi pozostać jednoznacznie udokumentowana również po zmianie systemu.
Działanie operacyjne musi pozostać zrozumiałe dla ludzi
Niezawodność techniczna ujawnia się w widocznej informacji. Zespoły powinny wiedzieć, ile zwykle trwa przesyłanie i od którego momentu zgłasza się opóźnienie. Ostrzeżenie wskazuje kanał i treść objęte problemem, a nie tylko wewnętrzną nazwę procesu. Redakcja może dzięki temu ocenić, czy odwiedzający widzą obecnie nieaktualny stan.
Każdy proces potrzebuje odpowiedzialnej jednostki. Może ona ponownie wysłać zatrzymaną wiadomość, kontynuować przebieg wsadowy lub zatrzymać błędną publikację. Jednocześnie musi być widoczne, kiedy potrzebna jest odpowiedzialność merytoryczna. Zespół techniczny może przesłać plik, ale nie może zdecydować, czy zmieniony warunek uprawnienia został prawidłowo wyjaśniony.
Odpowiednie rozwiązanie wynika więc z treści, czasu i możliwej szkody. Webhooki szybko reagują na pojedyncze zdarzenia. Przebiegi wsadowe przetwarzają planowane ilości i porównują zasoby. Razem obejmują aktualne zmiany i kompletność zbioru. Gdy ponowienia, bezpieczeństwo i zrozumiałe komunikaty są uwzględnione od początku, podłączone witryny i usługi pozostają aktualne bez obciążania codziennej pracy redakcyjnej zbędną technologią.