Tips for Report Development in AX BEFORE You Create the Report
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:
QueryRun qr;
Query q;
CustTable ct;
;
qr = new QueryRun(querystr(myQuery));
if (qr.prompt())
{
while (qr.next())
{
ct = qr.get(tableNum(CustTable));
print ct.AccountNum;
}
}
else
{
}
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:
http://msdn.microsoft.com/en-us/library/aa625948.aspx
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)
{
tmpMenuItemAccess tmpTable;
MSUserMenuItemAccessRDP dataProvider = new MSUserMenuItemAccessRDP();
MSUserTableAccessContract contract = new MSUserTableAccessContract();
contract.parmdataArea('ceu');
contract.parmUserId('ddst2');
dataProvider.parmDataContract(contract);
dataProvider.processReport();
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.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.