Overslaan en naar de inhoud gaan

📅 Schrijf je in voor de Masterclass report design in Power BI

Annelijn
9-4-2024 - 3 min

Self-Hosted Integration Runtime in Azure Data Factory voor OTAP

  

Bij een recent project wilde ik een OTAP straat creëren voor Azure Data Factory (ADF). Bij dit project maken wij in ADF gebruik van een Self Hosted Integration Runtime (SHIR) om connectie te maken met het bron systeem waar wij de data ophalen. 

 

Wat is OTAP

Het staat voor Ontwikkeling, Testen, Acceptatie en Productie. Dit model biedt een gestructureerde benadering om softwaretoepassingen te ontwikkelen, testen, accepteren en in productie te nemen. In de ontwikkelingsfase wordt de software gemaakt, gevolgd door uitgebreide testen om aan kwaliteitsnormen te voldoen. Na succesvolle testen wordt de software overgedragen aan de klant voor acceptatietests. Als deze zijn doorstaan, wordt de software in productie genomen voor gebruik door eindgebruikers. OTAP helpt bij het waarborgen van gecontroleerde en zorgvuldige wijzigingen aan software, waardoor de kwaliteit en betrouwbaarheid worden bevorderd.

 

We hadden de SHIR ingesteld staan op de productieomgeving van ADF. En op de ontwikkelomgeving is het een linked SHIR, omdat wij op de ontwikkelomgeving ook wilden beschikken over productiedata. Deze refereert dus naar de IR die staat ingesteld op de productieomgeving.  
 

Deployment pipeline in DevOps

Waar ik echter tegen aan liep is dat als je een deployment pipeline in DevOps maakt, je niet een parameter kan meegeven met betrekking tot het soort IR. En je wil natuurlijk niet dat de IR van de ontwikkelomgeving wordt uitgerold naar productie, want op de ontwikkel staat deze gelinkt met productie. 

Ik ben daarom op zoek gegaan naar een oplossing hiervoor: Hoe zorg ik er voor dat ik de SHIR één keer heb ingesteld in ADF en dat ik een deployment pipeline maak zonder dat de SHIR wordt overschreven.

 

Oplossing 

Het antwoord is redelijk eenvoudig. Je maakt namelijk een aparte Azure Data Factory aan die je niet opneemt in de OTAP straat. Deze ADF gebruik je puur alleen voor het instellen van de SHIR.

 
Deze deel je met de andere ADF’s in de andere omgevingen en krijgt dan ook het subtype “Shared”:


Keuze voor aparte resourcegroup

Je kan er bijvoorbeeld voor kiezen om deze op te nemen in een aparte resourcegroup die je als prefix een “s” geeft (in plaats van d voor development et cetera). De “s” staat hier voor “shared”. Dit is handig zodat je dit gescheiden houdt van de omgevingen in de OTAP straat voor het geval je ook een deployment pipeline hebt voor je infrastructuur. 

Vervolgens maak je in de ADF’s in de diverse omgevingen een linked IR aan die dus verwijzen naar de ADF die niet in de OTAP straat zit.  

In de andere ADF’s krijgt de SHIR dan ook het sub-type “Linked”: 

Zo zijn de gegevens op ontwikkel en productie gelijk en kan je de ontwikkel omgeving normaal uitrollen naar de andere omgevingen.  

 

Het Belang van Uniforme Serverconnectiviteit

Deze opzet werkt dus alleen als je met één server te maken hebt waarmee je verbinding maakt vanuit alle omgevingen. Verbind je bijvoorbeeld met een testomgeving van het bronsysteem op je eigen ontwikkelomgeving en met een productieomgeving van het bronsysteem met jouw eigen productie omgeving dan werkt deze opzet niet, omdat je dan steeds een aparte SHIR moet instellen.

Over de schrijver

Annelijn
LinkedIn

Meer weten over het werk als Data Engineer?