When Microsoft Dynamics AX 2012 was released, we had to change, or at least rethink, the way we created reports. The biggest change is that you now need to get the data in some manner, and then have the report render things out. When we had X++ reporting, we could do this simultaneously by modifying the fetch() method of the report. But when you step back a bit and look at this, is this process really a bad thing? Think about it, you can use either a query or a Report Data Provider class, and build out a temporary table that contains your data.
Why is this nice? You can actually test out your logic for retrieving the data BEFORE you do any type of report layout or design (OK, you have to have an idea of what your report is going to look like, but I hope you see where I am going with this). If you are using a query, you can create a simple job, process the query, and retrieve the information. You could create something like the following:
qr = new QueryRun(querystr(myQuery));
ct = qr.get(tableNum(CustTable));
At this point, you add in your parameters for the query and see what results you get. I know the above is a very simple example, so for more information please see the following:
Report Data Provider (RDP) classes and data contracts can also be tested using jobs. You can pass parameters into the data contract, and then have the RDP class do its processing.
static void TestDP(Args _args)
MSUserMenuItemAccessRDP dataProvider = new MSUserMenuItemAccessRDP();
MSUserTableAccessContract contract = new MSUserTableAccessContract();
tmpTable = dataProvider.getTmpMenuItemAccess();
while select tmpTable
info(tmpTable.UserId + “: ” + tmpTable.MenuItemType + ‘-‘ + tmpTable.MenuItemName + ” -> ” + tmpTable.GrantedAccess);
If you want more to see, you can make sure the temporary table used by the RDP class is NOT set to be a temp table, but is a normal table (for testing purposes). That way you can run the job, and then examine the contents stored in the table to see if you are getting the expected data. This also makes it quite easy to debug, as you simply set your breakpoints in the code, and the debugger will start when the breakpoint is hit.
So, using the above techniques, you more often than not will have your data retrieval debugged and ready to go even before you start designing a report.