cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Highlighted
plk Regular Visitor
Regular Visitor

Enterprise reporting artefact deployment strategies with PBIRS

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:

 

  • The file format of .pbix is not editable programatically (unlike every SSRS artefact) and so data sources cannot be changed directly which means they have to be uploaded to PBIRS and then changed with the REST API .... but ...
  • Datasources inside a .pbix file have no name and even the ids change every time the file is deployed to a PBIRS server. So, there is no way of matching datasources to the database of connections we use to determine datasources for a target environment during deployment.

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.

4 REPLIES 4
harikishant Regular Visitor
Regular Visitor

Re: Enterprise reporting artefact deployment strategies with PBIRS

Hi Mate,

 

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.

 

Cheers,

Hari T

plk Regular Visitor
Regular Visitor

Re: Enterprise reporting artefact deployment strategies with PBIRS

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 ...

harikishant Regular Visitor
Regular Visitor

Re: Enterprise reporting artefact deployment strategies with PBIRS

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.

 

Cheers,

Hari T

plk Regular Visitor
Regular Visitor

Re: Enterprise reporting artefact deployment strategies with PBIRS

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.