The value of a BI Product outside of Microsoft Dynamics AX 2012

With the a lot of focus this week around Business Intelligence, including being my entire session load, I keep getting asked the same question.: "Why are there so many BI products in the expo hall?" Another flavor of this is "Which BI Products are good candidates to look deeper into."



Before I give my public answer to this, let me first start with this. When you purchase and invest into Microsoft Dynamics AX 2012 you are also getting a BI Solution. It true then, when I state that BI is no longer a separate product or project. With the focus around the BI Semantic model, you can achieve Personal, Team & Organisational BI artifact creation without having any other tool.



You can create compelling executive dashboards, as well as other role tailored user experiences, enabled via SharePoint, Office & SQL Server technologies. This can be viewed without having to access the Rich Client of AX 2012 as well. So having a statement that a "CEO never uses AX" is not valid. Just because they don't make use of the rich client, to enter transactions, does not mean they do not use AX. In fact Role Centers should be front and center for the User Experience modeling for you AX investment.

With that said, there still is a valid reason for adding another BI enabling product to your total solution. First thing we have to focus on is the value such a product brings. If it brings relevant, pre-built, focused artifacts that fit into your business model and needs - then that is functional value. Further, just as important as the functional value, is the fact that whatever product this may be - it should never compete with the Microsoft Dynamics AX BI solution.

This means it should compliment the stack of SQL Server+SharePoint+Office. The artifacts it generates should be easily adding as web parts, so that the targeted Role Tailored user experiences are enabled - not replaced.

Microsoft is committed to the continued development and improvement of having this focus, Role Tailored User Experiences - as part of the out-of-the-box offering. So to answer in short: If the product compliments the stack that represent Dynamics AX, and add value for your company, then it's a possible good candidate for adding to your overall BI story your creating for your company.

That's all for this post. Make sure to join me at 4:00 PM Today, in room 604 for the round table discussion on "Understanding What is Available in Standard AX to Meet your BI and Reporting Needs." This will be an open discussion format, meant to engage the audience and have the audience guide and create the conversation.

Make sure to check back soon and often! Till Next Time!
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!"