Learning MS Dynamics AX 2012 Programming

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 language, it also includes embedded SQL. This means that writing SQL statements in AX is very easy, because as a developer, you don't need to create a connection to the database, then 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 language-integrated query (LINQ) for .NET.

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

In addition to the programming language, Dynamics AX provides an integrated development environment called MorphX. It is all about 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 an element. This also is the recommended approach to development in most cases. Most of the AX elements can be edited using MorphX.

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

You can open it by clicking on the AOT icon, shown in the following screenshot, from the top menu or by pressing Ctrl + D from anywhere in AX; this will launch the development workspace.

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

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 any time while you are in the AOT, you can hit Alt + Enter or right-click and select properties to open the Properties window, as shown in the following screenshot:

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 you can see in the Name property in the preceding screenshot means that it is mandatory. The 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 by relevance, relative to the element they represent. This sorting can, however, be set to alphabetical order from the user options form. Click on the Microsoft Dynamics AX button (Alt + F) and navigate to Tools | Options, to open the user options form. Under the Development tab, you can enable the Sort alphabetically checkbox to sort the properties alphabetically, as shown in the following screenshot:

The X++ code editor that ships with AX 2012 is based on Visual Studio's code editor and hence, it supports color coding, word completion, automatic indenting, scripting, zoom, multiline editing, and many other features that are available in Visual Studio. This is where all the X++ code will be written.

X++ code editor consists of three sections; method list, menu bar, and code window.

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

The code window obviously shows the X++ code for the selected method in the method list:

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

The available options are explained as follows:

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

One of the major differences between the AX compiler and other compilers (such as the Visual Studio's .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 you have changed can make classes that consume your changed code to stop compiling. If they are not recompiled, and probably changed as well, users will experience a runtime error.

To decide how the compiler should act when compiling the code, you can look into some options provided to you when you change the compiler parameters.

First of all, to change the compiler parameters, you have to open the user options form (click the Microsoft Dynamics AX button (Alt + F) and select Tools | Options). From the Development tab in the user options form, click on the Compiler option to open the Compiler setup form, as shown in the following screenshot:

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. Refer to the Cross-references section for more information regarding the cross-references. The fields in this form control how the X++ compiler should act. The code can be set to give compiler warnings at different levels, by changing the Diagnostic level option. You can choose 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 checks for best practices.

The output defines where the compiler messages should appear. They can appear in a compiler output form such as the one shown in the following screenshot:

Alternatively, messages can appear in a print window:

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

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, and the file itself is stored in a database along with the AX models. These label files consist of the label ID and the text for that label in that specific language. When opening a label file in a text editor, you can see labels listed, such as the following:

@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 who are 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) and navigate to Tools | Development tools | Label file wizard and run through the three self-explanatory steps of the Wizard.

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

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 names of the elements it is called from, the methods using it, and where it is used in the methods (line/column). Cross-references also enable developers to see all elements used by the selected element. Of course, the best use of the cross-reference tool is to be able to see where a particular element is used.

To be able to see the cross-referenced data, you need to update cross-references on a regular basis, at least if you want to see it in a development environment at a point in time where changes are being made. This can be done by setting up the cross-reference update to run in a batch, or you can set cross-references to update each time you change an element. To set it up to update every time you change an element, you need to change the compile parameters.

First of all though, you have to run a full cross-reference update. This is done by selecting the Microsoft Dynamics AX button (Alt + F) and navigating to Tools | Development tools | Cross Reference | Periodic | Update. You will see the following window:

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 selecting Selected and clicking on the Select button. You will then get a query where you can filter what kind of elements you would like to update 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 for the fields in the query that they are running, but also for fields from other related tables. An example of this is when the end user wants to print the report Cust, which lists customers. Let's say they 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 joint between the CustTable and the SalesTable.

Updating the type hierarchy will enable developers to look at a class or an extended datatype and see if it belongs to a hierarchy, as seen in the following screenshot:

The left side of the application hierarchy tree shows which class hierarchy the SalesFormLetter_Confirm class belongs to. All classes in AX automatically extend the Object class, as you can see at the top of the tree. The right part of the form will show you all the methods of SalesFormLetter_Confirm and where they are implemented in the class hierarchy.

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. Basically, it 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 use 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 for other developers, so only you can make changes to it. When you have made your changes to the element, 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 made 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

To set up the MorphX Version Control System (VCS) in AX, simply click on the Microsoft Dynamics AX button (Alt + F) and navigate to Tools | Development tools | Version Control | Setup | Parameters.

You should then set up this form, as shown in the preceding screenshot. First of all, you have to select Enable in the source control status. Then you need to select the version control type you would like to use. This book only covers the MorphX VCS as it is the best option for a small-sized project with five or less developers. 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 the Team Foundation Server, selecting the Team Foundation Server as the version control for AX might be a better option.

Note

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

You can also choose to have the AOT elements color coded, depending on the VCS status, and to receive a warning when reverting objects, as shown in the following screenshot:

After setting these parameters, you can choose to create a repository by clicking on the Microsoft Dynamics AX button (Alt + F) 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 in time. If you have a new solution without any modifications to the standard AX, this is not needed as you always have the option to go back to the original version in the system layers.

You can also set some rules as to what should be allowed or denied when trying to check in an element into the VCS, by clicking on the Microsoft Dynamics AX button (Alt + F) and navigate to Tools | Development tools | Version Control | Setup | System settings.

In this form, you can select to set rules so that the developers can't check the code that doesn't compile or have best practice 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

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 or by right-clicking the element and selecting 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 by clicking on the Check-In button from the AOT menu bar, hitting Alt + I, or right-clicking the element and selecting Check-In.

You will then see a form consisting of all elements that are 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 into 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 click on the History button, or right-click the element and select History.

The History form will show the history of a specific element in the AOT. The history consists of all the 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.

Note

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 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 helps 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 developers' 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 it from where you are, stop the code's 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, as well as breakpoints, output, and the variable watch.

Dynamics AX 2012 consists of 16 application object layers that contain all the elements you see in the AOT. These 16 layers are basically formed out of eight core application layers and a patch layer for each core layer.

These layers can be looked at as an onion with multiple layers; the lowest layer or core application layer being the SYS layer and the outermost layer being the user layer USR.

So 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 there isn't, 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 16 layers of Dynamics AX 2012 are shown here:

The following list is taken from the Dynamics AX 2012 MSDN site and provides an explanation for each layer:

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

As an AX developer, you can choose to have the piece of code you are writing to 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 (AOS). The data tier is hosted on MS SQL Server.

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 with 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, which is the file server. The file server is not really a tier itself, as it does not execute any code but only stores the code.