Tijd besparen door automatiseren
In het eerste deel van deze korte blogserie hebben we al een voorbeeld gezien van DataALM, hoe een geautomatiseerde database restore uitgevoerd kan worden, welke voorbereidingen gedaan kunnen worden, en welke post-refresh cleanup en reconfiguratie activiteiten nodig zijn. Sommige van de beschreven post-refresh taken moeten echt handmatig worden uitgevoerd, zoals het terugzetten van back-ups van nieuw aangemaakte financiële rapporten, beveiligingsconfiguraties, datamanagement templates en/of specifieke setup data in de sandbox omgeving die nog niet beschikbaar zijn in de productiedatabase en moeten worden opgeslagen.
Maar de meeste andere post-refresh taken kunnen worden geautomatiseerd door scripting, waardoor u veel tijd bespaart door de benodigde activiteiten veel sneller en efficiënter uit te voeren. In dit laatste blogdeel zullen we verschillende opties bespreken om dit te doen.
Automatische reconfiguratie via een SQL-script
Eén scripting optie is om direct SQL te gebruiken om automatisch de benodigde omgeving-specifieke instellingen voor de sandbox aan te maken en te updaten. U kunt zo’n script maken in Microsoft SQL Server Management Studio die draait op uw Tier-1 development sandbox, bijvoorbeeld door in te loggen op de target sandbox databaseserver, de Azure database te selecteren en dan “Generate Scripts…” uit te voeren in het menu Tasks:
Vervolgens kiest u “Select specific database objects” en selecteert u alle tabellen waarvoor u de gegevens wilt opslaan. Waarschijnlijk zult u in ieder geval de PrintMgmtSettings en PrintMgmtDocInstance tabellen toevoegen omdat het altijd vervelend is dat na een database refresh alle print management instellingen verdwenen zijn.
Vervolgens drukt u in de stap “Scripting Options” op de knop Advanced en zet u “Types of data to script” op de waarde “Data only”:
In de laatste stappen kunt u ” Save Scripts” kiezen en het script voor het aanmaken van gegevens wordt automatisch gegenereerd. Nadien kunt u dit script natuurlijk uitbreiden en bijwerken om het aan uw verdere vereisten te laten voldoen.
Het SQL-script uitvoeren in een Azure DevOps pipeline
Het gemaakte SQL-script kan bijvoorbeeld worden uitgevoerd via een Powershell taak in een Azure DevOps release pijplijn. Het nadeel is dat u, voordat u deze pipeline uitvoert, eerst databasetoegang moet aanvragen in LCS, die slechts 8 uur geldig is. Dus, hoewel u enige automatisering van de post-refresh taken kunt bereiken, vereist deze optie nog steeds een aantal handmatige activiteiten en is alleen geschikt voor ad hoc situaties.
Om een Just-In-Time (JIT) gebruikersnaam en wachtwoord te verkrijgen, logt u in op LCS, gaat u naar de ” Full details” van de omgeving waarvoor u de database hebt ververst en gaat u naar de “Manage environment” sectie. Daar selecteert u “Performance tuning voor AX (write to AX)”, voert u een korte beschrijving in het veld “Details” in en drukt u op de knop ” Request Access”:
Kopieer vervolgens de verstrekte JIT gebruikersnaam en het wachtwoord.
Vervolgens moet u ook databasetoegang inschakelen door een Inbound Allow regel toe te voegen voor het publieke IP-adres van de Tier-1 (bijvoorbeeld) development sandbox van waaruit u het SQL-script in de target Azure database gaat uitvoeren. Selecteer “Enable access” in het Maintain menu en voeg een Inbound Allow regel toe door op het plus teken te drukken en de juiste informatie in te voeren:
Na deze extra stappen kunt u nu de Azure DevOps pipeline uitvoeren. Log in op het Azure DevOps project van uw klant en selecteer Pipelines > Releases > Set environment-specific values en druk op de “Create release” knop:
In het dialoogvenster dat is verschenen geeft u vervolgens de JIT-gebruikersnaam en het JIT-wachtwoord op die u van LCS hebt verkregen en drukt u op Create:
Open de nieuw aangemaakte release en selecteer Deploy in de “Start VM” stage:
Het “Run SQL script” wordt automatisch gestart zodra de fase “Start VM” is voltooid. Deze stap kan als volgt worden gedefinieerd:
Om de SQL-statements in PowerShell uit te voeren, wordt het commando “Invoke-Sqlcmd” gebruikt. U kunt afzonderlijke SQL-statements uitvoeren met dit commando of een SQL-scriptbestand uitvoeren zoals in ons voorbeeld:
Na succesvolle afronding zal deze pipeline alle gewenste omgevings-specifieke waarden in uw sandbox omgeving hebben ingesteld, zoals print management instellingen, enzovoort.
Hoe zit het met een Runnable class of een Custom service?
Een andere automatische herconfiguratie scripting optie is het creëren van een runnable class (het goede oude job script van AX) om de omgeving-specifieke waarden in te stellen. Deze class kan worden uitgevoerd via de SysClassRunner functionaliteit in Dynamics en is vooral nuttig voor het herstellen van de waarden van de versleutelde velden die werden gewist tijdens de database refresh, omdat dit niet kan worden gedaan in een SQL-script.
In plaats van een runnable class kun je ook een aangepaste webservice endpoint bouwen die on demand kan worden aangeroepen nadat de database refresh is voltooid.
In deze code-gebaseerde scripting opties zou je ook de automatische configuratie kunnen opnemen zoals die gebeurt door middel van het eerder beschreven SQL-script. Natuurlijk, als je hier iets in wilt veranderen, dan moet je een codewijziging doorvoeren, terwijl een SQL-script daarentegen op elk moment kan worden gewijzigd zonder dat je door de build en release processen hoeft te gaan die gepaard gaan met die codewijziging. Echter, als u regelmatig terugkerende environment database refreshes wilt doen, bijvoorbeeld elke dag, dan zijn deze code-gebaseerde scripting opties echt de juiste manier!
Conclusie
Dit brengt ons aan het einde van deze tweedelige blog. In dit laatste deel hebben we een aantal automatische post-refresh herconfiguratie opties gezien om de benodigde activiteiten veel sneller en efficiënter af te handelen.
Ik hoop dat u deze blogserie met plezier gelezen heeft en weer het een en ander geleerd heeft. Tot de volgende keer!