Uniwersalna procedura aktywacyjna Service Brokera

wpis w: implementacja, t-sql | 0

Usługa Service Brokera, która pojawiła się wraz z wersja 2005 zadziwia mnie do tej pory.
Od wielu lat producent niewiele w niej zmienia, co może świadczyć o dobrze przemyślanej architekturze.
Z drugiej strony monitoring tej usługi dostarczony przez producenta pozostawia wiele do życzenia patrząc na to nawet z ergonomicznego puntku widzenia. Walka z wyłączającymi się kolejkami i komunikatami typu poison spędziła nie jeden sen z powiek. Jak sobie z tym najlepiej poradzić ?
Zakładam, że czytelnik zna podstawową budowę Service Brokera i ma doświadczenie w jego stosowaniu w warunkach produkcyjnych. To o czym należy pamiętać, to świadomość, że wbudowano w serwer bazodanowy mechanizm, który potrafi obsłużyć za pomocą języka t-sql komunikację asynchroniczną bez pomocy zewnętrznych narzędzi. To niewątpliwie wielki plus funkcjonalny.
Chciałbym skoncentrować się nad propozycją budowy szkicu uniwersalnej procedury aktywacyjnej, która obsługuje kolejkę targetową.
Dokumentacja Microsoftu sprowadza się do budowy dedykowanej per kolejka procedury aktywacyjnej, gdzie spore fragmenty kodu są powtarzane i jest to nieco niezgodne z podejściem DRY.
Przyjęte założenia:
1. Przekazywane są jedynie komunikaty w formie XML
2. Każdy typ komunikatu XML na podstawie jego root elementu będzie obsługiwany przez dedykowaną procedurę składowaną
3. Każda z takich procedur ma standardową postać

4. Wszystkie obiekty bazodanowe są obrębie jednej bazy.
5. Wykorzystany zostanie dynamiczny sql.
6. Procedura przyjmie minimalną liczbę argumentów i stanie się wewnętrzną procedurą aktywacyjną każdej z kolejek targetowych.

Proponowany nagłówek:

Powiązanie uniwersalnej procedury aktywacyjnej z przykładową kolejką

Niech nasza kolejka nazywa się SampleTargetQueue.

Przygotowujemy procedurę nakladkową definiowaną per kolejka

Powiązanie kolejki docelowej z tak przygotowaną procedurą aktywacyjną.

Szkic funkcjonalny uniwersalnej procedury aktywacyjnej

1. Pobranie z kolejki pierwszego komunikatu XML

2. Na podstawie root elementu XML ustalenie nazwy procedury składowanej odpowiedzialnej za logikę biznesową

Proponowany kod transformacji :

W tym przypadku wyznaczamy wartość nazwy procedury składowanej jako
spInterfaceAccountV5getNumberGetAccountNumber

3. Obsłużenie sytuacji wyjątkowych, komunikatów typu poison, XML-i niezgodnych ze schema parametru wejściowego procedury składowanej, wyłączonej kolejki, naruszenia więzów integralność.
4. Wszystkie powyższe punkty powinny być realizowane w ramach jednej transakcji

5. Zalogowane komunikaty błędów trafiają do jednej wspólnej tabeli.
Propozycja takiej wspólnej tabeli

Przykładowy fragment kodu uzupełniającego tabelę w przypadku wystąpienia błędu:

Znaczenie pola status:

wartość znaczenie czy do ponownego przetworzenia
0 nowy wpis TAK
1 wpis przetworzony z sukcesem NIE
2 wpis przetworzony z błędem TAK
3 nie wymaga przetworzenia NIE

 

Proste zapytanie monitorujące błędne wpisy w tabeli

Należy dodatkowo wprowadzić politykę retencji, gdzie po ustalonej liczbie dni, dane powinny być usuwane trwale, w szczegolności tam, gdzie status wskazuje na brak potrzeby ponownego przetworzenia.

 

 

Literatura

https://sqlperformance.com/2014/03/sql-performance/configuring-service-broker

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.