In this article I would like to show you how parameters/variables can be passed from Power BI Embedded to Tabular Cubes. In this example I would like to show you how users can be passed to the cube that do not exist in Windows. This means that user names are passed to the model, which then filters the data accordingly. For this I use the dynamic RLS you described in the following article:

Dynamic row-based security (RLS)

Because the user does not exist in AD, impersinaton, which was described in the following article, is not possible:

Connect your on-premises AS Cube with Power BI Embedded and re-use your existing security

No users can be passed to the respective cube who are running this session and they can only be Windows users. Thus, this example used users that do not exist in the directory.

I got the idea for this from the following article:

Using CUSTOMDATA and On-Premises SSAS with Power BI Embedded

The programming within the Power BI Embedded application was contributed by my colleague Michael Bujotzek, because he simply developed really cool source code!

The magic lies in the following function: CUSTOMDATA. The nice thing here is that a lot of data can be transferred. In itself you can treat it like a one-dimensional array, i.e. h. If further information is to be passed, all you have to do is agree on a separator. I’ll show you how this works later.

https://learn.microsoft.com/en-us/dax/customdata-function-dax

First it is necessary that a hybrid scenario is set up. This means that a gateway must point to the Tabulat Cube and a report with a semantic model must use it and be integrated into the application. A model with the dynamic RLS must be built inside the cube.

First, we have a simple cube that uses dynamic row-based security here. A role is not included here, it’s just about the structure so that relevant facts about the respective user are provided.

After the cube is deployed to the server, Power BI sets up the gateway to that cube. Here the user is fixed, i.e. h. all connections are established with the configured user.

If you call up the report, which provides a view of the current Windows user name (USERPRINCIPALNAME), you get the cube with all of its data under this user name.

If you configure or program the web application (this is just the example application from Microsoft) so that it receives CUSTOMDATA, data is included in the function. Here the value 123 is passed to the CUSTOMER role.

using (var pbiClient = await GetPowerBiClient())
            {
                // Create a request for getting Embed token 
                // This method works only with new Power BI V2 workspace experience
                var effectiveIdentity = new EffectiveIdentity(
                    username: "123",
                    roles: new List<string> { "Customer" },
                    datasets: datasetIds.Select(datasetId => datasetId.ToString()).ToList() 
                );

The role is absolutely simple, this is where the information that the function returns is used. To check, I transferred the content from the function into a measure.

If further information is provided from the function, it can be extracted accordingly. Here is an example of how the second part is extracted. Of course, this must correspond to the handover.

SecondPart:= 
VAR FullText = CUSTOMDATA()
VAR Parts = SUBSTITUTE(FullText, "-", "|||")
VAR SecondPart = PATHITEM(Parts, 2, TEXT)
RETURN SecondPart

If you now call up the application with the value 123 if the information is filtered according to this user name:

Now you pass on a different user name, which of course has to be maintained in the table if it is filtered by the user.

Personally, I find this function very valuable because it allows parameters/variables to be passed to a dataset within Power BI.