Monday, October 22, 2018

C#: End-to-End PowerBI Embedding - "App Owns Data"

In working with a number of developer-heavy customers, there seems to be a strong demand for taking the reports and dashboard developed in PowerBI and publishing them in either Intranet or Internet web pages.  This concept is currently known as PowerBI Embedded and comes in several different options for developers to implement.

Licensing and Disclaimer

Before we start, I will note that there are definitely licensing concerns and implications to choices made as a part of this tutorial.  While I could likely articulate the current rules surrounding PowerBI licensing, there are a variety of options and I am not truly qualified to explain all of these nuances. . . .so I won't even try.
PLEASE seek assistance from your Microsoft account team if you choose to Embed PowerBI in your applications to determine what licensing model works best for your organization.
Additionally, technologies frequently change.  I will make every attempt to update this tutorial as functionality and technology changes, however for the most current up-to-date information, you should always refer to the Microsoft PowerBI developer documentation, and never any individual tutorial (including this one).

Step 0: Make Some Choices

Before we begin, lets discuss some of the options available to developers who are trying to embed their report.  At it's simplest, developers can place their PowerBI reports in a web page by using an HTML IFRAME on their site and ensuring they have a pointer to the correct PowerBI report.  Here are a simplified list of options:

Option A - Publish to Web

The simplest way to get a PowerBI report into your website is to use the "Publish to Web" option in PowerBI.com.  Just publish your report from the PowerBI client application, and from the File Menu choose "Publish to Web".  This is an entirely public method of publishing though, and there is NO way to lock down ANYTHING.


Option B - User Owns Data

The second option is currently termed "User Owns Data", and in this model, each user who logs into your website with a valid Azure AD account will be allowed to see what they're permitted to in any given PowerBI Report.  Great for Intranet sharing where you know all of your users and trust their Azure AD sources.

Option C - App Owns Data - FOCUS OF THIS TUTORIAL

The third option is currently known as "App Owns Data" and leverages what is essentially a single service account to publish the report as that service account user.  Great for situations where you are publishing a report on a public website where users will not be logging in before they see your PowerBI report. 

Assuming you chose to go with Option C above, the rest of this tutorial will walk through how to implement this.  You can also follow the tutorial linked in the Option C section above, but these steps should simplify the official tutorial some more.

Step 1: Develop a PowerBI Report

While it may seem obvious, this first step is important to leveraging some of the tools to their greatest extent.  You can change your specific report later, however for the purpose of following the PowerBI Embedding wizard, it's easiest to have a .pbix file on hand as you embed your first report.
The easiest way to develop your first report is to download the PowerBI client and create a report to embed.  If you haven't done so already, you may download the PowerBI client from powerbi.com.

Step 2: Obtain a Service Account

This approach assumes that a service account user will be logging into PowerBI on behalf of your application, therefore, you will need to have a fully licensed PowerBI user [with password] created. Speak with your organization's Azure AD administrator and have them authorize the new user for PowerBI in the Office Portal (portal.office.com). 

Step 2a -Test Logging In with Service Account

Just to be sure your user was provisioned correctly (and has access to PowerBI), PLEASE login to Powerbi.com with your new user and ensure they can use or see a report (ideally the one you created above in Step 1).

Step 3: Use the Wizard!

The PowerBI product group recently developed an amazing wizard to walk users through the process of creating and embedding reports in your website.  Navigate to the wizard at https://app.powerbi.com/embedsetup and choose the option labeled "Embed for Customers".  If you are using PowerBI Government, the same wizard is available to you at https://app.powerbigov.us/embedsetup.
The following are some important notes for as you walk through the wizard:
StepNote
Step 1 - Sign InSign in with your new service account. If you do not login with your service account, your "user" will never have the chance to accept terms and conditions (Step 5), and you will get some strange unauthorized error in your code.
Step 2 - Register Your ApplicationThe PowerBI report you are creating needs to be registered in Azure Active Directory so that OAuth can be used to verify your user has rights to the report being published. The official Microsoft tutorial goes into great detail on what this means and why, but for now, just give your application a name so that it gets permission to use the embedded objects.
Step 3 - Create a WorkspaceEven though you probably already have a PowerBI workspace, just let the application create one for you. Your code can be updated later.
Step 4 - Import ContentSame as above. Even though you've probably already created a report, just for now, provide it a .PBIX file so that it creates another one for the sample source code that comes out of the wizard.
Step 5 - Grant PermissionsSince this service account is acting like a user, and every user needs to accept terms and conditions when using Azure AD for Oauth. . . .you'll need to allow your application and user to be related with one another in this step.

Upon completion, you should see an option to download sample code.  Download this .zip file and unzip it somewhere you can open it in Visual Studio 2015 or higher.

Step 4: Modify the Sample Solution Code

Open the .sln file you just downloaded in Visual Studio and navigate to the web.config.

Step 4a - Add Password to Web Config

The solution should have everyhing you need. . . EXCEPT a password.  While we should NOT publish this code (nor check it into source control) with a password in our code, for now we just want to be sure everything is working.  Add your password to the AppSettings section where you see the blank.



Step 4b -  Restore NuGet Packages

From the Tools Menu, navigate to the NuGet Package Manager and choose the option to restore packages not currently in the solution.



Step 4c - Update NuGet Packages (Optional)

If you will be publishing your work to a modern web server, you will likely want to update your packages to ensure any vulnerability and server-side incompatibilities are addressed before being published.  


Step 4d - Build and Run

If it worked, you should see a set of 3 buttons. . . if you pick Embed Report, the following should show without an error:


Step 5: Secure Your Identity

Now that we know it works, you will now want to go through and hide your service account's login in something other than plain text in the web.config file.

In the next article we will go through the options for securing your identity if you are using an Azure Web Service.  Stay tuned!