Hi,
Firstly, I'm not entirely sure if this is feasible, and since the process I'm referring to are actually set up and owned by a third party company a lot of this is guesswork..
We have a deployment process that a third party have developed for us that allows Dataset connection strings to be changed from our Dev environment to the Production evnironment, with requests from our organisation being automated via an email handler.
Since this process is updating the datasource for a dataset, it is restricted to Direct Query (no Mixed or Import storage reports will work), so we currently can't build any composite models which is in turn putting a lot of restrictions in movign forward with business requests.
My knowledge and experience using the API is admitedly limited, but I need to make recommendations back to the business about how we are using PBI and how we're going to manage scalability and perfromance in the future and the suggestion that we try using Aggregation tables in a composite model is currently a no-go due to hte Direct Query restriction outlined above.
The API method to automate changing from a Dev to a Prod environment is working (for DQ) and I have had some success previously using Parameters within a report to handle the Server and DB name, and then using the Update Parameters API as detailed here to automate promotion from Dev to Prod. However both of these approaches I have only used/seen in isolation..
Would it be theoretically possible to 'cascade' the two approaches so that at first contact it is assumed to be a DQ only report and therefore handled by the Update dataset connection string API method, but if that returns an error regarding the method not being available for Import (or in this case Mixed) models then try using the Update Parameters API method to complete the connection change ?
So a report would follow this logic:
try
Update dataset connection string API method - would succeed for DQ only reports
catch
try
Update Parameters API method - would only be tried if report is not DQ only (or a genuine error occurs which would also error here and pass into the next catch)
catch
Return error messages
I should point out, that in both cases - Import or DQ - the server and db being changed to would be identical, just handled differently.
Thanks in advance!
