Żadne zdarzenie nie może zostać utracone.

Sam w sobie nie. Gwarancje platformy obowiązują w określonych granicach. Gdy zmieniane są systemy zewnętrzne, aplikacja musi odpowiednio obsłużyć podwójne przetworzenie i ponowne próby.

Często można wykorzystać bramy (gateway) lub istniejące ścieżki eksportu. Konkretne rozwiązanie jest sprawdzane i zatwierdzane wspólnie z osobami odpowiedzialnymi za środowisko produkcyjne.

Zamówienie, stan maszyny lub zmiana stanu magazynowego mają wywoływać kolejne działania. Projektujemy kontrakty zdarzeń oraz wdrażamy platformę i integracje, aby odbiorcy mogli niezawodnie reagować, również w przypadku szczytów obciążenia lub przejściowych awarii.

Katalog zdarzeń ze schematami w AsyncAPI i Schema Registry Budowa klastrów Kafka lub RabbitMQ z szyfrowaniem, kontrolą dostępu i rozdzieleniem dzierżawców Podłączenie źródeł przez Debezium, Kafka Connect i mosty MQTT dla danych maszynowych Wzorce przetwarzania dla kolejności, idempotencji, ponawiania i Event Sourcing Eksploatacja z monitorowaniem opóźnienia, przepustowości i grup konsumentów

Katalog zdarzeń ze schematami i osobami odpowiedzialnymi Gotowa do eksploatacji platforma zdarzeń jako kod Polityka przetwarzania z wzorcami i przykładami

Zdarzenie opisuje zmianę, która już nastąpiła; polecenie żąda wykonania działania. To rozróżnienie pomaga nie mieszać zakresów odpowiedzialności. Definiujemy identyfikatory, moment wystąpienia, schemat oraz potrzebny kontekst. Kolejność rozpatrujemy dla jednostki istotnej biznesowo, na przykład zamówienia, zamiast z góry obiecywać kolejność globalną. Przy podłączaniu maszyn protokoły, granice sieci i dopuszczalne interwencje są uzgadniane z osobami odpowiedzialnymi za eksploatację.

Ponowne dostarczenie może wystąpić po zakłóceniach. Konsumenci otrzymują więc reguły pozwalające rozpoznać już przetworzone zdarzenia albo powtórzyć ich obsługę w sposób bezpieczny z biznesowego punktu widzenia. Spóźnione zdarzenia i późniejsze korekty są uwzględniane odrębnie. Planujemy przechowywanie, odtwarzanie zdarzeń (replay) oraz ochronę dostępu. Platforma zdarzeń nie jest automatycznie niezmiennym archiwum; wymagania dotyczące przechowywania i usuwania danych muszą być wdrożone świadomie. Zmiany schematu są sprawdzane pod kątem zgodności z istniejącymi konsumentami.

Odbiór obejmuje awarię konsumenta, narastającą zaległość oraz kontrolowany ponowny start. Dashboardy pokazują opóźnienie i błędy, a nie tylko liczbę odebranych komunikatów. Na początek potrzebujemy typów zdarzeń, oczekiwanych wolumenów, maksymalnego opóźnienia oraz sposobu biznesowego postępowania z kolejnością lub podwójnym przetwarzaniem.

Tworzymy połączenia oparte na zdarzeniach dla procesów, które mają reagować na zmiany. Planujemy przy tym nie tylko transport, lecz także znaczenie, kolejność oraz ponowne przetwarzanie zdarzeń.

Podwójne dostarczenie nie prowadzi do podwójnego skutku biznesowego. Zaległości i problematyczne wiadomości są widoczne. Docelowy zbiór danych można w uzgodnionym zakresie odbudować w sposób kontrolowany.

Przykład: potwierdzone zamówienie uruchamia przygotowanie wysyłki oraz powiadomienie klienta. Obaj odbiorcy przetwarzają dane niezależnie od siebie. Jeśli usługa powiadomień ulegnie awarii, zamówienie pozostaje zachowane; po ponownym uruchomieniu identyfikator operacji zapobiega niekontrolowanemu wielokrotnemu wysłaniu tej samej wiadomości.

Zdarzenie opisuje fakt, że coś się wydarzyło, na przykład potwierdzone zamówienie. Uzgadniamy identyfikator, moment wystąpienia, kontekst biznesowy oraz reguły wersjonowania. Odbiorcy muszą być w stanie rozpoznać, czy już przetworzyli tę samą wiadomość i czy zdarzenie zawiera informacje wystarczające do ich celu. Kolejność jest często wymagana tylko w ramach określonego obiektu biznesowego. Ten wymóg wpływa na partycjonowanie i równoległość przetwarzania. Unikamy ogólnych obietnic globalnej kolejności lub jednokrotnego przetwarzania biznesowego, a zamiast tego sprawdzamy gwarancje całego łańcucha, łącznie z systemem docelowym.

Wolny odbiorca nie może bez ograniczeń i niepostrzeżenie pozostawać w tyle. Monitorujemy opóźnienia i planujemy, jak zwiększyć przepustowość lub nadać priorytet przetwarzaniu. Dla błędnych wiadomości przewidujemy ścieżkę wyjaśniania, aby jeden problematyczny rekord nie blokował trwale całego przetwarzania. Możliwość ponownego przetwarzania zdarzeń jest wartościowa dla naprawy błędów i dla nowych odbiorców, wymaga jednak reguł przechowywania i ochrony danych. Określamy, które historyczne zdarzenia pozostają dostępne i jak przebiega odbudowa docelowego zbioru danych. Odbiór wyraźnie obejmuje przerwania, podwójne dostarczenie oraz ponowny start odbiorcy.

Mapa systemów, przepływy danych, wąskie gardła Dział biznesowy, eksploatacja IT, architektura, architekt integracji OTOKO® Inwentarz interfejsów, ocenione ryzyka, priorytetowe przypadki integracji

Architektura integracyjna, katalog interfejsów, model eksploatacji Architektura, bezpieczeństwo informacji, ochrona danych, dział biznesowy Architektura docelowa, własność danych dla każdego obiektu, wymagania bezpieczeństwa, model eksploatacji