after a hard and pain fully way implementing and using SSRS Reports in AX 2012, we actually think about to go back to the old AX report technologie. Mainly think about the external reports invoice, packing slip and so on, because these are the mostly used and customized reports.
In our experience customization and deployment times are exploded comparing the old technologie to SSRS Reports. Actually we do not see realy advantages in the field (except EP but do not use external reports in EP).
Mainly points for disappointment are..
- slow development with many waiting and thus unproductive times
- complicated and slow deployment
- loose of AX integration (cross references, comparing layers)
- overhead of configuration ending in error prone environments
- strang differents between preview and real printing
- slow first time call performance
- high resource consumption: development capacities, hardware, cost, time, nerves
I do a test implementation of an old AX 2009 packing slip in AX 2012, need one our to make them run and I am happy with it. I think using the old fashioned way as long as it exits is an option and hopping for better days.
Please share your experiences.
I share your concerns about SSRS as currently integrated with AX 2012 and AX 2012 R2.
I had started another thread at community.dynamics.com/.../108197.aspx but you raise many additional issues that I have not yet voiced.
Looking forward to continuing this discussion.
External documents reports can also be viewed from EP ,Except proforma journal prints remaining are possible.
I started working in ax in this feature. Ax 6.0 pre release development in migration of x++ reports to Ax ssrs.
I feel more comfortable in ax ssrs than plain morphx report.
I do feel its just a matter of time for the guys who used Ax 2009 or earlier versions .
I think some of your concerns will ease with time when you get more familiar with how it works.
Personally, I feel at ease with this change after getting used to it. In fact, I do like some of the capabilities this new model provided over the traditional reporting engine.
On the flip side, I also agree on some of the points you raised and hope to see improvements in the coming hotfix/releases. (I want to add one point that having no tools to lookup labels in Visual Studio is something they need to fix asap.)
My blog | PBC
This forum post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.
I don't really see where many of his core concerns are a matter of unfamiliarity. They seem inherent in the integration between products.
For example, "slow development with many waiting and thus unproductive times"
SSRS frequently makes unresponsive for long periods of time. Even just recycling the service takes an amount of time that nobody can justify. I can reboot a whole cluster of servers in the time it often takes SSRS to cold start. Deploying a new assembly sometimes causes SSRS to inventory all of the assemblies already deployed (this can only be observed with ProcMon as it loads every assembly one at a time).
Then "loose of AX integration (cross references, comparing layers)"
These are definitely missing, and no amount of experience is going to replace sorely missing tools and integration, especially if you come from a version of AX where you had them previously.
And "strang differents between preview and real printing"
Finding that your preview to screen and what appears on paper are different is not unique to SSRS, but it was hardly even a problem with the AX reporting engine, and when it was it was far easier to solve than getting SSRS to match an exacting format.
"slow first time call performance"
This is often due to a cold start, but even first hit on reports on a warm SSRS instance leave you staring at a spinning circle for quite a long time.
Finally "high resource consumption: development capacities, hardware, cost, time, nerves"
For whatever reason, SSRS fails to scale on massive hardware beyond a single processor thread and we frequently find multiple developers hung up waiting for the reporting services executable to finish whatever it's doing, while pegging 16 logical process machine at 6% for minutes at a time.
These are the things that developers struggle with today on AX 2012 and SSRS that are not being addressed. They translate directly into lost time and frustration. For those new to AX, perhaps they do not know any better, but for those of us coming from previous versions, it feels very much like a step backwards and that something was taken away that we enjoyed and depended upon.
Hmm, maybe I shouldn't have used the term "familiar".
What I wanted to say is by investing more time things could improve. I experienced issues and was slow when I started report development in AX2012. But eventually my productivity is more or less the same on both ssrs and morphX reporting engine. (Ofcourse it could be just me being slow when using MorphX heh.)
On "strange difference between previews and real print outs", when I have this it's usually related to margins or clearing out white space at the bottom of the report design. Once I pay attention to those I haven't had many problems.
The only other time I had this is when I use a certain work around to show running totals, it worked on preview but once print to PDF/html the numbers messed up. I saw that as a limitation of SSRS and moved on.
On the other hand, I fully agree that:
"loose of AX integration (cross references, comparing layers)"
"high resource consumption: development capacities, hardware, cost, time, nerves"
are problems that MS really need to look at.
In our first ax 2012 GoLive for a smaller company we are facing 600 hours for reporting customizations (configuration, develoment, deployment). This was 45 % of total customizations. In my experience over the last years, it is a very very high share. I agree with Dolee that things getting improve with practical knowledge. But the whole compiling, waiting, processing, deploying times are definitely not acceptable.
Customers know customization times from earlier AX Version. So we are looking hard for an excuse and bear the cost. By the way the customer is not satisfied with the execution time of the SSRS reports.
Thank you for your contributions
I have a related query
Our implementation partner is using SSRS reports (external, SQL based) and then calls them in the AX 2012. They are not using AX 2012 SSRS Reports. Please tell me what is the best practice and a few pros and cons.
One important gain of using AX integrated reports is the security integration that comes with it. Using SSRS reports would require a separate set of security setup.
Also, AX integrated reports allow developer to massage data into a temporary table using X++ code, then send to SSRS as data source. Standard classes and methods can be take advantaged of when generating the data. Using SSRS reports would mean developing stored procedures for similar tasks, and cannot reuse logic/code available in AX X++.
More over, when using AX integrated reports all the report objects and visual studio project files are stored in AOT. It reduces the time and effort on administrative tasks. (e.g. backup)
On the other hand, I don't have first hand experience implementing AX reporting using SSRS (external) report. However, I'd imagine SSRS reports will run faster due to less complexity involved in the architecture.