Overwriting DataSources is handled badly

[phkrug]

I'm currently trying to setup a pipeline and struggeling with the credential handling and the deployment of DataSources. The overwrite switch is handled quite badly by the SSRS itself. If the DataSource is present at the deployment the SSRS returns the status code 500 "Internal Server Error" (and 400 "Bad Request" in the body) of which both result in a deployment error in the pipeline. None of that is entirely true because the request is valid and the switch suggests that there could be already a DS with this name so handle that situation gracefully.

I suggest the intended behavior is that the DataSource is not overwritten if present and there is a warning. This happens if you deploy from within VS. The problem is that those http status code signal an error. So the SSRS is handling this whole situation quite bad. One solution could be to check if the DS is present before calling CreateDataSource from the API.

To add some background why this is a problem. I'd like to use a service account for that DataSource and store the credentials safely inside the SSRS. If I provide the full credentials on deployment the password would have to be in the XML and stored unencrpyted in the VCS. I can't deploy my reports with a properly linked DataSource without describing this DS in the XML for the reports. And I if I do that I would have to overwrite the DataSource because of how the SSRS handles overwriting. If the DS is overwritten I would have to either reapply the password for the DS in the SSRS website or provide the unencrypted password while deploying.

[mmajcica]

I usually set a placeholder for passwords, then, during the deployment, based on the environment, I substitute those. Similar to what I describe here http://blog.majcica.com/2018/04/25/deploy-ssis-packages-from-tfs-vsts-build-release/

Would this work for you?

Regarding the overwrite switch, can you show me some code on how it should work?

[phkrug]

I don't see when and where you are replacing those placeholders in your config. If I can use those replacements out of the DevOps Server then this would be the preferred way. But I don't see that the code is replacing those strings after it read the config. In my setup the config is part of my git repository. In the linked blog post you explain how to use placeholders or parameters for SSIS which don't apply here.

I could try to prepare another pull request with an example how I think the switch could work in DataSources. For the other artifacts like folders or reports this is quite easy. But the DataSources have to be linked to the reports and you heavily rely on the response from creating the DataSources so you have the ID and name of the DS. This is quite tricky if you don't actually create them if they are already present. In that case you would need to find the correct ID (you already got the name because that is how you know that this DS already exists). Bacause of this I'm struggeling with the change.

[mheptinstall]

@phkrug the placeholders are being replaced with variable values using the Replace Token Task. Your configuration would use tokens e.g. {{ServerName}} which this task would replace with variable values when deploying. Variables values can be stored encrypted in your pipeline although they may appear in logs after you have used the Replace Token Task.

[phkrug]

Works like a charm! Thank you for this hint. The issue with the crendentials for the DataSource is gone. But the handling of existent objects while deploying is still an issue I guess. In my case I can't run the deployment without the setting of overwrite=true because the second deployment will fail as the reports and folders will already be present.