Name is Anant Dubey and the intent to create this blog is to discuss the problems and issues that developer face in the dynamics AX development and to share the new things that come up with the new version of AX.

Wednesday, 18 November 2015

Event Handling in Microsoft Dynamics AX 2012

Today, I am going to talk on the event handling mechanism in Microsoft Dynamics AX 2012. With the event-handling mechanism in Microsoft Dynamics AX 2012 you can lower the cost of doing development and then upgrading these customizations.
Events are a simple and yet powerful concept. In daily life, we encounter with so many events. Events can be used to support these programming paradigms.
  • Observation: Generate alerts to see exceptional behavior.
  • Information dissemination: To convey information to right people at right time.
  • Decoupling: The consumer doesn’t need to know about the producer. Producer and Consumer can be sitting in totally different applications.
  • Terminology: Microsoft Dynamics AX 2012 events are based on .NET eventing concepts.
  • Producer: Object to trigger the event.
  • Consumer: Object to consume the event and process logic based on the event triggered.
  • Event: An action that needs to be triggered
  • Event Payload: Information that can go along with event.
  • Delegate: Definition that is passed to trigger an event. Basically, communicator between producer and consumer
Things to remember while using Events in AX2012
  • Delegate keyword to use in delegate method.
  • Public or any other accessibility specifier is not allowed in a delegate method.
  • Delegate Method return type must be void.
  • Delegate Method body must be empty.
  • A delegate declaration can have the same type of parameters as a method.
  • Event handlers can run only on the same tier as the publisher class of the delegate runs on.
  • Only static methods are allowed to be event handlers.
  • Delegate method can’t be called outside class. Basically, events can’t be raised outside class in which event is defined.
  • Event handlers for host methods can use one of two parameter signatures:
    • One parameter of the type XppPrePostArgs. Go through all the methods available in XppPrePostArgs.
    • The same parameters that are on the host method that the event handler subscribes to.
Now, let’s talk about how to use events in Microsoft Dynamics AX 2012.
  1. Let’s create a class Consumer to create EventHandler (sendEmailToCustomer). This will be called once order is shipped so that email can be sent to customer to notify. It has to be static method.
  2. Now let’s create Producer class where this event (sendEmailToCustomer) is called using Delegates. Add delegate by right clicking on Producer class > New > Delegate.
  3. Change its name to delegateEmail (you can have any name). Parameter should be same as event handler method (sendEmailToCustomer) i.e. of type Email. Notice it has no body and is a blank method.
  4. Now drag and drop sendEmailToCustomer method from Consumer class to delegateEmail
  5. Look at properties of EventHandler. You will notice it is pointing to Class Consumer and method sendEmailToCustomer
  6. If order is not shipped, I am creating another event handler (errorLog) in Consumer class to log error into error log.
  7. Create another delegate method (delegateErrorLog) in Producer class to call this event handler (errorLog)
  8. Drag and drop event handler (errorLog) in delegate method (delegateErrorLog) similar to step 4.
  9. Now let’s create main method in Producer class to ship order and let’s see how delegates can be used to trigger event handlers.
  10. Suppose shipOrder method returns true. Now, if I run this main method, it should go into delegateEmail method and should trigger method sendEmailToCustomer. Let’s run and see the result.
  11. Here is the result and it is as expected so it did trigger method sendEmailToCustomer.
  12. Let’s suppose shipOrder method returns false. Now, if I run this main method, it should go into delegateErrorLog method and should trigger method errorLog. Let’s run and see the result.
  13. Here is the result and it is as expected so it did trigger method errorLog.
  14. Handlers can also be added or removed
    Add Handler: It uses += sign.
    Remove Handler: It uses -= sign.
  15. Now, let’s use addStaticHandler in main method. If you see the code, it is calling addStaticHandler before calling delegate method. If we run it and see the result, it should send 2 emails.
  16. Here is the result as expected.
  17. Similarly if we use removeStaticHandler method instead of addStaticHandler before calling delegate method then it will remove handler and will not send any email.
So, you can see that with the use of delegates and event handlers, it is so easy to trigger events. Also, it will be easy and less time consuming to upgrade it. Suppose if delegates are called from standard methods while doing customizations then it will be so easy to upgrade if standard methods are changed in next release because only 1 liner code of calling delegate method needs to be rearranged and no changes will be required in event handler methods.
Use of Pre and Post event handlers
In Microsoft Dynamics AX 2012, any event handler method can dropped in other method. If the property "CalledWhen" is set to "Pre" then it becomes pre event handler. If it is set to "Post" then it becomes post event handler. Pre event handler is called before the method under which it is dropped and Post event handler is called after method ends. These are so powerful that event handler method can be created in new class and can be dropped in any standard or any other method without changing a single line of code and can be set as pre or post event handler as per business need. Suppose, before creating a customer in AX, business need is to do some business logic then logic can be written in pre event handler and can be dropped in insert method of CustTable. Similarly, if there is post logic to be written after customer is created then post event handler can be created and dropped in insert method of the Customer Table (CustTable).
Let’s see how pre and post event handler methods can be created and used.
  1. Let’s take same example. I added 2 event handler methods in Consumer class.
  2. Drag and drop both these event handlers in method sendEmailToCustomer
  3. Set property "CalledWhen" to Pre for EventHandler1 and Post for EventHandler2.
  4. Now let’s run main method of Producer class again and see the results. It should call EventHandler1 and then sendEmailToCustomer and then EventHandler2.
  5. Here is the result as expected.
With use of events, it has opened so many doors and possibilities. Model architecture and events can be integrated which can help if multiple vendors are doing customizations in different models so that it doesn’t impact customizations of other models/vendors. Use of pre and post handlers is so powerful that it can be used without changing a single line of code in original method. Pre or Post handlers can be just dropped in the original method and will be called automatically before (pre handler method) or after (post handler method) original method.
Stay tuned for more technical tips on Microsoft Dynamics AX 2012.

Tuesday, 17 November 2015

How to call .exe (executable) file through code in ax 2012

Here I am calling .exe file through AX 2012. What I have done in this is created a Crystal report of AX and make it in .exe format. Now I am calling this through AX 2012 R3.

static void Callingcrystalreport(Args _args)

Generate Report through code in ax 2012

In this post I am trying to automatically save report to any format in the shared drive.
report is generating based on parameters, after this we can check in the drive that report is stored in the drive.

static void GenerateReportThroughCode(Args _args)
    S3_WHSVariantTable        S3_WHSVariantTable;
    InventItemBarcode         inventItemBarcode;
    ReportRun                 reportRun;
        select inventItemBarcode where inventItemBarcode.itemBarCode == '4015400548485';
        reportRun = new ReportRun(new Args(ReportStr(S3_DP_RetailLabel_BN)));//where S3_DP_RetailLabel_BN is Morphx Report
        // reportRun.args().object(List);
        // reportRun.printJobSettings().outputToClient(true);
        // reportRun.printJobSettings().clientPrintJobSettings();;

Monday, 21 September 2015

Debugging in Microsoft Dynamics AX 2012 [AX 2012]

In Microsoft Dynamics AX 2012, development can be done in both X++ and .NET managed code. The development environment you use is either the MorphX Integrated Development Environment (IDE) or the Visual Studio IDE depending on the type of development you are doing.
Because X++ and .NET development are integrated, debugging may require that you use the Microsoft Dynamics AX debugger and the Visual Studio debugger depending on your development scenario. This topic provides an overview of common debugging scenarios and information about which debugger to use.
These debugging scenarios include the following:

X++ Code

The process for debugging X++ code varies depending on whether you are debugging standard X++ code or X++ code that is executed in Common Intermediate Language (CIL).

Gg860898.collapse_all(en-us,AX.60).gifStandard X++ Code

To debug X++ code, you use the Microsoft Dynamics AX debugger. This is the full-featured debugger that is part of the MorphX suite of tools. You can use this debugger to debug X++ code that:
  • Runs on the client
  • Runs on the server and is not executed in CIL
To debug X++ code, you set a breakpoint in the MorphX code editor. When you run the code, execution stops at the breakpoint and the Microsoft Dynamics AX debugger opens. You can continue to step through the code in the debugger. For more information, see Microsoft Dynamics AX Debugger.

Gg860898.collapse_all(en-us,AX.60).gifX++ Code that Calls runAs

In X++, you can use the runAs function to call a static method and specify that it is executed in CIL. You can only use this command to run code that runs on the server. Because the method runs in CIL, you must use Visual Studio to debug it.
The high-level process for debugging code called from a runAs function by using the Visual Studio debugger is as follows:
  1. Open your X++ code in the MorphX code editor and set a breakpoint on the line of code that calls the runAsfunction.
  2. Open Visual Studio. Use Application Explorer to open the X++ source code called by the runAs function and then set a breakpoint.
  3. In Visual Studio, attach the debugger to the server process (Ax32Serv.exe).
  4. Run the code in MorphX or step through the code in the Microsoft Dynamics AX debugger.
  5. When the breakpoint is reached in the source code that is running in CIL, context switches to Visual Studio and you can continue to step through the code.
When you debug code that is called by the runAs function in Visual Studio, you cannot change the X++ source code in the Visual Studio IDE. You must make the changes in X++, and then do an incremental CIL build to regenerate the .xpp files.

Gg860898.collapse_all(en-us,AX.60).gifCreate the .xpp Source Files

An .xpp file contains the X++ source code for one method of a class or table that is in the AOT. The Visual Studio debugger uses .xpp files when you debug X++ that has been compiled to CIL.
The generated .xpp files are stored in a directory path that might resemble:
 C:\Microsoft Dynamics AX\60\Server\Microsoft\bin\XppIL\source\
You prompt the system to create all the .xpp files by following these steps:
  1. Start the Microsoft Dynamics AX Server Configuration Utility.
  2. On the Application Object Server tab, select the check box that is labeled Enable breakpoints to debug X++ code running on this server.
  3. Restart the Application Object Server (AOS). The XppIL\source\ directory is created and populated.
Thereafter, the .xpp files that correspond to new or modified X++ methods are refreshed on subsequent compiles to CIL.

Managed Code

When you use managed code to develop applications for Microsoft Dynamics AX, you can:
  • Call managed code from X++
  • Call X++ code from managed code
The debugging process varies depending on whether you start debugging from the MorphX IDE or from the Visual Studio IDE.

Gg860898.collapse_all(en-us,AX.60).gifDebugging from MorphX

A common development scenario is calling managed code from X++. In order to do this, you create a managed code assembly in Visual Studio and add the assembly to the model store by using Application Explorer. After you have added the assembly project to the model store, the assembly classes are available from X++ code.
To debug managed code that is called from X++, you use both the Microsoft Dynamics AX debugger and the Visual Studio debugger. The high-level process for debugging from the MorphX IDE is as follows:
  1. Open your managed code in Visual Studio and set the breakpoints.
  2. Attach the Visual Studio debugger to the Microsoft Dynamics AX server (Ax32Serve.exe) or client (Ax32.exe) process.
  3. In the MorphX code editor, set the breakpoints, run your code, and use the Microsoft Dynamics AX debugger as you would typically.
  4. When code execution switches to managed code, context switches to the Visual Studio debugger. When you are finished stepping through managed code, control returns to the Microsoft Dynamics AX debugger.

Gg860898.collapse_all(en-us,AX.60).gifDebugging from Visual Studio

Before you can call X++ code from managed code, you must first add the managed code project to the model store. After you have done this, you can then use Application Explorer to add elements from the Application Object Tree (AOT) to a Visual Studio project.
To debug X++ code that is called from managed code, you use both the Visual Studio debugger and the Microsoft Dynamics AX debugger. To simplify the debugging process, you can use the debug properties on the .NET project. After you set these properties, the Visual Studio debugger will automatically attach to the correct Microsoft Dynamics AX process (server or client), call the X++ code that you specify, and stop at the breakpoints that you have set.
The high-level process for debugging from Visual Studio is as follows:
  1. In the MorphX code editor, set the breakpoints in X++.
  2. Open your managed code in Visual Studio. Make sure that the debug properties are set correctly on the project.
  3. Press F5 to run the project.
  4. When code execution reaches a breakpoint in X++ code, context switches to the Microsoft Dynamics AX debugger. When you are finished stepping through X++ code, control returns to the Visual Studio debugger.
Instead of setting the debug properties on the .NET project (which causes the Visual Studio debugger to automatically attach to the appropriate Microsoft Dynamics AX process), you can manually attach the debugger to the process.
For more information about how to debug managed code, see Walkthrough: Debugging a Managed Code Event Handler.


A service in Microsoft Dynamics AX is an X++ class that you expose as a service by adding attributes to the class and its methods. Services that you create in Microsoft Dynamics AX are compiled into CIL and run on the server. Therefore, you must use the Visual Studio debugger to debug them.
While you are developing a service class in X++, you can use the Microsoft Dynamics AX debugger to debug the functionality. To debug the code that calls the service, you then use Visual Studio.
The high-level process for debugging a service from Visual Studio is as follows:
  1. In Visual Studio, open the project that calls the Microsoft Dynamics AX service.
  2. In Application Explorer, locate the service operation that you are calling and open the source code.
  3. Set a breakpoint in the service code.
  4. Attach the Visual Studio debugger to the Microsoft Dynamics AX server process (Ax32Serve.exe).
  5. Press F5 to run the project. When the debugger reaches a breakpoint in the service, it will stop and you can then step through the service code.
    When debugging a service in Visual Studio, you cannot change the source code in the Visual Studio IDE. You must make the changes in X++ and then deploy the integration port to regenerate the service .xpp files.
For more information about the Visual Studio debugger, see Debugging in Visual Studio.


SQL Server Reporting Services is the reporting platform for Microsoft Dynamics AX. The report development environment is integrated into Visual Studio. You can debug reports using the Microsoft Dynamics AX debugger or the Visual Studio debugger, or you can create a job to verify the data that should be generated for the report. For information on how to configure debugging reports, see How to: Configure the Debugger to Debug a Report Data Provider Class. The tool that you use depends on the reporting solution.
Use the Microsoft Dynamics AX debugger for the following scenarios:
  • Debug a report data provider (RDP) class that is bound to a dataset of a report.
  • Debug a custom controller class for a report that runs within code and print management instructions.
  • Debug a custom UI builder class for parameter dialog solutions.
  • Debug a contract class for dataset generation input controllers.
Use the Visual Studio debugger for the following scenarios:
  • An RDP class that requires pre-processing uses services to call the logic. There are two types of pre-process RDP reports:
    • Reports that require print management because it is assumed that the same report will print to various destinations. Process the business logic once and then print the report to each destination.
    • Reports that require lots of processing time.
      For example, the Inventory Closing report.
  • A contract class that implements the Validate interface or the Initialize interface because it is executed using a service call.
  • Batch reports that require a pre-processed RDP class. When reports run in a batch, the reporting framework code is compiled to CIL.
    If a report in the batch executes an RDP class that does not require pre-processing, Reporting Services will execute the RDP class, and the RDP class can be debugged using the Microsoft Dynamics AX debugger.
  • To debug C# data methods, attach the Visual Studio debugger to a Reporting Services process. Set the target to the .NET 2.0 code type.
Verify a report dataset by using an X++ job:
  • Create a job to verify the report dataset for an RDP class based report. Pass a data contract to the job, call theprocessReport method, and then verify the results.
  • Create a job to execute a query that is used in a report and then verify the data.
For more information about debugging and troubleshooting report issues, see Troubleshooting reporting.

Enterprise Portal

Both managed code and X++ code are used for Enterprise Portal. The C# managed code is used in User Controls that appear on Enterprise Portal pages. The X++ code is used in data sets, tables, and classes that are accessed by Enterprise Portal pages. You can use Visual Studio to debug the C# managed code. You can use the Microsoft Dynamics AX debugger to debug X++ code for Enterprise Portal.

Gg860898.collapse_all(en-us,AX.60).gifManaged code in Enterprise Portal

The high-level process for debugging managed code in Enterprise Portal is as follows:
  1. Configure the Enterprise Portal site to enable debugging.
  2. In Visual Studio, attach the Visual Studio debugger to the Enterprise Portal process.
  3. Add breakpoints to the User Control code that you want to debug.
  4. Display the page in Enterprise Portal that contains the managed code that you want to debug.
For more information about how to debug managed code in Enterprise Portal, see How to: Debug User Controls.

Gg860898.collapse_all(en-us,AX.60).gifX++ code in Enterprise Portal

The high-level process for debugging X++ code in Enterprise Portal is as follows:
  1. Configure the Microsoft Dynamics AX installation to enable debugging of X++ code in Enterprise Portal.
  2. In the Development Workspace, add breakpoints to the X++ code that you want to debug.
  3. Open the Microsoft Dynamics AX debugger.
  4. Display the page in Enterprise Portal that uses the X++ code that you want to debug.
For more information about how to debug X++ code in Enterprise Portal, see How to: Debug X++ Code on EP Pages.

Batch Jobs

Like services that you create in Microsoft Dynamics AX, batch jobs are compiled into CIL and run on the server. Therefore, you must use Visual Studio to debug batch jobs.
Batch jobs are used when you have code that you want to schedule to run at a specific time or in regular intervals. One example is if you have code that performs lots of processing that you want to run when the system is not heavily used. Code that runs as a batch job must be contained in a class that extends the RunBaseBatch class. For more information, see RunBase Framework.
The process for debugging a batch job is similar to debugging a service. When you create your class in X++, you can use the standard Microsoft Dynamics AX debugger. To debug a class that is running as a batch job, you then use the Visual Studio debugger.
The high-level process for debugging a batch job from Visual Studio is as follows:
  1. Open Visual Studio. In Application Explorer, locate the batch job class and open the source code.
  2. Set a breakpoint in the code.
  3. Attach the Visual Studio debugger to the Microsoft Dynamics AX server process (Ax32Serv.exe).
  4. In Microsoft Dynamics AX, schedule the batch job that calls your class to run.
  5. When code execution hits the breakpoint that you set, the context switches to Visual Studio and you can continue to step through the code.

How to debug batch jobs and service operations?

All the batch jobs and service operations now run in the managed code (IL) and therefore breakpoints set in x++ do not get hit as expected! Instead you should be setting breakpoints in the IL code in Visual Studio. Here are the steps you would be following to do so:
1. Open Visual Studio as an Administrator and go to Tools > Options > Debugging > General. Make sure “Enable Just My Code (Managed Only)” is unchecked.
2. Go to Debug > Attach to Process. Click “Select…” and check the appropriate version of the managed code in your case.
3. Check both options at the bottom of “Attach to Process” form. Select Ax32Serv.exe from the list of processes.
4. Load the XppIL source file in Visual Studio now. Make sure you have enabled breakpoints to debug x++ code in the AX Server Configuration Utility. You can find these files under a location similar to the following:
C:\Program Files\Microsoft Dynamics AX\6.3\Server\AxaptaDev\bin\XppIL\source
5. Now set the breakpoint at any of the desired statement.
6. Finally, trigger the batch job or service operation to debug in the AX Client. The breakpoint set in Visual Studio should be hitting now! Make sure to generate IL to reflect the changes in the XppIL source files after updating the x++ code.

Monday, 15 June 2015

Application Object Server (AOS) Services WSDL URI accessible

Performing a service status check for prerequisite 'Application Object Server (AOS) Services WSDL URI accessible'. - Check failed.
When I click on the "Error"link I get the message:
"Resolution: Attempt to access the WSDL port manually by entering the URI http://<SERVER>:/DynamicsAx/Services/MetadataService. ..."
It seems that the port (8101) is missing in the URI the prerequisite checker is trying to access.
If I enter the URI http://<SERVER>:8101/DynamicsAx/Services/MetadataService in the browser it works without any problem.

The rootcause of this issue is, you must have installed .NET Business Connector to resolve some 32/64 bit InstallPath issue.
and The Default Client configuration in this server points to blank WSDL port.
To fix this issue:
1.Open Client configuration.
2.Create a new Configuration for AX and BusinessConnector. Ensure the WSDL port is set to the correct value [Default : 8101].
3.Perform Refresh Configuration to generate WCF Settings.
4.Exit the setup and run it again

Thursday, 11 June 2015

Tips and Enhancements in Dynamics AX 2012

Tips and Enhancements in Dynamics AX


This article is intended primarily for intermediate Microsoft Dynamics AX users who are familiar with X++ andMorphX. The Goal of this article is to help the users by providing the tips and enhancements in the Dynamics AX.
Microsoft Dynamics AX (formerly Axapta) is one among the Microsoft Dynamics ERP primary products. Microsoft has a range of products under the Microsoft Dynamics umbrella (like Navision, Axapta, Great Plains, Solomon, Concorde, Point of Sale, Retail Management System, Customer Relationship Management and etc) that are more applicable for the small, medium and larger business organizations.
X++ is the language used to built Dynamics AX. MorphX is an integrated development environment in Microsoft Dynamics AX that allows developers to graphically design the GUI. MorphX allows access to application classes that are available in the application, by launching the X++ code editor. Microsoft Dynamics AX provides a set of Web sites that give you access to data through web forms which are collectively deployed and accessed from Microsoft SharePoint Enterprise Portal. The development could also be done using Visual Studio.Net.




X++ is an Object Oriented Programming language, also called OOP language. A class is a collection of methods. And subclasses are classes that inherit from other classes by using the keyword extend. In X++, a new class can only extend one other class, multiple inheritance is not supported. If you extend a class, it inherits all the methods and variables in the parent class (superclass).Subclasses enable you to reuse existing code for a more specific purpose, saving time on design, development, and testing. To customize the behavior of the superclass, override the methods in your subclass.


Static modifiers are often used in classes for methods which need to be accessed frequently.
Final Modifier will prevent the class to be overridden. A final modifier on the method similarly cannot be overridden by a subclass.
Abstract Modifier is exactly opposite to Final modifier. The use of abstract classes is a way to force inheritance to make the sub classes use the base class. It prevent the class being declared using new(). An abstract method must be overridden as an abstract method and cannot have a code block. Abstract methods cannot be static.
Display and Edit Modifiers : Usually these modifiers are not present in other languages, they just belong to X++. These modifiers are used in Forms and Reports to edit and display data in the user interface. For more information refer online documentation here

Data Layers

Dynamics AX consists of sixteen application object layers that contain all the elements in the AOT.
Here are descriptions of the application object layers in Microsoft Dynamics AX 2009:
USR – User – Individual companies or companies within an enterprise can use this layer to make customizations unique to customer installations.
CUS – Customer – Companies and business partners can modify their installations and add the generic company-specific modifications to this layer.
VAR – Value-Added Reseller - Business partners use this layer, which has no business restrictions, to add any development done for their customers.
BUS – Business solution - Business partners develop and distribute vertical and horizontal solutions to other partners and customers.
SL1-SL2-SL3 – Certified solutions – Partners certified under the Microsoft Dynamics Industry Solution (MDIS) program distribute their solutions in the SL layers.
HFX – Hotfix – The Dynamics AX team delivers critical hotfixes using the HFX layer.
GLS – Global solution – The Dynamics AX Global Development and Localization team provides a set of GLS layers that contain country-specific functionality for regions in which Dynamics AX is released.
SYS – System – This is the lowest model element layer and the location of the standard Dynamics AX application. Only Microsoft has access to the element definitions at this layer.
The layer-based application object files (AOD files), Some of them have been renamed with a new prefix in different versions of Microsoft Dynamics AX as shown below in the following image.
The four layers DIS / DIP / LOS / LOP from Microsoft Dynamics AX 4.0 have been renamed to HFX / SL1 / SL2 / SL3 in Microsoft Dynamics AX 2009.
The six layers DIS / DIP / LOS / LOP / BUS / BUP from Microsoft Dynamics AX 4.0 have to be renamed to FPK / FPP /SLN / SLP / ISV / ISP in Microsoft Dynamics AX 2012.
AX 4.0 LayerAX 2009 LayerAX 2012 Layer

The six layers HFX / SL1 / SL2 / SL3 / BUS / BUP from Microsoft Dynamics AX 2009 have to be renamed to FPKFPP / SLN / SLP / ISV / ISP in Microsoft Dynamics AX 2012.


There are some functions which have been separated to another modules. Below are the few comparisons to show the new modules added in Microsoft Dynamics AX 2012.

AX 2009 ModulesAX 2012 Modules
General LedgerGeneral Ledger
Fixed Assets (New)
BankCash and bank management
Accounts PayableAccounts Payable
Procurement and sourcing (New)
Accounts ReceivablesAccounts Receivables
Sales and Marketing (New)
Inventory ManagementProduct information (New)
Inventory and warehouse management
Expense managementTravel and expense management
ProductionProduction control
ProjectProject management and accounting
Compliance and internal control (New)

The user interface in Microsoft Dynamics AX 2012 has been changed to be simpler and user friendly at all levels.

Fix for adding a new dimension in Dynamics AX

A very minor fix is required on the following SysDimensionAddWizard class to enhance the dimension functionality in Dynamics AX 4.0 and Dynamics AX 2009. This fix is not required for Dynamics AX 2012.
SysDimensionAddWizard class which runs the Financial Dimension Wizard, it is used for adding a new financial dimension to the system. Number of adding dimensions are controlled by Dynamics AX License key. Make sure you have sufficient licenses for the number of dimensions you are adding to Dynamics AX 2009, Since user defined dimensions are limited to seven.
Standard AX comes with the following three default dimensions:
  1. Department
  2. Cost center
  3. Purpose
In SysDimensionAddWizard class changes are required in its run() and versionControlCheckOut() methods.
Add the code to run() method under the if statement as shown in the below image.DimAX1.jpg
Add the code to the versionControlCheckOut() method as shown in the below image.
After adding the above code, test by adding the dimensions.
Note: There's no limitation on creating user defined dimensions, if you are using Dynamics AX 2012 ,the above fix and code changes are not required.

Data Consistency Check Framework in Dynamics AX 2009

The consistency check framework consists of classes with names ending in "ConsistencyCheck."
The consistency check in Dynamics AX validates only the predefined list of tables for each module. This ConsistencyCheck framework is heart of Dynamics AX. Unfortunately there is no much documentation available online on these topics. The intention is to provide some basic details about these classes.
SysConsistencyCheck Class is the base class which is extended by several classes in different modules. All the classes which are extending it override the run method. In which they specify the relevant table names related to the modules, they are checked by the kernelCheckTable or kernelCheckRecords methods. For more information on theSysConsistencyCheck class and its methods refer online documentation at the following link at
To run the Consistency check go to Basic > Periodic > Consistency check
SysConsistencyCheckJob Class which helps in running and scheduling the Consistency check batch jobs.
The following are ConsistencyCheck classes from Dynamics AX 2009 which gives information about the class hierarchy and the configurations to which they belong.
Class NamesParent ClassConfiguration Key

These are the ConsistencyCheck frame work classes for different modules in Dynamics AX 2009 being covered in the above list.
To know more information on the configurations to which they belong visit this link here.

Minor fix in the below class

LedgerConsistencyCheck class is responsible for validating the General ledger module.

LedgerConsistencyCheck class checks these following tables in the run() method.
List of Tables
  1. LedgerTable
  2. LedgerJournalTable
  3. LedgerTableAlternative
  4. LedgerTableAlternativeTrans
  5. LedgerParameters
  6. AssetLedgerAccounts (Missing)
Add the AssetLedgerAccounts table to the LedgerConsistencyCheck class at end of its run() method as shown in the below image. The accounts for Fixed Assets in chart of Accounts hold references to the data in 'fixed assets in posting profiles'. By including the above table in the class will help to check and improve the data consistency.
The LedgerConsistencyCheck class should look like the above image in AX 2009.
Note : This above fix is not required in Dynamics AX 2012.

Execute Stored Procedure from X++ code

To execute a stored procedure from X++ use the Server method, the Client method does not have permissions. Following is the screen shot of the code from Server method. you don't require any special privileges or permissions to execute a stored procedure. if used other then Server method, a message should appear like this 'Request for the permission of type 'SqlStatementExecutePermission' failed.'
create a job and write the above code as shown in the image.
When creating a table from AOT in Dynamics AX, developers often forget to right click and save the table, specially the developers habituated to SQL Server. There could be column names conflict if not saved in AOT and eventually the changes might be lost and cause other problems.
Note : If creating a table from AOT in Dynamics AX then there will be couple of default columns added to your table like RECIDRECVERSIONDATAAREAID and etc. Make sure to include and insert values into those fields.

Execute external database Stored Procedure from X++ code using ODBC connectivity

This is to show a method to execute external database stored procedures from X++ code. Create a job in AOT with following code. Follow the steps as explained here in the code like replace Server Name, Database name , Stored Procedure name. The below code is executed through the ODBC Connection.
static void execExternalDatabase(Args _args)
    LoginProperty loginProperty;
    ODBCConnection odbcConnection;
    Statement statement;
    ResultSet resultSet;
    ResultSetMetaData resultSetMetaData;
    Counter counter;
    str sql;
    SqlStatementExecutePermission perm;

    loginProperty = new LoginProperty();
    loginProperty.setServer("SERVERNAME Here"); // Replace your Database Server Name here

    loginProperty.setDatabase("DemoDB"); //Replace your Database name here
    odbcConnection = new ODBCConnection(loginProperty); // setting odbc connection here.

     // ODBC Connection to create Statement
     statement = odbcConnection.createStatement();

    // Replace the StoredProcedure you want to execute.
    sql = strfmt('EXEC [myStoredProcedureName]');

    // Set code access permission to Execute
    perm = new SqlStatementExecutePermission(sql);

    // if Stored Procedure has Select query use executeQuery method.
       resultSet = statement.executeQuery(sql);;
       resultSetMetaData = resultSet.getMetaData();
        for (counter=1; counter <= resultSetMetaData.getColumnCount(); counter++)
            switch (resultSetMetaData.getColumnType(counter))
            case 0,1 :
            case 3 :
    catch (exception::Error)
        print "An error occured in the query.";

    // Code access permission scope ends here.
Used a simple select query in the stored procedure and the result will be displayed on the infolog.

Changing the Object IDs

While exporting/importing the .XPO file from DEV to another environment like QA, the object ID's might some times clash in dynamics AX. Then it prompts a message like this object ID is already used and throws an error in the infolog. It doesn't import some of the Objects. The following is the sample provided to show errors and warnings while importing tables.
The Objects like (tables, and Classes) when created, Dynamics AX automatically assigns a ID to each object. Users do think that ID's cannot be changed, but that also can be changed by editing the .XPO file and use find &replace-all so that the existing ID number will be replaced with new ID number in all the places where ever the references are used. It basically changes the ID and UTILOBJECTID in the XPO file. The manual process could some times cause problems. The best way is let Dynamics Ax handle it.
While Importing the XPO files, uncheck the 'Import with ID values' and Select the 'Enable data recovery for tables with changed IDs' under the options as shown in the above image. Dynamics AX automatically assigns the new ID's. It automatically syncs the objects. This process makes easy when importing multiple XPO files related to a project. Rarely you might end up some times with warnings and that could be resolved by investigating.

Using .NET framework directly in X++

This facilitates the developers having knowledge of the .Net Framework. They could use them directly in X++ to enhance the custom features in Dynamics AX.
static void main(Args args)
//  System.DateTime is from .Net Framework
//  This is a sample to show how the Framework can be used along with X++ coding.

    System.DateTime     now;
    str                 getDateStr;
    now = System.DateTime::get_Now();
    getDateStr = now.ToString();
    info("It is now : "+getDateStr);
Developers could also develop and use the custom DLL's designed in Visual Studio 2008. In order to use the Custom DLL, it should be copied to the Dynamics AX installation path 'Client\Bin' folder. Adding references in Dynamics AX to those custom DLL's you can start using them in X++. The default path of deploying the new .Net DLL is as follows
[DRIVE]:\Program Files\Microsoft Dynamics AX\50\Client\Bin
Note : Dynamics AX 2012 only supports the higher version Visual Studio 2010 and .Net Framework 4.0.

Data Migration

SystemSequences in Dynamics AX help to assign different set of numbers to RECID on every table.
There are several methods of migrating data in Dynamics AX. I noticed some issues with the memory, performance and troubleshooting, as typically the memory is managed in Dynamics AX by Kernel (windows system dll).
There are migration tools which also assist in migrating, no doubt they are awesome. But the developers can still migrate data with out using any third party tools. This could be achieved by just using SSIS 2005/2008. This is a very powerful ETL tool which microsoft has already provided. The developers should only know few tricks to handle RECID's and then it is easy to pull data from any Source database and migrate to the Dynamics AX destination database. The developers need to create and sync the RECID number of a table with the NEXTVAL from SystemSequences.
Below is the sample T-SQL code to know the next RECID number for a particular table. The ID of a table can be identified from the table properties.
--The below TSQL code will help to know the next RECID number for a Particular table.

DECLARE @TableIdNumber varchar(150) 
SET @TableIdNumber = 1   -- This ID Number belongs to [Address] table and is provided as a sample.

Select Convert(Varchar(50),NextVal) NextRecID from SystemSequences where name = 'SeqNo' and tabid = @TableIdNumber   
There are few list of ID's provided in the above excel sheet. Test the above code in SQL Server.
Note : Dynamics AX 2012 only supports SQL Server 2008.
These following tables are very important since these are not specific for one module. The entire Dynamics AX depends on these tables and they are used in every module.
VendGroup table contains definitions of all Vendor Groups.
VendTable table contains vendors information for accounts payable.
CustGroup table contains definitions of all Customer Groups.
CustTable table contains the list of customers for accounts receivable and customer relationship management.
DirPartyTable contains all Address of Customers , Vendors and etc, this is also know as Global address book.
The table DirPartyTable contains all the entries in the Global address book. The Global address book stores all the persons and organizations information which are used through out the system.


Proxies are created and generated to call X++ classes and methods in Enterprise Portal.This feature facilitates in providing the X++ code resources available for use in the Visual Studio web application project. There are some predefined proxies available for Enterprise Portal.


The proxies can be found at the root of the development website. (ex. [Drive]:\ Intepub\wwwroot\wss\VirtualDirectories\80\App_code\Proxies\ )
In AOT under the node [Web]-[Web Files]-[Static Files]-[Proxies] you can view all the proxies.
To provide access to the Class mention the class and method names in the editor as shown above. And below is a example provided.
/ Class:[SampleClassName]
After adding it you need to generate proxies, now go to [Tools]-[Web Development]-[Proxies] and Click on Generate Proxies. you will now see new class is added to the Proxies node and a class added to the root directory.
To use the proxy class in C# following Assembly is used
using Microsoft.Dynamics.BusinessConnectorNet;  


The tracing provides the user to identify the time consuming SQL Queries, transactions and different code that executes on AOS. The performance could be measured and unnecessary load and process can be identified and avoidable.
RPC round-trips to server :This lets user to trace all RPC round-trips from client to the server.
X++ method : The calls traces all X++ methods that are invoked on the server.
Number of nested calls : Limits tracing to the specified number of nested method calls.
Function calls : Lets the user to trace all function calls that are invoked on the server.
SQL statements : Lets the user to trace all SQL Server statements that are invoked on the server.
Bind variables : Lets the user to trace all columns that are used as input bind variables.
Row fetch : Lets the user to trace all rows that are fetched using SQL Server
Row fetch summary (count and time) : Counts all rows that are fetched, and records the time spent fetching
Connect and disconnect : This option traces each time the AOS connects and disconnects from the database
Transactions: ttsBegin, ttsCommit, ttsAbort This option lets to trace all transactions that use the TTSBegin, TTSCommit, and TTSAbort statements
There's a detailed explanation on tracing which is provided by Tom Stumpf at the following links at

Performance Analyzer for Microsoft Dynamics

The Performance Analyzer for Dynamics is a tool which collects data from several Data Management Views (DMVs) and enables to
  • Investigate Blocking
  • Investigate SQL statements
  • Investigate Indexes
  • Investigate SQL Server configurations
For more information on this tool visit this site at

Code Profiler

The code profiler is used to calculate the X++ code execution time and the database activity time. When you start a Profiler and stop after execution, the information is stored in the database with the RunID. When you click on the Profiler runs, it will show all the RunID's and the tasks which were executed.
To avoid unnecessary disturbance of several tasks and want to use it for just a special task, you could use the following code. To execute this sample code change the Table Name and Column Name.
// This is a sample to show how to use code profiler for a specific user task.
static void execCodeProfiler(Args _args)
// replace YourTableName with Original Table Name
    YourTableName tableName; 
    Counter counter;

// profile start point.
#profileBegin("Test of profiler")
    while select tableName
    // replace ColumnName with the Orginal Column Name
    info(strFmt("Table name: %1", tableName.ColumnName)); 
    if (counter >= 10)
// profile stop point.

Now you can see the Run ID and other information in Profiler runs screen, basically this type of scenario is used when checking the performance of the object by running several times and checking the duration result.

Kerberos Protocol

Kerberos is a network authentication protocol. Without Kerberos authentication being set up, SSAS reports and SSRS reports will fail to load in the Enterprise Portal.
To verify Kerberos authentication is properly set up use the following command.
setspn –L <account name>   
To verify the HTTP service properly configured use the following command
setspn –L domain\bcproxy 
If the results point to the correct server, then the SPN was configured correctly for the HTTP service.
In all the .odc files, the following value has to be present.
Note : Kerberos authentication has been deprecated in Dynamics AX 2012.


There are around 30 video demonstrations on creating a .moxl reports using VisualStudio.Net at the following link
Note : The classic MorphX reports and .moxl reports are deprecated in AX 2012

TroubleShooting on the Sharepoint Pages

The problems on share point could be attended when you know what kind of error is throwing up. usually the messages are turned off, not to display it to the end user.
To check the log files which are located under the following path for SharePoint 2007.
[DRIVE]:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS
The above image is sample from SharePoint 2007 when a error occur.
The log files are located under the following path for SharePoint 2010.
[DRIVE]:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS
The above image is sample from SharePoint 2010 when a error occur.
Steps to show up the Error messages right on the web page.
Open the web.config for the appropriate web application located under ' [DRIVE]:\inetpub\wwwroot\wss\VirtualDirectories\80\web.config' and change the following values.
Just turn the custom error mode completely off
<customerrors mode="Off" />  ' Add under system.web  
set debug to true.
<compilation batch="false" debug="true" optimizeCompilations="true"> 
set CallStack to true
<SafeMode MaxControls="200" CallStack="true" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">   
After setting the changes reset IIS to reflect the changes done. Now you should see the error messages right on the web page. It will be easy to fix the problem after identifying it.
After fixing the problem change the above value settings back.


Using the Microsoft Visual Studio we could run stress and performance tests on Dynamics AX, there's a load test software available which is known as Application Benchmarking Toolkit for Microsoft Dynamics AX. There are several scenarios available along with sample test cases. The source code is completely developed using C#.
The above image is a sample to show different scenarios from Visual Studio 2008 Solution explorer. The Load Test Software could be downloaded from the following site, certain parameters are required to setup and run it.

Problem solving in Dynamics AX – A quick check-list

Sometimes, when developing, AX doesn’t work as expected, or behaves weird.
Here are some of the things you can try if you run out of ideas, below are some of steps.
Try to Reproduce: You probably already did, but make sure you can reproduce the problem. If it only occurred once, it’s not a problem.
Check your code again:Check your code carefully for errors, and maybe ask a colleague’s opinion.
Compile : Your project might contain compile errors, so compile it to be sure.
Close the debugger: Sometimes, when the debugger is active, AX will keep executing ‘old’ code. Close the debugger to make sure the latest code is executing.
Compile forward :When you have modified a class that is inherited by other classes, you might want to compile forward this class.
Synchronize data dictionary : You may have made changes to application objects that haven’t been synchronized with the database. Open the AOT, right click on the Data Dictionary node and choose Synchronize.
Restart AX client : Simple as that, close the AX client and start it again.
Reset usage data : Go to options screen (AX button > Extra > Options) and click the Usage Data button. Click reset to remove this data.
Check the application event log for clues : Open the event viewer on the AOS to see if the AOS service has logged something in it. Messages here can help you a great deal. You can also check the event log on the database server or your client pc.
Use Internet Search Engine : If you receive an error, just copy and paste it in Internet Search engine. Most likely you are not the only one having that problem.
Check your AX client version: You might for example be connecting to a SP1 application with an SP0 client. You can check this in the about screen: AX button > Help > About. The kernel version indicates the client version, below that is the application version.
Refresh AOD, Dictionary and Data : You can flush cashed information using three option in the Tools > Development tools menu: refresh AOD, refresh Dictionary and refresh Data. This can be useful when you just imported an xpo file, or when you are developing for the enterprise portal.
Delete AUC file : The application Unicode object cache file, if there is one, is located at [DRIVE]:\Documents and Settings\[USERNAME]\Local Settings\Application Data for xp, or [DRIVE]:\Users\USERNAME\AppData\Local for vista. Delete this file while the AX client is closed.
Check if other users are having the same problem : Knowing whether you are the only one that’s having that problem or if it’s a general problem is a big step towards solving the problem. For example, if you alone have the problem, restarting the AOS probably won’t solve it, but removing usage data might.
Check security settings : When only some users have a problem, big changes are that it has something to do with security settings. Security can be set up from Administration > Setup > Security, on the Permissions tab.
Check configuration key setup : Some features of AX won’t work if a configuration key is disabled, be aware of this.
Full compile : Open the AOT, right click the AOT node and select compile.
Restart AOS : Sometimes restarting the AOS solves your problem just fine. If you can, it’s worth the try as this doesn’t take long.
Remove .aoi file : When the AOS is stopped, you can delete the .aoi file from the application files. This file will be rebuilt when the AOS starts.
Check the Log files : There are few logs which are very important to know.
  • AIF Exception Log
  • Windows Event Log
  • endpoint's logs
The AIF exception logs can be accessed in Dynamics AX by going to
Basic | Periodic| Application Integration Framework | Exceptions
Files with client trace are located in Client’s log directory. In default configuration it is set to either
 [Drive]:\Users\Public\Microsoft\Dynamics Ax\Log\
or  [Drive]:\Document and Settings\All Users\Microsoft\Dynamics Ax\Log\
or [Drive]:\Program Files\Microsoft Dynamics AX\6.0\Client\Bin\DynamicsInfologTrace.log


There are differences in Dynamics AX 2009 and Dynamics AX 2012, differences in the modules, user interface, reports and many other features. The X++ MorphX reports are completely deprecated and recomended to use SSRS, The BizTalk adapter has been deprecated and replaced with WCF-compliant Services. As a developer what I see is the scope for development aspect using with Visual Studio.Net has eventually increased in MS Dynamics AX 2012. The goal of this article was to provide some useful tips and help the developers and encourage newbies to get familiarity on Dynamics AX.
There could be similar works found from other sources. How ever the objective of this article is to address the tips & solutions and few differences in Dynamics AX versions. To the best of knowledge know such work was found for matching/reference.

The above attachment file( provides some useful information on all the changes between Dynamics AX 4.0 and Dynamics AX 2009. It was downloaded from the below link as is.
For more information on the new, changed and deprecated features for Microsoft Dynamics AX 2012 refer online documentation at the following link


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)