Forum Discussion
semantic model - get datasources
- 11 months ago
Hi LuITS,
The DatasourceId you see from PowerShell/REST get datasources is not the semantic model (dataset) ID. It’s the bound data source ID (gateway/internal binding), so it won’t match your upstream semantic model GUIDs. That behavior is by design (docs).
- For composite models (reports that stitch multiple semantic models), Power BI creates a local semantic model when you publish. To find the true upstream models behind that local model:
- Best (admin) method: use the Scanner API and read upstreamDatasets for the local model ID. That returns the real source semantic model IDs and workspaces (PostWorkspaceInfo, GetScanResult).
- Workspace-scope method: call Get-PowerBIDatasource on the local semantic model and inspect connectionDetails. For entries with datasourceType = AnalysisServices and server starting with powerbi://..., the connectionDetails.database identifies the upstream semantic model you can match in the Service (docs).
Deep dive
Why the IDs don’t match
- DatasourceId in the Get Datasources response is defined as the bound data source ID, mainly used for gateway bindings; it is not the dataset/semantic model GUID (docs).
- When you publish a report that references multiple semantic models, Power BI creates a local semantic model in your workspace (chaining). That local model then has AnalysisServices-type data sources pointing at other Power BI semantic models (composite models doc).
Two reliable ways to map local -> upstream semantic models
A) Tenant/Capacity admin approach (Scanner API) - most robust
- Trigger a scan:
# Requires Fabric admin rights (or service principal) and Admin API settings Connect-PowerBIServiceAccount $body = @{ workspaces = @(@{ id = "<workspace-guid>" }); lineage = $true } | ConvertTo-Json $start = Invoke-PowerBIRestMethod -Url "https://api.powerbi.com/v1.0/myorg/admin/workspaces/scan" -Method Post -Body $body $scanId = ($start | ConvertFrom-Json).id do { Start-Sleep -Seconds 2 $res = Invoke-PowerBIRestMethod -Url "https://api.powerbi.com/v1.0/myorg/admin/workspaces/scanStatus/$scanId " -Method Get | ConvertFrom-Json } until ($res.status -eq "Succeeded") $result = Invoke-PowerBIRestMethod -Url "https://api.powerbi.com/v1.0/myorg/admin/workspaces/scanResult/$scanId " -Method Get | ConvertFrom-Json- For your local semantic model ID, read upstreamDatasets to get the actual sources. If it’s empty, make sure Admin API metadata settings are enabled in the Admin portal (setup guide).
B) Workspace-scope approach (no admin)
Connect-PowerBIServiceAccount $compositeDatasetId = "" $datasources = Get-PowerBIDatasource -DatasetId $compositeDatasetId $upstream = foreach ($ds in $datasources) { if ($ds.DatasourceType -eq "AnalysisServices" -and $ds.ConnectionDetails.Server -like "powerbi://*") { [PSCustomObject]@{ SourceServer = $ds.ConnectionDetails.Server SourceDatasetId = $ds.ConnectionDetails.Database } } } $upstream | Format-TableIf you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.
- For composite models (reports that stitch multiple semantic models), Power BI creates a local semantic model when you publish. To find the true upstream models behind that local model:
Hi LuITS,
The DatasourceId you see from PowerShell/REST get datasources is not the semantic model (dataset) ID. It’s the bound data source ID (gateway/internal binding), so it won’t match your upstream semantic model GUIDs. That behavior is by design (docs).
- For composite models (reports that stitch multiple semantic models), Power BI creates a local semantic model when you publish. To find the true upstream models behind that local model:
- Best (admin) method: use the Scanner API and read upstreamDatasets for the local model ID. That returns the real source semantic model IDs and workspaces (PostWorkspaceInfo, GetScanResult).
- Workspace-scope method: call Get-PowerBIDatasource on the local semantic model and inspect connectionDetails. For entries with datasourceType = AnalysisServices and server starting with powerbi://..., the connectionDetails.database identifies the upstream semantic model you can match in the Service (docs).
Deep dive
Why the IDs don’t match
- DatasourceId in the Get Datasources response is defined as the bound data source ID, mainly used for gateway bindings; it is not the dataset/semantic model GUID (docs).
- When you publish a report that references multiple semantic models, Power BI creates a local semantic model in your workspace (chaining). That local model then has AnalysisServices-type data sources pointing at other Power BI semantic models (composite models doc).
Two reliable ways to map local -> upstream semantic models
A) Tenant/Capacity admin approach (Scanner API) - most robust
- Trigger a scan:
# Requires Fabric admin rights (or service principal) and Admin API settings Connect-PowerBIServiceAccount $body = @{ workspaces = @(@{ id = "<workspace-guid>" }); lineage = $true } | ConvertTo-Json $start = Invoke-PowerBIRestMethod -Url "https://api.powerbi.com/v1.0/myorg/admin/workspaces/scan" -Method Post -Body $body $scanId = ($start | ConvertFrom-Json).id
do {
Start-Sleep -Seconds 2
$res = Invoke-PowerBIRestMethod -Url "https://api.powerbi.com/v1.0/myorg/admin/workspaces/scanStatus/$scanId
" -Method Get | ConvertFrom-Json
} until ($res.status -eq "Succeeded")
$result = Invoke-PowerBIRestMethod -Url "https://api.powerbi.com/v1.0/myorg/admin/workspaces/scanResult/$scanId
" -Method Get | ConvertFrom-Json- For your local semantic model ID, read upstreamDatasets to get the actual sources. If it’s empty, make sure Admin API metadata settings are enabled in the Admin portal (setup guide).
B) Workspace-scope approach (no admin)
Connect-PowerBIServiceAccount
$compositeDatasetId = ""
$datasources = Get-PowerBIDatasource -DatasetId $compositeDatasetId
$upstream = foreach ($ds in $datasources) {
if ($ds.DatasourceType -eq "AnalysisServices" -and $ds.ConnectionDetails.Server -like "powerbi://*") {
[PSCustomObject]@{
SourceServer = $ds.ConnectionDetails.Server
SourceDatasetId = $ds.ConnectionDetails.Database
}
}
}
$upstream | Format-Table
If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.