OĪ nice and easy one, -O allows for existing models to be overwritten. Once again our Service Principals are environment dependent, so we have these parameters piped in from Azure Pipelines. Going back a line, we establish a similar dynamic connection string for the AAS instance.
D "Provider=MSOLAP Data Source=$($_.TargetASServer) User ID=$($ASServicePrincipal) Password=$($ServicePrincipalApplicationSecret) Persist Security Info=True Impersonation Level=Impersonate" "$($_.TargetASDatabaseName)" Within our project the Username/Password of the SQL DB instances are environment dependent, hence the values are not specified in the configurations function but instead passed in to the script from Key Vault through Azure Pipelines.
TABULAR ANALYSIS PASSWORD
Let’s jump ahead and take a look at that: -C "Placeholder" "Provider=SQLOLEDB.1 Data Source=$($_.TargetSQLDataSourceServer) Persist Security Info=True User ID=$($TargetSQLDataSourceUsername) Password=$($TargetSQLDataSourcePassword) Initial Catalog=$($_.TargetSQLDataSourceDatabase)"Īs you can see, the SQL DB Server, Database, Username, and Password are all dynamically filled in at run-time. What this script is doing is replacing the data source found in the Model.bim with a standardized placeholder which we subsequently swap out in our -C parameter call. Note that this is the whole script - it doesn’t require a namespace/class definition to function, as this is all resolved by Tabular Editor. In our case, we point it to a C# script within our Source Control.
S specifies a script that TabularEditor can use to parameterize deployments. S "$PSScriptRoot\.\.\Dependencies\ConnectionStringCleanup.cs" ` If for whatever reason the Model.bim in your project is named differently across projects, then you would need to add this to the configuration document. We call the TabularEditor.exe and pass in the path to our Model.bim. & "$PSScriptRoot\.\.\Dependencies\Tabular Editor\TabularEditor.exe" "$PSScriptRoot\.\.\.\AzureAnalysisServices\$($_.ProjectModelName)\Model.bim" The call to Tabular Editor itself is handled through the use of multiple command line parameters and switches, but what are they actually doing? The arguments between the “Build” and “Deploy” parameter sets are mostly the same, so I’ll run through them and highlight where they differ.
TABULAR ANALYSIS FULL
The Powershell script itself is designed to support two different scenarios - instances where developers would want to build the deployment script on their machine, and for the CI/CD process to handle the full deployment of changes. Given how great it is, it is probably not much of a surprise then to find out it has a very robust and powerful command line executable which is perfect for our requirements! Let’s take a closer look… Not only that, but you can connect to deployed models, interrogate them, make changes, and deploy your changes all from within the GUI. Unlike editing within Visual Studio, you can make changes directly against the Model.bim file on your machine without needing to deploy it to a Workspace Server. Tabular Editor has to be one of my favoruite tools for interacting with Tabular Models. bim, or the TMSL script we had made instead? Pondering all this led me to my next discovery… Second Attempt: Introducing Tabular Editor! Not only that, but what if we wanted to support different types of outputs depending on whether it is a build or a deploy? In our current example we go ahead and deploy the updated Model.bim, but what if we wanted to export the. While we have shown that this Powershell deployment does work in principal, it’s still obvious that a lot of configurations and tweaks would need to be made in order to support running this across multiple models - that’s not to say we couldn’t do it all in PowerShell, but supporting all the different environments and edge cases could get a little tricky!
TABULAR ANALYSIS CODE
Changing to Powershell 5 solved this.Īfter executing this code we have successfully deployed our model! When I was testing this code I ran into errors using Powershell 6 as the sqlserver module was not correctly importing the Invoke-ASCmd cmdlet. This will initiate the interactive sign in flow. If you wanted to test this code locally and didn’t want to use a Service Principal, you could use your own e-mail assuming you have permissions to set yourself as an admin on the AAS instance.
0 kommentar(er)
