XMLA Semantic Model Management

Know what the endpoint is for

The XMLA endpoint is the protocol that Power BI uses for communication between client applications and the engine that manages semantic models. It is the door that external tools and notebooks knock on when they need to query, inspect, or change a published model.

Every Fabric or Power BI Premium workspace exposes an XMLA endpoint, and all data sent over XMLA is fully encrypted. Nothing has to be switched on for that traffic to be protected, and nothing can be switched off when a tool fails to connect.

It helps to fix the boundaries of the protocol early:

Everything else in this concept follows from that first line: which mode you connect in, what address you connect to, and which tool you point at it.

Match the access mode to the job

The endpoint is enabled for read-only access by default. Read-only access supports queries against model data and metadata, which is enough for inspecting, testing, and reporting on what a model contains.

A capacity administrator can enable read-write access for a workspace. Read-write access is the documented choice when an external tool must deploy model changes, run scripted operations, or trigger refresh.

This access-mode distinction is the first deployment decision: inspection can remain read-only, but modification requires read-write access.

It explains a failure that looks mysterious from the tool's side. A client that connects, browses, and queries perfectly yet cannot deploy is not misconfigured; it is meeting the default, and only a capacity administrator can change it.

Address the workspace

An XMLA connection string uses the format powerbi://api.powerbi.com/v1.0/[tenant name]/[workspace name]. Two things are named there, and neither of them is a model: the tenant and the workspace.

The connection string targets a workspace rather than one semantic model. That is a deliberate shape, not an omission.

Because the address stops at the workspace, one connection string serves every model inside it. Convenient — a single string in a notebook or a tool profile — but it means the address alone never tells you which model you are working with.

Two mistakes follow from forgetting that:

• Pushing a model name into the tenant segment, which corrupts the address instead of selecting anything.
• Reading a successful connection as proof that the right model is open. It is not; the model is chosen afterwards.

Then choose the model in the client

After connecting to the workspace, specify the semantic model to query. How you name it depends on the client. SemPy accepts the model name as a parameter, while DAX Studio and Tabular Editor use the model as the database or initial catalog.

This second step is where an otherwise healthy session stalls. A tool that reached the correct workspace address and still has nothing to query has not chosen a model yet. The fix is a selection, not a new connection string, and certainly not a change to how the traffic is protected.

Applications designed for Azure Analysis Services or SQL Server Analysis Services typically work with Power BI through XMLA with minimal configuration changes, so the two-step habit — workspace first, then model — carries over from tooling a team may already own.

Validate with SemPy

SemPy is included in Fabric Runtime 1.2 and later and connects Fabric notebooks to semantic models through XMLA. That turns model validation into something a notebook can do on demand, the same way every time.

Its metadata functions can list tables, columns, measures, and relationships in a published model. Before asking whether a model is right, you can ask what it contains.

SemPy also supports calculation and data-quality checks:

read_table() loads model data into a FabricDataFrame so notebook assertions can check conditions such as null or duplicate keys. These scripted checks are repeatable and can form a validation suite that runs before deployment.

Read a relationship check correctly

The relationship check is worth a closer look, because its result reads backwards at first. The list_relationship_violations() function receives a dictionary of table DataFrames and returns foreign-key rows that have no matching primary-key value; an empty result means the relationships are intact.

An empty output is the good outcome. Rows in the output are orphans: keys pointing at something that is not there.

The other functions answer other questions. evaluate_measure() checks that a calculation returns what it should, grouped by the dimensions you name, and evaluate_dax() runs whatever query a check needs. Structure and arithmetic together are what a pre-deployment suite has to cover.

Pick the external tool by the job

DAX Studio provides interactive DAX query testing against a published semantic model. Tabular Editor provides a visual object tree for model inspection and editing, and its Best Practice Analyzer applies configurable structural rules. ALM Toolkit compares schemas between semantic models, such as development and production models.

All three use the same XMLA workspace connection string, so the choice between them is about the job in front of you, not about access.

Choose SemPy for automated, repeatable validation and an external tool for interactive desktop feedback. One person exploring a problem wants an answer now; a team shipping every week wants the checks to run without anyone remembering to run them.

Key takeaways

• Read-only XMLA supports data and metadata queries; deploying model changes requires read-write access, enabled by a capacity administrator.
• The connection string targets a workspace, after which the client selects a semantic model — by parameter in SemPy, as the database or initial catalog elsewhere.
• Every Fabric or Premium workspace exposes the endpoint, and all traffic over it is fully encrypted.
• Use SemPy for scripted, repeatable validation: relationship violations, measure evaluation, custom DAX, and table-level assertions.
• Use the external tools for interactive work: DAX Studio for query testing, Tabular Editor for structure and rules, ALM Toolkit for schema comparison.