With our long and diverse experience in data solutions, it became clear to ABCloudZ that a large majority of Business Intelligence and Analytics solutions will, at some point and degree, rely on a semantic or multi-dimensional type of model to support its architecture, providing fast aggregations, and the desired fact-dimension capability for all sorts of data iterations.
Until recently, if we take Microsoft as an example, your Analysis Services instance – be it on premises or on the cloud –would be a required step in that path.
Through our experiences, we’ve always noticed the many players on the market kept the competition at a high and healthy levels, seeking to offer the best option on data process and integration, to then later allow you to display it through a visualization platform.
With the introduction of XMLA endpoint in Power BI, Microsoft adds to the already powerful toolbox, providing you with an open-platform for XML for analysis – or XMLA – which relies on the exact same fully encrypted communication protocol use by Microsoft Analysis Services, and under the hood, provides semantic modeling, governance, lifecycle, and data management.
At last, data processing and analysis, and visualizations, are now offered through the same platform with no additional cost.
XMLA endpoint at this point is offered only with Premium and Embedded workspaces and allows you to deploy your semantic model straight into Power BI, then later share, distribute and source from it to the same end as before with Analysis Services.
On a simple translation, while deploying your SSAS Tabular Models from Visual Studio, one of your options is to target it straight to your Power BI workspace instead of Analysis Services, centralizing one more piece of your data architecture inside of Power BI, and potentially saving you the costs and the work to run and support it through Analysis Services itself.
A simple change of task, a big architectural change
Before XMLA endpoints were embedded to Power BI Services, your typical solution architecture would most usually rely on one of the data processing and analysis services from the market, similar to the diagram below.
As described before, with XMLA endpoints now embedded to Power BI Services, your XMLA data model of choice, can rely for you to deploy it straight into Power BI as showing below.
Another possible approach can be taken as below, a more straightforward route in scenarios where your concern and scope are limited to Data Processing, Analysis, and Visualization.
Steps to enable your XMLA read-write are really simple, as by default it comes set for read-only, not allowing you to Deploy your models until you change it.
From a Premium capacity XMLA can be enabled looking at.
- Settings > Admin portal.
- Capacity settings > Power BI Premium > capacity name.
- Expand Workloads
- XMLA endpoint setting, select Read Write.
The XMLA endpoint setting applies to all workspaces and datasets assigned to the capacity.
From a Premium per User – PPU
- Click Settings > Admin portal.
- Select Premium Per User.
- Expand Dataset workload settings.
- In the XMLA endpoint setting, select Read Write.
The same can be said for changes on your deployment procedures, simply change the target server destination to be your workspace URL, and you’re ready to go. Make sure you update your Model.bim compatibility level to 1500 or higher.
Make it available, keep control, don’t worry about security
Once your model is deployed, you’ll find it available as a dataset from your workspace, with all the available options Power BI currently carries for Data sharing, distribution, and security, including the useful data lineage.
Once you open it, the details page provides you with basic features as Create a Report, Share, Analyze in Excel, Lineage, and a quick view menu with a navigation option through each available table from the Tabular Model on the right.
After you consider the above, another benefit of this approach becomes clear. On top of the now optimized and shorter architecture, your ability to distribute data through Excel doesn’t have to add to the troubles and risks of managing Excel files floating on your corporate network.
These files can be contained inside the Power BI workspace, which can rely on SharePoint and OneDrive as support storage and management points and inherit Power BI security through its own security governance that includes all the sources contained in the file.
With this setup, once an Excel Analysis is developed based on requirements, or by a user on a self-service basis, both files can be made available, shared, and distributed through Power BI, which can later be embedded through Microsoft Teams.
Despite the many layers sharing the file, and the multiple users sharing and accessing it, the security and organization can now leverage the fact that the file location is not a shared folder, or users exchanging it through e-mail or messages.
Distribution will be made by sharing the link only, users on their end can access the file from both the Excel Desktop app and on the web – through Microsoft Edge for example. In both cases file integrity, source, lineage, and security remain in the Power BI workspace, and the related OneDrive or SharePoint respective support source.
If users follow a different path, sharing their files straight through other channels as an attachment, only users with security clearance on their sources will be able to access their data. This means people without access to the respective Power BI workspace can receive and try to open the file, but access to the source will be denied, protecting data and assuring compliance.
Explore better possibilities XMLA endpoints
Let us explore your current architecture, and help you evaluate how the newest Power BI Embedded Services can optimize your results and costs, through the growing and popular data visualization platform that is Power BI.
Come experience an effective, better controlled, and safer way to empower Self-Service data analysis through Excel, without the fear of data and security breaches.
