Here you master the difficult art of replicating classes so that your copied reports will run. We are getting closer and closer to seeing what AX can really do with reports. But hang tight because you must master the duplicate report trick if you want to gain adequate Dynamics AX Framework specific report speed. Once done, however, the rewards will speak for themselves. What is nice about this post is that if you get it, you have mastered all the steps necessary to duplicate a report in Dynamics AX.

This is a continuation from the last post.

http://instructorbrandon.com/how-to-speed-up-report-writing-in-dynamics-ax-ssrs-with-the-duplicate-report-trick-part-2b/

Now, if you read part 1, you will employ a similar method here, expect for with classes. You will do the import/export trick. So, first, let’s identify the classes that we need to replicate.

If you followed Part 2A, you will notice that the process you do here is extremely similar. Therefore, expect more general instructions than before as I assume that you have already Part 2A of this tutorial.

http://instructorbrandon.com/how-to-speed-up-report-writing-in-dynamics-ax-ssrs-with-the-duplicate-report-trick-part-2a/

First, right-click on vendInvoiceController

Second, export the brand new controller class and the old controller class to an XPO file somewhere that you can find

Third, while the copy and paste is nearly the same as what you did on Part 2A of this series, there are a couple of small differences. On the xpo file for the original file, do a replace all, replacing vendinvoice with brandonahmad_vendinvoicece and VendInvoice with brandonahmad_VendInvoice. Important, make sure that match case is checked here as classes often have case differences. Afterwards, make sure that you replace the origin of the VendInvoiceController xpo file with the new Origin. See the screenshots below:

And here is another example

And run a second case sensitive match

Fourth, import the file back into dynamics AX. Like the report import that you did in Part A, you will notice that file name doesn’t mean much. It’s the contents of the file that matter, which you changed.

Fifth, repeat the same process for each of the classes listed in the table above. When you are done, you should have your controller, contract, UI Builder, and Data Provider classes.

Sixth, make sure that you compile all the artifacts and deploy the report.

Congrats. At this point, you would normally be able to open up the controller class and fire up the report, which we will do in Part D. However, there is one small caveat that I wanted to show. Notice how I used the “brandonahmad_(classname)” pattern when naming my classes. Unfortunately, this will cause an error when naming RDP classes. RDP classes have an undocumented name limit of 22 to 23 characters (can remember exact characters). This is because the “classname_dynamicparameter” cannot equal more than 40 characters, and this autogenerated. Normally, in the real world, you wouldn’t have to worry about this because you would use a 3 or 4 letter abbreviation (example: ahma_vendinvoicedp) rather than a big long name. But demo bait is demo bait.

So, though the steps are correct and probably would generate no error in real life provided that you used a smaller appendix for naming your classes than “brandonahmad”, we will spend Part D fixing this error. Again, it is likely that you won’t run into this. After that, we’ll be able to run the report or you could run it now if you used your own appendix. Either way, hold on because once we get a replicated report, the fun begins.