Quantcast
Channel: Developer topics
Viewing all articles
Browse latest Browse all 17897

Power BI Embedded multi-tenancy architectural patterns

$
0
0

We've got a multi-tenant SaaS application, deployed in Azure, and are looking into utilizing Power BI Embedded for serving Analytics.

 

Basically I'm trying to understand some architectural options specific to the multi-tenancy aspects but can't find any references to architectural patterns specific for multitenant apps utilising Power BI. 

 

For reference, each tenant will have a common database schema for the data, but we have followed the 'Database Per Tenant' pattern (https://docs.microsoft.com/en-us/azure/sql-database/saas-tenancy-app-design-patterns).

 

I was expecting to be able to define reports/dashboards/datasets etc at a level above workspaces so they could be referenced per workspace but this doesn't seem to be a design feature (unless I'm missing something)

 

As far as I can understand, we have 2 options for a multitenancy model. Any suggestions/experiences would be greatly appreciated.

 

NOTE: Apologies for any newbie gaffs as I'm just understanding the scope and feature set of Power BI so may be missing some fundamentals here!!

 

Option 1 - Workspace Per Tenant


Setup a singe 'Tenant Workspace Template' workspace that has all of the reports/dashboards we would make available

 

With this we could utilise the Powershell in the following article to duplicate a 'template' workspace (when a tenant is onboarded)
https://powerbi.microsoft.com/en-us/blog/duplicate-workspaces-using-the-power-bi-rest-apis-a-step-by-step-tutorial

 

We then would have to fix up the datasources to point to the correct to the correct database for that particular tenant (this I have already POC'd using the PowerBI client sdk).

 

Advantages
- clean seperation of workspace per tenant
- dedicated datasource to tenant data (good data isolation)

 

Disadvantages
- maintenance nightmare (updates to reports in the central 'Tenant Workspace Template' would need to be propagated to 100's/1000's of tenant workspaces).


Option 2 - Single global workspace with dynamic datasource routing

 

I'm not sure if this can be done, but potentially for each request, dynamically lookup the correct datasource depending upon the claims of the user.

 

Advantages
- Single report/dashboard/dataset definitions
- No maintenance across tenants (ie single sources/codebase)

 

Disadvantages
- Must have bullet proof datasource routing (ie risk of serving incorrect tenant data)

 


Viewing all articles
Browse latest Browse all 17897

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>