Czym jest i jak działa XMLA Endpoint w Power BI?

Jakiś czas temu (marzec 2019) Microsoft ogłosił, że użytkownicy Power BI Premium będą mogli wykorzystywać XMLA Endpoint. Co to jest XMLA Endpoint, jak działa i do czego możemy ten mechanizm wykorzystać? O tym i o kilku dodatkowych rzeczach chciałbym opowiedzieć w ramach niniejszego artykułu do lektury którego serdecznie zapraszam.

Na wstępie powiedzmy sobie czym jest XMLA, jest to skrót od eXtensible Markup Language for Analysis i jest niczym innym jak protokołem używanym przez Analysis Services w którym zakodowane są requesty do serwera. Endpoint to nic innego jak serwis, który nasłuchuje tych requestów. Oznacza to, że jeżeli np. odpytujemy model tabelaryczny z poziomu Excela, Management Studio czy jakiegokolwiek innego narzędzia to wysyłamy zapytania właśnie do takiego endpointa.  To, że pod Power BI kryje się model tabelaryczny Analysis Services wiemy niemal od zawsze i nie jest to żadna tajemnica. Nie tak dawno pisałem nawet artykuł o tym w jaki sposób podłączyć się do instancji Analysis Services, która została uruchomiona pod Power BI Dekstop. Udostępnienie endpointów dla Power BI pozwoli nam podłączać się do datasetów osadzonych w serwisie z poziomu właściwie dowolnego narzędzia! Jest to również świetna możliwość podłączenia się do już stworzonych modeli z poziomu np. raportów typu Paginated czyli starego poczciwego Reporting Services.

W jaki sposób znaleźć adres endpointa i podłączyć się do osadzonego w serwisie datasetu? Jeśli używamy Power BI Desktop to jedyne co musimy zrobić to wybrać jako źródło właśnie Dataset:

Podobna funkcjonalność występuje w Power BI Report Builder gdzie jako źródło możemy wybrać Add Power BI Dataset Connection… :

Kwintesencją opisywanej funkcjonalności jest podłączenie z poziomu innych narzędzi. Aby tego dokonać wystarczy wejść na portalu we właściwości wybranego przez nas datasetu i w sekcji Server setting znajdziemy odpowiedni Connection string wraz ze wskazaniem konkretnego datasetu:

Jeśli wejdziemy we właściwości całego workspace również mamy łańcuch połączeniowy, tylko w tym wypadku tak jak można się spodziewać bez wskazania konkretnego datasetu. Na poniższej animacji można dodatkowo zauważyć, że adres ten jest widoczny tylko wtedy gdy mamy do czynienia z Power BI Premium czyli Dedicated capacity:

Powyższe adresy możemy użyć w łańcuchu połączeniowym, spróbujmy zatem połączyć się do zestawu danych z poziomu Management Studio (polecam najnowszą wersję tego narzędzia ponieważ przy starszych występowały problemy z połączeniem).  Jako Server type wybieramy zatem Analysis Services, a jako Server name wpisujemy łańcuch połączeniowy, który znaleźliśmy we właściwościach na portalu (ze wskazaniem datasetu bądź bez):

SSMS rozpozna, że chcemy się podłączyć do Power BI i wyświetli nam odpowiednie okno uwierzytelnienia:

Jeżeli wszystko się powiedzie to powinniśmy zobaczyć dataset jako bazę danych:

Jeżeli w naszym workspace jest więcej niż jeden dataset to każdy z nich zobaczymy jako osobną bazę:

Po podłączeniu standardowo możemy takie zestawy odpytywać przy pomocy języka DAX:

Na ten moment nie wszystkie datasety będą widoczne przez endpoint i tak np. zestawy danych łączące się poprzez Live Connection do Analysis Services lub np. Push dataset nie będą wyświetlane. Podobnie zresztą jak datasety powiązane z arkuszami Excela, które zostały osadzone na workspace.

Przechodząc dalej chciałbym dodatkowo pokazać w jaki sposób podłączyć się do takiego zestawu z poziomu Excela. W tym narzędziu standardowo aby pobrać dane na zakładce Data wybieramy opcję Get Data -> From Database -> From Analysis Services:

W otwartym oknie podajemy adres workspace (czyli bez właściwości Initial Catalog zawartej w łańcuchu połączeniowym):

Dalej już postępujemy tak jak zawsze czyli wybieramy bazę danych i właściwie możemy zacząć odpytywać nasz zestaw danych przy pomocy tabeli przestawnej:

 

---

Ostatnim narzędziem jakie chciałem użyć do testu endpointa jest oczywiście Powershell. Spróbuje wykorzystać standardowe podejście z połączeniem oledb do Analysis services. Cały skrypt wraz z komentarzami wygląda następująco:

#Ladujemy SSAS assembly
[System.reflection.Assembly]::LoadWithPartialName("Microsoft.AnalysisServices")  

#Connection string do XMLA Endpoint
$SSASConnectionString = 'Provider=MSOLAP.8;Initial Catalog=MyReport2;Data Source=powerbi://api.powerbi.com/v1.0/myorg/adch'

#zapytanie ktore chcemy zrealizowac poprzez endpoint
$DaxQuery = “evaluate DimCurrency”

#tworzymy obiekt bedacy polaczeniem
$Connection = New-Object -TypeName System.Data.OleDb.OleDbConnection
$Connection.ConnectionString = $SSASconnectionString

#tworzymy obiekt bedacy komenda
$command = $connection.CreateCommand()
$command.CommandText = $DaxQuery

#tworzymy zestaw danych w ktorym bedziemy przechowywac rezultat zapytania
$adapter = New-Object -TypeName System.Data.OleDb.OleDbDataAdapter $command
$dataset = New-Object -TypeName System.Data.DataSet
$adapter.Fill($dataset)

#zwracamy rezultat na ekran
$dataset.Tables[0] |Format-Table

#zamykamy polaczenie      
$connection.Close()

Oczywiście powyższy skrypt nie jest automatyczny i w trakcie wykonania wyświetlone zostanie okno do uwierzytelnienia do serwisu Power BI (oczywiście mogli byśmy się go pozbyć jednakże nie jest to celem niniejszego testu). Po prawidłowym zalogowaniu rezultat powinien być widoczny w konsoli:

Wygląda całkiem fajnie prawda? A to jeszcze nie wszystko! Część z Was zapewne niejednokrotnie używała XMLA do tworzenia obiektów w Analysis Services np. dynamicznego tworzenia partycji. Na ten moment (6.01.2020) możemy wykorzystywać XMLA Endpoints jedynie do odczytu danych jednakże Microsoft już zapowiedział, że będzie możliwość zapisu przez endpoint (link) co otwiera jeszcze większe możliwości. Nie pozostaje nam nic innego jak na ten moment cieszyć się z tego co mamy bo dzięki temu powiększa się wahlarz możliwości architektonicznych i możemy coraz lepiej integrować ze sobą narzędzia.