Uniwersalna procedura aktywacyjna Service Brokera

    No Comments

    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

    Configuring Service Broker for Asynchronous Processing

     

    Categories: implementacja, t-sql

    Dodaj komentarz

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