Microsoft Dynamics AX 2009 Programming: Getting Started

By Erlend Dalen
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies

About this book

Microsoft Dynamics AX 2009 is Enterprise Resource Planning (ERP) software that comes with its own development environment and a programming language called X++. It is specialized and optimized to solve the tasks that are typical of an ERP system. But the specialized development environment of AX brings a steep learning curve. Hence, getting started with Dynamics AX and mastering it effectively can sometimes be daunting.

This tutorial has been carefully structured to guide you through the basic features of AX development, and get you started as quickly as possible. With this book, you will soon be able to develop and maintain comprehensive management solutions for enhancing your application's performance.

The book starts with a tour of the development environment, which helps you gain a deep understanding of Dynamics AX tools and architecture. It will introduce you to the X++ language. It helps you to create new functionality that can be used and changed in the standard application. You'll also learn how to search, manipulate, and integrate data.
The practical examples in this book take you through sample AX development projects and help you learn to create forms, reports, menu items, menus, and navigation pages. It also helps you work with the MorphX application.

The author's experience of developing solutions with Dynamics AX enables him to share insights in an effective, clear, and friendly way.

By the end of this book, you will have a better understanding of the inner workings of Microsoft Dynamics AX – making your development simpler and faster, and your applications fast, reliable, and robust.

Publication date:
December 2009


Chapter 1. Getting to know Dynamics AX 2009

By reading this chapter, you will learn how the development environment is structured and what tools are accessible to the developer in AX. The famous HelloWorld code will be a piece of a cake for you to understand after the first step-by-step walkthrough of this book, and you will know what the different nodes in the application object tree represent.

Here are some of the topics that you can learn more about in this chapter:

  • Creating a job that prints something on to the screen

  • A tour of the development environment

  • A look at the tools available

  • An overview of the AX architecture


Development environment

Let's have a look at the main features of the AX development environment:

  • The AX programming language

  • The Application Object Tree

  • The X++ code editor

  • The compiler

  • The labels

Programming language

The programming language in AX is called X++, and its syntax is similar to Java and C#. In addition to being an object-oriented programming (OOP) language, it also includes embedded SQL. This means that writing SQL statements in AX is very easy, because you, as a developer, do not need to create a connection to the database, create a statement that is executed on the connection, and so on. Instead, you can write the SQL statements directly into the X++ code much like you now can with LINQ for .NET.

You will get to know the syntax, features, and how the X++ language works in general in Chapter 2, X++ language.


In addition to the programming language, Dynamics AX provides an integrated development environment called MorphX. MorphX is all of the visual development in AX, and it lets the developer create code elements in a graphical way much like Visual Studio by dragging and dropping, and setting properties on elements.

Application Object Tree

The Application Object Tree (AOT) is where you find all code elements in AX.

You can open it by clicking on the icon from the top-menu shown below or by pressing Ctrl + D from anywhere in AX.

You will then see the AOT presented in a tree view as shown on the right-hand side in the following screenshot:

Data Dictionary

The AOT is organized to contain all elements that relate to how the data is stored in the database and those that relate to security, such as the Security Keys, Configuration Keys, and License Keys, under the node called DataDictionary. Under this node, you will find tables, maps, views, extended datatypes, base enums, license codes, configuration keys, security keys, table collections, and perspectives.


Macros are predefined values used throughout the solution and are present just as a best practice tool. You won't have to hardcode values into the code, but rather reference a macro-element within a macro.


Classes in AX are classes in the same sense as you are used to from C# or Java or whichever object-oriented programming language you already know. They are blueprints of how objects should look at runtime.


Forms are the end users' way of communicating with the system. They can open forms to search for data, view data, change data, create new records, or delete records. In addition, forms very often contain buttons that link to other forms, reports, and classes that execute business logic.

Data Sets

Data Sets are new in AX 2009 and are used by Visual Studio components, such as Reporting Services reports and AX User Controls, as you will see in later chapters. The data sets define the tables that are used by these Visual Studio components by adding the tables to the data sets much like you would do with table in a data source.


Reports are the standard AX reports that will display data in a report form to the users, or write the data to a printer or file.

Report Libraries

Report Libraries are links to reporting projects in Visual Studio. You can't create a reporting library directly from AX. You have to create a reporting project in Visual Studio first and import it into AX. It then becomes a report library.


Queries in the AOT are predefined static queries that can be reused throughout the whole application. A query contains a hierarchy of data sources that defines the data that should be available for the query. Queries can also be used by other elements in AX such as in forms, reports, and classes.


Jobs are static methods intended to directly execute a small piece of code. They work fine for code that is supposed to execute once, but are not intended to be a part of a customer solution.


Menus present the end user with options to open the most used forms and reports and to start periodic tasks.

Menu Items

MenuItems are pointers to forms, reports, or classes. There are three different types of menu items: Display, Output, and Action. The display menu items are used to open forms; the output is used to open reports and the action is used to execute a class with a main method (start point).


The Web node consists of subnodes that in turn hold different types of elements relevant for developing web applications such as the enterprise portal.


Services are used to set up web services that let other applications use AX classes through the Application Integration Framework (AIF). The AIF is used for electronic communication with trading partners or applications.


The workflow framework in AX lets developers create workflows that define certain execution flows depending on certain events. The typical scenario for using a workflow in AX is the purchase requisition where one employee enters a purchase order. If the purchase order is over a certain limit, it has to be approved by a manager. If denied by the manager, a message is triggered to the employee who created the order. If approved, the order is automatically sent to the vendor.


Resources are files that are imported into the AX database, and can be referenced in the code from the resources node in the AOT rather than using a directory and filename on the disk. These files are typically images, icons, cascaded stylesheets, and XML files. You can preview the files by selecting a resources node in the AOT, right-clicking on it, and selecting Open.

System documentation

At the bottom of the AOT, you can find different types of help. The system documentation consists of documentation of the AX core. These are the elements in AX that are not open source. This means that you, as a developer, have to relate to these elements as "black-boxes". This means that only you will know what to put into methods and what you can expect to get back. You can find information about global functions here such as strlen(). This function (and most other functions) is documented with an explanation of the input parameters, return value, and an example of how to use the function.

The same goes for core classes and their methods. Typical core classes are Map, Array, AsciiIo, FormRun, XppCompiler, and so on, just to mention a few.

Application Developer Documentation

Application Developer Documentation consists of documentation regarding standard AX tables and classes. This documentation is basically just another way of displaying information that you, as a developer, should be able to find by browsing the AOT, reading code, and looking at properties.


"So how do I look at properties?" you might ask. Well, at anytime while you are in the AOT you can use a combination of Alt + Enter keys, or you can right-click on the AOT and select Properties. The next image is a screenshot of the Properties window.

Each element-type in the AOT will have a fixed set of properties that can be changed by the developers. The properties marked with bold text have been changed specifically for the selected element. The pink background that you will see in the Name property means that it is mandatory. A yellow background means that it is best practice to have something in that property. The rest of the properties are defaulted by the system.

The properties are by default organized after relevance relative to the element it represents. This sorting, can however, be set to alphabetic order from the user options form. Press the Microsoft Dynamics AX button (Alt + M) and navigate to Tools | Options to open the user options form. Under the Development tab page, you can enable the Sort alphabetically checkbox to sort the properties alphabetically, as shown in the following screenshot:

X++ code editor

The X++ code editor is where you will write all code. It consists of three sections: method list, menu bar, and code window.

The method list will show all methods in the selected element if you double-click on an element. If you double-click on a method within an element, you will see only that method in the method list. If you then double-click on another method in the same element, you can see both selected methods in the method list. When you change a method, it will display an asterix after the method name in the method list. This asterisk shows that you a changed method that has not yet been saved.

The code window will obviously show the X++ code for the selected method in the method list, as shown in the following screenshot:

The menu bar has the following buttons, listed from left to right, as shown in the following screenshot:

Description of the menu bar button is as follows:

  • New: Creates a new method within the selected element.

  • Save: Saves all the methods open in the method-list.

  • Run: Executes the method or class if it is executable.

  • Breakpoint: Sets a breakpoint at the line where the cursor has been placed.

  • Enable/Disable breakpoint: Enables or disables a breakpoint.

  • Remove all breakpoints: Removes all breakpoints for the current user.

  • Compile: Compiles and checks for errors in the code.

  • Lookup properties/methods: Displays help for the selected text if the cursor is placed over a core-function or method, list methods for a class, available values for enums, and so on.

  • Lookup label/text: Opens the label editor and searches for the selected text.

  • Scripts: Opens a context-menu that consists of small code snippets such as do-while loop, header comments, and so on. You can also create your own scripts by creating new methods in the EditorScripts class.

  • Help: Displays the help file for the selected text in the code window, if such a help file exists. If not, it displays the help file for the X++ code editor.


The compiler in AX is in many ways just like any other compiler. It checks for syntax errors and gives the developer error messages if there are any syntax errors found. It can also give warnings if it sees any code that it finds misplaced or not written according to best practice rules.

Though one of the major differences between the AX compiler and other compilers, such as the Visual Studio .NET compiler, is that the AX compiler only requires you to compile the code that you have changed. The problem with this is that the code that you have changed can make classes that consume your changed code not to compile anymore. If they are not recompiled and probably also changed, users will experience a runtime error.

To decide how the compiler should act when compiling you can change the compiler parameters.

First of all, to change the compiler parameters, you have to open the user options form, that is, press the Microsoft Dynamics AX button (Alt + M) and select Tools | Options.

From the user options form click on the Compiler button to open the compiler setup form. Here you check the Cross-reference flag and you are good to go. Remember that compiling code in AX will take a lot more time when it has to update the cross references as well. See the following screenshot for more information regarding the cross references:

The fields in this form control how the X++ compiler should act. It can be set to give compiler warnings at different levels by changing the Diagnostic level. You can select not to receive any warnings about strange looking code, such as having a line of code after a return statement in a method. Compiler errors will, of course, still show. Level 4 means that the compiler will also run best practices checks.

The Output defines where the compiler messages should appear. They can appear either in a Compiler output form, such as the following one:

Or in a print window, such as the next one:

The compiler output form is set as default as it contains more information and has a more standardized look and feel. It is divided into the following tab pages:

  • Status: Lets you see the overall status of what you have compiled

  • Errors and warnings: Displays any errors or warnings depending on the diagnostics level set in the compiler setup form.

  • Best Practices: Shows the best practice warnings as specified in the best practice parameters form.

  • Tasks: Tasks are added in the code by writing a comment that has the TODO statement as shown below:

    // TODO: Remember to fix the for-loop


The labels in Dynamics AX are a way of translating all user visible text by only referencing to a label ID in the code. Each language is represented by a language-specific label file within each label module. These label files consist of the label ID and the text for that label in that specific language. The label files are stored in the application directory and have the file extension .ald (Application Label Data). When opening a label file in a text editor you can see labels listed below:

@SYS390 Quantity that is not yet cost accounted in the BOM unit.
@SYS400 Create and compose serial numbers automatically.
@SYS403 Finish must be greater than start.
@SYS418 Transfer customer information?

This means that if you write @SYS403 in the label-property of a field in AX it will display Finish must be greater than start. to the users viewing that field in a form or report, if they are using the language code en-gb (as this was taken from the label file AxSYSen-gb.ald.)

To create a new label file, simply start the label file wizard from the Microsoft Dynamics AX button (Alt + M), navigate to Tools | Development tools | Label file wizard, and run through the three self-explaining steps of the wizard.

Your label file will then be named AxXXXen-gb.ald, where XXX is a three lettered abbreviation chosen when walking through the wizard.


Creating your first AX program

To make the HelloWorld example, we simply open the AOT by pressing Ctrl + D from anywhere in the main Dynamics AX window or by clicking on the AOT button in the top menu, as shown in the first screenshot in this chapter.

Go to the Jobs node in the AOT, right-click on it, and select new Job.

Check if the Job opens automatically.

A new X++ editor window will open showing a new Job:

static void Job1(Args _args)

As a Job is static and has an input parameter of the Args class, it can be run directly. Obviously, the previous example doesn't do anything, it simply edits the job. It will display a HelloWorld message on the Print WINDOW while running the job by clicking on the Go button or by pressing F5.

static void HelloWorld(Args _args)
  print "HelloWorld";

The pause statement will halt the execution of the program and ask you if you would like to proceed. It is shown in this example just so that you see what the Print WINDOW displays. If the pause statement hadn't been put here the Print WINDOW would print HelloWorld and just close again in a blink of an eye. This is shown in the following screenshot:


Development tools

AX comes with many different tools that can help developers do their job. Some of these tools are, however, rarely used because they provide little value. We will now have a look at some of the tools you will use on a day-to-day basis when programming in AX. Some of the things you need to know about are:

  • Cross references

  • MorphX version control

  • Debugger

Cross references

The cross references let developers select an element in the AOT and ask the system where the element is used. The result is listed in a form and shows if the element is used for read or write, the name of the elements it is called from methods using it, and where in the methods it is used (line/column). Cross references also enable the developers to see all elements used by the selected element, but of course, the best value for the cross reference tool is to be able to see where one certain element is used.

The following is a screenshot of the form displaying the result:

To be able to see the cross references you need to update them on a regular basis, at least if you want to see them in a development environment at a point in time where changes are being done. This can be done by setting up the update to run in batch, or you can set cross references to update every time you change an element. To set it up to update every time you change an element, you need to enable the Cross-reference parameter in the Compiler Options form that you find by pressing on the Microsoft Dynamics AX button (Alt + M) | Tools | Options and clicking on the Compiler button. First of all though, you have to run a full cross reference update. This is done by selecting the Microsoft Dynamics AX Button (Alt +M) and navigating to Tools | Development tools | Cross Reference | Periodic | Update. The following screenshot shows the Update cross-reference screen:

You can choose to delete all existing cross-references before creating them again, update cross-references for all elements in the AOT, or select which elements you would like to have updated by clicking on the Select button. You will then get a query where you can filter what kind of elements you would like to update the cross-references for.

In addition, there are two other useful types of cross-references that can be updated from this form. Updating the data model will enable end users to filter queries not only the fields in the query that they are running, but also fields from other related tables. An example of this can be when the end user wants to print the report Cust that lists customers. Let's say he would like to limit the report to show only the customers who have ever created an order. He would then have to add the SalesTable to the structure of the report, so that it would create an inner join between the CustTable and the SalesTable.

Updating the type hierarchy will enable developers to look at a class or an extended data type and see if it belongs to a hierarchy. This is shown in the following screenshot:

The left-hand side part of the form, that is, the Application Hierarchy Tree will show which class hierarchy the SalesFormLetter_Confirm belongs to. All classes in AX automatically extend the Object class as you can see in the top of the tree. The right-hand side part of the form will show you all the methods in the SalesFormLetter_Confirm and where they are implemented in the class hierarchy.

MorphX version control

If you have done development in Visual Studio on projects with multiple developers, you have most likely used a version control tool and know the essentials of it. If not, let me try to explain how a version control tool works. It basically is a repository where you can check elements in and out and track changes done to an element over time. If for some reason you would like to take back an older version of an element, the version control enables you to do that as well.

When you check an element out it is locked to other developers so only you can make changes to it. When you have completed your changes to the element you simply check it in and comment on what kind of changes you have made. It will then be available for other developers to change again. If for some reason one of the changes done to the element creates an unwanted situation you can simply revert the element to the state in which it was before the particular change was made.

Setting up the MorphX Version Control System

To set up the MorphX Version Control System (VCS) in AX simply press the Microsoft Dynamics AX button (Alt + M) and navigate to Tools | Development tools | Version Control | Setup | Parameters. You will get the screen shown in following screeshot:

You should then set this form up like I have done in next screenshot. First of all, you have to select Enable in the Source control status. Then, you need to select the version control type that you would like to use. This book only covers the MorphX VCS, as it is the best option for most AX development. The main reason for this is that it doesn't require each developer to have a full AX installation locally like the Visual Source Safe and Team Foundation Server do.

If you are creating a new module for AX, or if you are already using Team Foundation Server, then selecting Team Foundation Server as version control for AX might be a better option.


When using the MorphX VCS, the repository is actually inside the AX database, so you will always have an access to it as long as you are logged on to your AX solution

You can also select to have the AOT elements color coded depending on the VCS status and to receive a warning when reverting objects.

After setting these parameters, you can choose to create a repository by pressing the Microsoft Dynamics AX button (Alt + M) and navigate to Tools | Development tools | Version Control | Setup | Create repository.

This will basically check in all elements in the AOT with a shared comment at that point of time. If you have a new solution without any modifications to standard AX, this is not needed, as you always have the possibility to go back to the original version in the system layers.

You can also set some rules as to what should be allowed and denied when trying to check in an element into the VCS by pressing the Microsoft Dynamics AX button (Alt + M) and navigating to Tools | Development tools | Version Control | Setup | System settings. This is shown in the following screenshot:

In this form, you can select to set rules so that the developers can't check in code that doesn't compile or have best practices errors.

You can also set up a test project and run the code through that test project successfully before being able to check in code.

Using the MorphX Version Control System

When you have set up the MorphX VCS, you can start adding elements to the VCS as you start working on them.

To add an element to the VCS, simply select the element in the AOT and click on the Add to version control button from the AOT menu bar, as shown in the following screenshot, or right-click on the element, and select Add to version control:

When an element has been added to the version control, you will be able to check in the element to add your changes to the repository. This is done either by clicking on the Check in button from the AOT menu bar, pressing Alt + I, or by right-clicking on the element and selecting Check in. This screen is shown in the following screenshot:

You will then see a form consisting of all elements that are either checked out, or added to the VCS but not yet checked in. You have to type a description of what you have done to the element before clicking on OK. The element will then be checked in to the repository.

To see the history of what has been done to this element over time you can select the element in the AOT and either click on the History button, or right-click on the element and select History.

The history form will show the history of one specific element in the AOT. The history consists of all check ins with comments, user ID, date, time, and version ID.

You can also open the .xpo file from the history form by clicking on the View File button.


XPO is the export format that is used by AX to export and import code. It can be used to transfer code from one AX solution to another. The XPO files are in text format and can be opened in a text editor for verification.

To open up the selected version of the element in an AOT window click on the Open new window button. If you open a version other than the current one, or one that is checked out by someone else, you will only be able to read the code (no changes allowed).

Selecting two versions of the same element enables the Compare button where you can compare the two different versions to track the changes.


The most important developer tool is the debugger. This tool will help you in your search to find what is wrong with your code, if you are one of those developers who write code that doesn't work as expected. Even if you never write code with bugs, you might be lucky enough to find other developer's bugs, and the debugger will then hopefully make you curse and swear a little less.

The debugger contains two main sections—the code section at the top and the information section at the bottom.

The code section is where you see the active code being executed. You can execute the code step-by-step, run from where you are, stop the code execution, step into, step over, and even go backwards in the active method, set breakpoints, toggle breakpoints, and remove breakpoints.

The information section contains separate windows for the call-stack, local, global and class variables, breakpoints, output, and variable watch.



Now that you have seen some of the development tools in AX, let's have a look at how AX is built from a technical perspective.

We will look at the following concepts:

  • Application object layers

  • Network tiers

Application object layers

Dynamics AX 2009 consists of sixteen application object layers that contain all the elements you see in the AOT.

These layers can be looked at as an onion with multiple layers. In the middle is the core application in the SYS layer and the outermost layer is the user layer USR.

Therefore, when any application element is being executed the system will look at the outermost code layer first to see if there is any code for that element; if not, it peels a layer off the onion, and tries the next layer. When it hits a layer where the element exists, it will use the code from this layer, and will not continue to peel off layers to find code for that element in the innermost layers. The following figure shows the multiple layers:

As you might have noticed, the above figure only shows half of the layers. Each of the layers in the illustration, except the HFX, SL1, SL2, and SL3, has a patch-layer. The patch-layers are used for service-packs and hotfixes, and exist one layer outside its corresponding main layer. If we look at the SYS layer there is actually a SYP layer between the SYS layer and the GLS layer.

The HFX, SL1, SL2, and SL3 layers are new in Dynamics AX from version 2009, but can be found in previous versions as DIS, DIP, LOS, and LOP.

The list below is taken from the Dynamics AX 2009 SDK and provides an explanation of each layer:




The standard application is implemented at the lowest level, the SYS layer. The application objects in the standard application can never be deleted.


When the application is modified to match country/region-specific legal demands these modifications are saved in a separate layer, the GLS layer. If an application object, for example, a form, is modified in the GLS layer, the modifications are saved in the GLS layer only and the modified version of the form is used.


HFX is an application object patch layer reserved by Microsoft for future patching or other updates.

SL1, SL2, or SL3

A layer where the distributor can implement vertical partner solutions. SL is an abbreviation for SoLution.


When a business partner creates their own generic solution, their modifications are saved in the BUS layer and the top-level application objects are used.


Value Added Resellers (VAR) can make modifications or new developments to the VAR layer as specified by the customers or as a strategy of creating an industry-specific solution. Such modifications are saved in the VAR layer.


The supervisor or administrator of an end user installation might want to make modifications that are generic to the company. Such modifications are saved in the CUS (CUStomer) layer.


End users might want to make their own modifications, such as in their reports. These modifications are saved in the USR layer.

Each of these layers is represented in the application folder with a .aod file if there is any code in the solution in the layer. The same goes for the patch layers. This means that the application object file for the SYS layer is AxSYS.aod, and as the patch layer for SYS is called SYP, the patch file would be AxSYP.aod.

Network tiers

AX 2009 is built as a three-tier solution. This means that it has a data-tier where the data is stored, a logic-tier where all business logic is executed, and a presentation-tier that presents information to the user and receives input from the user.

As an AX developer you can select to have the piece of code you are writing be run on the client or the server. The client will represent the presentation-tier and the server will represent the logic-tier. The AX server is also called the Application Object Server or AOS. The data-tier consists of either an MS SQL or an Oracle database.

There are also two completely different clients available in AX. The regular Windows client, also known as the rich client, is the one most users think of when we talk about the AX client, but there is also a business connector client. The business connector client can be used by a third-party application to integrate to AX, and it is also used by the enterprise portal.

In addition to these three layers we also often talk about a fourth component in the tier model, the file-server. The file-server is not really a tier in itself as it does not execute any code but only stores the code.


Case Study: Carz Inc.

Most of the examples in this book will be related to a case study where you will be assigned to develop a module in AX for a car rental company called Carz Inc.

Carz Inc. rents out cars and sells cars after they have reached a certain mileage.

They need to store information about their cars and their customers. They also need a booking system within Dynamics AX that enables them to see which cars are available or rented out within different car groups.

The customers should also be able to see availability from an enterprise portal site.

The examples will show you step-by-step how to create extended data types, tables, forms, reports, and everything you need to make the whole module work according to best practices rules and according to the requirements set by Carz Inc.



Now that you have made it through the first chapter of this book, you have hopefully gotten a good foundation to learn more on how to program in AX.

This chapter has shown you how to write the famous HelloWorld program in AX and taken you through the development environment where you learned about the different elements in the AOT.

You have seen some of the most important development tools that you will get to know very well once you get going with the AX development.

The application object layers and network tiers have shown you the main concepts behind the technical architecture of AX, and finally, you have read a little bit about the case study that we will continue to use throughout the book.

In the next chapter, you will learn the syntax of the X++ language by looking at the different data types you can use in X++, how to write statements and loops such as if-else and while loops, how different operators are used, and how to create and use classes and methods.

About the Author

  • Erlend Dalen

    Erlend Dalen started working as a developer with the first version of Axapta in 1998. He was then working with some of the first Axapta  implementations in Norway and was also part of a team that created an advanced product configurator for Axapta. From 2000 to 2002, he worked on developing e-commerce, mobile, and integration solutions in Java for a Norwegian IT consultancy company. He joined Columbus IT in 2002, working first as a senior developer in Norway and in the USA and then as the technology manager of the Norwegian branch, where his responsibilities included implementing new technology areas, creating an e-commerce solution for Dynamics AX, and being the technology solution architect in internal and external projects.

    For the past four years, Erlend has been working as a web developer for Norsk Test AS, where he spends his days programming in Python using the Django web framework.

    Browse publications by this author
Book Title
Access this book and the full library for FREE
Access now