There are initial clarifications to understand about AXBuild:

• The legacy compilation options in the MorphX client remain available.
• AXBuild involves the compilation of X++ source code into AX p-code and metadata validation, but it does not involve the subsequent generation from p-code into .NET Framework CIL.
• AXBuild can compile all the elements in the system, but its scope cannot be narrowed to compiling just a subset of classes and other elements.

Sometimes a compilation of all the AOT elements is needed. Such occasions include:

• Setup of AX 2012 R2.
• Installation of upgrades and hotfixes.
• Migration from development to test, staging, and production environments.

1  Phases of any X++ Compile Process

In the earlier blog post, How the X++ Compiler works for AX2012 we gave a high level explanation of the processes that compile X++.  Three major phases were described:

• Phase 1:    Declarations and method signatures.
• Phase 2:    Metadata validation and method bodies.
• Phase 3:    Recompilation of elements that had preliminary errors.

These phases apply to the compile process under AXBuild just as they apply to the compile process you initiate by clicking in the MorphX client menus.

2  Legacy Client Tier Compile of Full X++

Until today the X++ compilation and metadata validation processes were always executed on the client tier using one single thread. Figure 1 represents the X++ compilation process that runs on the client. The client requests metadata from the Application Object Server (AOS) tier. Metadata is needed for every element that must be compiled or validated. The metadata stored in SQL Server is de-serialized by the AOS into the internal representation of a TreeNode. Then the metadata is transferred over the network to the client. If the client and AOS are installed on the same computer (the “one box” configuration), a process-to-process communication over RPCs is used in place of a two tier network communication.

After the client received the metadata, the client compiles the X++ source code. The X++ source code is translated in AX p-code. The AX runtime understands the p-code and can execute it. The compile process also validates any references to other elements that are specified through properties. Information about any errors is written to the compilation log. After each element is compiled, the client enriches its representation of the element with updated metadata and p-code. Next the client sends the enriched representation to the AOS. The AOS saves the updated element in the model store database.

Figure 1. Metadata transfer during compilation and validation process.

Agile development benefits from the client tier compile of X++, because the development cycles often require compilation of a narrow subset of all classes and forms etc. In the MorphX client the developer can compile individual elements such as one class. The developer can test the change, fix the code, recompile the one class, and retest. The compilations of individual classes complete in a second or two, so these agile development cycles are kept efficient.

Also, the compiler on the client tier is fully leveraged and integrated with productivity tools like Cross Reference, IntelliSense, and Visual Studio.

3  AOS Tier Compile of Full X++ (only in cu7)

For a full X++ compile, the legacy client tier scenario is slow. Having the compilation run on the client is ironic for the following reasons:

• One irony is that the source code and the metadata are on the server computer, yet the compilation that needs the source and metadata is run on the client computer.
• The server computer is typically more powerful in terms of hardware.

In cu7 we are introducing AXBuild, an X++ compilation management utility that you run on the same server computer that hosts the AOS. AXBuild achieves its speed gains for the following major reasons:

• The client is excluded from the scenario. This eliminates the network communication from the AOS to the client and back. See Figure 2.
• AXBuild runs on a server computer that typically has more powerful hardware than the client computer has.
• AXBuild runs the compilation as a 64 bit process, instead of a 32 bit process as with MorphX. This allows more active memory to be addressed.
• AXBuild compiles subsets of AOT elements in parallel, whereas the client compilations process uses just a single thread.

 Figure 2. Parallel compilation on the server tier.

Exclusion of the Client Tier: In the legacy full X++ compilation that runs on the MorphX client, the network transmission of information from the AOS to the client and back adds 28% to the wall clock duration of the compilation process. Even if the client is installed on the same computer with the AOS, transmissions through RPCs are needed.

Parallel Compilation: AXBuild starts multiple temporary AOS processes. These AOS worker processes run in parallel.  AXBuild coordinates their compilation acitivities. AXBuild does the following:

• Assigns a subset of AOT elements for compilation to each temporary AOS.
• Collects the results from each temporary AOS, and writes the results to a single combined compilation log file.

AXBuild calculates the optimal number of temporary AOS workers as best it can, and it reports its calculation to its console. The calculation is based on the number of CPUs that the server computer has. However, you can fine tune and control the number of AOS workers by using the /workers= parameter. Factors you might consider include:

• Amount of active memory that the server computer has.
• CPU demands that other processes might make while the compilation runs.

4  New compiler constraints

Calls to COM Objects Cannot be Chained Together

When your X++ method contains calls to COM objects, the syntax shortcut of chaining methods calls together can cause the compiler to report an error.  The simple solution is to rewrite a couple lines of code make the variable types more explicit and discoverable by the compiler.

 A.    Example that Fails:    The following X++ code example chains the method2 call to the end of the method1 call.  The server compiler reports an error for the method2 call:

void methodXpp()

{

    COM comInstanceA = new COM("My_COM_Type_A");

    comInstanceA.method1().method2();    // methods call chained together

}

 Underlying Details:    Often COM objects that are called by X++ code are installed only on the client tier, and are not installed on the server tier.  In the preceding code example, the underlying problem is that the server compiler cannot know whether method1 returns another COM object or just an integer.  A plain integer would not have a method named method2, so the compile cannot validate the call to method2.  For the call to method1, the compiler accepts the late-binding approach by inserting into the p-code a call to the COM method named dispatch.

 B.    Example that Succeeds:    The following rewrite of the preceding X++ code example eliminates the chain, and the server compile passes without error:

void methodXpp()

{

    COM comInstanceA = new COM("My_COM_Type_A");

    COM comInstanceB;

    comInstanceB = comInstanceA.method1();

    comInstanceB.method2();

}

Underlying Details:    In the preceding code example, the X++ compiler is told by an explicit type declaration that variable comInstanceB is a COM object.  This gives the compiler justification to insert a call to the dispatch method for method2.

If you install cu7 all the application code exposing this pattern has been addressed and fixed, so no compilation errors should be reported. However if you choose not to install the application code portion of the cumulative update, you are going to get some compilation errors due to this pattern (Figure 3).

Figure 3. Compilation errors generated if application code is not installed as part of cu7 setup.

5  Performance Gain

The performance gain depends on the available resources in the computer where the parallel compilation process is being executed, including number of CPU’s and memory available. However to put some numbers in perspective, we have taken some careful measurements.

5.1  Configuration

• MorphX client, AOS and SQL Server installed on the same computer.
• 4 Cores 3.7 GHertz.
• Hyper-Threading enabled, which logically doubles the CPU count.
• 32 GBytes of physical active memory.
• 6.0 Gigabits/s SATA Controller
• Windows Server 2012
• SQL Server 2012 Enterprise with SP1 (no memory constraint)
• Windows virtual page caching disabled.
• Fresh AX 2012 R2, with cu7 installed.

5.2  Results of Performance Test

• Compilation using AXBuild.exe running 9 AOS workers: 10 minutes and 40 seconds.
• Compilation using MorphX client (for comparison): 2 hours and 26 minutes.

Both measurements were done using the same hardware and software setup.

6  Miscellaneous Details

• When you use the AOT of the MorphX client to import a .XPO file, the resulting X++ compile occurs only on the client tier  (.XPO files import operation remains unchanged in cu7). 
• All generation of .NET Framework CIL remains unchanged in cu7.
• The MorphX client is the Development Workspace window in ax32.exe.
• Even though the name of the AOS program ax32serv.exe contains ‘32’, it is a 64 bit program.
• Hotfix KB2844240 is still relevant, getting better performance during compilation on top of AXBuild and legacy compilation from the client. This hotfix does not have to be installed independently from cu7, it is already included as part of the cumulative update, however you have to make sure it is executed against your model store using "AxUtil.exe schema".
• AXBuild.exe needs to be executed with hot-swap disabled. For more information about hot-swap mode refer to Hot-swapping of .NET Assemblies in the AOS [AX 2012].
• AXBuild.exe is not a tool that can be ported independently from cu7 (copying it to a computer with a previous Dynamics AX2012 R2 version), since it needs additional support introduced into the Ax32Serv.exe (AOS) and other binaries only available starting in cu7 version.
• For additional important information about AXBuild, see our formal Help topic on MSDN titled AxBuild.exe for Parallel Compile on AOS of X++ to p-code.

Now you can get diagrams like this - prebuilt for key areas:

This is where you find it: https://www.microsoft.com/dynamics/ax/erd/ax2012r2/

Also check out this blog post: https://blogs.msdn.com/b/x/archive/2013/05/23/announcing-the-axerd-website-for-dynamics-ax-2012.aspx

Enjoy! :)

The compile process is a little bit involved, so a drawing quickly becomes quite complicated. Instead we've tried to present the explanation in two modes that compliment each other:
A. C#-ish pseudocode
B. Corresponding paragraphs of verbiage

C#-ISH PSEUDOCODE

// Phase1: Limited compile only for metadata
// (of class declarations and method signatures).

foreach(Element in AOT)
{
       Element.CompileHeaders();
}

// Phase2: Full compile for metadata and code bodies.

foreach(Element in AOT)
{
       compileSuceeded = Element.Compile();

       if (compileSuceeded == false)
       {
              ListOfBadElements.Add(Element);
       }
}

// Phase3 to PhaseN: Recompile the errored elements
// until success or error stabilization.

if (ListOfBadElements.Count > 0)
{
       while(true)
       {
              foreach(Element in ListOfBadElements)
              {
                     compileSuceeded = Element.Compile();
                     if (compileSuceeded == false)
                     {
                           NewListOfBadElements.Add(Element)
                     }
              }
             
              if (ListOfBadElements.Count == NewListOfBadElements.Count)
              {
                     break; // The list of elements with errors has been stabilized.
              }

              ListOfBadElements = NewListOfBadElements.GetCopy();
              NewListOfBadElements.Reset();
       }
}

VERBAL EXPLANATION

During a complete AOT compilation, there are at least two full compilation phases, plus the potential for N iterations of Phase3.

Phase1 is a pass over all the AOT elements. For now the compile operations concern only the class declarations and the method signatures. These limited compile operations create metadata about the types and their methods.
Reference errors are ignored during Phase1 because they are uninteresting consequences of the compile sequence. For example, the first class that is compiled might reference another class that has not quite yet been compiled, but which will be compiled a moment later in Phase1.

Phase2 is a pass over each AOT element to perform a full compile of each. The compiler validates all metadata, all references, and all X++ code. The compiler emits p-code (which the interpreter can later execute).
Any AOT element that suffers an error is added to a list of bad elements. In the explanatory pseudo code this list collection is named ListOfBadElements.

Phase3 occurs only if ListOfBadElements is not empty at the end of Phase2.
Phase3 is a pass through ListOfBadElements, so that each previously bad element can be recompiled. The elements that fail this recompile are added to a new list that is named NewListOfBadElements.
At the end of Phase3 there are three possible outcomes:

A. NewListOfBadElements.Count == 0
This means the overall compile has completed successfully. Error log will be empty. There might be warnings or informational messages (TODOs)

B. NewListOfBadElements.Count == ListOfBadElements.Count
This means the set of errors has stabilized (at a number above zero), which means the overall compile has failed. Error log will contain the errors, warnings and informational messages.

C. NewListOfBadElements.Count < ListOfBadElements.Count
This means that Phase3 made useful progress in reducing the count of errors. Therefore another phase like Phase3 must be run. This leads to Phase4, Phase5, and PhaseN for as many iterations as progress continues.
The more elements the AOT contains, the more likely it is that iterations beyond Phase3 will be needed.

AND THEN SOME...

Also note that the compile pass is doing more than crunching X++ code into executable p-code. It's performing a vast number of metadata validations and it's updating the security information by running the Security Inference process on applicable constructs to update the security information available. 

AX doesn't employ a dependency driven build system, but rather an algorithm that is driven by the amount of errors it encounters in each compile pass through the AOT. This strategy requires a minimum of two passes - exactly two in the best case, and more if there are "unfortunate" dependencies as these might turn out as errors in the second pass as dependencies are yet to be compiled. The third pass will typically take care of this subset. However, the compile time is proportional to the size of each pass and the elements processed. If an element fails to compile successfully in a pass, it is added to the next pass and thus increases the effort in that next pass. Compilation ends (success or fail) when the last pass didn't provide further progress on resolving the pending errors.

So you see how that gets effected by broken application? You've effectively added dead weight to each pass after the second and depending on what you've left broken, it might entail quite significant increase in compile time. E.g. forms are quite intricate to compile and verify, so are tables and classes, so if you leave a significant number of these broken, your compile time might suffer quite significantly.

Bottom line: leaving part of your application broken is not just a risk from an execution perspective. It also negatively effects the turn-around time when you need to compile.

At the time of blogging this, the hotfix is so hot off the press and freshly published that the KB information isn't fully available yet, however the testing is completed, the hotfix is final and can be downloaded/requested from the following link:

https://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2844240

Like all the other hotfixes to the product binaries, it's a full service roll up of hotfixes to all the binaries.

The core of the fix is in the Model Store schema managed by axutil and, if you don't rely on SQL replication for your model store, you can get a very similar effect by deleting the Primary Key index defined for the table ModelSecurityPermission (DISCLAIMER: This requires tinkering directly with the SQL schema, so it's only advised for experimental use. For all production scenarios, please apply the hotfix in completeness.) The hotfix is different and a little bit more involved since it redefines a PK for the table, to ensure that replication is still possible, while maintaining the best possible query plan. The hotfix will be part of the upcoming CU6 release for AX2012 R2.

Note: when you've applied the hotfix, you need to run "axutil schema" against the model stores you want updated.

With this fix, we're addressing the loss in compile speed that surfaced with the R2 release, relative to AX2012 RTM. With that one done, we're continuing the pursuit of other improvements. Stay tuned...

First off, it’s important to recognize that AX is single threaded in nature. Only one element is being compiled at a time and since compilation process is exercising all three tiers of the architecture (client, AOS and model store), it is extremely bound to the execution speed of each of these tiers and in the communication between them. The size of the application will also affect the compile time proportionally.

Now with this premise, the differences we’re seeing are starting to make sense. Turns out that to minimize the “friction” and thus optimize compile performance, proximity of the three tiers is the most significant. This can be achieved through colocation so more of the involved components are running on the same machine. The more the merrier. This of cause with obvious limitations like saturation of the machine etc. The fastest compile is typically achieved by creating a “1-box” setup: SQL, AOS and Client on the same machine. This limits network impact between the tiers, which has a dramatic impact on the compile time.

When creating a 1-box setup it’s important to manage the saturation of the box. Since SQL Server is a server product, unless instructed, it will take over the box to optimize SQL performance. The main limitation to incur on SQL is how much memory it uses. If the box has 16GB memory, allowing for 4GB SQL memory looks like a good setting. With an 8GB box, 3GB seems to be the sweet spot for optimal compile in our tests with an 8GB VM on a single 3.6GHz XEON processor, 4 + HT core host, with standard 7200rpm SATA disk. On such a VM, compile times for RTM out of the box showed to be one hour and fifty minutes. Note that these are ad hoc measurements with every possible caveat, so we’ll be working on real reference numbers for different topologies.

Back to tuning again…. Then there’s the SQL IO. We are reading and writing a lot, so SQL is benefitting from fast disks. Whether 10.000/15.000rpm disks, SSD or even RAM disk, it will improve, but results vary a lot and generally shouldn’t be the first place to tune. However, once you start really tuning, this might be interesting. Similar for SQL Server connectivity where local systems can communicate faster through shared memory than through TCP. We have no solid quantification of the gains from this particular tuning at this point, but some system configurations might deprive SQL from choosing the most optimal configuration, so it might be worth checking those configuration options, when you want to take tuning to the next level.

So what’s the big problem - less than two hours is not that bad? Well, many of us are driving for virtualization of machines to get simplicity in our deployments and leverage the investments better. This calls for massive scale servers and those servers are typically equipped with extensive multi-core processors. However, these are typically not running at the same high clock-frequencies as those with less cores (no over-clocking, turbo, …). With the compile time being very connected to the clock frequency, these servers will yield worse compile times than many laptops, despite their sophistication in architecture, scalability and IO. In essence, they are massive, but slow. With AX2012RTM and R2, there’s a good reason to think of this when creating your build machine. Small and nimble still beats big and slow.

One problem remains – the compile necessary when shipping models to other environments. With the freedom of not having to deal with element IDs between vendors came a need to compile in the scenarios where we add new/changed models to an environment. If that happens on a server-grade machine (with slower cores) and with multiple tiers involved, we’re back at paying the big price for the compile. The recommendation here is to leverage the customer test system instead of the production system and ensure that the test system supports as close to “1-box” setup for the particular task of compiling the application after model install. Then when the test system is compiled (faster than the production system could do it), the whole model store is moved to the production system, which would also allow for very quick switch over to the new application. The ALM papers for AX2012 describe staging in quite some details on how to baseline systems to allow all this.

While all these tips can bring down compile time for many, they are not the end of the story. We continue our work to improve this and ensure that we can provide as much efficiency as possible, through new tools, instructions and product fixes and changes. We will need a way to handle the ever growing code base in a productive way. As a side note to those working with R2, we’ve lately identified the cause for a quite significant degradation of compile performance for R2, which is going to be addressed by a hotfix being made available within the next very few weeks. And the work continues on.

A few white papers that might be of interest in this context:

1)     Change management and TFS integration for multi-developer projects:

                https://technet.microsoft.com/EN-US/library/jj713631.aspx

2)     Deploying Customizations Across Microsoft Dynamics AX 2012 Environments:

https://technet.microsoft.com/EN-US/library/hh292604.aspx

Feel free to share your own tuning results here as comments.

Jakob on behalf of the X++ compiler team.

Amongst the most significant improvements are:

1. Performance - leveraging the x64 architecture and multi-threading, we get 40-50% improvements in execution time.
2. Better optimization of the sequencing for EDTs, Queries and Views, making the import faster.

We'll be writing more about using CombineXPOs later, but for now you can get the beta version of the "Microsoft Dynamics AX2012 Combine XPO Tool" here:

https://informationsource.dynamics.com//RFPServicesOnline/Rfpservicesonline.aspx?ToolName=Microsoft+Dynamics+AX+2012+Combine+XPO+Tool+Beta+1.0

One thing that can only be underestimated is the value of having a heartbeat for your product. The heartbeat provides a regular rhythm to your engineering process, ensuring that the state of the product is well-known on an ongoing basis. A heartbeat consists of many different parts, the build process being one of the most prominent ones. When working with AX, how are you going to get this heartbeat? It all depends on how advanced your engineering practices are.

In this blog post and some to follow, I’ll talk about the purpose of a heartbeat and show how to establishing various levels of automation, including a nightly build and tools/techniques we can use to optimize the engineering system when we have a nightly build. My examples are going to be focused on AX 2012, but many of them apply to AX 2009 with little or no change.

Let’s look into the specifics for the two extremes of engineering systems I see used:

1. Opportunistic shared one box development – one or more developers share AOS and database. What is on this shared machine defines the product at any given time.
2. True distributed development – external version control system as your universal truth and every developer has their own local setup.

For (1), the basic heartbeat is making sure that what you have is in the right shape. When I say shape in this context, it’s typically fundamentals like “does it compile?” “Are we consistent with the best practices?” Sometimes it extends into “do our unit tests pass?” Multiple people working real time on a shared server will leave us with a frequent consistency issue. A heartbeat for such a system will likely have to be timed to the project schedule as the system will be in a more or less broken state for parts of the development as someone will always be working on something new and unfinished. The value of a daily run depends largely on the ability the team has to filter noise from true failures. We’re going to look at the individual tools necessary to orchestrate the automation, but we cannot generally solve for the ad hoc nature of this kind of concurrent engineering.

For (2) it’s a somewhat more formal process, ensuring that what we have under version control will actually turn into a product when we put it all together. It is also a process that has the potential to deliver output to streamline the daily system setup for development and test.

There are no specific requirements around the frequency of the heartbeat – as with many things in life it’s about balance. Don’t go overboard with too high a frequency as you will probably spend too much time maintaining a system that will not provide enough value back iteration by iteration. Don’t make frequency too low either as issues will accumulate (snowball) and you will only realize when you’re already in too deep. A daily heartbeat – typically referred to as “the nightly build” - can satisfy most.

Before venturing into the details, I’d like to run down a practice that I consider non-negotiable for a successful heartbeat:

The product builds cleanly. While we can have large arguments about whether a certain class really needs to compile when the customer is not using that functionality, it’s just a dead end conversation. It is only going to be more costly in the future if you have
broken code sitting around. If you have part of the code base you don’t want to deal with functionally, you should do what it takes to make it compile and make sure it throws an exception if ever called anyway. Go ahead and comment out offending code you don’t want to fix up, but make sure it compiles and make sure that even if someone else changes the system to call this code (trust me – happens too often), it will fail visibly and with good diagnostics. This includes all test assets in the product by the way, so since you’re adding unit tests (wink-wink), these need to compile cleanly too!

Then there’s a set of practices, which I favor, but where your individual approach will have to weigh in:

Unit tests execute successfully. At least they need to execute and when you’re really at it, they should be successful.

Code is well written and complete. Ensure that best practice tools are leveraged to maintain high code quality. With a well-established heartbeat you might even introduce a set of rules that you apply after the fact to increase your due diligence, but where you don’t want to burden every developer with them as they do the change. These baby-sitter tasks are a great source of quality improvements when you have an automated engineering system.

Enough said - now let's get to it! The first level of automation we’ll look into is the compile. This is helpful regardless whether you’re running on a shared environment or on your own. The main purpose is to ensure that we know the syntactical state of the application. Typically, this is what you do by choosing compile from the AOT root node, but for automation purposes, this process can be executed from the command line using the following command:

ax32.exe -startupcmd=compileall -development

By adding -development, we save a few cycles otherwise used to setup the application workspace, main menu etc. In the big picture it’s not much of a difference, but no reason not to take it. As the compile process is extensive and takes a good while to complete, we want to cut all the excess we can. Ensuring that you’ve disabled VCS (if using a file based one) is another way of saving some time during compile. At some point, I'll post about what can be done with respect to the hardware and configuration to generally optimize the execution. To give a sense of what’s to expect, a full compile with warning level 3 set in development options and an application that is about 20% larger than SYS alone, takes around 4 hours to complete on a Hyper-V VM  configured with 2 cores/6GB/one virtual disk on an aging 2.3GHz XEON workstation with 7200 rpm SATA-3 disks. This is not a very sophisticated setup (no RAID, no ultra-fast disks, tons of memory, etc.), so there’s quite some headroom for improving the times. As comparison, a top of the line server can accomplish this in less than 40 minutes due to its efficient I/O system. But unfortunately that’s not the box under my desk…

When the process completes, it will have written a log file with the results of the compilation. The log file can be found here:

"%userprofile%\Microsoft\Dynamics AX\Log\AxCompileAll.html"

The log file will list errors, warnings and best practice deviations. By creating a simple cmd file with the command, it can be executed at given scheduled intervals. There are many obvious additions to this basic script. As an example, you could copy the log file to some archive directory adding the current date to have a history of logs. Or you could send off the result as email to yourself or to the team. Also, only a little magic is needed to decipher the actual result of the build from the build log and paint the mail red or green depending on the result. Once you have the basic script going, you’ll quickly find ways to improve your engineering automation.

With this simple automation we've established the basic heartbeat of our application development. Many other parts are needed to complete the picture. I’ll share some insights on those in later posts.

While this blog has been sleeping for quite a while, the topics discussed these last few days have called for a revival. With the conference behind us, we’ll get going on tips, tricks and links to help deal with the complexities of building quality applications and managing the development cycle and environment.

Also, once again, thanks for the huge contribution from everyone attending our sessions and taking the time to talk to us in the breaks.

On behalf of the AX Tools folks.

Jakob

But you can jumpstart your product and technology learning and planning by attending three days of deep technical content delivered by Microsoft leaders and technology experts. This is your chance to learn, get inspired, and see how Microsoft Dynamics AX can help you provide innovative solutions for your business.

https://www.microsoft.com/dynamics/DynamicsAXtechnicalconference2011

Who will attend?

• Developers building and implementing solutions on Microsoft Dynamics AX. Understand how you can be more productive and provide innovative vertical solutions. Understand the philosophy behind the model-driven design and the service-based architecture built on the foundation provided by the Microsoft .NET Framework.
• Technical Implementation Consultants can learn about the simplification of the deployment architecture, and integration with the Microsoft platform components like Microsoft SharePoint 2010, Microsoft SQL Server 2008 R2, Microsoft Visual Studio 2010, and Microsoft Office 2010.
• Functional Implementation Consultants can get a jumpstart on the massive innovation and expansion of horizontal and industry functionality.
• Customers can benefit by understanding the evolution of the technology and functionality and can plan their upgrade.

The event is on the Redmond campus, running from January 17 through January 20, 2011.

Why should you attend?

• Get hands-on experience with the upcoming release of Microsoft Dynamics AX.
• Talk directly to the team building the product.
• Network and learn from other partners and customers to plan your upgrade.
• Get a pre-release version to continue your learning and development when you get back to the office.

The new Microsoft Dynamics AX adheres to the needs of your people and the demands of your industry.

Join our community. Learn. Inspire. Innovate.