Forum Discussion

Helper I

4 years ago

Solved

Update Data Source Credentials (Databricks) via API

Hi,

We have set up a CI/CD pipeline in Azure devops where we are able to deploy:

- binary pbix to PBI service

- XMLA (tabular editor) to PBI service

As an extra step of course we want to be able to set the credentials to our Azure Databricks endpoint programmatically via API. But this seems not as trivial. I found the following page Datasets - Update Datasources - REST API (Power BI Power BI REST APIs) | Microsoft Docs , but it seems the limitations cancel out the use case for Databricks.

Also found Gateways - Update Datasource - REST API (Power BI Power BI REST APIs) | Microsoft Docs but we are not working with a gateway since it's a cloud connection.

I also found TOM as a means to manage data sources, but not sure if this could be a valid option.

Any ideas on this?

mikemowgli
3 years ago
Hi PaginatedDino ,

Could you check the PATCH Datasource method? We're using this in our team, and it works even for XMLA datasets.

3 Replies

mikemowgli
New Member
3 years ago
Hi PaginatedDino ,

Could you check the PATCH Datasource method? We're using this in our team, and it works even for XMLA datasets.
v-easonf-msft
Community Support
4 years ago
Hi, PaginatedDino

The official documentation mentions that 'for other data sources, use the Update Parameters API call'.

Have you tried the content in the link below?

Datasets - Update Parameters

Best Regards,
Community Support Team _ Eason
- PaginatedDino
  Helper I
  3 years ago
  Hi v-easonf-msft
  
  Thanks for the feedback, sorry for the late reply but I was on holiday.
  Okay that might work for the "binary pbix to PBI service" scenario, but I see the following limitation for XMLA based data sets:
  Datasets created using the public XMLA endpoint aren't supported. To make changes to those data sources, the admin must use the Azure Analysis Services client library for Tabular Object Model.
  So if I understand correctly, because we leverage some PPU workspaces where we deploy via XMLA (DEVOPS + Tabular Editor), we basically cannot go around the usage of Tabular Object Model, right? At least not for the initial deployment. I think XMLA deployments don't overwrite credentials, so that could potentially be, for now, an accepted caveat.

Related content