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!"

AX 2012 - AX-SSRS Report Design Concepts

Recently I have been focusing on the BI and reporting aspects that come as part of Microsoft Dynamics AX 2012. There is a lot of great resources for this topic, and it's a topic that drives a lot of value, when speaking about AX 2012.

Since this is the case, I wanted to continue my focus on reporting, with this blog post, focused on the two categories, if you will, of types of AX-SSRS reports. These are Model Driven Solutions and Code Driven Solutions.


Model Driven Solution Diagram

First up, lets talk about the model driven solution, in terms of AX-SSRS reports. When speaking about the model driven approach to AX-SSRS report development, the focus is around the use of Query objects, from the AOT, to model your report with. The idea, with such reports, in that very little X++ code is needed to enable them.

This path, should be favored as much as possible, as it's the least amount of TCO in terms of report development. With this approach, and with report design in general, we have the report itself, and surrounding it is the design, data and control aspects of the report.

When talking in terms of the model driven approach, the design, as you can see from above is created within Visual Studio 2010. Further, the data aspect, is represented via a Query object, and a good example of the control for such a designed report is ranges.

Keep in mind, when thinking about such design patterns, that the Query object is meant to be a re-usable API in AX 2012. The same query object that powers a AX-SSRS report design, could also enable a PowerPivot report, or could be used to help define and deliver Contextual BI elements, say for an InfoPart.

Moveing forward with this thought process, lets look to the next category, for AX-SSRS report design. This is the Code Driven Solution.


Code Driven Solution Diagram

With this concept, we have our basic design elements, or constructs for reference. It's the design, data and control points. Looking at the above diagram and comparing the code driven solution vs. the model driven, we see that at the heart of the design, is still Visual Studio 2010.

Beyond that though, these are much different than the Model driven solution, and the use of queries. The idea for this concept, is when code is needed to create the data behind a report. When this is the case, the data, for the above is represented by RDP, or Report Data Provider. This is a new class type for AX 2012, that enables the ability to design more complex reports, when the need to "mash" data from different sources arises.

Moving along with this concept, we also see that for the control, we have a Data Contract. This too is new to AX 2012, and we have seen some of these, in my coverage of services in AX 2012..

The data contract, when used in a design pattern that is laid out in the above, is meant to act as a simple class, that ties extended data types, that represent the data contract properties, to the report design itself. Enabling, therefore, the correct formatting of data, based on underlying table and data type designs.

With these two concepts in mind, we can start to move forward with report design. A big focus, and understanding point needs to be seen here. That is, you don't see the mention of BIDS, or Business Intelligence Development Studio. That is the standard SSRS design piece. The reason this is the case, is that VS2010 and a special project type are used to enable the creation of AX-SSRS reports. BIDS is actually hosted within VS2010, at least the design space is, so once in the VS2010 project, it's very familiar process for those use to using BIDS. However BIDS, and standard SSRS reports are not meant to be used in delivery data, with AX 2012.

To help you further, with learning these concepts, there are a couple of resources I would like to point you to. First, the Microsoft Dynamics AX BI team blog: Dynamics BI Team Blog. This is a resource I have highlighted before, and one I want to make sure everyone is aware of and makes use of.

Also, the same team, behind that blog, creates YouTube videos, at the following YouTube channel: Dynamics AX BI YouTube Channel. Here again, we have another great resource, in which the main topics of this post are discussed more fully, and taking to a deeper level. Some really great video's out there, so I highly recommend reviewing them, as you can.

Finally, Microsoft recently published the Whats New: Reporting for Developers in AX 2012. This is a really great resource, espically for those that have done AX-SSRS report development in AX 2009. All the concepts contained within that page, need to be fully understood, so that you can take full advantage of all the great improvements Microsoft has given us with this release, around report development.

Well that's all for this post, check back soon though as there is a whole lot more to come.

Till next time!

Follow Me @:
    

"Visit the Dynamics AX Community Page today!"