When (before) starting to develop in AX2012

AX2012 has been around for some time now, but there are still many installations running on previous versions. Switching to AX2012 is not terribly hard, but it has some surprises for you. Therefore, I thought I’d start a collection of things you should be aware of and consider when (before) starting your first AX2012 implementation, that are not mentioned in the whitepapers and training materiel I’ve seen so far.

Maybe this can save you some time.

Common misunderstandings:

  • Wrong: TFS and models work together smoothly.
    • Instead: The parent and all child elements will have to be in the same model, if you use TFS.
    • Example: On ClassA you shouldn’t do the following
      • assign method doSomething() to modelX
      • assign method doSomethingElse() to modelY
    • Why? Because in TFS, your ClassA will still reside in only ONE model repository!
    • AX is not going to warn you if you do it wrong.
  • Wrong: If I test without CIL, I’ll still catch all bugs …

Think about the following:

  • TFS: Do you allow multi-checkout on all elements (or only on labels)?
  • TFS: What is your check-in policy? Which constraints to you want to impose on check-in?
  • TFS: When do you check-in? Only when all your work is done for the entire Feature, or do you allow intermediate check-ins? If yes, under which circumstances? If no, how do you handle core elements like InventTable, SalesTable that will be changed „at the same time“ by several developers?
  • Do you create new fields on Standard AX tables or on 1:1 related tables?
  • Do you use table inheritance? What do you use it for? Recommendation: Use it sparingly, if at all – hope it will be better in future versions.
  • Do you use RecIDs as Foreign Keys? Recommendation: Don’t exagerate.
  • Do you make use of models? What for? If you’re not an ISV or VAR, you’ll usually be doing well with the following models:
    • Label
    • Business Logic
    • Test code
    • Data Migration code
  • Don’t forget to design the security artifacts when creating a new solution!

Things that will be helpful:

  • Create a Batch Job to automatically build crossreferences every night.
  • To compile your entire application, use ax build in multiple threads.
  • Create a few test users you can use for security testing.

As indicated, this is in no way a complete list. Will add to it whenever I remember one of the lessons I had to learn the hard way.