Problem with new new REST API and report datasources

[Anonymous]

I am having problems with the new SSRS REST API, in particular relinking uploaded reports to their datasources. Microsoft have confirmed that the API doc as published is not correct in that the PUT on report datasources should take an array of datasources, not just one datasource but I still can't get it to do anything other than return 400 errors every time, no matter what I try. Nothing useful in the logs either. Here is a minimal snippet in Powershell where I simply get the datasources, modify the path and try to PUT the changes datasources back again. The PUT always gets a 400 error.

$ret = Invoke-RESTMethod -Uri "$restroot/Reports(Path='/$replib/$fname')/DataSources" -Method GET -ContentType "application/json" -UseDefaultCredentials

# $ret is correct and $ret.value is an array of datasources

# Change datasource path
$ret.value | % {
  $_.Path = "/$dclib/" + $_.Name
}

# Convert to JSON
$body = $ret.value | ConvertTo-Json

# Put modified Datasources array back into report
$ret = Invoke-RESTMethod -Uri "$restroot/Reports(Path='/$replib/$fname')/DataSources" -Method PUT -Body $body -ContentType "application/json" -UseDefaultCredentials

[Anonymous · Accepted solution]

Solved myself - by increasing tracing level on PBIRS logs and seeing a complaint about JSON payload not matching to an array type. I only had one datasource and due to the amazingly stupid mapping of single-item arrays into the bare item which Powershell does in some circumstances, the endpoint was not getting a JSON array. Fix was to replace:

$body = $ret.value | ConvertTo-Json

 with

$body = ConvertTo-Json $ret.value

because the pipe invokes the stupid array unwrapping. This silly behaviour of Powershell is particularly annoying in APIs where datatypes matter so much.