AX 2012 - Fatal AXRDCE Exception Error Addressed

Today, I wanted to spend a little time writing about an error that some people using AX-SSRS reports have started to run into. This is specifically related to an error that might sound something as the following.: "Fatal exception performing AXRDCE transformation step. The report cannot be rendered. Please contact your system administrator."

This error message may appear for out-of-the-box reports as well as custom development report elements. Further, this can occur even after said reports have been executing fine for a little while. There is a number of ways to get past this related to the removal of AUC files from the SSRS server, and refreshing the WCF configuration tied to the AX config file for the SSRS instance. However what I want to talk with you about on this topic today, is the ultimate fix for such issues.

For starters, you will need to launch Dynamics AX 2012, and go to the System Administrators > Setup > Business Intelligence > Reporting Services > Report Deployment Settings. This form is shown, loaded in the below image.



What we see highlighted is a form that contains a report element, one of it's design's and a check mark in a field called static. If you have a report listed in this form, as set as such with static as being applied, then AXRDCE is not used with those targeted report elements. You see the purpose of AXRDCE is to render as run-time, the needed language translations as well as contextual security. So keep these two points in mind, when you make use of the Report Deployment Settings Form.

That stated, if you list a troublesome report element as well as design within this form, having mark static. Then you deploy that specific report element to SSRS, your AXRDCE woes will be gone for good. This will tell Dynamics AX to deploy the report & it's report cultures so that the Dynamic generation of language translation does not take place.

Well that is all for this post, I hope that someone finds this useful in your Dynamics filled projects! Till Next Time!
Follow Me @:
       

"Visit the Dynamics AX Community Page today!"

AX 2012 BI Basics - Dual Datasets for single Report Data Provider

I hope everyone had a wonderful Thanksgiving! I must say for me, it was great being with family and friends, however I was terribly sick and still fighting this cold. With that I'm finally getting back into the swing of things and ready to get some great value added content back on the blog.

With this I wanted to focus back on some BI Basics with Microsoft Dynamics AX 2012. The focus for today's post is around delivering two Datasets via a ReportDataProvider class. The idea, is that we have a need for a header and details section of a report, in which the data will be delivered via a single Report Data Provider.



One of the best examples of this, that really is easy to understand and explain this concept via is the WMSPickingListReportDP class. This class has two methods that have the decoration of SRSReportDataSetAttribute as part of it's make up. One if for the header, as seen in the image above. The next is for it's details, as seen in the image below.



Both are very similar in deed, and both return variables that are declared and filled within the calling of the processReport() method of this Report Data Provider class. This in turn allows the report design, to have a linked set of Temporary tables, one for header data that is returned and used for rendering, and the other is for the details beyond the scope of the given header data that is filled for a specific WMSPicingListReport.

What this shows, is the power and flexibility of the AX-SSRS framework when used and designed correctly. I would, also in this post like to take a step back, and lets review then the following when considering the design of such reporting artifacts for an instance of AX 2012.



Above we see a diagram that shows the concepts of the reporting framework for Microsoft Dynamics AX 2012. The idea, is that you always start with the data, this includes inside or outside of AX 2012. Further moving from there, going to the report design, the report elements, and finally the execution of the report, and security to govern it.

The following is a list of the task needed, in order when you start to design and creating AX-SSRS BI Artifacts.:

• Define Data Source (Query / Code, OLAP, Other DS)
• Define Ranges (Query or Code)
• Create a Reporting Project
• Create a Dataset bound to Data Source
• Create Report design
• Publish report
• Create Menu item for launching
• Define Security Elements

It's important to keep this focus in front of you when designing and working within the AX-SSRS framework. If you do then you can be assured you will get the most out of your reporting investment.

That's all for this post, but check back soon as I will have more to come. Till Next Time!

Update: I wanted to make sure and back reference a post I did, that covers the core concepts of the AX-SSRS reporting process. You can find that post here.: AX 2012 - AX-SSRS Report Design Concepts. As the name suggests, this post covers well the core concepts, and will help refresh anyone that needs it on the process of reporting for AX 2012.
Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

Report Development Basics in AX 2012 - Debug Query & Code based reports

Today, I wanted to take some time and continue this focus we have around Report Development Basics in AX 2012. This is a continued theme really, building block parts of helping understand how to Create a System of Engagement for AX 2012 customers. Today's focus is around one that I think everyone planning to do any report development, the correct way, in AX 2012 should fully understand. That is Debugging Query & Code based report objects.



First I will say that this post assume you have an understanding of the two types of AX-SSRS report development options. This is either via a Modeled Solution, aka Query Based, or Code based solution, aka Report Data Provider based. You can learn more about these concepts in the following post.: AX 2012 - AX-SSRS Report Design Concepts


Model Driven Solution Diagram

First lets start with how to debug a modeled, or query based report. The idea is that you have a query you have created, and now your not getting the data you think you should. The best way I have found, for debugging such a report data source, is via an X++ job.

The following is an example job that can be used, for doing just that.:

static void TestQuery(Args _args)
{

/*
Example job used to test query results with.:
*/

QueryRun queryRun;
Counter totalRecords;

// Table Variables:

VendTable vend;
VendCertification VendCert;

queryRun = new QueryRun(queryStr(queryVendCertInfo));

if (queryRun.prompt())
{
while (queryRun.next())
{
vend = queryRun.get(tableNum(VendTable));
info(Vend.AccountNum);

VendCert = queryRun.get(tableNum(VendCertification));
info(VendCert.CertificationNumber);

totalRecords++;
}
}

info(strFmt("Total Records : %1", totalRecords));

}

Now to break this down a bit. We have a QueryRun object that points to our desired query. In this case, it's one I created called queryVendCertInfo. This query references the VendTable, and further has a relation to the VendCertification table.

I'm able to execute the query, and the prompt call even brings forth the SysQueryForm for Dynamic Filters can be applied. Having this, you can now successfully test in query, as well as any query that is a bound data source for an AX-SSRS report dataset.


Code Driven Solution Diagram

Moving right along, the next area of focus for report debugging is a code driven AX-SSRS element. This is a report object, that as it's bound data source is a Report Data Provider class. There is a nice How to, posted by Microsoft you can find here.: How to: Configure the Debugger to Debug a Report Data Provider Class [AX 2012]

Let me state here that this assumes your working in the development mode, where everything is contained within a single server role. Meaning that for the developer, you have your own AOS, SSRS, SQL Server, as well as Visual Studio 2010, AX client, etc. With that assumption aside, you can then easily debug a report, that is based on a Report Data Provider class.

Since there is a nice how to, I have no need to re-hash those steps. I will say that you need to make sure that the AOS Service account is in the Microsoft Dynamics AX Debugging Users group.



After doing this, and making sure that you have an AOS configuration that enables global break points, the next steps are placing a Breakpoint; keyword in the processReport() method and then having the MorphX IDE Debugger open.



After doing this, you can then debug a code based report, either when executed from within the AX 2012 work space, or from within Visual Studio 2010. One thing that you will notice, when debugging from within VS2010 is after the preview action runs through the debug process once, it stops from running through the debug process again.

There is a process however that you can employ, that will allow you to reload the VS2010 project, and therefore allow multiple debug runs, without having to close out of VS2010 each time.



As the above screen shot suggests you need to unload the VS2010 project. In doing that, the next step would be to reload the VS2010 project that contains the AX-SSRS report elements.



With the above information you should have what you need to help debugging most AX-SSRS reporting development scenarios. That's all for this post, check back soon as more to come, including the continue Freaky Tech Friday series tomorrow! Till Next Time!
Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

Report Development Basics in AX 2012 - Drill Through Options

Today I wanted to take some time and start back focusing on BI & Report Development topics for Microsoft Dynamics AX 2012. This is one area that helps us shape Microsoft Dynamics AX 2012, into a true System of Engagement for customers.

Today I wanted to talk about the ability to perform a drill through action from one report, to another source in AX 2012.



This is a popular possibility, that enables one to create an engaging report experience for launching from a more summarized report data - into the details such summarized reporting represents.

We see this in action with AX 2012, via Web Parts for Enterprise Portal. These are most always hosting AX-SSRS chart based report objects, or other forms of grouped and summarized data. Usually clicking on the details of the value being summarized in the report, will take you to a more detailed transaction view of the data it is meant to represent.

There are two options, when we look at the Drill Through possibilities, either Report Drill Through Action or URL Drill Through Action. As the names imply each will either launch another report, or launch a new browser directed at the specific URL to be viewed, when clicked by the user.



In order to work with a targeted Report for drilling through too, it has to be referenced either within the same model project - of opened within the same solution design space. You can see this with the two report objects I have shown above.



Doing this will enable for you to have a source, or drill from, as well as a target or drill through report objects. We can see in the above image that I have a selection of either Report1 design or Report2 design. Since Report1 is my source object, I will select Report2 Autodesign.



Having done this, as you see above, I now have my Report Drill Through Action along with parameters that I need to set. Usually the auto-generated parameters like company, report culture, etc can be passed through from the source report object. However this is where a target report object, of the drill through action, can have it's report output shaped by context of the data from the source.

Moving right along from here, we have the URL Drill Through Action. As with the report drill through action, the URL is added from the fields on the design of a report. In doing this, we see in the following options for our URL Drill Through Action.



As the above image suggests, we have the ability to pass any number of URL's, along with parameters that can be dynamically driven from the source report object. A good example would be a report that had tracking information, and you wanted to automatically fire into UPS site from the report, and have it show the status of a package.

All-in-all, the drill through actions we have when talking in terms of report development for Microsoft Dynamics AX 2012 help us create more engaging reporting experiences for users. This is the ultimate goal, to engage the user with needed and critical information, for solid execution of their roles responsibilities.

That's all for this post. Check back soon however as a lot more to come! Till Next Time!
Follow Me @:
    

"Visit the Dynamics AX Community Page today!"