How to Debug batch jobs and service operations in Dynamics AX 2012

All batch jobs and service operations now run in managed code (IL) and require different debugging steps.  Rather than setting breakpoints within X++, you need to set them within the IL code that corresponds to the X++ code and debug in Visual Studio.

1. Open Visual Studio as 'administrator' and attach the debugger to the Ax32Serv.exe process.
2.  Note that it may also be necessary to change the ‘Attach to’ selection to ‘Managed (v4.0) code’ and make sure “just my code” is unchecked in VS: tools->options->debugging->General
3. Once done, open up the file you want to debug in Visual Studio. All of the X++ code is compiled into IL and can be found in the following directory after deployment: ..\Program Files\Microsoft Dynamics Ax\6.0\Server\AxaptaDev\Bin\XppIL\source\
4. Set a breakpoint in the file you opened.
5. Go to Ax and run the process in batch mode, or execute the service operation. This will end up hitting your breakpoint, provided you set it in the right place.

If you make some changes to X++ code and want those changes reflected in the generated IL code, you need to do the following AFTER you have compiled the X++ code.Once done, your changes will be reflected in your next debugging session:

Dynamics AX 2012 AXUtil.exe command-line utility for models

A new command-line utility, called axutil.exe is used to work with models and model files. You can use this utility to create, export, import, uninstall, and list installed models. You can use the axutil.exe Help for an overview of various commands and parameters used by each command. The setup program uses this utility to install the Microsoft Dynamics AX 2012 application.

Breakpoints in forms button click() method is now operational in Dynamics AX 2012

Great news for the developers, the pain point on Dynamics AX 2009 related to the unavailability of breakpoint in form's button click() method is no longer exist in Dynamics AX 2012. User can insert breakpoint in from's button click method as he can do it in other locations. Traditionally user write 'breakpoint' to debug the code on form's click() method.

Dynamics Ax 2012 - accessing the correct QueryBuildDataSource for a FormDataSource

Traditionally within Forms it has been rather cumbersome to get to the QueryBuildDataSource for a specific FormDataSource within Forms. You had to write code such as this:

public void FormDataSource::init()
{
    QueryBuildDataSource qbds;
    super();
    qbds = this.query().dataSourceTable(tableNum(CustTable));
}

That’s all fine and dandy if you have a simple Form, but on some Forms you might have multiple instances of CustTable, especially with the advent of ReferenceDataSources. In these cases you might fall back to using the name of the FormDataSource to ensure you get the correct QueryBuildDataSource:

public void FormDataSource::init()
{
    QueryBuildDataSource qbds;
    super();
    qbds = this.query().dataSourceName(this.name());
}

This is also problematic in the cases that a different query is applied to the Form, such as in the CopyCallerQuery from a List Page to a Details Page. This makes it all very confusing and difficult, and to tell you the truth, we have a very long method in the kernel that finds the correct QueryBuildDataSource for the respective FormDataSource. The good news is those methods are now exposed to X++!
With Dynamics AX 2012 you can now use the methods “FormDataSource::queryBuildDataSource()” and “FormDataSource::queryRunQueryBuildDataSource()”. The first method will return you the QueryBuildDataSource in the FormDataSource.query(), while the second will return you the QueryBuildDataSource in the FormDataSource.queryRun().query(). There’ll be another blog entry discussing when using each is appropriate, but the short of it is use the first whenever you want to modify the QueryBuildDataSource and have the modification stay throughout the life of the Form (such as adding developer ranges that you never want the user to be able to change). The second should be used when you want to make modifications that will just live for the current “executeQuery” call and will be cleared whenever the user clicks on the “Clear Filters” button.
Want to see any additional APIs? Let us know and we can consider adding them.

Non admin debugging in Dynamics AX 2012

1.) Add the admin to the roles that you want to test. Note that it is ok to leave the admin user in the system administration role.
2.) Open a dev workspace and close the application work spaces.
3.) Set applicable breakpoints.
4.) Create a job with the following line of code and execute: SecurityUtil::sysAdminMode(false);
5.) So at this point the current session is in “non-admin mode”.
6.) Use Ctrl+W to open the application work space. You should notice that few menus / menu items are available
7.) Run the test and any break points set will be hit.

Current constraints / limitations

When SecurityUtil::sysAdminMode(…) is invoked, it is only applicable to the current session. So you must use CTRL+W to open the app workspace; launching a new client will not work.
Since this is scoped to the current session scenarios like run-as are not supported and also services / EP is not supported at this point.

Trade and Logistics training

Such a great side for SCM learning:
Dynamics AX training