Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Register now to learn Fabric in free live sessions led by the best Microsoft experts. From Apr 16 to May 9, in English and Spanish.

Reply
Anonymous
Not applicable

Datasource status by ID REST API call fails with Bad Request 400 error

I am working with the REST API. Per the documentation, we can query datasource status by ID. https://docs.microsoft.com/en-us/rest/api/power-bi/gateways/getdatasourcestatusbyid It appears the URL is identical to querying a datasource by ID, with "/status" appended to the end.

 

But I always get a 400 "Bad request" error.

 

A GET with the appropriate header to this URL to query the datasource works:

https://api.powerbi.com/v1.0/myorg/Gateways/742dbe90-2a61-453e-90e7-123456789abc/Datasources/38ec9ca...

 

A GET with the same header to this URL to query the datasource status fails:

https://api.powerbi.com/v1.0/myorg/Gateways/742dbe90-2a61-453e-90e7-123456789abc/Datasources/38ec9ca...

 

If I try it with "/status2" the error is 404 "Not found". So "/status" is there, but either it is broken, or there is an error in the docs on how to use it, or I am doing something wrong.

 

Any ideas?

 

Thanks,

Tim Curwick

 

 

2 ACCEPTED SOLUTIONS
Anonymous
Not applicable

With a hint from Kay Unkroth, I realized the API returns more detailed error information in the response body. When using Invoke-RestMethod, the response body requires a little work to get at.

 

try { Invoke-RestMethod -Uri $Uri -Headers $Headers }
catch { ([System.IO.StreamReader]$_.Exception.Response.GetResponseStream()).ReadToEnd() }

 

With that, I was able to see that I'm getting a timeout error. I'm opening a ticket with Microsoft to find out why.

 

Thanks,

Tim Curwick

View solution in original post

Anonymous
Not applicable

WABD - Working as (badly) designed.

 

It turns out the API returns an http error to tell you the queried datasource status is "error". (We have an on-going issue putting many of our datasources in an error status, which is why I'm writing something to monitor the status.) Which means you need complicated code to tell the difference between an actual http error and status information. And additional complicated code to get the additional details about the error status, because PowerShell commands don't allow for the possibility that an API would successfully return data, but label the response with an error code.

 

 

View solution in original post

4 REPLIES 4
Anonymous
Not applicable

With a hint from Kay Unkroth, I realized the API returns more detailed error information in the response body. When using Invoke-RestMethod, the response body requires a little work to get at.

 

try { Invoke-RestMethod -Uri $Uri -Headers $Headers }
catch { ([System.IO.StreamReader]$_.Exception.Response.GetResponseStream()).ReadToEnd() }

 

With that, I was able to see that I'm getting a timeout error. I'm opening a ticket with Microsoft to find out why.

 

Thanks,

Tim Curwick

Anonymous
Not applicable

WABD - Working as (badly) designed.

 

It turns out the API returns an http error to tell you the queried datasource status is "error". (We have an on-going issue putting many of our datasources in an error status, which is why I'm writing something to monitor the status.) Which means you need complicated code to tell the difference between an actual http error and status information. And additional complicated code to get the additional details about the error status, because PowerShell commands don't allow for the possibility that an API would successfully return data, but label the response with an error code.

 

 

Anonymous
Not applicable

Hi,

 

Not sure if this is still useful but if the datasource is OK then a 200 response is returned with no data. So lets say you do $ds = Invoke-Restmethod ...

If $ds -eq $null {

     $result = "OK"

}

In case the datasource is in error you can do this:

Try {

$ds = Invoke-Restmethod ...

$datum = New-Object –TypeName PSObject
$datum | Add-Member @{DataSourceID=$datasource_id} -PassThru
$datum | Add-Member @{DataSourceStatus="OK"} -PassThru
$datum

}

catch {

$streamReader = [System.IO.StreamReader]::new($_.Exception.Response.GetResponseStream())
$ErrResp = $streamReader.ReadToEnd() | ConvertFrom-Json
$streamReader.Close()
$datum = New-Object –TypeName PSObject
$datum | Add-Member @{DataSourceID=$datasource_id} -PassThru
$datum | Add-Member @{DataSourceStatus=$ErrResp.error.code} -PassThru

$datum

}

}

 

Hope this helps

Anonymous
Not applicable

liljath,

 

Thank you. I am doing something similar.

 

BTW, while it still appears in a lot of sample scripts, this is actualy a PS v1 coding pattern:

 

$datum = New-Object –TypeName PSObject
$datum | Add-Member @{DataSourceID=$datasource_id} -PassThru
$datum | Add-Member @{DataSourceStatus="OK"} -PassThru
$datum

 

Try this instead:

[pscustomobject]@{
    DataSourceID = $datasource_id
    DataSourceStatus = $ErrResp.error.code }

 

Thanks,

Tim Curwick

Helpful resources

Announcements
Microsoft Fabric Learn Together

Microsoft Fabric Learn Together

Covering the world! 9:00-10:30 AM Sydney, 4:00-5:30 PM CET (Paris/Berlin), 7:00-8:30 PM Mexico City

PBI_APRIL_CAROUSEL1

Power BI Monthly Update - April 2024

Check out the April 2024 Power BI update to learn about new features.

April Fabric Community Update

Fabric Community Update - April 2024

Find out what's new and trending in the Fabric Community.