Fr

Due to its interesting capabilities such as nance and

supply chain management, business intelligence and
reporting, project management, and so on, Microsoft
Dynamics is one of the most widely used solutions
adopted by many organizations across the globe.
This book is a step-by-step tutorial that covers elements
from the initial design through to development.
Each concept is fully explained and demonstrated by
the creation of a real-world project. You will learn
some really useful, advanced development techniques
such as extending your code with metadata and
exception handling.
This book is an invaluable tutorial if you are moving from
another ERP system or language, or if you are a technical
consultant with a desire to create efcient functional
designs and business solutions.

Who this book is written for

Acquaint yourself with the decision-making

process to create robust technical solutions
Design extendable data structures using
appropriate technologies
Create code that is reusable from the start,
and avoid time-consuming code refactoring
Understand how and why form logic is
separated into interaction classes

Understand the importance of using patterns

and frameworks
Test and debug your code to check
functionality and performance efciency

$ 59.99 US
39.99 UK

professional expertise distilled

P U B L I S H I N G

Sa

pl
e

P r o f e s s i o n a l

E x p e r t i s e

D i s t i l l e d

Create code that is extendable by other

parties, without modifying your code

Simon Buxton
Mat Fergusson

If you are a software developer new to Dynamics AX

programming or an experienced developer migrating from
an earlier version of Dynamics AX, this book is an ideal
tutorial to help you avoid the common pitfalls and make
the most of this advanced technology. This book is also
useful if you are a solution architect or technical consultant,
as it provides a deeper insight into the technology behind
the solution.

What you will learn from this book

Microsoft Dynamics AX 2012 R3

Programming Getting Started

Microsoft Dynamics AX 2012 R3

Programming Getting Started

ee

Microsoft Dynamics AX 2012 R3

Programming Getting Started
A quick-start guide to developing maintainable and extendable
business solutions with Microsoft Dynamics AX 2012 R3

Prices do not include

local sales tax or VAT
where applicable

Visit www.PacktPub.com for books, eBooks,

code, downloads, and PacktLib.

Simon Buxton
Mat Fergusson

professional expertise distilled

P U B L I S H I N G

In this package, you will find:

The authors biography

A preview chapter from the book, Chapter 1 'Efficient Design and
Development with Microsoft Dynamics AX'
A synopsis of the books content
More information on Microsoft Dynamics AX 2012 R3 Programming
Getting Started

About the Authors

Simon Buxton has worked with Dynamics AX since its earliest incarnations, starting out
as a consultant and developer in early 1999 when Dynamics AX was known as Damgaard
Axapta 1.5.
Simon quickly became a team leader at Columbus IT Partners and carried out one of the
first AX implementations in the UK before joining a new reseller, Sense Enterprise
Solutions, as its technical director. Sense Enterprise Solutions enjoyed a global reach
through the AxPact alliance and Simon was placed as AxPact's technical lead. Simon
played a major role in expanding the company to become a successful Microsoft partner
and was the technical lead on a number of highly challenging technical projects around
the world, from the UK, to Bahrain, to the USA. These projects included developing
solutions for third-party logistics, multichannel retail, and eventually developing an
animal feed vertical, as well as integrating Dynamics AX into production control
systems, government gateways, and e-commerce solutions, among others.
Sense Enterprise Solutions was sold to a major PLC and since then, Simon has teamed up
with Binary Consultants as their technical architect, where he works with some of the
most technically able AX and Microsoft .NET professionals in Europe. Binary
Consultants are involved in the implementation, upgrade, and support of Microsoft
Dynamics AX, the development of add-ons for AX 2012 and AX 7 (under the name
Axponents), and vertical solutions in animal feed.
Simon was the author of Microsoft Dynamics AX 2012 R2 Administration Cookbook,
published in 2013, by Packt Publishing, and was a reviewer on Implementing Microsoft
Dynamics AX 2012 with Sure Step 2012, which was published by Packt Publishing in
March 2013.

Mat Fergusson started his journey into software development in 1998 by studying
software engineering at Sheffield University. After graduating, Mat took to working in IT
infrastructure, quickly progressing from desktop support to infrastructure implementation
and management.
Armed with real-world experience of supporting users and seeing how applications and
infrastructure are actually used, Mat began moving back into full-time application
development, building classic ASP applications at the tail end of the .com boom.
Mat was among the very early adopters of Microsoft's next generation development
platform, .NET. Over the next few years, Mat would develop numerous web applications
and integration projects using VB.NET and later C#, and in 2005, he started developing
mobile business applications built on the Windows CE platform years before the iPhone
made mobile applications ubiquitous.
After completing the first release of an award-winning hosted health and safety mobile
application, Mat decided to gain some broader experience and embarked on a one and a
half year world tour, which saw him broadening both his IT and life skills by working for
the Enterprise Applications division of HP in New Zealand and becoming a certified dive
master in Thailand.
Returning to the UK, Mat teamed up with his old colleagues and between them, they
founded Binary Consultants, where he continues to work today. In the last 6 years, Mat
has continued to refine his .NET development skills in his role as .NET Lead at Binary,
and has been responsible for several highly specialist web applications for the cosmetic
industry in Russia and the rapidly growing online gaming industry in Malta.
In the last 2 years, Mat has started cross training in AX development, an experience that
has helped him directly in writing this book with Simon. Mat's current specialty however,
is the development of .NET applications for Binary's clients that extend the capabilities
of AX by interfacing with the WCF services exposed by the AIF, introducing rich
visualization and interactions that simply aren't possible with the AX client.

Microsoft Dynamics AX 2012 R3

Programming Getting Started
Microsoft Dynamics AX is an ERP solution for complex (single-site and multisite),
multilanguage global enterprises. This flexible and agile solution provides advanced
functionality for manufacturing, retail, public sector, and service sector industries. It
provides not only a strong set of built-in functionality, but also an industry-leading
integrated development environment, allowing an organization to provide even higher
levels of fit. This book should be on the tool shelf of any software engineer who works
with or is about to embark on a career with Dynamics AX.
This book provides software engineers and those involved in developing solutions in
Dynamics AX with clear guidance on best practices, theory, and practical examples
covering broad areas of the Dynamics AX integrated development environment and
surrounding technologies. Even for experienced software engineers, this book will
provide a good source of reference material for efficient software development, helping
your solutions to be easier to maintain, extend, and upgrade through this book's easy-tofollow practical guidance.
In order to facilitate this, the book follows the development of a single solution as a
means to explain the design and development of tables, classes, forms, BI, menu
structures, and security. Concepts such as models, layers, software development patterns,
and frameworks are explained and given a real-world context and perspective using my
experience to point out many traps that lie in wait. This book demonstrates not only how
to write flexible solutions, but also why a design approach was taken.
The structure of this book is designed so that it is useful right from the initial chapters,
without sacrificing the theory that is needed to provide the necessary depth of knowledge
when working with Dynamics AX. By Chapter 4, Creating the User Interface, we will
have a working solution for maintaining data and by the end of Chapter 8, Designing
Your Security Model, we will have covered most of what is required from many
solutions. Although titled "Getting Started," we don't stop with the basics, as we will also
cover advanced development techniques and features that will help even experienced
Dynamics AX software engineers.
The sample solution was designed and developed as this book was written and is
available for download. It was co-developed by two authors who live in different
countries using Team Foundation Server with Visual Studio Online.
With this comprehensive tutorial, you will be armed with the knowledge and insight you
need to develop well-designed solutions that will help your organization get the most
from this comprehensive solution, for both the current and upcoming releases of
Microsoft Dynamics AX.

What This Book Covers

Chapter 1, Efficient Design and Development with Microsoft Dynamics AX, covers a
technical overview of Dynamics AX, models, layers, and the integrated development
environment. This chapter also provides guidance on source control, software
development patterns, and how to minimize the footprint of your solution.
Chapter 2, Preparing Our Solution, provides both the theory and practical steps that are
to be followed when starting work on a new solution. This includes creating a model,
project, and label fi le; configuring source control; and designing the technical solution
and test plans.
Chapter 3, Creating Data Structures, guides us through the creation of the data structures
used for our hypothetical solution, bringing in new concepts such as table inheritance,
extended data types, enumerated types, and referential integrity.
Chapter 4, Creating the User Interface, includes the creation of the user interface, using
standard design patterns for the development of the forms and menu structure. We also
step into writing classes to provide reusable form logic.
Chapter 5, Creating Business Logic and Hooking into Core AX, covers how to handle
table events in a class for easier reusability, adding navigation, and using number
sequences. It also includes how to hook into core AX using eventing and delegates to
minimize the footprint of standard code.
Chapter 6, Adding Business Intelligence, provides practical hands-on guidance for the
creation of parts that are used in AX to give real-time, pervasive business intelligence to
users. These include info parts, form parts, cues, and cue groups.
Chapter 7, Extending the Solution, dives deeper into the solution we have developed,
adding secondary list pages, drop dialogs, and reusable business logic with data contracts,
and exposing business logic to external applications through services.
Chapter 8, Designing Your Security Model, covers the design and development of the
security of our solution, including roles, duties, privileges, and process cycles. We also
cover code access permissions and how to secure data through the use of data policies
(extensible data security).
Chapter 9, Customizing Standard AX, provides guidance on how and where to modify
standard or third-party code without suffering from the maintenance cost associated with
upgrading modified code. Also included is the use of standard frameworks, demonstrated
by an example of vendor electronic payments.
Chapter 10, Advanced Features and Frameworks, demystifies more advanced topics such
as the SysOperation framework, global address book, and financial dimension framework
through clear, practical examples showing how these should be used.

Chapter 11, Advanced Development Techniques, covers date-effective tables, exception

handling, computed columns on views, and controlling which tier our code runs on. We
also step into the world of using metadata, making sense of advanced techniques that
many may shy away from.
Chapter 12, Unit and Performance Testing, includes practical guidance on unit and
performance testing, including how to create automated test plans that help us avoid
the regression that changes often incur. Performance testing and diagnosis are explained
through the use of the code profiler, which covers analysis on both code and database
performance.
Appendix A, Code Editor Scripts, provides information and code samples on how to
extend standard code editor scripts, saving you time while developing code.
Appendix B, More on Version Control, gives additional guidance on the interaction
between version control, models, and layers; how to build your solution; and how version
control works with label files.

Efcient Design and

Development with Microsoft
Dynamics AX
Dynamics AX provides one of the best development environments of any ERP
product. It is often easy to forget, as a software developer, that the purpose of
this environment is to create or extend functionality in order to satisfy a business
requirement. For those moving from a development environment, such as Visual
Studio, to Dynamics AX, it may appear a little restrictive, and for those not used
to a rich development environment, it can appear dauntingly flexible.
The purpose of this chapter is to explain the core concepts of developing or
extending functionality in Dynamics AX, enabling your solutions to be maintainable,
extendable, and to minimize the impact on future updates and upgrades.
In this chapter, we will cover the following topics:

A technical overview of Dynamics AX

Layers and models

The MorphX IDE

Source control option

Patterns and frameworks

The technical architecture of a solution

Minimizing the footprint of customizations

[1]

Efficient Design and Development with Microsoft Dynamics AX

A technical overview of Dynamics AX

At the simplest level, Dynamics AX is designed as a three-tier architecture and
requires three main components to function: a database server, an application
server, and a client.
The database server performs two roles; it hosts both the business database and the
model store database. The database server must be a supported edition of Microsoft
SQL Server.
The application server is referred to as the Application Object Server (AOS) or AX
Server. This provides many services, including web services, to the client Windows AX.
The Windows AX client is the application that the users use to perform their tasks.
It also allows us to access the integrated development environment (IDE).
All requests for application elements (such as forms) and data are made to the
AOS through remote procedure calls (RPC) or the Windows Communication
Foundation (WCF). There is no direct communication between the client and the
SQL Server. All data goes through the AOS; this is fundamental to the design. It
ensures that all of the business logic is common across all clients and enforces data
integrity and security.
The following diagram, which has been recreated from Microsoft TechNet,
highlights this:
Microsoft Dynamics AX Windows client
Application
pages
using
MorphX
forms

Report
viewer
control

Business
overview
Web Part

WCF

Development tools

Report
viewer
Web Part

Visual Studio
MorphX
.NET Business
Connector

RPC

Metadata
service

Custom
services

User session
service

Document
services

WCF
Workflow

Query
service

System services

Application services

AOS services
Application Object Server (AOS)

Business
database

Model store
database

Microsoft Dynamics AX
Microsoft SQL Server

[2]

...
.NET Framework 4.0

Chapter 1

The full details can be accessed at http://technet.microsoft.com/en-us/

library/dd362112.aspx.

The element named Application pages using MorphX forms in the preceding
diagram represents the vast majority of all content viewed within the Windows AX
client, for example, the Sales order details form.
All forms written within the AX client development environment under
the Forms node are MorphX forms; they may include .NET controls such
as Print preview and custom .NET controls.

The client primarily uses RPC for communication between the client and the AOS,
but certain elements within the client use WCF; for example, the Report viewer
control. Applications such as Microsoft Office, SQL Server Reporting Services
(SSRS), and custom applications also use WCF. These applications access services
that are hosted by the AOS.
Much of the complexity is hidden from us, and we do not have to remember every
nuance of the integration between the tiers. Gaining an understanding of the
structure, however, is important.
For example, we will later be writing code that will run on a specific tier (AOS
or client). In this case, it is important to pay attention to where the objects are
instantiated and how they are marshalled between the client and server.

The model store database

The model store is a database hosted by the same SQL server as the business
database. It is always named after the business database and suffixed with _model.
For example, if the database is called MsDynAXLive, then the model store database is
called MSDynAXLive_Model.
This model store contains the application code and metadata. The application code is
stored in both the source code and compiled forms. This means that all objects in the
AOT, such as database table definitions, forms, classes, reports, and Visual Studio
projects, are stored in this database.
There are many benefits of this design, one of which is that it is now more
easily handled as part of our high availability and disaster recovery plans.

[3]

Efficient Design and Development with Microsoft Dynamics AX

Each element (such as a class, method, database table, field, and so on) has an
element ID. These have many uses, which are mainly internal. One such use is for
handling the link between the elements' stored table definitions and the physical
table definition within SQL Server.
The important point here is that we cannot simply assume that we
can use a model store database with a business database that was not
generated from that model store database.

The compiler and CIL

The primary language for development in AX is X++, and it is syntactically similar to
C#. AX compiles code as required to its intermediary language, p-code. This p-code
is AX's native object code and AX will execute most code in this way. The compiled
code stored in the Model store database is p-code.
Microsoft introduced a .NET Common Intermediate Language (CIL) compiler to
AX 2012. This allows AX code to run under the .NET runtime and achieves better
performance. This does not replace the p-code, and is generated from the compiled
p-codenot directly from the source code.
This means we have two sets of executable code, p-code and CIL. The
form-level logic still uses p-code, but some table events and serverside code and all of the code accessed through WCF will run the CILcompiled code.

CIL generation also creates physical DLLs and updates the WCF services (both those
hosted by the AX Service and those hosted by IIS).

Layers and models

The Layers and Models section is taken from the Packt Publishing book, Microsoft
Dynamics AX 2012 R2 Administration Cookbook. It has been amended to suit a software
development audience.
One of the key founding features of Dynamics AX was the ability to modify the
software easily without locking the solution into a version. This was so advanced,
even when the software was first released, that it would often be cheaper and faster
to write the functionality in Dynamics AX than to upgrade the incumbent system.

[4]

Chapter 1

AX not only had an outstanding IDE (the MorphX IDE) but also a solution to
the problem of upgradability, change tracking, and management of solutions
written by various parties; for example, Microsoft independent software vendors
(ISVs)/Partners and the end-user/customer.
The solution to this was the technology called the layer system.

Layers
Layers segregate modifications (or the creation) of an application object's elements
(for example, a field on a table or a control on a form). This allows Microsoft
partners/ISVs and the customer to write a new functionality or change an existing
functionality in a specific layer without directly modifying the standard software or
the software supplied by the partner or ISV.
The following layers are available from the highest layer down:
Layer

Description

USR

The user layer is for end-user modifications, such as reports. It often has changes
written by the development team of the end-user organization.

CUS

The customer layer is for modifications that are specific to a company.

VAR

Value-added Resellers (VAR) can make modifications or new developments

to the VAR layer as specified by the customer or as a strategy of creating an
industry-specific solution.

ISV

When an ISV creates their own solution, their modifications are saved in the
ISV layer.

SLN

The solution layer is used by distributors to implement vertical partner solutions.

FPK

The FPK layer is an application object patch layer reserved by Microsoft for
future patching or other updates. For more information, see Patch Layers [AX
2012] at https://msdn.microsoft.com/en-us/library/aa891248.
aspx.

GLS

When the application is modified to match country- or region-specific legal

demands, these modifications are saved in the GLS layer.

SYS

The standard application is implemented at the lowest level, the SYS layer. The
application objects in it can never be deleted.

This information is taken from http://msdn.microsoft.com/en-us/library/

aa851164.aspx.
Each layer has a patch layer, where SYP is the patch layer for SYS, and so on. The
patch layer is used to ship hotfixes and service packs. A range of tools can be used
to compare and merge code into a higher layer (that is, USR), where it has been
changed by the patch.
[5]

Efficient Design and Development with Microsoft Dynamics AX

Although it may seem logical to use the patch layer for updates to your
system, this actually just adds more work and detracts from its goal of
maintainability. It was sometimes useful before we had models, but with
the model technology, it is used for a different purpose.

The current layer is set in the AX configuration utility, and to use any layer other
than the USR layer, you need an access code, which Microsoft provides as part of
your license.
When a change is made to individual elements (methods, fields, form controls, and
so on), it is copied to the current layer. This copy then hides the element in lower
layers. The compiler does this by looking down at the elements from the highest
layer downas if it were looking through the panes of a glassas shown in the
following image (which is taken from Microsoft TechNet):

[6]

Chapter 1

The exception to this is if we modify an object that is already in a higher layer. In

this case, the change is done in the higher layerif there is any change in the current
layer, it is not used. This is by design; if the change was made in the lower layer, it
would not be used, as it would be masked by the higher layer change.
This means that your changes are protected, allowing you to merge the changes
as required.
Commonly, your partner will develop features or customize AX in the VAR layer,
and the end user (the customer) in either the CUS or the USR layer.
On rare occasions, the customer may use both CUS and USR. One example would
be a global organization that has systems in several countries and employs an
internal development team. In this case, the internal development team will develop
the core system in the CUS layer, leaving the country to develop its own specific
requirements in the USR layer.
Prior to AX 2012, the elements were not shredded to a sufficient level. In other
words, forms were treated as one element and therefore copied in their entirety
to your layer, should you simply add a field to a grid. This posed a problem for
Microsoft because it limited the amount of add-on solutions that could coexist in a
system without a developer merging the code.
This shredding of elements, into individual controls on a form for instance, exposed
another problem for ISVs developing add-ons on AX.
An ISV would write their add-on in a specific layer: for example, SLN or ISV (in the
previous versions, it would be the BUS layer). They would deliver their solution as
an entire layer (which used to be a file ending in AOD) along with labels.
This, therefore, limited the number of ISV solutions you could use within your
implementation without greatly increasing the complexity of implementing them.
The answer to this issue came in the form of models.

Models
Every element in a layer belongs to one model; if a layer does not have a model, the
system will create a default model for it when a modification is made; for instance,
the USR model. These are not normally used and, in my opinion, should never be
used, as we cannot be sure whether this was intended.
A model exists in a specific layer, and elements in a layer can only belong to one
model; this is by design and should not be thought of as a limitation. Thus, a model
is a collection of elements in a specific layer.
[7]

Efficient Design and Development with Microsoft Dynamics AX

If you import an add-on as a model, it will be imported into its original layer.
The only thing you have to do is to synchronize, compile the application, and
regenerate the CIL. This model can also be removed; again, all you need to do is
synchronize, compile the application, and regenerate CIL.
You can then, in your layer and model, make changes to the add-on for your specific
requirements; and when the ISV releases an upgrade, you simply have to import the
model and use AX's tools to highlight the changes that may conflict with yours.
Models have many benefits, and I suspect more than what were initially intended
when designed:
For ISVs, models create the following abilities:

Digitally sign the models

Ship the model in a way that is easy to deploy on their customers' systems

Send patches and upgrades to customers that are relatively easy to apply

For partners, the benefits of models are the following:

Easy alignment with development, deployment, and quality

assurance processes

Simplified deployment of builds during the system's implementation

The partner can more easily use ISV solutions in their offering to their
customers, which allows the partner to focus on their specific value offering

Environments such as live, User Acceptance Testing (UAT), and

development are more easily kept aligned

There are advantages for customers too, which are as follows:

The ability to have more control of their system, where they can choose to
install or remove add-ons with PowerShell commands. Earlier, the customer
could only remove the whole layer and not add-ons within a layer.

Simplified deployment of internally developed solutions

As a side effect of the benefits to ISVs and partners, better value and quality
of implementation are achieved, thereby reducing the risk
Don't fall for the trap of creating a model for each requirement
because even with the object model's shredded control or field
level, you will find overlaps (that is, changes required to a method
across two requirements).

[8]

Chapter 1

In our experience, partner and customer layers typically have the following models.
Typical partner (VAR) models are as follows:

The main functionality model (often named as a prefix and the customer
name, for example, axp<CustomerName>)

Labels

Security roles

Add-on models

Here are the typical customer (CUS or USR) models:

The main functionality model

Labels

Customer-specific security roles

A label file is a dictionary of label codes that that the Dynamics AX
client uses to display labels and text in the user's language.

The reason a label file is in its own model is that the label file is not shredded into
elements, and therefore, all labels in a label file exist in one model. Each party
would normally maintain one label file, which has a three-letter name, and is
therefore limited.

The MorphX IDE

The development environment is accessed from within the Windows AX client,
which is also referred to as the MorphX IDE. It opens a new application window,
tailored specifically for development. This environment is still the AX client,
and forms can be opened and code executed as if it were opened from the main
client window.
The quickest way is through keyboard shortcuts:

Ctrl + D: This opens the IDE, with the Application Object Tree (AOT) open.

Ctrl + Shift + P: This opens the development environment, with the Projects
window open.

Ctrl + Shift + W: This performs an action equivalent to Ctrl + D.

[9]

Efficient Design and Development with Microsoft Dynamics AX

The development environment is structured into the following main components:

Title bar: This tells us which server the client is connected to.

Main menu: This is a classic MDI menu that runs across the top of the
window. There are customization options for some parts of its structure.

Content area: This contains the AOT, Projects window, and code
editing windows.

Properties: This shows the properties of the selected element. It floats when
opened for the first time, but is usually docked to the right.

Compiler output: This appears when an object is compiled. It is docked at

the bottom by default, but can be made to float. It can occupy some of the
valuable content area.

Status bar: This is configurable through your user options. The most
important information shown here is about the company, layer, and
current model.

AOT
The typical centerpiece of the IDE is the AOT. This contains the entire application
code of AX. The following screenshot shows a tree view, which is organized by
object type:

[ 10 ]

Chapter 1

The button ribbon at the top of the window is context sensitive to the selected node,
and in sequence, they are as follows:

Open: This will open the selected object, such as a form. It is actually an
execute action. So, for a table, it will open the table browser, and for a class,
it will try to execute if it contains a static Main method.

Properties: This will open the property sheet. This action can also be done
by pressing Alt + Enter.

Save all: This will save all unsaved elements. This action can also be done
by pressing Ctrl + Shift + S.

Import: This will open the XPO import dialog, allowing code to be
imported into the system.

Compile: This will compile the selected object or node. If a node is

selected, this button compiles all objects within that node. This action can
also be done by hitting the F7 key.
If we click on the compile icon while the AOT node is selected, the
entire system is recompiled. This can take over an hour to complete.

To navigate around the AOT, you can use the mouse, but the most efficient method
is to use the keyboard. The AOT behaves intuitively, that is, the right arrow key will
expand a node and the left arrow key will collapse. Partially typing an object name
will move to that object. For example, to navigate to the table named CustTable
from the AOT node, perform the following steps:
1. Press the right or down arrow key. This will move to the first node,
called Data Dictionary, under the AOT.
2. Press the right arrow key again to expand this node.
3. Press the right arrow key again to move down to the first node, Tables.

[ 11 ]

Efficient Design and Development with Microsoft Dynamics AX

4. Expand the Tables node with the right arrow key, and then press the down
arrow key to move to the first table, as shown in the following screenshot:

5. Start typing CustTable; AX will move the cursor down as you type,
displaying the text typed in the status bar at the bottom of the
application's window.
This may seem quite simple, but it is very important that we are fast at navigating
around the environment so that it is second nature.
We can now look at the property sheet for CustTable. We could use the button on
the AOT window, but this takes time. Instead, use the Alt + Enter keyboard shortcut.
Using keyboard shortcuts is much faster than using the mouse, so
this should always be the preference. You might be slower at first,
but it pays off later.

The following links contain useful shortcuts. You don't need to learn them all, but it
is useful to use the keyboard shortcuts for the commands we frequently perform:

Shortcut Keys: Code Editor [AX 2012]: http://msdn.microsoft.com/enus/library/aa865357.aspx

Shortcut Keys: AOT [AX 2012]: http://msdn.microsoft.com/en-us/

library/aa623612.aspx

The property sheet will show the properties relevant to the current object type, in the
case where the properties are pertinent to a table.
Although these may seem safe to adjust, any change made to any
property sheet is still a modification and will move the object into
your layer and model, even if you change the property back.

[ 12 ]

Chapter 1

We access most of the tasks we perform on an object through the right-click context
menu (or the Windows context menu key). This menu is context aware, and we will
go through this when we perform the task.
The following screenshot is of the context menu for CustTable, accessed by rightclicking on the CustTable node:

Here are some generic options on this menu:

Open: This is not always available, and should be thought of as an execute

command. Its behavior depends on the selected object type:

Tables and Views: This opens a table browser, a grid view form
showing all visible fields and the possibility to edit (beware!).

Table maps: This opens a table browser for fields in the map, but will
show no data. This is of limited value.

Forms: This opens the form as if it were opened from the AX client. It
is useful for testing forms as we modify them.

Classes: This will execute the class if it has the Main static method.
Many have assumed that it would open the code editor.

Queries: This will open the Query tool with the query loaded. It is of
limited use.
[ 13 ]

Efficient Design and Development with Microsoft Dynamics AX

Menu items: This will open the object referenced as if it were opened
from the Windows client.

Jobs: This will execute the job; beware here, as many assume that this
opens the code editor!

View code: This opens the code editor with all methods visible.

Open New Window: This is a very useful feature. It will open a new AOT
window starting from the currently selected node. This is great for the
drag-and-drop functionality.

Save: This will save the changes made to the currently selected object.

Export: This exports the objects from the currently selected node to an XPO
filea file that contains the object definitionso that it can be imported to a
different system.

Delete: This deletes the element at the select level from the current layer.
So, if you change CustTable, you can delete your changes and revert to the
next layer below. This is discussed in more detail in the next section.

Restore: This will revert the selected objects to what is stored in the model
store database, losing unsaved changes. Also, this is useful for loading the
changes made by another developer working in the same system, or to
refresh a form's data source if we add fields to the table it references.

Duplicate: This will create a duplicate of the object. If the object is a table, it
does not copy the data. If the copied object contains static methods, they are
not refactored to the new object name.

Compile: This will compile the current object, or in the case of a node, the
objects within that node.

Find: This will open the Find tool, allowing you to search for an element or
the source code text.

Compare: This opens the Compare tool (discussed in detail later), which
allows you to compare the object across layers.

Add-Ins: This a submenu of options that will be discussed when required.

Properties: This opens the property sheet.

[ 14 ]

Chapter 1

Saving your work

When you make a change to an object in the AOT, AX highlights this with a vertical
red bar, as shown in the following screenshot:

Objects can be saved automatically, based on a timeout in your user options.

This automatic save does not occur while editing the code in the code editor,
which is good.
You can save all unsaved changes with the Ctrl + Shift + S option. This works
everywhere in the IDE except the code editor. This is because the code editor is
actually the code editor from Visual Studio, where this particular hotkey makes
whitespace characters visible.
When the work is saved, AX writes the changes to the model store database. If the
element (for example, a class method) is new, AX will create a unique element ID
for it. If two developers open the same method, the first person to save the method
"wins"; the other developer will be told that the method is newer on the server.
Using the Restore option from the right-click menu will retrieve the version
from the server.

The Projects window

A project is a subset of objects taken from the AOT. This could be thought of as
a painter's palette. Any changes made to an object in a project are not sandboxed
into that project. The change is also made to the same object in the AOT; the project
merely contains references to the AOT object.
There are two types of project: private and shared. Private projects are collections
only visible to the user who created them, and are generally of little use. Some
projects automatically created by AX are an exception to this, as the elements
(tables, methods, and so on) can contain a status indicating whether the object
is complete or not.

[ 15 ]

Efficient Design and Development with Microsoft Dynamics AX

Therefore, all projects we create will be shared. To create a shared project, we follow
these steps:
1. Open the Projects window (Ctrl + Shift + P).
2. Right-click on the Shared node and choose Project, which is under New.
3. This will create a new project named Project1 (if not, it means we have not
given a previously created project a proper name).
4. We should rename this with a suitable name. This is done by double-clicking
on the object (as you do to rename a file in Windows explorer) or choosing
Rename from the right-click context menu. The double-click method is faster.
Naming conventions are critical to getting maintainable code.
These are discussed later in this chapter.

To open the project, simply double-click on it. AX will display a window with a
single node. Elements can now be dragged from the AOT as required.
The next step is to create the project structure. The best structure to use is the same
structure as that of the AOT, as this makes items easier to find. This is done by the
following steps:
1. Right-click on the root node and choose Group, which is under New.
2. Rename this node to be the same as the AOT node we are creating, for
example, Data Dictionary.
3. Open the properties of this node and change ProjectGroupType to
DataDictionary (from the drop-down list), as shown in the following
screenshot. You would then continue this process for the nodes in the AOT.

This is clearly time-consuming. The good practice is to do this

once and name the project ProjectTemplate. Then, simply
duplicate the project every time you need it.

[ 16 ]

Chapter 1

As you change ProjectGroupType, you will see that the icon in the project node
changes to the icon in the equivalent AOT node.
Creating a project and changing the project group type has an additional
benefit; AX now understands that the element contains objects of that
type, and the right-click | New menu will then offer to create an object of
that type.

Source control the options

Source control has become more prevalent with AX development in the last 5 years.
Initially, there was no specific source control with the development environment, but
we survived. This was done through heavy use of comments and adding a dummy
method for the development history to each modified object.
We have had version control for a few versions now, and in AX 2012, it has been
improved further. The source control options we have are as follows:

Source depot

Visual SourceSafe

MorphX VCS

Team Foundation Server (TFS)

What Microsoft recommends here is either MorphX VCS or TFS. We prefer to avoid
shared development and use TFS internally, which is integrated with our project
management methodology.
Microsoft provides a good reference for this in MSDN at http://msdn.microsoft.
com/en-us/library/aa639568.aspx. The following table, taken from the preceding

article, shows the key differences:

Concurrent development

MorphX VCS

TFS

No

Yes

Isolated development

No

Yes

Change description

Yes

Yes

Change history

Yes

Yes

Quality bar enforcement

Yes

Yes

Branching

No

Yes

Work item integration

No

Yes

Labelling support

No

No

[ 17 ]

Efficient Design and Development with Microsoft Dynamics AX

The isolated development feature means that each developer has an isolated AX
environment. The developer's machine (usually a virtual server) would need to be
reasonably powerful in order to run the environment at a suitable speed.
It also has a more involved process; that is, the developer has to check in their work
(which is file-based), and then a build has to be created.
The main advantage of TFS over MorphX VCS is the integration with work items,
which can be used alongside your sure-step agile methodology. We also have an
advantage in that the source is also held in a separate repository.
The MorphX VCS provides features similar to TFS (except branching), but it allows
the development server to be shared by multiple developers. Objects are still checked
out (and therefore locked) and checked in with comments. It also allows the use of
the built-in code compare tool to review the changes between different versions.
This is a simple, yet clever, version control solution, but it also has one drawback.
The version control information is stored in a set of tables in the business database.
This means you lose the version control data if you rebuild the business database
from the live business database.

General development practices

Efficient software development means following good and consistent development
practices. This is not just about creating fantastic, well-designed code, but also about
the seemingly little things such as naming conventions and comments.
We will not cover all the best practice guidelines here, as it is more pertinent to
explain them as we use them. We'll cover some general guidelines before we start.

Naming
First, all the objects you create or elements added to an object authored by another
party must be prefixed. The prefix is usually specific to your organization; in the
case of Binary, we use two prefixesBCL for all work we carry out as a VAR, and
AXP for our ISV work. The prefix cannot be of any three characters; for example, Sys
would be a bad prefix because it is also used by Microsoft for their system objects.
When adding element to your own objects, do not prefix them. All type names
(extended data types, tables, classes, and so on) must begin with a capital letter,
and all instance variables and methods must have a lowercase first letter.

[ 18 ]

Chapter 1

Although the AX compiler is not case-sensitive, the CIL is; thankfully, this compiles
from the p-code, so it isn't normally a problem. It is nonetheless good practice to
write code as if it is case-sensitive. This also helps make the code much easier to read.
The second part of naming is that you should capitalize the first letter of each
word in the type, method, or variable name; for example, CustTable and the
initFromCustTable method. This, again, makes the code much easier to read.

Commenting
A version control system cannot replace good code commenting. Any change made
to an object that was not authored by you should be tagged with the following:

Your organization's prefix

Your initials

Reference to the business requirement (for example, a Technical Definition

Document (TDD) reference or a Functional Requirements Document
(FRD) reference)

The date

A few words as to the reason for the change and what the change is
intended to do

A second line (as required) to explain what the change is intended to do

Let's take a look at the following example:

// BCL 5.2.4 (var) by SB on 2014/06/07: Set the focus to the item id
control
SalesLine_ItemId.setFocus();
// BCL 5.2.4 end

Use yyyy/mm/dd as a date format because dd/mm/yyyy or mm/

dd/yyyy can cause confusion across continents. However, if you do
see a date that is not YMD, it is most likely to be DMY, not MDY.

If you add a method to an existing object, you should add a header comment.
This can easily be done by entering /// in the first line of the method. It should
contain the comment line, as shown in the preceding code snippet.

[ 19 ]

Efficient Design and Development with Microsoft Dynamics AX

If you have made a change to a form layout, you should add a method called
DevelopmentHistory highlighting the changes. Otherwise, you may realize that it
gets lost when another developer applies an update or hotfix. This content format is
up to your organization; this would normally be a list of changes formatted in a table
in the same format as the earlier change tag.
Adding comments is often a pain and, when focused on writing an exciting piece of
code, they are easily forgotten. One way to solve this is by making the addition easy
by modifying the EditorScripts class.
The EditorScripts class has methods that create code blocks and even entire
methods for you, either through the right-click menu or by typing a keyword. The
class can be modified by adding a public method that accepts an Editor instance.
Appendix A, Code Editor Scripts, covers this topic.

Editor scripts
Editor scripts are code snippets that insert code into the current method, and can
even ask for information as part of the process. They insert either statement blocks,
such as a switch statement block, or an entire method. They are simple to enter;
simply type the script name and press the Tab key.
For example, if we have a class called BclFleetVehicleTableType and enter the
text construct in a method, the following code is inserted:
public static BclFleetVehicleTableType construct()
{
return new BclFleetVehicleTableType();
}

The available scripts can be seen by right-clicking on the method and navigating to
Scripts | template, as shown in the following screenshot:

[ 20 ]

Chapter 1

Patterns and frameworks

The easiest way to describe patterns and frameworks is to state that patterns describe
how we perform a task, and a framework is the existing code that we use or extend.
Both are very important.
Although patterns do not contain actual code, they are critical for ensuring that what
we write is consistent, extendable, and easy to understand by members of our team.
This removes a lot of thinking about how a task is performed, so we can focus on the
actual problem.

Patterns
A good example of how patterns can be used is demonstrated by the following
requirement: we require a method to edit the customer credit limit from the customer
list page. This should be a button on the action page that will open a dialog, showing
the current credit limit and allowing the user to update it. When the user clicks on
OK, it will update the customer's credit limit.
There are many ways to do this, and it may seem appropriate to create a form that
initializes from the current customer on the list page, and updates the record when
the user presses OK.
This is until we get the next series of requests:

Can we add the button to the collections list page?

Can we add the button to the sales order form?

Can we run a routine that validates the open sales order?

Can we place the resulting sales orders that fail the credit limit in
a workflow?

The preceding requests are clearly additional work, but the code should require
only extending and not rewriting. What often happens is that the design is
changed to such an extent to try to fit the requirement that it is barely readable
by the original developer.
The actual design we should have adopted would be similar to the following:

The form, instead, interacts with a data contract, which is initialized from
the caller

A handler class is written to take the data contract (which contains

the new credit limit and the customer to be updated) and makes the
necessary updates
[ 21 ]

Efficient Design and Development with Microsoft Dynamics AX

A data contract is a class that has a set of public properties that form a structured
dataset, allowing the data to be passed to and among objects. They can also cross
tiers across the architecture and be marshalled to external services.
The additional work is to create two classes and about 10 lines of code. This will
make the solution much easier to extend, and if adopted by a team, easier to read
and maintain.
Many development teams spend some effort in adopting patterns, and sometimes
evolving them over time. We have many patters in AX, and most of the tasks we
need to perform can be done by following an existing pattern.
Microsoft has published the reference patterns that we should follow at Microsoft
Dynamics AX Design Patterns, http://msdn.microsoft.com/en-us/library/
aa851876.aspx.

Frameworks
The frameworks in Dynamics AX are designed to be either used or extended.
They are often a complicated set of tables and classes, and sometimes contain a
user interface. We take advantage of them by extending and/or implementing a
specific class.
Most of the key functionality in AX is accessed through the existing business logic;
this is true for some master data tables, and certainly true of all transactional data.
For example, in order to post a sales order confirmation, we would use
the FormLetter framework. In this case, the framework provides the
FormLetterService class, which has the postSalesOrderConfirmation method.
Other frameworks are designed to assist us in common development patterns or
provide access to features that are not directly accessible from X++. In the preceding
example, we could've used the SysOperation framework, which allows us to
interact with the batch framework, thereby allowing asynchronous code execution.
We will use and extend these frameworks as we progress through the chapters.

[ 22 ]

Chapter 1

The technical architecture of a solution

A good design is just as relevant to small change requests as it is for larger
development. It has many attributes; some key points to consider are as follows:

Configurable: As much of the decision-making should be stored in

configuration and parameter tables as possible. It may take longer, but
it will save time when the development goes through integration testing.

Extendable: The solution (no matter how small) should be designed such
that it can be extended without rewriting. Using patterns can help with this.

Design around standard patterns: This helps avoid reinventing the wheel
and ensures a higher quality design that is more consistent. The solution
we write should look and feel like any other part of AX, which means less
training and better adoption by our users.

Validate the design: This should be done against the requirement before the
work on the design commences. In some cases, it is appropriate to prototype
the solution.

Use the advanced features of AX appropriately: Just because a cool feature

exists doesn't mean it should be used in this case.

Configuration and parameters tables should be rule-based: For example, a

property used to determine which mode of delivery is urgent is limiting. It
implies that there can only be one urgent delivery mode.

Minimize changes to standard code. The more standard code we change,

the more the work required to maintain the system in terms of updates and
upgrades. We discuss minimizing this footprint in the next section.

Most of the functionality that we write in AX (a new solution or customization of an

existing functionality) is data-based. We use forms to create, maintain, and view this
data; tables to store and validate this data; and classes to act upon it.

Data structures
The first part to design is the data structures. Even though these may evolve, a lot of
attention is required here. A simple analogy would be to compare this to building
a house; you can change the furniture, even add a room, but you cannot add a
basement garage.

[ 23 ]

Efficient Design and Development with Microsoft Dynamics AX

There is some guidance to be found here; that is, the structure will normally fit into
an existing pattern that has already being used by AX. We normally expect to have
the following types of tables in our solution:

Parameter: This is a single record table that typically contains the table's
defaults and other behavioral properties, such as the default printer settings.

Group: An example of this can be the customer group or delivery mode

tables. They can act as lookup values, or even control functionality. For
example, we may create a table that contains a user's default label printer.
When you find yourself creating multiple fields of the same
type (for example, the Urgent delivery method, Normal
delivery method, and Low priority delivery method
fields), they should be records in a table with a reference
(enumerated type) so that you can identify them in code.

Main: These are the master data tables, such as items and customers.

Worksheet header and Worksheet line: These are the standard document
entry tables, such as the sales order table and lines where the dataset has a
header and lines.

Worksheet: This is a table used to enter data that is later processed in some
way. This not very common in AX, as most documents have both a header
and lines.

Transaction header and Transaction lines: This is the result of the worksheet
after posting, or committing, such as the sales invoice header and sales
invoice lines.

Transaction: This is the table where the result of posting is a single-level

transaction record. The stock transaction table called InventTrans is an
example, which is viewed as a list of stock transactions.
The preceding types are actually set as a property on the table
when it is created, thus further enforcing the pattern.

During the course of this book, we will be writing a solution based on a hypothetical
case of a fleet management system as Contoso's internal development team. Based
on the previous guidance, we can take the following simple requirement and quickly
turn it into a data structure: we require the ability to view and maintain records of
vehicles and their utilization.

[ 24 ]

Chapter 1

From this, we can see that we will need to store a list of vehicles, probably of varying
types, and then a record of their utilization will be attached to each vehicle. This
leads us to the following structure:
Table type
Parameter

Example table name

ConFMSParameters

Description
The main parameters

Group

ConFMSVehicleGroup

A list of vehicle types

Main

ConFMSVehicleTable

A list of vehicles

Transaction

ConFMSVehicleTrans

The utilization records

In this case, little thought was required, as the requirement fits nicely into the
standard AX patterns.
The naming was also straightforward: the organization's prefix is Con, the module's
prefix is FMS, and the rest of the name comes from the entity name and the table
type. You will see this type of naming throughout AX. As far as possible, we
should be able to understand from the name alone what it is, what it does,
how it does it, and why.

The user interface

The next part of the structure is the user interface, where we again have a set of
templates that suit most circumstances:

List page: This is the main entry point to both main tables and worksheet
tables. The list page offers the ability to search and act upon the data. You can
also open a details form from list pages that allows the record to be edited
or a new entry to be created. An example of it can be found by navigating to
Forms | CustTableListPage.

Details form, master: This is designed to allow maintenance of master data,

such as customers and items. This is not an entry point, but is opened from
a related record or the list page. We sometimes use this form type to create
data, but we typically use a specific creation form for this. An example of this
can be found by navigating to Forms | CustTable.

Details form, transaction: This is intended for maintenance of worksheet

tables, such as the sales order form. An example of this can be found by
navigating to Forms | SalesTable. The term "transaction" may be confusing
here; it is not related to the TableGroup property of the table.

Simple list: This is useful for group and transaction tables that are a simple
list of records with only a small number of fields to present. An example of
this can be found by navigating to Forms | CustClassificationGroup.
[ 25 ]

Efficient Design and Development with Microsoft Dynamics AX

Simple list, details: This is where the group table has many fields that are
better arranged in groups of fields. There is still a list element, but there is
a pane that allows easier entry of data. An example of this can be found by
navigating to Forms | DeliveryMode.
Table of contents: This template is used for parameter forms. For example,
Forms | CustParameters.
Dialog: These forms follow a style design to be used as a popup to gather
some information and return it to the caller. A form used to create data is
likely to use this template, as we enter data and then ask AX to create the
record once complete.
Drop dialog: These appear as if they drop down from the calling button,
and are typically used to perform an action using the current record. They
are designed to display a small number of form controls, which the user will
update as required before pressing OK. The following screenshot shows this:

The preceding templates are available for us to choose from when

we create a form. Using these templates further assists us in
creating a user interface consistent with AX.

Based on the preceding templates, we can create the following forms for our
example requirement:

Table of contents: ConFMSParameters

Simple list, details: ConFMSVehicleGroup
List page: ConFMSVehicleTableListPage
Details form, master: ConFMSVehicleTable
Simple list: ConFMSVehicleTrans
[ 26 ]

Chapter 1

We normally name forms after the table they act on, except for list pages. The last
example does not really have a true template; the simple list is the closest. The data
structures and forms are taken directly from how other parts of AX behave. This
should always be a design goal as it ensures that our users' incumbent knowledge of
AX is used, reducing the time to learn the new feature and minimizing errors.

Application logic
Classes are used to store the main business logic, and are often used to handle
user interface and table events. This allows the code to be reused and extended
more easily.
The other key point is that we should also consider that we may want our solution
available for mobile devices, and careful thought about how we write the logic can
make this much easier.
Classes in AX can be deployed as custom services that are consumed as WCF
services in mobile or other Windows applications. This means that the logic should
be simple to access, and having business logic in distinct classes allows the logic to be
reused safely.
For example, we have a table with a status field that performs some validation and
other events. We would write this in the data contract / service class patterna data
contract to store the data to be acted upon, and a service class to process the change.
This can be used on a dialog form with the AX client or exposed as a service allowing
a mobile application to set the status.

Minimizing the footprint of changes

The footprint we make on existing objects is a key consideration when it comes to
solution maintainability and the associated costs.
Microsoft has made key investments in the development environment in order
to make it easier to write code in such a way that it sits alongside another party's
solution. The advantage for Microsoft is that their customers can adopt multiple
solutions or add-ons from ISVs with minimum effort.
Prior to AX 2012, this effort would have involved merging code from different
partners, and additional effort would have been required to ensure that a hotfix
from one organization did not regress code in another add-on.
The following sections will highlight the practices and technologies that
accomplish this.
[ 27 ]

Efficient Design and Development with Microsoft Dynamics AX

Where to make the change

We often are asked to make changes to AX that requires standard objects to be
modified; often, the difficult decision is about where the change is to be made.
First, we should consider how the code is structured by taking the example of a
form that acts upon a table. Tables are structured into fields, field groups, indices,
relations, delete actions (for example, cascading the deletion to child tables), and
methods. Forms are structured into form-level methods, data sources (a reference
to a table), and controls. A request might be, "Can we make the vehicle field on the
transport form mandatory?"
This is possible; the form control does have this property, but so do the data source
field and the equivalent field on the tableso which of these to use? The answer is
always: as high in the stack as possible. The requirement is that the table always has
this particular field filled in, so wherever this field is added, it should be mandatory.
The same pattern applies to code changesalways at the highest level and in this
order: class, table, form data source field/method, form control.
Making changes to form controls is very rarely required, and should be
considered as a deviation from best practices.

Even hiding controls on forms should be handled in a method (which is usually

called enableControls), as this makes the change more obvious and much easier
to read, extend, and reuse.

The use of eld groups

Field groups allow us to place fields into groups that are later placed on a form.
The form then dynamically displays the fields that are in that field group. Standard
AX uses this pattern extensively, and by adding a new field to the appropriate field
group, the forms magically display this new field.
The reason this reduces footprint (when it may appear we are just making a change
elsewhere) is that forms take more time to upgrade than tables and classes.

Eventing
Eventing is a new key feature in AX 2012 that, along with Models, is a key enabler
for ISVs to write add-ons for AX.

[ 28 ]

Chapter 1

Event subscription
This technology allows you to subscribe to an event in AX. So, instead of modifying
the method, we simply subscribe to it as a pre or post event. We can then perform
our logic elsewhere in an X++ or .NET assembly, and even modify method
parameters and return values.
This subscription is not a modification to the source method, and therefore,
a method can have subscriptions in several different models in the same layer.

Delegates
Delegates are empty method stubs to which we subscribe. They are created by
the original author and called from within their code. This is done so that you can
subscribe to events that happen within a method without modifying a method.
For example, the following lines of code would be a delegate written by an ISV
(Axp is the prefix used by this ISV):
delegate void weightCaptured(AxpWeighTicketContract _contract)
{
}

The ISV will then call this delegate at the appropriate time with the data contract.
By subscribing to this delegate, you can handle the event and perform the necessary
tasks with the supplier contract. This provides a hook into the supplied solution
without modifying it. For more information about the guidelines on delegates,
visit http://msdn.microsoft.com/en-us/library/gg879953.aspx.

Extending a class
Another method of modifying behavior with a minimal footprint is to extend
the class. This should be done only if you cannot perform the task through an
event subscription.
The pattern is implemented with the following steps:
1. Create a new class and use the extends keyword to extend the class you
need to change.
2. Override the method you wish to change.
3. Modify the construct method on the base class so that it constructs your
class based on the criteria you want.

[ 29 ]

Efficient Design and Development with Microsoft Dynamics AX

Table-level form events

The table has several events that happen based on form events. The mechanism is
conceptualized as follows, in this example for the modified event:

A data bound field's modified event will call the data source field's
modified method

The bound data source field's modified event will call the table's
modifiedField event with the field ID of the field being modified

The table's modified event is normally a large switch statement based on the field
ID parameter with a case for each handled field. To modify this, we can simply add a
case for our new field or change the behavior of an existing case.
In this situation, we should subscribe to the modifiedField method, but another
option would be to create a new method with the same profile. This is preferable if
we are the end-user organization, but required for VARs and ISVs. This is done by
copying the method header. Let's take a look at the following example:
public void modifiedField(FieldId _fieldId)

We can then create a new method, as follows:

public void conModifiedField(FieldId _fieldId)

We can then create a switch statement to handle the fields we need to in this new
method. In order to call this new method, we can then add a call to our new method
in the original modifiedField method:
public void modifiedField(FieldId _fieldId)
{
super(_fieldId);
switch (_fieldId)
{
case fieldNum(<TableName>, <FieldName>):
// code
break;
}
// Con Var modification by SB 2014/06/09 handle custom fields
this.conModifiedField(_fieldId);
}

[ 30 ]

Chapter 1

Downloading the example code

You can download the example code files from your account at
http://www.packtpub.com for all the Packt Publishing books
you have purchased. If you purchased this book elsewhere, you can
visit http://www.packtpub.com/support and register to have
the files e-mailed directly to you.

Summary
In this chapter, we covered a lot of the groundwork, from the technical architecture
of Dynamics AX to the development practices. Following this guidance should
both save time in development and allow solutions to be developed that fit in the
standard AX practices to be developed.
In the next chapter, we will go through the preparation work that we perform
each time we start a new project, putting into practice the concepts covered in
this chapter.

[ 31 ]

Get more information Microsoft Dynamics AX 2012 R3 Programming Getting

Started

Where to buy this book

You can buy Microsoft Dynamics AX 2012 R3 Programming Getting Started from the
Packt Publishing website.
Alternatively, you can buy the book from Amazon, BN.com, Computer Manuals and most internet
book retailers.
Click here for ordering and shipping details.

www.PacktPub.com

Stay Connected: