Pros and Cons of using SSRS for Dynamics AX 2009 Reporting
I wrote the following blog entry, in order to attempt to give an idea of what all reporting possibilities exist for getting at a company's data, inside Dyanamics AX 2009.
Dynamics AX 2009 - Reporting Possibilites
Since then I have also wrote the following, detailed technical how to blog entries about calling a custom SSRS report from X++ code, and passing in parameters, and also for getting at X++ source code, from within a SSRS report.
- Calling a Custom Dynamics AX 2009 SSRS report and passing parameters - From X++
- Dynamics AX 2009 - Calling X++ logic from SSRS and C#
Reporting in Dynamics AX 2009 is a heavy focus, as more and more companies are wanting to understand how to get the right data to the right people. That was the whole thinking behind creating role centers in Dynamics AX 2009. To target specific information worker profiles, and to give the ability for companies to target specific information workers in custom ways that fit to the company needs.
Since writing the above entries, I have had a full request now, to talk about the pro's and con's of using SSRS reports for getting at data that lives inside a Dynamics AX 2009 instance.
So looking at this, the pro's are quickly seen. The report can be delivered via a Role Center, inside Dynamics AX, and over the web. The processing of these reports can be scaled out to other servers, for performance needs. SSRS offers the ability to work quickly with SSAS / OLAP data, KPI's, etc. and add this to the report design. The creation of these reports happens in Visual Studio 2008, and therefore VS benefits exists. There exist an ad-hoc tool, that gives users a good reach into the data, though not all parts can be done via the Ad-Hoc right now.
There are more, but the above is the highlighted. And the final pro, I would add to this would be the fact that Microsoft is moving it's Dynamics product line to make use of SSRS as the reporting tool. So moving there now, prepares for the future road map of tomorrow.
Now, with all the great things about SSRS and Dynamics AX 2009, there are of course limits or con's.
One of the first things is, it's not the native report engine and designer inside Dynamics AX. Morphx reports are. So all the standard reports and reporting are done and have been done in X++ reports.
This is I would say, the biggest con about SSRS and Dynamics AX 2009. And because of this fact, and handful of other cons come with this fact.
Like for example, since this is the case, then you have to go through the .Net BC to get at X++ business logic / code from an SSRS report. Everyone would much prefer to have more native access to this.
The interaction with with reports from X++ code is different than standard reports, and requires more attention. There is lack of information about limits, issues, etc. because SSRS is not native.
The Query window that comes with most reports, which allows quick adding of filtering fields, etc. does not exists with SSRS reports. The developer of the report can add parameters to the report, still it's not as flexible as the Query Window that exists for X++ reports.
Now with that said, you can develop a class that makes use of a Query dialog, that captures filtering information, and if your good enough in X++ and think far enough in your SSRS report design, you can offer this ability. (if your interested in that, feel free to contact me for a quote.)
I think that is good enough for now. I will leave on this, SSRS should be a major focus to anyone wanting to do reporting in DAX 2009 and beyond. The limits / cons will continue to move away, as SSRS becomes more and more native to Dynamics AX.
Also, on PartnerSource, the Reporting & BI Courseware was just released eariler this month. So if you have access to PartnerSource I suggest you check this out.
Check back soon, and see you next time!
"Visit the Dynamics AX Community Page today!"
Since then I have also wrote the following, detailed technical how to blog entries about calling a custom SSRS report from X++ code, and passing in parameters, and also for getting at X++ source code, from within a SSRS report.
- Calling a Custom Dynamics AX 2009 SSRS report and passing parameters - From X++
- Dynamics AX 2009 - Calling X++ logic from SSRS and C#
Reporting in Dynamics AX 2009 is a heavy focus, as more and more companies are wanting to understand how to get the right data to the right people. That was the whole thinking behind creating role centers in Dynamics AX 2009. To target specific information worker profiles, and to give the ability for companies to target specific information workers in custom ways that fit to the company needs.
Since writing the above entries, I have had a full request now, to talk about the pro's and con's of using SSRS reports for getting at data that lives inside a Dynamics AX 2009 instance.
So looking at this, the pro's are quickly seen. The report can be delivered via a Role Center, inside Dynamics AX, and over the web. The processing of these reports can be scaled out to other servers, for performance needs. SSRS offers the ability to work quickly with SSAS / OLAP data, KPI's, etc. and add this to the report design. The creation of these reports happens in Visual Studio 2008, and therefore VS benefits exists. There exist an ad-hoc tool, that gives users a good reach into the data, though not all parts can be done via the Ad-Hoc right now.
There are more, but the above is the highlighted. And the final pro, I would add to this would be the fact that Microsoft is moving it's Dynamics product line to make use of SSRS as the reporting tool. So moving there now, prepares for the future road map of tomorrow.
Now, with all the great things about SSRS and Dynamics AX 2009, there are of course limits or con's.
One of the first things is, it's not the native report engine and designer inside Dynamics AX. Morphx reports are. So all the standard reports and reporting are done and have been done in X++ reports.
This is I would say, the biggest con about SSRS and Dynamics AX 2009. And because of this fact, and handful of other cons come with this fact.
Like for example, since this is the case, then you have to go through the .Net BC to get at X++ business logic / code from an SSRS report. Everyone would much prefer to have more native access to this.
The interaction with with reports from X++ code is different than standard reports, and requires more attention. There is lack of information about limits, issues, etc. because SSRS is not native.
The Query window that comes with most reports, which allows quick adding of filtering fields, etc. does not exists with SSRS reports. The developer of the report can add parameters to the report, still it's not as flexible as the Query Window that exists for X++ reports.
Now with that said, you can develop a class that makes use of a Query dialog, that captures filtering information, and if your good enough in X++ and think far enough in your SSRS report design, you can offer this ability. (if your interested in that, feel free to contact me for a quote.)
I think that is good enough for now. I will leave on this, SSRS should be a major focus to anyone wanting to do reporting in DAX 2009 and beyond. The limits / cons will continue to move away, as SSRS becomes more and more native to Dynamics AX.
Also, on PartnerSource, the Reporting & BI Courseware was just released eariler this month. So if you have access to PartnerSource I suggest you check this out.
Check back soon, and see you next time!
"Visit the Dynamics AX Community Page today!"
Labels: Default OLAP Cubes, Dynamcis AX, Dynamics AX 2009, Future, Query, Reporting, Reporting Options, SSRS, X++
1 Comments:
Hi Brandon! First of all, thank you for your blog.
If I may, what you based on having said about MS road map for SSRS as a 'standard' reporting tool for Dynamics family?
Could you give me any links or some comments on this, please?
Post a Comment
<< Home