Now that SSRS authoring tools have finally been updated (and there is a great article Nick Doelman published the other day on this topic), it might be the right time to ponder on which technology we should be using moving forward since there are two now:
- Power BI Paginated Reports
So, how do Paginated Reports fair against SSRS?
To start with, both are somewhat the same. They are both meant to deliver pixel-perfect reports, and, actually, Power BI Paginated Reports are using the same “rdl” format as SSRS.
Unlike SSRS, Power BI Paginated Reports are supposed to be designed using a tool called Power BI Report Builder. Although, it will probably look surprisingly familiar to anyone who had some experience with SSRS:
SSRS will run on the reporting server, and, as far as model-driven applications go, it’s always been the case that reporting server would have been hidden from us, developers.
However, we can go to the model-driven app and run reports from there. That said, we have to use FetchXML to build those SSRS reports, and that kind of limits us in terms of the capabilities, since FetchXML, even though quite powerful, does not offer the same capabilities as SQL.
And SSRS is “free”. Meaning that it comes with model-driven apps.
That last one can be a big deal if you are thinking of switching to Power BI Paginated Reports, since the first thing you’ll probably realize is that you need a Premium Power BI workspace.
A Premium Workspace will cost you, quite a bit. This is not to say that Power Apps licensing in general is cheap these days, and this is not to say that everybody can develop SSRS reports. Most likely, if you are thinking of getting SSRS reports developed, you’ll need to start paying the developer, and this is not cheap either, so, in the end, if you tried comparing licensing fees only, it might not give you an accurate picture.
So, assuming SSRS has been covered so many times and you probably know what’s doable with SSRS, let me cover some of the Power BI Paginated Reports features.
There is a direct SQL connection (to the TDS endpoint)
This may give numerous advantages – using SQL instead of Fetch is, well, a dream came true. But, since Power BI Paginated Reports are not solution aware, this may mean deployment is not going to be as easy.
Also, so far TDS endpoint is still in preview, so, as much as I’d like to be able to say we can rely on this kind of reporting moving forward, I think we’ll need to wait and see if/when TDS endpoint goes to the GA. Still, if and when it does go to the GA, this comparison will make even more sense.
I mean, it seems to be a no-brainer that writing a SQL query is much easier than creating FetchXML:
That easily leads to the following report:
And we can run it in the Report Builder right away to see the output:
This report can be stored in the Premium Power BI Workspace
And, once it’s saved, we can go to the Power BI web site in the browser and see the report there:
Once there, there is no need for the report builder anymore – report users can run this report directly from the Power BI website:
And there is that “Export” option, btw…
What about the security?
This one I’m not sure about right now. There are two sides there:
- Datasource credentials
- Access to the report
Access to the report is controlled through report sharing:
I have to admit I was not able to share my report yet, since there is always an error. Could it be because of the TDS datasource? Possibly, have to track it down yet.
Once I’ve managed to share this, I’ll probably be able to see how it works with the datasource access, too. This may have to wait, though
Update (Jan 26): there is a follow up on the security topic in the next post
And I think here is the kicker, really… Power Automate Integration
It’s more than Power Automate – it’s just that there is Rest API we can use with Power BI. And, of course, where there is Rest API, there can be a Power Automate Connector:
On the list of features which are missing from SSRS (in Model Driven Apps, at least), I’d rate this #1.
Here is that report in my mailbox:
So, there is definitely something to think about here. Will Microsoft keep supporting both technologies? Will they merge somehow? Will SSRS be migrated to Power BI at some point? Will TDS endpoint become GA soon? Will SSRS (for Model-Driven Apps) get a Power Automate connector?
At the moment, I have no definitive answers, but, hopefully, there is some food for thought in this post. So… choose wisely
Power BI paginated reports definitely seems to the future….but not for Dynamics 365 projects IMHO because of (in terms of customer priority):
1. Additional licensing! – As you mentioned, PBI Premium license required. Not PBI Pro, PBI premium!
2. User experience – SSRS / FetchXML reports can be run from a record, view/grid and throughout the application, while PBI paginated reports do not provide the same seamless experience.
3. ALM – In these times where D365 implementations are adopting a DevOps mind-set. bringing Power BI reports is a stumbling block, as they follow a different life-cycle management.
It is hard to argue with those points, but I think where there are licensing fees, there will be improvements. And, with the free ssrs reports… it is almost like you get more than you paid for… unfortunately. So, with Power BI reports available, I wonder if there will ever be a connector developed for ssrs in Dynamics? Or if direct sql access will ever be supported. Those are things which, once we are past the licensing fee, are making me wonder what to choose.