SQL Server Notification Services

Notification Services to wycofany komponent SQL Server służący do generowania i dostarczania powiadomień.

Rola SQL Server Notification Services w architekturze SQL Server

SQL Server Notification Services był komponentem platformy Microsoft SQL Server przeznaczonym do automatycznego generowania i dostarczania powiadomień na podstawie zdarzeń oraz zapisanych subskrypcji. Zdarzeniem mogła być na przykład zmiana wartości w tabeli, pojawienie się rekordu w źródle danych albo informacja przekazana przez zewnętrzny proces. Mechanizm nie służył do wykonywania pojedynczego zapytania wysyłającego komunikat, lecz zapewniał cały przepływ: pobranie zdarzenia, zapisanie go, dopasowanie do subskrybentów, utworzenie treści powiadomienia i przekazanie jej do kanału dostarczania.

Rozwiązanie składało się z instancji Notification Services oraz jednej lub większej liczby aplikacji powiadomień. Konfiguracja była opisywana za pomocą plików XML, w tym Instance Configuration File oraz Application Definition File. W definicji aplikacji określano między innymi klasy zdarzeń, klasy subskrypcji, reguły generowania powiadomień, dostawców zdarzeń i dystrybutorów. Komponent korzystał z baz danych SQL Server do przechowywania zdarzeń, subskrypcji, kolejek oraz wygenerowanych powiadomień, dlatego jego działanie zależało zarówno od poprawnej konfiguracji usługi, jak i od dostępności instancji bazy danych.

Przepływ zdarzeń, subskrypcji i powiadomień

Przepływ danych rozpoczynał się w dostawcy zdarzeń, czyli elemencie odpowiedzialnym za pobranie informacji ze źródła. Notification Services udostępniał dostawców zdarzeń dla wybranych źródeł, między innymi dla tabel SQL Server i plików, a także umożliwiał tworzenie dostawców niestandardowych. Dostawca przekazywał dane zgodne z określoną klasą zdarzenia. Następnie zdarzenie trafiało do bazy aplikacji, gdzie mogło zostać połączone z subskrypcjami użytkowników.

Subskrypcja opisywała zainteresowanie określonym typem informacji oraz sposób jej dostarczenia. Reguły generowania powiadomień porównywały dane zdarzenia z zapisanymi warunkami subskrypcji. Jeżeli warunek był spełniony, generator tworzył powiadomienie na podstawie klasy powiadomienia i odpowiedniego formatu treści. W tym miejscu można było wykorzystać dane zdarzenia, dane subskrybenta oraz informacje pobrane z dodatkowych tabel. Po wygenerowaniu komunikat trafiał do dystrybutora, który przekazywał go do skonfigurowanego kanału, na przykład poczty elektronicznej albo innego mechanizmu obsługiwanego przez rozszerzenie.

Konfiguracja i typowe punkty awarii

Diagnozowanie Notification Services wymagało sprawdzenia zgodności kilku warstw konfiguracji. Nazwa instancji, nazwa aplikacji, identyfikatory klas zdarzeń i subskrypcji oraz parametry połączenia z SQL Server musiały odpowiadać wartościom użytym w plikach XML i w bazie danych. Błąd składni w pliku definicji aplikacji, niezgodny typ danych albo brak wymaganej tabeli mógł uniemożliwić uruchomienie aplikacji lub powodować odrzucanie zdarzeń. Istotne było także sprawdzenie konta, pod którym działała usługa, ponieważ konto musiało mieć wymagane uprawnienia do bazy danych, katalogów roboczych i źródeł zdarzeń.

Objawem problemu nie zawsze był natychmiastowy błąd w interfejsie użytkownika. Zdarzenia mogły pozostawać w kolejce, gdy dostawca nie pobierał nowych danych, reguła generowania nie znajdowała pasujących subskrypcji albo dystrybutor nie mógł dostarczyć komunikatu. W praktyce należało rozdzielić te etapy i sprawdzić, czy zdarzenie zostało zapisane, czy wygenerowano powiadomienie oraz czy próba dostarczenia zakończyła się powodzeniem. Przydatne były logi usługi, stan procesów pomocniczych, zawartość tabel aplikacji oraz test wykonany na kontrolnym zdarzeniu i jednoznacznej subskrypcji. Sam brak wiadomości końcowej nie wskazywał jeszcze, w której części przepływu wystąpiła usterka.

Znaczenie wycofania komponentu dla starszych instalacji

SQL Server Notification Services jest technologią wycofaną z dalszego rozwoju. Komponent był dostępny w starszych wydaniach SQL Server, a następnie został usunięty z SQL Server 2008. Z tego powodu podczas pracy ze starszą aplikacją trzeba najpierw ustalić dokładną wersję SQL Server, system operacyjny, zainstalowane składniki oraz sposób uruchamiania usługi. Próba odtworzenia takiego środowiska na nowszej instalacji SQL Server bez zachowania zgodnej wersji komponentu może zakończyć się brakiem wymaganych plików, usług lub narzędzi administracyjnych.

Przy diagnostyce komputera, na którym działała starsza aplikacja, warto zabezpieczyć kopię plików konfiguracyjnych, sprawdzić wpisy usługi systemowej, przeanalizować logi uruchomieniowe i potwierdzić dostępność baz danych Notification Services. Należy również odróżnić błąd samego komponentu od problemu z SQL Server, siecią, certyfikatem, serwerem SMTP lub uprawnieniami konta usługi. Jeżeli środowisko ma zostać utrzymane, konieczne jest dobranie zgodnej platformy i kontrolowanie jej stanu. Jeżeli aplikacja ma być rozwijana, rozsądne jest zaplanowanie migracji logiki zdarzeń, subskrypcji i dostarczania powiadomień do współczesnego rozwiązania, ponieważ instalowanie nieobsługiwanego komponentu nie przywraca jego wsparcia ani zgodności z nowymi wersjami SQL Server.