Error: SSRS/EP error when the return type in display method is incorrect – Dynamics AX 2012

When you work with data sources through a query in EP/SSRS you might land up in this error “Data or calculated fields with type “Record” are not supported”.

How do i resolve ?

One of the tables that is being used in the data source has a display method with a return type as “record”.  Scan through all the display methods and find the one that has the display keyword but still returns a type record in the signature. In our case we had a method similar to this

    Public display inventTable getInventTable()
    {
         return InventTable::find(this.itemid);
    }

Why does this happen ?

It is illegal to use a display keyword for a method that returns any complex object like “Container”, “Record”, “Class”. The reason we don’t find it inside AX is because compiler doesn’t validate it and it can be deducted only at run time. So say you have you a display method as in the example above but you never use it then AX never complains about it.

When these tables are accessed through Query in SSRS, SSRS tries to run through the list of display methods to show up in the field selection. Since SSRS cannot comprehend the return type it throws this error.

For more tips and learning about SSRS – AX 2012 order the book Dynamics AX 2012 Reporting Cookbook authored by me.

Related articles

• SSRS Tip: Speed up RDP based SSRS reports testing in Dynamics Ax 2012 (kamalblogs.wordpress.com)
• SSRS tip: No row message in Dynamics Ax SSRS 2012 (kamalblogs.wordpress.com)
• SSRS Tip: Using invisible parameters in contracts – Dynamics AX 2012 (kamalblogs.wordpress.com)
• SSRS tip: Take care that VS and AX client are in the same layer for SSRS – Dynamics AX 2012 (kamalblogs.wordpress.com)
• Dynamics Ax 2012 reporting cookbook for SSRS – Dynamics Ax 2012 (kamalblogs.wordpress.com)

Towards Dynamics Ax Product Certification – Best Practices (Part III)

Recommended Reading:

Towards Dynamics Ax Product Certification – Best Practices (Part I)

Towards Dynamics Ax Product Certification – Best Practices (Part II)

Part – III

Though certification was our goal, the outcome of the certification exercise interested us in sticking to it more devotedly. In fact we went a step more than what it was demanded by the certification rules.  But to ensure all this we had to make the BP check process something that can be regularly used.

Below are few procedures we created/adopted to make the BP check something that can be regularly used…

> AIF BP Check is quite time consuming. So when every  you modify an table(adding or removing fields) which has corresponding AxBC class ensure that you regenerate all the service class that are used by the AxBC class. To regenerate use the following form

Tools -> Applications Tools -> Development Tools -> Application Integration Framework -> Update document service

This will update all the AIF Dataobjects like Classes, Macros related to the AxBc and prevent resulting BP’ Errors

>During Development don’t use the TODO command to store future requirements/clarifications. Use a separate requirement sheet/Quality backlog to record this. If you are using a Version control it is quiet easy. You can set it up in the “System Settings” form under version control.

>When you run BP for the entire application it results in a huge file(more than 500 MB) so it is better to reduce the log file size. There are two ways through which we can reduce the log files.

1. Enusre that only the checks that you required are verified. Go to the Best Practice form and clear all irrelevant check box. Like “XML Documentation” which are not required for certification. In our case we still got a larger file. So next we went in to the SysBPCheck_*** classes and tried controlling every individual validation. To do this we made a  entire list of BP check’s and decided what we want to follow or not follow. Then what ever we thought we wouldn’t follow we stopped their execution using #if directive macro. This exercise helped us bring down the log file size considerably. [Ref: Excel with all best practice: http://tinyurl.com/3ymz9pk]

2. The next target was the log file that was generated[We didn’t use syscompiler output window since the log was huge]. Looking in to the log file we found that there were lot of unused fields being exported[To identify the unused fields refer to the CSS in \Classes\SysCompilerOutput\xmlExport]. So we decided to export only the  fields that were necessary to view the log. You can do this by overriding the Xml() method of TmpCompilerOutput table.This considerably reduced the size of our log file, I  think it was some were around 4 times less. 🙂

By getting these procedures in place we have built a BP check system that regularly runs with our automated nightly builds. We made quality development a continuous process.

With this I conclude the series on Best Practices. In a next series of article i will explain how we automated form documentation, builds and Release notes for our vertical. Keep reading.

🙂

Towards Dynamics Ax Product Certification – Best Practices (Part II)

Refer Here… for the First Part

Towards Dynamics Ax Product Certification – Best Practices (Part I)

In order to figure out the warnings from our vertical layer we had to make a dataset of the standard warnings without our layer. After fixing the remaining 100 warnings we sent our application for mock certification test to internal test team. They found more than 50  BP errors in individual components.

This came to us as a surprise as our automated build process indicated only zero vertical warnings. After some exploration  in to the compilation process indicated that the Bp count that comes through standard AOT  compile is not actual.

To achieve a complete Best practice check we must use the sys cmed –BP check and not a  compile on the entire AOT.

ax32 -startupCmd=checkbestpractices

This invokes BP check  component by component. This output is what we need to use to ensure that our application is BP error free.

The proper Bp check almost ran for 9 hours and 30 minutes resulting in a total of 1 lakh and 50 thousand Bp errors, warnings. The huge number of error made it difficult to verify the compiler output directly in Ax. The exported log file was more than 400 MB which failed to open in any browser.

Finally we had to use streaming editor like GREP to scan through and find errors. The scan indicated errors in both our vertical and standard ax(believe me it has).

We fixed all this BP Errors to achieve our first complete error free  build that can be sent to certifications.

This is a quite time consuming and tedious if required to be followed in a regular basis. We used our learnings here to improve the Bp system, make it simpler and easy to follow every day.

Let’s see how we made it simpler in the next part…

Towards Dynamics Ax Product Certification – Best Practices (Part I)

At Innovites the last couple of months have been a challenging period. We prepared our product for Dynamic Ax Certification along with two live implementations. In this multi post article, I will try to detail the derailing issues that we tackled to keep us in track. I thought this would be an interesting source of input for people who are planning be certified like us.

In order to get the product certified there are quite some criteria’s but as a product manager my whole responsibility was on ensuring the quality of the application in par with the Ax ceritification requirements.

On a very high level following is what we aimed at.

• Application should have “0” errors and warnings
• Best practice errors should be Zero
• No “To Do” tasks should be in the application
• Well documented help system

We planned to prepare for certification almost one year after commencing our product development. We felt it is a quite a late decision after seeing the number of BP errors, warnings and Todo tasks crossing the 500 mark.

Since our development environment was entirely on TFS it was easy to make the start even with such large number of violations. The options of “reject check in” with Bperror warning and Tasks  in Source controlled helped us implement this. The following article from the X++ team was highly helpful in resolving our warnings.

X++ team link – http://blogs.msdn.com/x/archive/2007/08/21/correction-guide-compiler-warnings.aspx

http://blogs.msdn.com/x/archive/2007/07/11/getting-rid-of-the-loss-of-precision-warning-message.aspx

Once we started this practice we found a steep increase not just in quality but also in terms of reliability in the code.

By the mean time we had slowly built strong Development infrastructure on top of TFS includes an automated build system that publishes Aod, Patches along with their release notes automatically to an PTP ( will details this in a article later). This automated system helped us keeping in track of our development quality every day.

After a month long practice we realized that the total number came down below the 100 mark , we reached “Ground Zero”(a internal project code) in the next couple of days.

The quality improvement in the application through this exercise interested us to get more disciplined. So this time we dived to fix the BP warnings as next step which is not a pre-condition forcertification. There were too many warnings from which it became difficult for us to identify the ones that we wanted to fix.

To our surprise we unraveled so many interesting things when we tried to fix these warnings. It even further delayed our certification process. …

Let’s look at them in my next article….

see you for now…