Clarifications about embedding limitations in Power BI Pro license

[rbellini]

Hi,

we are building a web application that will be used by different tenants, our customers, and will allow them to gain some insights about their business processes. You can consider this web application to be a "visualization tool" to display meaningful charts and diagrams starting from raw data collected by our flagship product.

I am responsible for maintaining and improving the platform, whose initial development was outsourced to another company.

First of all, the application leverages Power BI to embed dashboards in the web page; each tenant will have its own workspace (group) containing a set of dashboards. It is worth noting that we are in charge of maintaining the different workspaces and the tenants have no Power BI license, they will access their data only through our platform. The application code currently implements the "user owns data" scenario, and obtains token to access Power BI by authenticating with our Power BI Pro account data; the dashboards are then embedded in the browser by including the access token as "AAD" type (not "Embed") in JS.

I thought about changing the authentication process by switching to the "app owns data" scenario, since we have just one license and we do not use tenant identity to authenticate to Power BI, not to mention that the password of the user associated to the license expires periodically and this can lead to unnoticed service disruption. So far so good, I set up a service principal and changed the token type to Embed in the JS part, everything works just fine.

Yesterday I stumbled upon the infamous embed token limit, which means that right now we have reached a usage of 10% of free embed tokens. The docs recommend to switch to dedicated capacity, so our choices seem to be either Embedded or Premium.

Consider that right now our cost related to Power BI is $10 each month for the Pro license, and that using the Embedded SKU with the basic tier A1 will increase that cost by ~70x. We would like to avoid incurring in such high charges, since we cannot easily justify hundreds of dollars each month to our future few customers, just for a data visualization platform.

Given that the current authentication and embedding scenario seems to work, with the caveat that the web application is still not available to any of our customers and we are only performing internal tests on it, is it feasible to continue using the password approach with the AAD access token for embedding or is there any drawback that might come up in the future when the system will be running in production for our tenants?

For example, there can be some limitation or throttling to the Azure Active Directory/Power BI API or embed URL when using the Pro license, whereas Embedded or Premium have no limitation? How can we expect the application to behave when multiple accesses/requests will be issued from different browsers that refer to the same licensee? I cannot find such information on the docs.

I understand the security concern of disclosing the AAD token, since it will be available by inspecting browser network calls, but we can rest on the fact that this is meant to be a controlled platform and a limited number of users/tenants will be granted access.

Thanks in advance for any clarification on this topic.

[brentlightsey]

@rbellini - I'd be curious to hear what your going forward solution has been. Did you use the API to calculate usage? What did you determine to do for yoru strategy?

Curious as I'm facing a similar situation. Feel free to private message me if easier, or I'm here on LinkedIn. 

https://www.linkedin.com/in/brentlightsey/

Thanks!

-Brent

[Jayendran]

Hi @rbellini ,

As per the official doc,

Embed tokens with PRO license are intended for development testing, so a Power BI master account or service principal can only generate a limited number of tokens. Purchase a capacity for embedding in a production environment. There's no limit to how many embed tokens you can generate when you purchase a capacity. Go to Available Features to check the usage value that indicates the current embedded usage in percentage.

For your question,

Yes PowerBI embedded capacity/premium capacity don't have any limitation.There won't be much difference  when multiple accesses/requests will be issued from different browsers that refer to the same license, but without having the capacity you will easily exhasted the embedded token generation.

If you really concern about the cost, understand which capacity suits for your requirement either azure sku or premium

You can save cost in Azure SKU by resume/stop the capactity on non-business hours/weekends. So that you can charge only the hours you consumes.

I already provided a much detailed answer for better understanding of ASKU and Premium Capacity. What should you choose ? When should you choose ? You can refer that from below link

https://community.powerbi.com/t5/Developer/Power-BI-Embedded-in-the-Organisation/m-p/839583#M21309

[rbellini]

Hi @Jayendran ,

thanks for your prompt reply.

Based on the link you posted and on my research I think that Azure SKU (A1) will be more than enough, given our current requirements.

As for this part

---

There won't be much difference  when multiple accesses/requests will be issued from different browsers that refer to the same license, but without having the capacity you will easily exhasted the embedded token generation.

---

I think I need to rephrase my question. I'm aware of the eventual exhaustion of free embed token, whether they are generated using master account or service principal approach. My question is about the other scenario, i.e. no embed token generation request is performed by our back-end code, instead the back-end authenticates against Azure AD and returns directly the access token, which is used along with the embedUrl retrieved from Power BI API and included by our JavaScript when displaying embedded dashboard (with TokenType AAD, not Embed).

Since this approach seems to work as well and does not imply generating an embed token, as far as I can tell, I suppose it can be used indefinitely without leading to embed token exhaustion: am I right in this assumption?

I was wondering if doing this might cause problems of different nature in the long run (other embedding limits, API throttling, performance problems, different authentications to Azure AD with the same user) when the platform will be used by the tenants. This is obviously ignoring the potential security issue of exposing access tokens to the client side, and the minor but still bugging issue about recurring password expiration.

In other words, is this a suitable workaround or is there no alternative to using at least Power BI Embedded and looking for other ways of optimizing cost, such as the automatic resume/suspend approach you suggested?

Thank you for your time.

[Jayendran · Accepted solution]

Hi @rbellini ,

Yes, you are right for the user owns data there is no concept called "embedded Tokens" also no need to worry about exhaustion of embedded tokens.

But when coming to long term/performance side, microsoft suggest to use a Premium capacity  as your report is going to used by the entier organization so the rendering of reports will be slowed down due to the default shared capacity of your workspace (in other words workspace without any capacity)

So viewing in long term you should use a Premium capacities (either EM SKU's or P SKU's) for your embed analytics.

But Premium capacity is not like run on demand approach like ASKU you cannot able to resume/suspend the capacity. 

EM SKU is yearly commitment ,monthly billed montly 

P SKU monthly or yealry commitment, billed montly 

[rbellini]

Hi @Jayendran ,

Thanks for pointing out the performance problems related to not using a dedicated capacity. Just one more question: can we expect the performance to be capped to a fixed amount of resources or is there no "lower boundary" of responsiveness, given the capacity is shared and depends on other customer's usage of Power BI?

Thank you very much for your explanations and your time!

[Jayendran]

Hi @rbellini ,

Sorry I couldn't able to comment on that, as MS didn't provide the exact about the performance metrics/impact. I'd suggest you to create a MS support ticket, they can able to provide it more exactly.

[rbellini]

Hi @Jayendran ,

Many thanks, we'll reach out to MS support in case we need an accurate information about limitations on shared capacity.

Regards