AX 2012 - Report Layout and Style Templates

In a recent post, I talked about AX 2012 and Diving into BI Analytics as a starting point back into a series of post around The BI Story for AX 2012. The point of this series of post, is to drive understanding of the BI options in Dynamics AX, and therefore driving value around making the most use out of your investment.



To help continue this series, I will start to dive into more and more specifics around AX 2012 & BI, specifically around creating BI artifacts with the out-of-the-box tools.

To that end, recently I was working with a long time client, and one of the things that was brought up was the use of Report Templates, in reference to how these could be used in Microsoft Dynamics AX MorphX reports in the past.



Just to be clear on this point, you have the ability to have Layout Templates as well as Style Templates. As I've done in the past with such articles, I would like to start this deeper dive, with referencing what Microsoft has provided for us on MDSN. As I've also stated in the past, Microsoft has been doing a great job with the release of AX 2012 around documentation and this topic is covered with some nice resources.

The following is that resource list:

• Using Report Layout and Style Templates [AX 2012] - Home on MDSN for this topic
• Predefined Layout and Style Templates [AX 2012] - A very detailed listing of the predefined templates in AX 2012, including the desired report type in which each can be applied.
• How to: Create a Layout or Style Template [AX 2012] - A nice how to article on creating layout & style templates
• How to: Apply a Layout or Style Template [AX 2012] - A final how to on applying layout & style templates in AX 2012

Now with these resources in hand, we have the ability to start making use of layout & style templates, understand the value, and create our very own if so desired.

To a point of use for these, for example, say in an Auto Design scenario you would like to have the Company Name, Page information, etc on the header of your auto design reports. This was very common need with MorphX reports. Well in order to do this, you could follow the how to on applying Layout & Style templates, and use that to apply the ReportLayoutStyleTemplate which has said information as part of the header.

Further, you can create your own custom layout and style templates that might contain specific design elements, or parts of Header information that help create a specific an uniformed rendering of reports that can go very far with the user base.

The point to be taking, is it's still possible to achieve this same need as it was in AX MorphX reports, with the new reporting model of AX SSRS.

With that, I will end this post and thought process for now. I hope that as we continue down this path, you will see more and more the flexibility and depth of Reporting and BI artifact creation that exists out-of-the-box for AX 2012. Till Next Time!

Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

AX 2012 - Install multiple instances of SSRS

One area that might rise up during implementation needs, specifically for small and mid-sized deployments of Microsoft Dynamics AX 2012, is the ability to install multiple instances of SQL Server Reporting Services (SSRS) on a single server role. The goal, with this need, is to enable the two instance of SSRS, to reside on the same server role, yet, point to different instances of AX 2012.



This is critical for enabling multiple instances of AX 2012 to function, while not increasing the need for another actual server role, virtual or not. To enable this, Microsoft has refined the steps in order to achieve this, which I've done now several times actually. The home page on TechNet for achieving this task can be found here.: TechNet: Install multiple instances of Reporting Services on the same computer (for use with Microsoft Dynamics AX) [AX 2012]

The steps for achieving this second instance, after doing the initial SSRS deployment, can be found as follows:

• Install the new Reporting Services instance
• Configure the new Reporting Services instance
• Modify Reporting Services configuration files
• Restart the new Reporting Services instance
• Create a new Microsoft Dynamics AX configuration
• Connect Microsoft Dynamics AX to the new Reporting Services instance
• Deploy reports to the new Reporting Services instance
• Revert to the original Microsoft Dynamics AX configuration

With this in hand, and making sure you pay special attention to the order of these steps, and follow each step correctly, you should, with relative ease, be able to install multiple instances of SSRS on the same server role, pointing to different instances of AX 2012.

I will point out, that there is a chance you could run into a possible deployment security related issues, that I wrote about in the past: AX 2012 - SSRS Security deployment issue.

Hopefully this will help someone out, who is wanting to take advantage of having multiple SSRS instances on the same windows server role, pointing to different instance of Microsoft Dynamics AX 2012.

That's all for now, but check back soon as I continue my dive into Workflows, Performance series post, design patterns, Dynamics Ecosystem coverage, as much, much more!

Till next time!

"Visit the Dynamics AX Community Page today!"

AX 2012 - SSRS Security deployment issue

I wanted to take the time and do a quick post, for reference on a possible security issue you may run into when deploying reports in a new instance of Microsoft Dynamics AX 2012.



In this, lets take and say your part of the Domain Admins group within the Domain for active directory. Your going along, all happy and ready to deploy reports now, and you get the following.:

"The deployment was aborted. You do not have privileges to deploy to server: (servername). For deployment, you must have administrative rights to the SQL Server Reporting Services (SSRS) server. Contact your administrator to deploy."

In running into this, there is actually something a little strange you may have to do, in that if you are in a group within the Local Administration group on the SSRS server, and your getting the above error message. When this is the case then the solution is to take and add your specific active directory user id to the local administrators group on the SSRS server your trying to deploy reports to.

After doing that, then your able to continue on. You can find our more about this from the following link.: Deploy default reports in AX 2012

"If your Windows domain account is assigned to a group that is a member of the Administrators group, it may take some time to validate that you are a member of the Administrators group. Consider adding your Windows domain account directly to the Administrators group if you experience a delay in the report deployment process."

I actually had to perform this action myself, in order to deploy the reports. Hopefully this will help someone out facing the same issue in the future. Make sure to make use of that MSDN article as well.

That's all for now, but check back soon as I have so much more coming! Till Next time!



"Visit the Dynamics AX Community Page today!"

Microsoft Dynamics AX 2012 and the importance of PowerPivot

As my continued series on Microsoft's next release of AX, Microsoft Dynamics AX 2012, I wanted to take and focus around Microsoft Office PowerPivot.



I first wrote about this topic back in May of 2009, which you can find here.: The Future of Microsoft BI: Project 'Gemini'

In that article, I attempted to explain the benefits and purpose of what then project Gemini, and now that we know it as PoverPivot, will have for Dynamics AX.

Today, with Microsoft Dynamics AX 2009 and the Office 2010 system PowerPivot is already being used in some forms or fashion, however as I pointed out in a previous AX 2012 post, through the use of OData feeds, it will have a much bigger role. Microsoft Dynamics AX 2012, OData and EDM

Moving beyond this, lets think about what PowerPivot means for a customer. The point of PowerPivot is to enable true self service BI within a company. To allow IT depts to control, through security, access to certain datasets, published feeds, etc. that can then be handed off to power users, who can consume and work with those feeds, published cubes, etc. to perform self service BI with that given data and it's context.

PowerPivot takes the need of having every little cube type, out of the hands of a OLAP developer, and places its ability to get at the same data within the power users that need to define the model and reporting results desired.

Looking at this from Microsoft Dynamics AX 2012 point of view, we will see PowerPivot users consuming AX data, in really three ways.:

• Through published Data Services from AX Query Objects as OData feeds


• Through consuming developed OLAP cubes, that are built from AX data.


• Finally through consuming SSRS Atom feeds. (Whats new in SQL Server 2008 R2 - Section: Rendering Reports to Data Feeds)

This is very powerful stuff, because all of these ways of exposing datasets that come from Dynamics AX 2012, all interact and get their respective data through the Application layer.

Very important to understand this point, and so it's very powerful indeed. What you will have then is a Developer, or Architect create a Cube from a perspective within AX, also maybe a couple of Query Object based OData feeds, as well as some AX SSRS reports. These can then be consumed by a PowerPivot user, with proper security context and rights to perform self service BI needs.

There is a great article on Microsoft TechNet about consuming SSRS 2008 R2 Atom Data Feeds for PowerPivot.

"With the release of SSRS 2008 R2, we now have a new rendering extension to render Atom data feeds from SSRS reports. You use this extension to generate Atom-compliant data feeds that are readable and exchangeable with applications that can consume data feeds generated from reports. For example, you can use the Atom rendering extension to generate data feeds that you can then use in the SQL Server 2008 R2 PowerPivot client."

Now will these replace the need for dashboards, No! In fact these will help enable more AX mashups, that mix and match technology, that enable secure access to company data, while enabling the users tools they need to get at and work with that data.

That's all for now, but check back soon as more to come!

Till next time!

"Visit the Dynamics AX Community Page today!"

SSRS 2008 Setup Option for Dynamics AX 2009

With deploying Role Centers, and specifically around SQL Server Reporting Services (SSRS) 2008 for Dynamics AX 2009, we have seen all kinds of existing whitepapers, blog entries, etc. That help get Role Centers up and running.

Reporting Services is a part of the underlying technology that enables Role Centers to work.

With Dynamics AX 2009 and SQL Server 2005, as part of SSRS setup we had the IIS Pool Identity that we set to the .Net BC. We also had to setup an execution account that the Reporting Service executed under, and that had correct Kerberos Security SPN's created.

With SQL Server 2008, Reporting Services, we no longer have a SSRS site in IIS, and therefore no longer an AppPool identity to set for the .Net BC. What does you do then?

Well if the .Net BC account is also your execution account for SSRS, what the service 'logon as' is set too, then your fine. However what if you Want a seperate account for your .Net BC, that is different from the account used for esxecution of the Reporting Service?

This is where the execution account, in the Reporting Services comes into play. Wait though!

In the setup, have we not seen where when this is set, we see issues with Role Centers, specifically SSRS based web parts not working? Yes, but with SQL Server 2008 Reporting Services, and this desired setup, then we have to supply the execution account be that of the .Net BC.

Doing so enables us to have a seperate account for the execution of the SSRS service, that is different from the .Net BC account, while still enabling Kerberos security work and Reporting Services Web Parts to be fired correctly that point back into Dynamics AX.

So in short.:

• You can have a seperate account that runs the Reporting Service, that is different from the .Net BC account.


• In SQL Server 2008, no AppPool identity to set.


• Instead of AppPool identity, setup the Execution Account as the .Net BC account.


After having correct Kerberos Security, with SPN's setup, then this will enable the desired mentioned configuration.

One other point with SQL Server 2008 Reporting Services, do everything through the 'Reporting Services Configuration Manager'. This includes restarting the services, and setting accounts and settings. It's not recommended that you restart the Reporting Service, through the Service MMC. Doing so cause order of service startup actually to sometimes mess up.

That's all for now, but check back soon as more to come!

"Visit the Dynamics AX Community Page today!"

Dynamics AX 2009 - SSRS Report Deployment Issue

If you have deployed the SSRS Report Lib.'s from Dynamics AX 2009 before, you might have ran into some timeout issues.

Even with deploying the reports one ReportLib at a time. And if you have not seen this yet, most likely you will.

An error message, sometimes with great detail will show up during the Reports Deployment process, and that will reference something similar to the following.

[ThreadAbortException: Thread was being aborted.]

The ThreadAbortException is the key for this error. Basically the thread trying to do the deploy is timing out writing to the Report Server.

Most likely you cause is related to the amount of langauge files / cultures that are trying to be deployed for the given ReportLib.

A simple change can be done to help fix this issue.



The following is the steps to do, that relate to the above table inside Dynamics AX.:
1) Open the AOT
2) Expand Data Dictionary > Tables > LanguageTable > Fields
3) Right click on the 'LabelFile' field and choose properties
4) Change the Visible property to 'Yes'
5) Save the change
6) Right click on the LanguageTable and choose Open
7) In the table, uncheck the Label file field for any languages that are not needed
8) Deploy the ReportLibs again that were having issues

This may not be the fix all the time, but most likely it will be. Also this can be used to help clean up the Report Manager. The initial deploy can deploy a lot of reports in languages you just don't care about. So you can remove those, or clear the entire Report Manager and then deploy with only the language files / Cultures that matter to you.

Well that's call for now, check back soon, as I have more post coming! See you then!




"Visit the Dynamics AX Community Page today!"