Prenumerera på dataförändringar från SQL Server Master Data Services

Hur bygger man en effektiv prenumeration på Master Data?

När du använder Master Data Services (MDS) i SQL Server för att lagra och hantera masterdata så erbjuder produkten en hel del funktioner för detta. Här finns stöd för att organisera informationen i en masterdata-modell. Det finns funktioner för att skapa och underhålla strukturer som till exempel samlingar och hierarkier. Produkten kan dessutom användas enskilt eller tillsammans med SQL Server Data Quality Service (DQS) och/eller SQL Server Integration Services (SSIS) för att förbättra datakvalitén på masterdata. Detta kan ske i MDS genom stöd för Business Rules eller som jag skulle vilja kalla dem Data Quality Rules. I DQS sker det till exempel genom att utnyttja dess funktioner för datatvätt och de duplicering. Dessutom innehåller MDS såklart funktioner för att importera data och sedan exportera den färdigställda masterdata mängden.

Inget inbyggt stöd i Master Data Services

Om du redan har kommit så långt att du har börjat planera för hur masterdata ska tillgängliggöras så har du kanske märkt att MDS inte har något stöd för att prenumerera på förändringar via Push-teknik. Det går alldeles utmärkt att hämta aktuella masterdata-medlemmar från databasen via det som i Master Data Services kallas för prenumerations vyer eller att dela domänerna mellan kollegor i Excel. Men att Master Data Services själv skickar ut förändringar eller notifikation om förändring av masterdata det finns det inget stöd för.

Lösningsförslag

En lösning på detta scenario går däremot utmärkt att bygga på databasnivå med hjälp av Change Data Capture (CDC), Service Broker och MDS. Det bygger då på att vi med hjälp av CDC på masterdata-entitetens lagringstabell reagerar på förändringar. Genom att läsa CDC-tabellen med korta intervall från en Service Broker tjänst som använder automatisk aktivering för att bearbeta kön så kan man hålla nere ledtiderna på förändrat data. Den definierade tjänsten innehåller en kö med en Stored Procedure som startar på timer för att läsa ut mängden av nya och förändrade rader från CDC och sänder dessa som ett meddelande på kön till en ytterligare tjänst. Aktiveringsproceduren för denna tjänst lyssnar efter meddelande om ny eller förändrad masterdata och agerar på detta.

Designval

Här finns ett vägval att göra, endera så innehåller meddelandet hela det aktuella informationsobjektet eller så innehåller det bara en referens till nyckeln för informationen. Detta val grundar sig på de datakvalitétskrav som finns och förändringstakten hos ditt masterdata.

Vi kan till exempel av prestandaskäl välja att inte skicka med hela informationsobjektet varje gång det förändras. Ett förslag är att endast skicka med nyckelvärdet och sedan låta aktiveringsproceduren hämta den senaste gällande versionen för medlemmen. Det förutsätter att det är godtagbart för mottagande system att få endast den senaste gällande versionen eftersom det finns risk för att tappa mellanliggande versioner av data om förändringstakten är hög.

Ett annat designval handlar vem som uppdaterar det mottagande systemet, ett alternativ skulle kunna vara att med hjälp av routing i Service Broker skicka meddelandet till den SQL Server-instans där mottagande system finns och att aktiveringsproceduren på den instansen tar hand om uppdateringen.

Eller ska masterdata uppdateringar spridas via företagets Enterprise Servise Bus (ESB) och konsumeras via REST-baserade microtjänster?

Teknik

Lösningen baseras endast på kända SQL Server tekniker som möjliggör denna typ av prenumeration. CDC är den komponent som fångar upp förändringen och Service Broker den komponent som håller igång processen och skapar en händelse för varje uppdaterad eller nytillkommen medlem i den aktuella masterdata entiteten i MDS. CDC måste sättas upp för varje entitet men objekten i Service Broker kan återanvändas så länge meddelandetyper och aktiveringsprocedurer anpassas för detta.