Introduction
Dynamics AX has two
development environments: Microsoft Visual Studio, used primarily for
developing Enterprise Portal and reports, and MorphX, the main Dynamics
AX IDE .
MorphX is a
model-based, object-oriented development environment. Developers use
X++—the MorphX programming language—and the MorphX toolset to develop,
customize, and extend Microsoft Dynamics AX applications.
Developing with MorphX
Like most IDEs, MorphX includes, among other tools, a source code editor, a compiler, a version control system, and a debugger.
In this section, you’ll see how these tools map to a typical product cycle model, shown in Figure 1.
You can follow the model shown in Figure 1
strictly, use variations, or manage your projects less formally.
Whatever style of project management you choose for running your
projects, you need to consider what should happen in each of these five
phases: planning, designing, implementing, stabilizing, and releasing.
Most software projects
start with a planning phase. In this phase, product planners decide on
the market segment, establish the vision for the product, and allocate
resources.
In the design phase,
design documents are created, design reviews are conducted, prototypes
are implemented, and requirements are documented. In the next phase,
implementation, code is written, tested, and shipped. When
implementation is complete, the stabilization phase begins. Here the
focus is to validate the product quality: Are all requirements met? Does
the product work as intended? Does the product meet performance goals?
When the product
stability is satisfactory, the product can be released. The release
phase includes packaging, marketing, and maintenance, which might
involve releasing error corrections and service packs.
The product cycle starts over with the next version of the product.
Planning Phase
Unlike
many development environments, in the Dynamics AX IDE, you never start
from scratch. Even in your first Dynamics AX project, when you might
have a lot of learning to do, practices to formulate, and partnerships
to form, you have a code base to start with.
In the planning phase of a
Dynamics AX project, application designers and developers investigate
the existing functionality and plan how to integrate with this
functionality at a high level. Typically, this takes place at the user
interface level.
Design Phase
As we said earlier, in
the design phase of the product cycle, prototypes are implemented,
design documents are created, design reviews are conducted, and
requirements are documented.
As you develop your
designs and prototypes, the first Dynamics AX tool you’re likely to use
is the Application Object Tree (AOT). Accessible through the Dynamics AX
user interface by pressing Ctrl+D or by clicking the toolbar icon, the
AOT is typically the starting place for all development in Dynamics AX.
It is the repository for all the elements that together constitute the
existing business application.
The next tools you
encounter are the property sheet and the X++ code editor. Most nodes in
the AOT have a set of properties that you can inspect and modify by
using the property sheet. Method nodes contain X++ source code. You use
the X++ code editor to view and modify the code.
With these tools, you can,
for example, see the structure of forms (by using the AOT), the
properties specified on each control (by using the property sheet), and
the event handlers’ implementation (by using the X++ code editor). You
use these tools throughout the remaining phases of the product cycle.
If
you use the Version Control tool, you benefit from all elements being
read-only. In read-only mode, you can investigate without the risk of
changing the existing code. If you’re working on the first version of
your project, you can also use the layering technology to provide the
same safeguard.
The tools mentioned so
far reveal implementation details at the element level. Three additional
tools show how elements relate to each other at a higher level: the
Cross-reference tool, the Find tool, and the Reverse Engineering tool.
The Cross-reference tool
shows you where any specific element is used. In the design phase, you
can use this tool to determine where table fields are displayed,
initialized, read, modified, and so on. The Find tool allows you to
search any element in the AOT. In the design phase, you typically search
the entire AOT. The Reverse Engineering tool raises the abstraction
level. With this tool, you can generate Microsoft Visio Unified Modeling
Language (UML) models and Entity Relationship Diagrams (ERDs). If you
find yourself struggling to understand the object hierarchies or the
data models, looking at a UML diagram can be useful.
During the design
phase, you should also consider your approach to testing. Designing for
testing from the beginning makes your life easier later in the product
cycle, and it typically results in a better design.
Implementation Phase
When your design
documents and functional specifications are complete and you’re ready to
start developing, you should consider setting up the Version Control
tool. Version control allows you to keep track of all changes, which is
particularly useful when you are working in large teams. You can also
specify criteria for code quality. Code that doesn’t conform to the code
quality you specify is rejected in the version control check-in
process, so you can be sure that code that doesn’t meet the quality
standard isn’t allowed into your project.
In your first
implementation, you should use the Development Project to group related
elements. Without it, working efficiently in the AOT can be difficult
because of the many elements it contains. A project provides a view into
the AOT, allowing you to focus on the elements you’re working with.
Using a development project also allows you to define what you want to
see and the structure in which you see it.
After you’ve written your
source code with the X++ code editor, you must compile it. The compiler
generates the bytecode from your X++ source code and presents any syntax
errors. The compiler also triggers the Best Practices tool, which
validates your implementation of X++ code and element definitions
according to development guidelines, allowing you to automatically
detect coding errors and warnings.
You
can also use the Visual Form Designer and the Visual Report Designer to
construct your forms and reports. If you’re developing a multilingual
feature, you can use the Label Editor to create localizable text
resources.
You might want to refer
to code examples during the implementation phase. The Find tool and the
Cross-reference tool can help you identify examples for API usage. The
Cross-reference tool is also helpful if you need to refactor your code.
If your code doesn’t
produce the results you expect or it has errors, you can use the
Dynamics AX Debugger to track the problem. The debugger starts
automatically when execution hits a breakpoint. You might also need to
see the data that your feature is using. You can use the Table Browser
tool to look at this data.
Stabilization Phase
When you’ve completed
your implementation, you should find and correct any problems in your
code—without introducing new problems. You can use the debugger to find
problems in your code. If a problem mandates a change of method profiles
(return values or parameters), you should use the Cross-reference tool
to perform an impact analysis of your changes before you make them. If
you use the Version Control tool to track changes, you can use the
Compare tool to highlight differences in each revision of an element.
Release Phase
When upgrading your
customers from one version of an application to the next, say, from an
earlier version of Dynamics AX or from one version of your functionality
to the next, you need to ensure that no code conflicts exist. To detect
any conflicting changes to elements, you can use the Detect Code
Upgrade Conflicts option, which is available from the Upgrade checklist
or the Microsoft Dynamics AX drop-down menu in the client:
Tools\Development Tools\Code Upgrade. To resolve conflicts, the Compare
tool is unmatched. It allows you to compare versions of elements, and,
based on the results, upgrade elements.
