Good Practice: Always Display the Reporting Environment

Good Practice: Always Display the Reporting Environment

When you work on real-world projects in power BI, you would probably have different environments Like DEV, UAT, Pre-Prod and Prod. It is important for you and your audience to know what the data is coming from. Am I looking at Dev or UAT data or I am actually looking at real data in Production environment. You may have asked or been asked with a question like “Where the data is coming from?”. It is important to know how trustworthy the data you’re analysing is. In this post I show you an easy way to show the environment your Power BI report is connected to.

How It Works

To display the environment name you use query parameters, then you reference that parameter, turn it to a table and add columns to show the environments accordingly. Easy right?

Read more about query parameters from a list output here.

Depending on your scenario the implementation might be slightly different, but the principals are the same. In this post I use a SQL server database. Therefore I need to Parameterise server name. in real world you may also need to parameterise the database name. Again, if your case is quite different, like if you get data from Excel, then the Excel path can be different for different environments. Let’s dig-in.

  • Open Query Editor
  • Click “Manage Parameters”
  • Click “New”
    • Enter “Name” and “description”
    • Tick “Required”
    • Select “Text” in “Type”
    • Select “List of values” in “Suggested Values” and type in server names for different environments
    • pick a “Default Value” and “Current Value”
    • Click OK
Creating new parameter in Power BI Query Editor

So far you created a new parameter that can be used to get data from a SQL Server data source.The next steps show you how to use that parameter to show the environments in your reports.

Continue reading “Good Practice: Always Display the Reporting Environment”

Power BI Ecosystem Report Authoring Tools Demystified

Power BI Reporting Tools Confusion

There are a lot of discussions these days around Power BI tools to create reports and for sure many of you may have already downloaded and worked with some of them if not all of them. You may also already thought that some of the tools’ names are confusingly similar. I recently had an interesting conversation with fellow who has a lot of SSRS report writing background. I was talking about Paginated reports and said, I downloaded the latest version of Power BI Report Builder… that he immidiately said, wait a second…

  • John: Power BI Report Builder? Oh I see, that’s the one that you can create paginated reports with then you can deploy those reports into an SSRS instance.
  • me: NOPE! That’s not the case I’m afraid.
  • John: Oh I know, I meant Power BI Report Server, you can deploy the reports to an instance of Power BI Report Server. I knew it!
  • me: NO! That’s not what I’m talking about…
  • John: What the…?

I bet some of you had similar conversation with a friend or a customer. OK, in this post I explain a little bit about report authoring tools available to you and your organisation to get the most out of your Power BI ecosystem.

Here is a list of all reporting tools currently available to you:

  • Power BI Service: It is a SaaS (Software as a Service) offering from Microsoft in the cloud. The users in an organisation, based on their access rights, may be able to create and publish data, reports, dashboards in Power BI Service. The users can also schedule data refreshes on the published data as well as securely sharing and distributing the contents. While creating or editing reports is possible in Power BI Service, it is strongly recommended to avoid this method for several reasons. The most obvious one is that the changes you make in a report may be soon get overwritten by someone else that republishes the same report from Power BI Desktop. Check this blog post from SQLChick to see why you should avoid creating or editing reports directly from Power BI Service. The reports are downloadable in PBIX format. Use Power BI Service here.
  • Power BI Desktop: It is a desktop report authoring tool that can be used to connect to, or loading data from, varies types of data sources, preparing, transforming and cleansing that data and at last visualising the data. Power BI Desktop is the predominant report authoring tool with a lot more functionalities and flexibility than Power BI Service. For instance, setting up Role Level Security (RLS) is NOT available in Power BI Service. The format of the report file is PBIX. Download Power BI Desktop from here.
  • Power BI Report Builder (Paginated): Paginated reports aka “pixel perfect reports”, as the name resembles, are formatted in a way to fit perfectly on a page. That report page might later be printed. You have exact control over the page formatting to display your data in tables or charts. The reports are not as interactive as Power BI Desktop reports are. Paginated reports are based on RDL technology which is standard report format in SQL Server Reporting Services. The tool for developing paginated report in Power BI ecosystem is Power BI Report Builder. The reports file type is RDL. You can currently publish Paginated reports only to a Workspace that is backed with a premium capacity. Download Power BI Report Builder from here.
Continue reading “Power BI Ecosystem Report Authoring Tools Demystified”

What Does XMLA Endpoints Mean for Power BI and How to Test it for Free?

Test Environment from Power BI XMLA Endpoint

XMLA endpoint connectivity for public preview has been announced late March 2019. As at today, it is only available for Power BI Premium capacity users. This sounds like a massive restriction to a lot of people who don’t have a Premium capacity, but they’d love to see how it works. In this article I show you an easy way to get your hands to Power BI XMLA endpoint as quick as possible. Before I start, I’d like to simply explain what XMLA endpoint is and what it really means for Power BI users.

Power BI is Like Onion! It has layers!

Generally speaking, Power BI has two different layers, presentation layer and data model layer. Presentation layer is the visual layer, the one you make all those compelling reports and visualisations. The data model as the name resembles, is the layer that you make your data model in. This layer is the one you can access it via XMLA connectivity.

In a Power BI Desktop file, you can see both layers:

Different layers of Power BI

How XMLA Relates to Different Layers in Power BI?

As you may have already guessed, XMLA is only related to the data model layer and it has nothing to do with the presentation layer. So you may connect to a data model, browse the data model, import data from the model to other platforms like Excel and so forth.

XMLA Is Not New!

Seriously? Yes, seriously. It is not new. It’s been around for many years and perhaps you’ve already used it zillions of times. Whenever you’re connecting to an instance of SQL Server Analysis Services, either Multidimensional or Tabular from any tools like SQL Server Management Studio (SSMS), Power BI Report Builder, Excel, Tableau, etc…, you’re using XMLA connectivity indeed.

Power BI is an Instance of SSAS Tabular

It is true. Power BI runs a local instance of SSAS Tabular model. So, whenever you open a Power BI Desktop file (PBIX), Power BI creates a local instance of SSAS Tabular model with a random local port number that can be accessed on your local machine only. When you close the file, the local instance of SSAS Tabular is shut down and its port number is released.

I first revealed the fact that you can connect to the underlying data model in Power BI Desktop from whole different range of tools like SSMS, SQL Server Profiler, Excel, etc… on Jun 2016. So, we indeed were using XMLA to connect to Power BI data models for a long time. We can even take a step further to import our Power BI data models into an instance of SSAS Tabular. In that sense, we are literally generating XMLA scripts from Power BI to create the same data model in SSAS Tabular. How cool is that?

Sooo… What is new then?

Continue reading “What Does XMLA Endpoints Mean for Power BI and How to Test it for Free?”

Quick Tips: Boolean Conditions when Querying SSAS DMVs

Boolean Comparison in SSAS DMVs, Error: A Boolean expression is not allowed in the context

If you are querying SSAS DMVs you may want to add some conditions in the query.

Something like getting all active relationships, perhaps like below:

select * from $SYSTEM.TMSCHEMA_RELATIONSHIPS where IsActive = 'true'

Running the above query on an instance of SSAS Tabular gives you the following error message:

Error: A Boolean expression is not allowed in the context …

Fixing this is quite easy, run the below query to get active relationships:

select * from $SYSTEM.TMSCHEMA_RELATIONSHIPS where IsActive

Boolean Comparison in SSAS DMVs

And to get inactive relationships run this one:

select * from $SYSTEM.TMSCHEMA_RELATIONSHIPS where not IsActive

Boolean Comparison in SSAS DMVs

Using Unicode Characters in Power BI

Unicode Characters in Power BI

There are several scenarios to use Unicode characters in Power BI including but not limited to:

  • Creating simple KPI columns in Table or Matrix visuals
  • To show the status of a measure more visually like using starts
  • Using Unicode characters as icons in your reports representing the subject

Chris Webb explained some of the above scenarios here.

In this post I explain how you can use Power BI as a tool to generate almost all valid Unicode characters in Power BI. You can download the PBIT at the bottom of this post. Then you can copy the Unicode characters from Power BI and use them in all textual parts of your report like visual titles, text boxes and so on.

The Unicode planes start from 0 to 1,114,111 which is decimal equivalent of 0 to 10FFFF in hexadecimal numeral system. For more information on Unicode planes check this out.

So, a simple way to generate all possible Unicode characters is to generate a list of decimal numbers starting from 0 ending at 1,114,111. This way we generate a series of decimal numbers regardless of the gaps between starting and ending Unicode blocks. Then using UNICHAR() function in DAX to generate corresponding Unicode characters. With the following DAX expression you can easily generate a list and the corresponding Unicode characters: Continue reading “Using Unicode Characters in Power BI”

Quick Tips: Keyboard Shortcuts/Hotkeys When Writing DAX in Power BI Desktop

DAX Keyboard Shortcuts in Power BI Desktop

Keyboard shortcuts is an interesting topic for developes that can really improve your report development in Power BI Desktop. In this post I show you some keyboard shortcuts/hotkeys when writing DAX in Power BI Desktop.

 

  • Indend right: Ctrl + ]
  • Indent left: Ctrl + [

Mini-tip: You can also indent your code to ther right by pressing TAB or indent left by pressing Shift + TAB. But, the difference is that if your cursor is in the middle of a line, when you press TAB it divides your code to two pieces and indends the characters to the right from the position that cursor is in.

  • New line keep indent: Shift + Enter
  • New line starting from first of line: Alt + Enter
  • Activate Intellicence: Ctrl + Space
  • Comment multiple lines: Ctrl + KC or Ctrl + /
  • Uncomment multiple lines: Ctrl + KU or Ctrl + /
  • Move the current line up/down: Alt + Up/Down Arrow Key
  • Enter multiple lines of code at once: Ctrl + Alt + Up/Down Arrow Key
  • Find and replace a word: Ctrl + D to highlight the current word, Ctrl + D again to find/highligh the same next word. Continue pressing Ctrl + D to find/highlight all same words, then start typing to replace all words at once
  • Find and replace all of a kind at once: Ctrl + Shift + L to highlight a part of your DAX expression then start typing to replace the highlighted words at once

Continue reading “Quick Tips: Keyboard Shortcuts/Hotkeys When Writing DAX in Power BI Desktop”