We have a problem currently with the fact that .pbix files are very different from any other SSRS reporting artefact in terms of enterprise readiness for deployments. We have a full-featured deployment system that can deploy entire trees of reporting artefacts along with replacing datasource definitions at deploy time depending on the target environment (DEV/TRAIN/PROD) etc. This has been working nicely for years but now we are moving to PBIRS and away from SSRS native mode, users want to be able to deploy .pbix artefacts in the same way. This seems to be basically impossible because:
These issues make .pbix files really poor in terms of enterprise deployments. If anyone knows any way around these issues, I would be interested ...
It really is a basic part of any enterprise grade managed reporting solution to be able to change reports (datasources, parameters, cacheing etc). during deployment depending on the target enviromnent.
It really instrests me talking about the deployment in PBIRS.
The ideal way that I prefer to manage the datasources is to have a configuration table which has the encrypted var binary of datasource conn. string, username and password. These values are unreadable but are highly secured in terms of password being shared across the team.
You can just maintain a single version of the report and just manage the configuration from the backend after the deployment. You should never go with the Datasource ID which obviously changes it's for each deployment.
You can run the below query to get the configuration values and store them in your environment.
select ConnectionString,username,Password from DataModelDataSource
Hope this guides you towards your deployment strategies.
That is also how we do it, by maintaing such details and replacing them at deploy time. However, due to the complexity of managing hundreds of PBIRS instances and their DBs, I really don't want to have to make direct DB queries just for this one operation when everything else is managed through a REST API. There is a PBIRS API for PATCHing datasources but this is essentially useless since it keys off the changeable ID. Microsoft support tell me that this is on their backlog to look at ...
Are you able to modify the connection strings from the REST API's using the Datasource PATCH query??
I was thinking there is no support to change the conn. string. However, I know that we change the security context of a DataSource.
Yes, it can be changed with the PATCH command but one can't identify the connection by name (there can be more than one) and key it to information about what to change it to from an external database, for example. As I mentioned, the GUID is useless as it changes across re-uploads and the name attribute for datasources is always null.