Dynamics AX
  RSS Feed  LinkedIn  Twitter
Want to turn you're data into a true asset? Ready to break free from the report factory?
Ready to gain true insights that are action focused for truly data informed decisions?
Want to do all of this across mutliple companies, instances of Dynamics and your other investments?
Hillstar Business Intelligence is the answer then! (www.HillstarBI.com)

Hillstar Business Intelligence for Microsoft Dynamics AX and NAV on Mobile, Desktop, Tablet


Let us prove to you how we can take the complexity out of the schema and truly enable users to answer the needed questions to run your business! Visit Hillstar Business Solutions at: www.HillstarBI.com

Sunday, March 03, 2013

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 @:
   RSS Feed  LinkedIn  Twitter

"Visit the Dynamics AX Community Page today!"

Labels: , , , , , , , ,

Wednesday, January 23, 2013

AX 2012, SQL Server 2012 & NLB Reporting Services





Today I wanted to take the time, and give light to a specific topic, Network Load Balancing Reporting Services with AX 2012 & SQL Server 2012. As I have done in the past, to help shed light on this most important topic, I invited Matt Tortorice AX System Engineer for McWane, Inc. to give us some insights on this topic.



Matt, along with McWane, is currently implementing Microsoft Dynamics AX 2012 for some of their divisions. Recently, I worked with Matt on the topic of clustering for reporting services, and he is here to help give valuable, customer based insight into the process.


Matt Tortorice LinkedIn Profile | @mtortorice


After following the “Configure a Report Server on a Network Load Balancing Cluster” article on TechNet, and generating my machine key from aspnetresources/machineKey I was able to apply the new Machine Key value to both of our load balanced Report Servers web.config file. In doing this, we ended up with a configuration that looks similar to what is pictured below.:



When first launching into the instance of Microsoft Dynamics AX 2012, that had three AOSes, users had no issues executing report. Users, that is, that where connected to the first AOS that has an Reporting Services configuration associated with it that is.

Those Users trying to run an SSRS Report when connected to the any other AOS instances (ax102, ax103) would get the following error message.: “The default Report Server Configuration ID could not be found in the SRSServers table.” This error message was presented in an infolog, similar to the one pictured below.:



To solve this problem, the answer was to create a Reporting Server Configuration for each AOS in the cluster by setting the Application Object Server Name to each AOS instance. In other words, 3 identical Server configurations except for the AOS Server name. Configuration ID 1 points to AX101, ID 2 points to AX102 and ID3 points to AX103 as seen below:



Once there was a Report Configuration for each AOS instance all of the reports SSRS Reports would generate when a client was connected to any AOS. All reports where able to execute, no matter what AOS a user was logged into. Further each of the report server configurations where pointing to the NLB, or Network Load Balancing server name.

Having done this, we where able to take full advantage of SQL Server 2012, with a scaled out, load balanced reporting servers that better meets are reporting needs. This will further enable, as needed, future scale as our users demand more, and more reports from our Microsoft Dynamics AX 2012 instance.


I would like to thank Matt for taking the time to share with us, about this topic. Giving us insight into the trenches of Microsoft Dynamics AX 2012 and how the stack is helping him realize real value for his company needs.

Further, the following is more information about Matt and his blog, where he plans to continue his journey, and helping all of us along the way.:

With a Background in .Net Development, SQL Server Management and Microsoft Server Administration I began my unexpected adventure in Dynamics AX in late 2012 when I was tasked with setting up 3 Dynamics AX 2012 CU3 Single Server Environments using SQL Server 2012, and a 9 Server Production installation of Dynamics AX with 3 AOS Servers, 2 SharePoint EP Servers, 1 SharePoint Search Server, 2 SQL Server 2012 Servers in a High Availability Group and 1 Help/FileServer. I will continue to blog about my experiences and answer any questions I get at http://blog.thedeprecated.com

That's all for this post, check back soon as I will continue the focus of valued added content. We will dive further into the Dynamics based world, with more coverage of BI, Reporting, Services and more! Till Next Time!
Follow Me @:
   RSS Feed  LinkedIn  Twitter

"Visit the Dynamics AX Community Page today!"

Labels: , , , , , , , , , , , ,

Thursday, October 11, 2012

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 @:
RSS Feed  LinkedIn  Twitter

"Visit the Dynamics AX Community Page today!"

Labels: , , , , , , , , , ,

Tuesday, October 09, 2012

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 @:
RSS Feed  LinkedIn  Twitter

"Visit the Dynamics AX Community Page today!"

Labels: , , , , , , , , ,

Wednesday, February 22, 2012

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:

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 @:
RSS Feed  LinkedIn  Twitter

"Visit the Dynamics AX Community Page today!"

Labels: , , , , , , , , , , , ,

Sunday, January 08, 2012

Updated: AX 2012 - Run Reports without hitting the Production DB





I hope everyone is enjoying their weekend. I did want to post that I plated my recent post about how to setup a reporting database, that would enable the execution of AX 2012 reports, without hitting the production database. AX 2012 - Run Reports without hitting the Production DB



To sum up, here is the update:
" a reader of this post pointed out that this would not work for the setup using log shipping. Using log shipping is for HA, and he is 100% correct. The log shipped db will remain in standby mode and therefore the .net bc would fail in connecting to it. So instead of using log shipping replace that concept either with replication, or mirroring. The other points that people have brought up, including the same reader, is the cost for the license for the SQL server as well as the extra AOS needed. This is true, however if the desire is to offload the processing of reporting resources from the production, transactional db, then the cost of the extra license would have to be used in order to weight the value in which such a setup could bring. With this, still it is possible to have a reporting database that is different than the production transactional db."

It's still a valid possible solution, but with any such solution, of course there is a cost weight associated with it. Thanks to everyone who shared with me their thoughts on this. The concept was meant to be something that was refined and could give the community a possible solution for enabling such a need.

That's all for now, check back soon as more to come. Till next time!

Follow Me @:
RSS Feed  LinkedIn  Twitter

"Visit the Dynamics AX Community Page today!"

Labels: , , , , , , ,


Copyright 2005-2011, J. Brandon George - All rights Reserved