Problem
Europejska infrastruktura weryfikacji leków składa się z wielu współpracujących ze sobą systemów krajowych i centralnych. Wystąpienie awarii, planowanej przerwy technicznej lub znanego problemu wymagało szybkiego przekazania precyzyjnej informacji do zainteresowanych organizacji i użytkowników.
Dotychczasowa obsługa takich komunikatów była trudna do skalowania. Odbiorcy potrzebowali informacji dotyczących wyłącznie wybranych krajów, systemów i rodzajów zdarzeń, natomiast operatorzy musieli kontrolować cały cykl życia zgłoszenia — od jego utworzenia, przez aktualizacje, aż po zamknięcie incydentu.
Kontekst
EVI — European Medicines Verification System Information — pełniło rolę centralnego źródła informacji o zdarzeniach operacyjnych w ramach EMVS.
System musiał obsługiwać zdarzenia dotyczące wielu krajów, środowisk i komponentów infrastruktury. Każda publikacja mogła zmieniać się w czasie: otrzymywać aktualizacje, nowe przewidywane terminy rozwiązania, informacje o przyczynach lub potwierdzenie przywrócenia prawidłowego działania.
Równocześnie użytkownicy powinni otrzymywać tylko te wiadomości, które odpowiadały ich subskrypcjom, bez konieczności ręcznego śledzenia wszystkich komunikatów.
Podejście
Zaprojektowałem i rozwijałem backend systemu jako Web API w ASP.NET Core. Aplikacja rozdzielała odpowiedzialność za zarządzanie zgłoszeniami, publikowanie zdarzeń, obsługę subskrypcji oraz wysyłkę powiadomień.
Zdarzenie było traktowane jako obiekt posiadający własny cykl życia. Operator mógł określić między innymi:
- kraj lub grupę krajów,
- system i środowisko, którego dotyczy zdarzenie,
- rodzaj oraz poziom wpływu,
- czas rozpoczęcia i zakończenia,
- aktualny status,
- opis problemu i kolejne aktualizacje.
Po opublikowaniu lub zmianie zgłoszenia system identyfikował właściwych subskrybentów i przygotowywał dla nich odpowiednie powiadomienia.
Architektura
- ASP.NET Core Web API jako warstwa udostępniająca operacje związane ze zgłoszeniami, użytkownikami i subskrypcjami.
- Microsoft SQL Server jako źródło prawdy o zdarzeniach, odbiorcach, konfiguracji subskrypcji i historii wysyłki.
- SSO zapewniające kontrolowany dostęp do funkcji administracyjnych.
- Quartz.NET do realizacji zadań cyklicznych i przetwarzania operacji wykonywanych poza żądaniem HTTP.
- SendGrid jako usługa odpowiedzialna za dystrybucję wiadomości e-mail.
- Microsoft Azure jako środowisko uruchomieniowe aplikacji i jej infrastruktury.
- GitOps do kontrolowanego, powtarzalnego wdrażania zmian pomiędzy środowiskami.
Implementacja
Jednym z kluczowych elementów był mechanizm dopasowywania zgłoszeń do subskrypcji. Użytkownik mógł określić zakres interesujących go informacji, a system oceniał każde nowe lub zaktualizowane zdarzenie na podstawie kilku kryteriów jednocześnie.
Proces obejmował:
- zapisanie lub aktualizację zgłoszenia,
- określenie krajów, systemów i środowisk objętych zdarzeniem,
- wyszukanie pasujących subskrypcji,
- utworzenie powiadomień dla właściwych odbiorców,
- przekazanie wiadomości do SendGrid,
- zapisanie wyniku wysyłki i historii komunikacji.
Operacje wysyłania zostały oddzielone od podstawowej obsługi żądań API. Dzięki temu publikowanie zgłoszenia nie było uzależnione od czasu odpowiedzi zewnętrznego dostawcy poczty, a nieudane próby mogły być bezpiecznie ponawiane przez zadania Quartz.NET.
Istotnym elementem była również audytowalność. System przechowywał historię zmian zgłoszeń oraz informacje o wygenerowanych i wysłanych powiadomieniach, co ułatwiało analizowanie przebiegu komunikacji.
Stack
ASP.NET Core Web API, Microsoft SQL Server, Microsoft Azure, Quartz.NET, SendGrid, SSO oraz proces wdrożeniowy oparty na GitOps.
Rezultat
Powstał centralny system umożliwiający uporządkowane zarządzanie informacjami o zdarzeniach operacyjnych dotyczących wielu krajów i komponentów EMVS.
Operatorzy mogli prowadzić zgłoszenie przez cały jego cykl życia i publikować kolejne aktualizacje, natomiast odbiorcy automatycznie otrzymywali tylko te informacje, które odpowiadały zakresowi ich subskrypcji.
Rozdzielenie obsługi zgłoszeń od mechanizmu dystrybucji wiadomości zwiększyło odporność rozwiązania na błędy usług zewnętrznych i umożliwiło bezpieczne ponawianie niedostarczonych powiadomień.
Lessons learned
- W systemach wielokrajowych filtrowanie odbiorców jest równie istotne jak samo publikowanie komunikatów.
- Powiadomienie powinno być osobnym elementem domeny z własnym statusem, historią i możliwością ponowienia wysyłki.
- Operacje zależne od zewnętrznych dostawców nie powinny blokować podstawowego procesu publikowania zgłoszenia.
- Historia zmian i wysyłki jest niezbędna w systemach, w których liczy się możliwość odtworzenia pełnego przebiegu komunikacji.
- GitOps ułatwia utrzymanie spójnej konfiguracji aplikacji działającej w kilku środowiskach.