Als wir zum ersten Mal ein solches Cube-Deployment allerdings durchgef\u00fchrt haben, ging das nicht, ohne \u00fcber die ein oder andere Klippe zu stolpern. Deshalb beschreibe ich hier, wie man vorgehen muss.<\/p>\n\n\n\n
Voraussetzungen<\/h2>\n\n\n\n
Ausgangssituation: Ich gehe davon aus, dass wir im Visual Studio einen Cube erstellt haben.<\/p>\n\n\n\n
Wichtig ist, dass wir den Kompatibilit\u00e4tsmodus auf 1500 gesetzt haben:<\/p>\n\n\n\n (Man beachte, dass diese Einstellung nur bearbeitet werden kann, wenn das Model.bim im Visual Studio ge\u00f6ffnet ist)<\/p>\n\n\n\n \u00dcber einen Build erzeugen wie dann ein asdatabase-File:<\/p>\n\n\n\n Das erzeugt im bin<\/em>-Folder folgende Dateien (das ist noch alles unabh\u00e4ngig von unserem Deployment nach Power BI Premium):<\/p>\n\n\n\n In der Regel machen wir es nun so, dass wir in unser Quell-Code-Verwaltungssystem das „Model.asdatabase“ einchecken und von einem Branch in den n\u00e4chsten (-> Test -> Prod) bewegen – die anderen Dateien werden f\u00fcr den Deployment Wizard nicht ben\u00f6tigt. Hier werden wir gleich einen Fallstrick sehen – aber dazu gleich mehr.<\/p>\n\n\n\n Nun wollen wir das so erzeugte Model.asdatabase-File in einen Power BI Premium-Arbeitsbereich deployen. Dazu ben\u00f6tigen wir als erstes die Adresse, auf die wir es deployen k\u00f6nnen. Diese finden wir im Arbeitsbereich.<\/p>\n\n\n\n Es ist zu beachten, dass das ein Premium-Feature ist. Der Arbeitsbereich muss deshalb entweder einer Power-BI-Premium-Kapazit\u00e4t zugeordnet sein (erkennbar am Symbol Mit der Arbeitsbereichverbindung kann man sich dann auch im SQL Server Management Studio auf den XMLA-Endpoint verbinden. Das werden wir sp\u00e4ter noch brauchen.<\/p>\n\n\n\n Nun k\u00f6nnen wir versuchen, den Cube zu deployen. Dazu starten wir den Analysis Services Deployment Wizard und w\u00e4hlen die Model.asdatabase-Datei aus. Als Server tragen wir die powerbi:\/\/-Adresse von oben ein:<\/p>\n\n\n\n Die Eintragungen auf den n\u00e4chsten Seiten sind nicht relevant, zumal wir ja den Cube zum ersten Mal deployen. In der Regel deploye ich sonst Rollen nicht und \u00fcbernehme die bisher geltenden Einstellungen. Auf das Default Procesisng verzichten wir jetzt (wir machen das nachher vom SQL Server Management Studio aus).<\/p>\n\n\n\n Witzigerweise erhalten wir die Fehlermeldung „Die Datenbank „BlogDemoCube“ ist nicht vorhanden, oder Sie besitzen keine Zugriffsberechtigung.“ Das ist richtig – aber wir wollen den Cube ja auch erstmalig deployen. Hier der Screen Shot:<\/p>\n\n\n\n Die L\u00f6sung f\u00fcr dieses Problem ist, die Datei „Model.deploymentoptions“, die wir vorher gesehen haben, auch in das Verzeichnis zu legen, von wo aus wir die Datei „Model.asdatabase“ deployen. Die „Model.deploymentoptions“-Datei sieht so aus (es ist also tats\u00e4chlich keine wertvolle Information, sondern kann einfach so \u00fcbernommen werden):<\/p>\n\n\n\n Durchl\u00e4uft man nun nochmal den Deployment-Prozess, \u00e4ndert sich die Fehlermeldung zu „Der Vorgang wird nur f\u00fcr ein Modell unterst\u00fctzt, dessen Eigenschaft „DefaultPowerBIDataSourceVersion“ in Power\u00a0BI Premium auf „PowerBI_V3″ festgelegt ist.“:<\/p>\n\n\n\n Diese Fehlermeldung ist immerhin aussagekr\u00e4ftig. Wir l\u00f6sen das Problem, indem wir die datei Model.asdatabase in einem Editor (sagen wir Notepad++) bearbeiten. Wir f\u00fcgen nach „culture“ die geforderte Eigenschaft ein: „defaultPowerBIDataSourceVersion“: „powerBI_V3“,<\/strong><\/p>\n\n\n\n Vor der Bearbeitung sieht es so aus:<\/p>\n\n\n\n Und nach der Bearbeitung so:<\/p>\n\n\n\n Nun funktioniert das Deployment \ud83d\ude42<\/p>\n\n\n\n Der Cube ist im Arbeitsbereich sichtbar:<\/p>\n\n\n\n Au\u00dferdem sieht man ihn im SQL Server Management Studio:<\/p>\n\n\n\n Allerdings sind wir noch nicht fertig, da wir den Cube noch verarbeiten m\u00fcssen.<\/p>\n\n\n\n Davor m\u00f6chte ich aber noch ein paar Hinweise geben:<\/p>\n\n\n\n Machen wir also weiter: Wie nach jedem Deployment (auch nach Azure Analysis Services) muss man die Credentials neu eintragen, die f\u00fcr die Verbindung auf die zugrundeliegende Datenbank benutzt werden:<\/p>\n\n\n\n (In unserem Fall verwenden wir SQL Server Authentifizierung auf einen SQL Server in Azure)<\/p>\n\n\n\n Nun k\u00f6nnten wir – wenn es ein Azure Analysis Services-Cube w\u00e4re, die Cubeverarbeitung erfolgreich durchf\u00fchren. Wenn wir aber nun die Verarbeitung starten, kommt eine Fehlermeldung:<\/p>\n\n\n\n Die Fehlermeldung lautet: „Failed to save modifications to the server. Error returned: ‚{„error“:{„code“:“DMTS_DatasourceHasNoCredentialError<\/strong>„,“pbi.error“:{„code“:“DMTS_DatasourceHasNoCredentialError“,“details“:[{„code“:“Server“,“detail“:{„type“:1,“value“:“\/\/servername\/\/“}},{„code“:“Database“,“detail“:{„type“:1,“value“:“\/\/datenbankname\/\/“}},{„code“:“ConnectionType“,“detail“:{„type“:0,“value“:“Sql“}}],“exceptionCulprit“:1}}}“. Das ist \u00fcberraschend, da wir ja die Credentials gesetzt haben. Wir m\u00fcssen aber noch in der Power BI App im Arbeitsbereich Einstellungen des Datsets machen:<\/p>\n\n\n\n Hier sehen wir schon unter „Datenquellen-Anmeldeinformationen“ den Fehler: „Ihre Datenquelle kann nicht aktualisiert werden, da die Anmeldeinformationen ung\u00fcltig sind. Aktualisieren Sie Ihre Anmeldeinformationen, und versuchen Sie es erneut.“<\/p>\n\n\n\n Die L\u00f6sung ist nun nahe liegend: Unter „Anmeldeinformationen bearbeiten“ muss man die gleichen Credentials nochmal eintragen:<\/p>\n\n\n\n Mit diesen Einstellungen funktioniert jetzt die Cubeverarbeitung:<\/p>\n\n\n\n Damit haben wir die Aufgabe komplett erledigt.<\/strong><\/p>\n\n\n\n Eine Anmerkung gibt es allerdings noch: Ich habe den Fall mit einer Datenquelle in Azure durchgespielt. Wenn die Datenquelle on premise liegt, \u00e4ndert sich die letzte Aktion (Einstellungen des Datasets) leicht: In diesem Fall m\u00fcssen dort die Gatewayeinstellungen korrekt gesetzt werden:<\/p>\n\n\n\n Damit man diese Einstellung machen kann, muss der eigene User als Mitglied auf dem gateway eingetragen sein (\u00fcber Power BI > Einstellungen > Gateways verwalten).<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Seit \u00fcber einem Jahr gibt es nun die M\u00f6glichkeit, Cubes, die man – wie bisher auch – in Visual Studio erstellt, nun direkt nach Power BI in einen Arbeitsbereich zu deployen. Dies hat einige Vorteile: Man muss keine eigenen Analysis Services Dienste mehr vorhalten (weder on prem noch Azure Analysis Services) Das spart ggf. Lizenzen, … Deployment eines Cubes als Power BI Premium Dataset<\/span> weiterlesen ![\"\"](\"https:\/\/www.csopro.de\/biblog\/wp-content\/uploads\/2022\/04\/grafik-7.png\")
<\/a>Build und Deployment <\/h2>\n\n\n\n
<\/a><\/a> ) oder unter einer Power BI Premium Einzelbenutzerlizenz laufen (erkennbar am Symbol ). Unter Einstellungen findet man dann im Reiter Premium die Adresse f\u00fcr die Verbindung:<\/p>\n\n\n\n<\/a><\/a>
Wenn wir das aus dem bin<\/em>-Verzeichnis direkt machen, w\u00e4re uns das ganze also gar nicht passiert, da Visual Studio diese Datei dort ja ablegt. Wie gesagt, verwenden wir aber unterschiedliche Branches f\u00fcr unsere Umgebungen und haben dort nur das Model.asdatabase eingecheckt und bisher (onprem Analysis Services oder Azure Analysis Services) konnten wir auch nur mit dem Model.asdatabase deployen.
Die Datei „Model.deploymentoptions“ enth\u00e4lt dar\u00fcber hinaus auch keine Informationen, die nicht im Wizard abgefragt werden. Das macht das ganze umso komischer.<\/p>\n\n\n\n<DeploymentOptions xmlns:xsd=\"http:\/\/www.w3.org\/2001\/XMLSchema\" xmlns:xsi=\"http:\/\/www.w3.org\/2001\/XMLSchema-instance\" \n xmlns:ddl2=\"http:\/\/schemas.microsoft.com\/analysisservices\/2003\/engine\/2\" xmlns:ddl2_2=\"http:\/\/schemas.microsoft.com\/analysisservices\/2003\/engine\/2\/2\" \n xmlns:ddl100_100=\"http:\/\/schemas.microsoft.com\/analysisservices\/2008\/engine\/100\/100\" xmlns:ddl200=\"http:\/\/schemas.microsoft.com\/analysisservices\/2010\/engine\/200\" \n xmlns:ddl200_200=\"http:\/\/schemas.microsoft.com\/analysisservices\/2010\/engine\/200\/200\">\n <TransactionalDeployment>false<\/TransactionalDeployment>\n <PartitionDeployment>DeployPartitions<\/PartitionDeployment>\n <RoleDeployment>DeployRolesRetainMembers<\/RoleDeployment>\n <ProcessingOption>Default<\/ProcessingOption>\n <ADALCache>None<\/ADALCache>\n <OutputScript><\/OutputScript>\n <ImpactAnalysisFile><\/ImpactAnalysisFile>\n <ConfigurationSettingsDeployment>Deploy<\/ConfigurationSettingsDeployment>\n <OptimizationSettingsDeployment>Deploy<\/OptimizationSettingsDeployment>\n <WriteBackTableCreation>UseExisting<\/WriteBackTableCreation>\n <\/DeploymentOptions><\/pre>\n\n\n\n
<\/a>{\n \"name\": \"xxxxxxx\",\n \"compatibilityLevel\": 1500,\n \"model\": {\n \"culture\": \"de-DE\",\n \"discourageImplicitMeasures\": true,\n \"dataSources\": [<\/pre>\n\n\n\n{\n \"name\": \"xxxxxxx\",\n \"compatibilityLevel\": 1500,\n \"model\": {\n \"culture\": \"de-DE\",\n \"defaultPowerBIDataSourceVersion\": \"powerBI_V3\",\n \"discourageImplicitMeasures\": true,\n \"dataSources\": [<\/pre>\n\n\n\n<\/a><\/a>Cube verarbeiten<\/h2>\n\n\n\n
<\/a><\/a><\/a><\/a><\/a><\/a><\/a>