Saturday, 19 April 2014

Debugger Shortcut Keys [AX 2012]

Command name
Shortcut keys
Description
Copy
CRTL+C
Copies selected text to the Clipboard
Print
CRTL+P
Prints the contents of the code window
Select all
CRTL+A
Selects all content
Close
CRTL+F4
Closes the active window
Close all
CRTL+SHIFT+F4
Closes all windows
Next window
CRTL+F6
Switches to the next window
Previous window
CRTL+SHIFT+F6
Switches to the previous window

Command name
Shortcut keys
Description
List Breakpoints
CTRL+ALT+B
Activates the Breakpoints window
Enable Breakpoint
CTRL+F9
Enables or disables a breakpoint
Disable all Breakpoints
CTRL+SHIFT+F9
Clears all breakpoints
Toggle Breakpoint
F9
Inserts or clears a breakpoint
Local Variables
CTRL+ALT+V
Activates the Variables window
Show Output Window
CTRL+ALT+O
Activates the Output window
Show Call Stack Window
CTRL+ALT+C
Activates the Call Stack window
Show Watch Window
CTRL+ALT+W
Activates the Watch window
Run to Cursor
CTRL+F10
In break mode, resumes executing code from the current statement to the selected statement (cursor location)
Set Next Statement
CTRL+SHIFT+F10
Sets the execution point to the line of code a developer has chosen
Show Next Statement
ALT+* (asterisk on the numeric keypad)
Move the cursor to the line of the next statement to be executed
Start
F5
Changes the break mode to continue executing code
Step Into
F11
Executes code one statement at a time, following execution into function calls
Step Out
SHIFT+F11
Executes the remaining lines of the function that the current execution point lies in
Step Over
F10
Executes the next line of code, but does not follow execution through any function call
Stop Debugging
SHIFT+F5
Stops debugging

Command name
Shortcut keys
Description
Find
CTRL+F
Searches text in code window
Find Next
F3
Finds the next occurrence of the text being searched for

Saturday, 12 April 2014

Using the Microsoft Dynamics AX Debugger

When a debugging session begins, the Microsoft Dynamics AX Debugger is automatically started by either the Microsoft Dynamics AX Client or the Microsoft Dynamics AX Business Connector, if the debugger has been enabled. For more information about enabling the debugger, see Enabling the Debugger.
All information shown in the debugger is retrieved directly from the client or the Business Connector. The debugger has no connection to the database, the application, or the Application Object Server (AOS).
When you want to debug X++ code, you must first set a breakpoint in the source code by using the code editor in the client. For information about setting breakpoints, see Using Breakpoints. When the code is run and the line where a breakpoint is set has been reached, execution is suspended and the debugger is automatically started. The debugger shows the location in the source code where code execution was stopped.
You can insert, remove, enable, or disable breakpoints in both the code window and the Breakpoints Window. Breakpoints are preserved between debugging sessions.
When the code execution has been stopped at a breakpoint, you can continue, end, or single-step through the source code.
Single stepping commands are:
  • Step Into – The execution steps into the current line if it contains a function or a method call.
  • Step Over – The execution steps to the next line of code in the current function or method.
  • Step Out – The execution steps out of the current function or method.
Run to Cursor executes code until it reaches the location of the cursor in the code window. Conceptually, it is similar to a temporary breakpoint.
Show Next Statement displays the location of the current execution point. The feature is helpful when you have been browsing in other source code windows in the debugger, and the location of the current execution point is not obvious.
Set Next Statement allows the user to choose which line of code is run next. This is denoted by the yellow arrow in the gutter. Choosing which line of code runs next can be done only inside the uppermost method on the call stack.
There are three ways to use this functionality:
  • Position the cursor on the line that you want to set as the current statement, and on the Debug menu, click Set Next Statement.
  • Right-click the line that you want to be the current statement, and on the shortcut menu, click Set Next Statement.
  • Drag the yellow arrow in the gutter of the code window to the line that you want to set as current. A blinking red arrow indicates the line that is the current target of the Set Next Statement action.
You can use Set Next Statement only on lines with executable X++ statements on them—blank lines, lines with only braces or semicolons, and variable declarations are not valid targets.
Shortcut menu items for copying the contents of a debugger window to the Clipboard have been added. You can choose Copy Selected Line(s) or Copy All Lines. The Call Stack, Variables, and Watch windows have this capability. Additionally, in the Variables window you can copy only the Value column by pressing CTRL+C with one or more rows selected. The Copy Selected Lines action executes.
When a row is copied, the text is placed on the Clipboard in the following formats:
  • Variable window format and Watch window format:
<Name text padded to 50 characters with spaces><tab><Value text><tab><Type text><new line>
If the Name text is longer than 50 characters, it is truncated. If the Value text is longer than 2,048 characters, it is also truncated. In the Variables window, the text of the Value column is not truncated if the user chooses Copy Selected Value.
  • Call Stack window format:
<[S] or [C]><4 spaces><Path text padded to 100 characters with spaces><tab><line number><new line>
The [S] and [C] represent whether the code is running on the server or on the client.



Using Breakpoints
In the Microsoft Dynamics AX Debugger, breakpoints allow you to suspend code execution where and when you need to. This allows you to run code until it comes to a breakpoint rather than traversing through the code, line-by-line. A breakpoint does not terminate the code execution, but instead suspends it. When the debugger has reached a breakpoint and the code execution is suspended, the debugger is said to be in break mode.
Breakpoints can be set from both the debugger and the code editor in the client. The effect of a breakpoint is similar to a Stop statement in Microsoft Visual Basic.
Breakpoints are persisted on a per-user basis. For example, if a breakpoint is inserted by user 1, user 2 cannot see the breakpoints that user 1 has set. This is true regardless of where the code with the breakpoint is running.
You can set breakpoints in the debugger and in the code editor.
To set a breakpoint:
  1. Position the cursor where you want to insert the breakpoint.
  2. Click the Insert/Remove Breakpoint icon on the debugger toolbar, or press F9.
When a breakpoint is inserted, in the code editor, the entire line changes color to indicate that there is a breakpoint in the line. In the debugger, a red dot appears in the gutter to the left of the line.
NoteNote
Setting breakpoints can be performed only on lines with executable X++ statements on them. Blank lines, lines with only braces or semicolons, and variable declarations are not valid lines for setting breakpoints.
  • To see a list of breakpoints from the Microsoft Dynamics AX client, click Breakpoints on the Edit menu, or press SHIFT+F9. In the debugger, the breakpoints are listed in the Breakpoints window.
  • To enable or disable a breakpoint, press CTRL+F9, or click the Enable/Disable Breakpoint icon on the debugger toolbar. Disabling a breakpoint is an alternative to removing one. Disabling makes the breakpoint inactive, but it remains in the list of existing breakpoints. There is no need to remove a breakpoint if it might be needed later.
  • To insert or remove a breakpoint, you can press F9, click the Insert/Remove Breakpoint icon on the debugger toolbar, or right-click in the gray margin in the Output window and click Insert or Remove. Breakpoints can also be removed from the Breakpoints window by right-clicking and then clicking Remove Breakpoint.


Saturday, 5 April 2014

Debugger AX 2009

The Microsoft Dynamics AX debugger is a tool that communicates with the Microsoft Dynamics AX Client or the Microsoft Dynamics AX Business Connector.
Use this debugger to debug X++ code that is running on the following:
·         Microsoft Dynamics AX Business Connector
·         AOS
·         Microsoft Dynamics AX Client
Debugging X++ code in the Business Connector is similar to debugging code that is running on the client. The only difference between debugging on the Business Connector and debugging on the client is that the Business Connector has no client window. The client must be used to set the initial breakpoints.

How to: Enable the Debugger
Enable the debugger according to where the code is being executed on a client, a server, or the Microsoft Dynamics AX Business Connector.
Enabling the debugger on the Microsoft Dynamics AX client allows you to debug code that is run on the client. You must first enable the debugger on the client before you enable it on either Business Connector or Application Object Server (AOS).
  • On the Tools menu, click Options.
NoteNote
The debugger can be related to only one instance of Microsoft Dynamics AX at a time. When you simultaneously debug code on two different clients on the same computer, two instances of the debugger are started.
Enable the debugger to debug code that is run by Business Connector.
  1. Enable the debugger on the client, as shown in the previous step.
  2. Open the Microsoft Dynamics AX Configuration Utility. This is a stand-alone utility that manages client configurations:
    1. Click Control Panel, double-click Administrative Tools, and then double-click Microsoft Dynamics AX Configuration Utility.
  3. On the Developer tab, select the check boxes in the Settings area, as appropriate.



Enable the debugger to debug code that is run by AOS.

  1. Enable the debugger on the client as shown in the previous set of steps.
  2. On the computer that hosts AOS, open the Microsoft Dynamics AX Server Configuration Utility, which is a stand-alone utility that manages server configurations but not client configurations:
    1. Click Control Panel, double-click Administrative Tools, and then double-click Microsoft Dynamics AX Server Configuration Utility.
  3. On the Application Object Server tab, select the check box labeled Enable breakpoints to debug X++ code running on this server.

Saturday, 29 March 2014

Label IDs in Dynamics AX 2012

 Dynamics AX handles text localization by using a label ID (e.g. @SYS1234) in code and metadata; the real text is looked up then based on user’s language. .NET developers may recall localization resources and satellite assemblies and it’s indeed a very similar principle.
There are few changes in Dynamics AX 2012 regarding labels, mostly because of the movement of application files to database (model store). Labels are now located in AOT (Label Files node) or – from another perspective – in ModelElementLabel table in database.
New label files are still created by Label file Wizard, but the existing ones are imported and exported in AOT, not as before by direct manipulation with .ald files in the application directory.
This alone is a quite confusing change for many people and even more radical changes were made for labels saved in a version control system.
Version control                                                                                                           
If you create a new label, let’s say in the ABC label file, ID of the new label is @ABCx (e.g. @ABC42). It was exactly the same in previous versions too.
But if a version control is active, it’s different.
In case of active version control, a temporary label ID is created at first. It looks somehow like @$AA1 (I think one temporary label file is created for each user-defined permanent file – sequentially from AA to AB, AC etc.).
This temporary ID is replaced by a “normal” ID (i.e. ID corresponding to the label file name) when inserting to the version control. Label ID is replaced also in code and metadata, but only if these objects are checked into version control together with the label file.
What are these temporary IDs good for? If every developer has his own Dynamics AX environment (as recommended), it’s necessary to guarantee that no duplicated IDs are created on different places. It used to be accomplished by Team Server which centrally assigned individual IDs. The current solution doesn’t require any central component for development; each environment assign label IDs by its own. Only when inserting to version control, permanent label IDs are assigned, which is a serial operation without any risk of ID conflict.
Version control in Label editor
Version control commands are accessible from Label editor. They work similarly as for other objects (labels are saved in version control as good old .ald files), just be sure that the right label file (field Label file ID) is selected.

Potential problems
And what if I don’t check in code and labels together?
Let’s show it by an example:
I create two labels and code using them. Notice that they are temporary IDs prefixed by @$:

I insert the code to version control but I forget the label file:

Code is saved to version control without any change and thus using temporary IDs:

Such code obviously won’t work correctly in other AX instances. But if I check in the code again, now with the label file:

temporary IDs are correctly replaced. You also get an infolog message enumerating changed objects:

Another situation arises if you insert labels to version control, but omit some code. All code not included in the check-in stays the same and continue to use temporary IDs. Fortunately, it’s not difficult to find the right permanent label, because the text of the temporary label is changed to contain such information:

However, the fix must be done manually.
No matter how we achieved the goal, now we can run the code with correct labels:



Tuesday, 25 March 2014

Services in Ax


AX 2012 supports the following three kinds of services:

  • Document services are query-based services that can be used to exchange data with external systems by sending and receiving XML documents. These documents represent business entities, such as customers, vendors, or sales orders.
  • Custom services can be used by developers to expose any X++ logic, such as X++ classes and their members, through a service interface.
  • System services are provided by Microsoft Dynamics AX. System services include the Query service, the Metadata service, and the User Session service.
Application Object Server (AOS) is the Windows Communication Foundation (WCF) service host for Microsoft Dynamics AX 2012 services that are exposed to users and applications on an intranet.


  • To consume services over the Internet, you must host services on Internet Information Services (IIS).
  • Services that are hosted on IIS use the WCF message routing service. IIS routes all service requests to AOS.
  • All service requests are processed on AOS, regardless of whether they originate on the Internet or an intranet. AOS then returns a response to the service consumer via IIS.
  • Exchanges that are configured to use Web services are processed synchronously and therefore are not queued.
  • AX deploys the service that is based on Web Services Description Language (WSDL) to a subfolder of the virtual directory that is associated with the Web site that you provide.