80670AE AX2012R3CU8 DEV1 ReferenceMaterial

Online Companion Guide
80670AE
Development I in Microsoft Dynamics AX 2012
R3 CU8
Contents
Online Companion Guide........................................................................................................................................1
80670AE...................................................................................................................................... 1
Development I in Microsoft Dynamics AX 2012 R3 CU8............................................................1
Disclaimer................................................................................................................................................................4
Module 1: Architecture................................................................................................................................5
Module 1: Architecture Video Transcript....................................................................................5
Lesson 1: Module Overview......................................................................................................... 5
Lesson 2: Features of Dynamics AX............................................................................................ 5
Lesson 3: Architecture................................................................................................................. 6
Lesson 4: Data Partitions............................................................................................................. 7
Lesson 6: Model Driven Architecture............................................................................................ 9
Lesson 7: Licensing and Configuration....................................................................................... 10
Lesson and Module Summary.................................................................................................... 10
Module 1 Key Take Away.....................................................................................................................................11

Module 1: Practices...............................................................................................................................................12
Module 1: Things to think about:....................................................................................................................12
Module 2: Data Dictionary....................................................................................................................................13
Module 2: Data Dictionary Video Transcript..........................................................................................13
Lesson 1: Module Overview....................................................................................................... 13
Lesson 2: Introduction to MorpX and the Application Object Tree..............................................13
Lesson 3: Introduction to Tables................................................................................................. 14
Lesson 4: Data Types: Primitive and Extended...........................................................................15
Lesson 5: Creating Tables.......................................................................................................... 16
Lesson 6: Indexes....................................................................................................................... 17
Lesson 7: Relations.................................................................................................................... 17
Lesson 8: Base Enumerations.................................................................................................... 18
Lesson 9: Views.......................................................................................................................... 18
Module 2 Key Take Away......................................................................................................................................19

Module 2: Things to think about:...................................................................................................................20
Module 3: User Interfaces.........................................................................................................................21
Module 3: User Interfaces Video Transcript...........................................................................................21

Lesson 1: Module Overview...................................................................................................... 21
Lesson 2: Forms......................................................................................................................... 21
Lesson 3: Joining Data Sources.................................................................................................. 23
Lesson 4: Menu Items................................................................................................................ 23
Lesson 5: Form Templates.......................................................................................................... 24
Lesson 6: List Pages................................................................................................................... 24
Lesson 7: FactBoxes................................................................................................................... 25

Things to think about:......................................................................................................................................27
Module 4: Security.............................................................................................................................................28
Module 4: Security Video Transcript......................................................................................................28
Lesson 1: Module Overview....................................................................................................... 28
Lesson 2: Definitions.................................................................................................................. 28
Lesson 3: Set up a New User...................................................................................................... 30
Lesson 4: Assign a User to a Role.............................................................................................. 30
Lesson 5: Change Duties on a Role............................................................................................ 31
Lesson 6: Change Privileges on a Duty...................................................................................... 31
Lesson 7: Assign a Permission to a Privilege.............................................................................. 32
Lesson 8: Investigate Access..................................................................................................... 32
................................................................................................................................................... 32

Things to think about:......................................................................................................................................33
Practices....................................................................................................................................................35
Practice 1.1: Create a New Model and Development Project...............................................................................35
Practice 2.1: Create a New EDT............................................................................................................................36
Practice 2.2: Create a New Table...........................................................................................................................36
Practice 2.3: Create a Primary Index.....................................................................................................................37
Practice 2.4: Create a Relation...............................................................................................................................37
Practice 2.5: Add an Enum....................................................................................................................................39

Practice 3.1: Create a Form...................................................................................................................................40
Practice 3.2: Create a Form from a Template........................................................................................................40
Practice 4.1: Create a New Security Role..............................................................................................................42
Disclaimer
This Online Companion Guide is to be used in conjunction with the E-Learning for this course.
This online companion guide can be used to take notes or provide additional information on the
topic.
Module 1: Architecture
Module 1: Architecture Video Transcript

Lesson 1: Module Overview
Microsoft Dynamics AX 2012 R3 CU8 is a customizable Multilanguage and multicurrency ERP
solution. It excels in a number of industries such as manufacturing, e-business, wholesale and
service industries.
AX is a completely integrated solution, is web enabled, and supports Microsoft SQL
Server. With customizable source code, the solution can be modified as necessary based on the
specific requirements of customers.
In this module, we'll look at the basic features of Microsoft Dynamics AX 2012 R3 CU8.
We'll then review basic form navigation and then look at the architecture of Microsoft Dynamics
AX.
After that we'll talk about development environments and the options for making
development changes in AX.
Next we'll review the model driven architecture of AX, and finally talk about how licensing
and configuration works within AX.
Lesson 2: Features of Dynamics AX

Microsoft Dynamics AX is a unique and powerful solution that contains a lot of great functional
features. It uses a unified database architecture that enables the organization to have a unified
view of all the companies in the organization.
There's a separate database for business data and for the application model. It applies a
highly integrated design between functional areas such as resource planning, sales,
manufacturing and so on.
AX also uses a dimension-based system for all of the modules. This enables the
organization to view the same data across multiple dimensions.
In addition to this, AX has built-in support for multiple currencies and multiple languages.
This enables an organization to use the same AX application to transact globally in any of the
global currencies and define exchange rates between these currencies.
Users in different locations of the world will be able to use the application in their local
language without having to have separate instances of the application.
Beginning with AX 2012 R2, AX supports the concept of data partitions. Partitions enable
organizations to separate data between groups of companies. We'll talk more about data
partitions later in this module.
AX also has a number of advanced features. For instance, you have the ability to do
advanced forecasting and master planning. There is a robust data import export framework that
enables organizations to import and export bulk data in a very efficient manner. Starting AX
2012 R3, AX also supports integration with the SQL Server master data services, enabling
organizations to keep master data in sync between separate AX application instances or between
AX and other systems that master data.
Management reporter adds functionality to help organizations build and view enhanced
financial reports. Finally, AX now allows you to deploy Microsoft Dynamics AX 2012 R3 CU8
environments directly on Microsoft Azure, further it using total cost of ownership and improving
manageability.
In addition to functional features, AX also contains a lot of great development features.
AX contains an integrated development environment called MorphX. MorphX can be customized
for customizing the standard application or even developing new features and modules. In
addition to MorphX, customers and partners can also use Microsoft Visual Studio to develop
solutions.
AX uses the application object tree, or the AOT, as a mechanism to provide a uniform and
compact repository for viewing code and metadata related to AX.
The development concepts are deeply integrated to enable a rapid development
experience. For instance, you can use drag and drop functionality for many of the programming
and customization tasks. AX also supports the concept of projects to help organize and track
customized applications.
We'll take a deeper look at these features over the rest of this course.
The client workspace is the standard rich client interface that an end user uses. Let's
review some of the key components of the client workspace. Within the workspace, the title bar
is the standard Windows title bar. The navigation pane is the menu on the left side of the screen
that shows all of the modules the current user has access to.
The content pane displays role centers, list pages and area pages. Role centers display
specific data, reports, alerts and common tasks associated with a user's role in the organization.
The role center is displayed when an end user opens the application or goes to home in the
navigation pane.
List pages display lists of data. They are optimized to view and search through a list of
records and act on information. Area pages display all menu items relevant to the module
selected in the navigation pane. They are grouped logically to make it easier for end users to
find what they need.
The Windows view and help menus allow you to access the development workspaces,
help, and other informational screens. The address bar provides a breadcrumb IU that allows you
to rapidly navigate to various parts of the application.
The file menu provides access to a host of features such as print, business intelligence
tools, alerts, the ability to export to Microsoft Excel, and so on.
And finally, the status bar shows you information about your current session such as the
current company, currency, layer, partition, user, and so on.
Let's now look at some of the key features of list pages. In this example, we look at the
customer's list page, which is accessible from accounts receivable, common customers, all
customers. Here in the center of the form is a grid that displays the list of customers. Above the
grid is a filter pane that can be used to filter the records that are displayed on the grid. At the
top of the screen is the action pane that contains buttons to open other forms and to take actions
related to the selected customer.
On the right are FactBoxes that show data related to the selected customer. When a
record is clicked on the grid, detail data related to that customer is shown in the preview pane.
Lesson 3: Architecture
Microsoft Dynamics AX has a three-tier architecture. Three-tier architecture is defined as having
a separate database, application server and client, where the database stores the data, the
application server runs the application business logic, and the client application allows users to
connect to the server to access Business Logic and use the data in the database.
In Microsoft Dynamics AX, the three tiers include the following: A SQL Server database
that houses the data entered into and used by the Microsoft Dynamics AX application. There is a
separate database that houses the data, and another one that stores the model store that
contains application elements.
Application elements are explained in the next lesson.
The next tier is an Application Object Server, or the AOS. This is a service that runs most
of the Business Logic. This runs continuously on a central server.
The client application is the user interface through which an end user accesses Microsoft
Dynamics AX. There are various clients available, including the Microsoft Dynamics AX rich client
and the enterprise portal.
Let's take a deeper look at the three-tier architecture that makes up a typical deployment
of AX. At the database tier, we have a few different databases. The Microsoft Dynamics AX
database is an online transactional processes, or OLTP database, that stores all of the business
data in SQL tables. There's also model database that stores all of the metadata and application
code in the model store.
Some BI components of Microsoft Dynamics AX also require you to use SQL Server
Reporting Services and SQL Server Analysis Services. SQL Server Reporting Services, or SSRS, is
used for running reports. The SQL Server Analysis Services, or SSAS, database is derived from
the data in the OLTP database in a format that is optimized for fast reporting and analysis.
The Application Object Server, or the AOS, is the Microsoft Dynamics AX application
server. The AOS is where most of the Business Logic is executed. The AOS runs many tasks.
Some of the most important runs are the X++ runtime that runs the X++ code, which provides
most of the Business Logic in Microsoft Dynamics AX; the security layer, which enforces security
to manage access to data and functionality; the session management infrastructure, which
manages client services; and the web services end point, which enables external applications to
connect to AX using web services.
Multiple AOS servers can be run and installed to spread the processing load over multiple
servers. This improves performance in larger implementations.
Then at the client layer, there are a number of different clients that connect with AX. The
Microsoft Dynamics AX rich client is the primary client to access AX functionality. Most forms
displayed in the rich client are designed by using the MorphX development environment.
Roles central pages are SharePoint pages that are displayed within a rich client form.
SQL reports are culled from the rich client by using the report we are controlling.
Another common client is the Enterprise Portal, or EP. EP pages are displayed through a
web browser. A subset of the functionality and reports are also available on the portal.
Microsoft office can also be used as a client to access the Microsoft Dynamics AX
application and data. Office add-ins are available out of the box for Microsoft Excel and Microsoft
Word. Users can use Excel to view, edit, create and delete data in AX. Word can be used to build
rich documents that source data from AX.
Since the data access is through the AOS, AX enforces user level security on the data and
the fields, even when the data is accessed through the Office applications.
Other applications can also be used as clients to Microsoft Dynamics AX. Examples
include mobile applications, specialized applications written in DotNet, and even Legacy
applications. Applications can be integrated using methods such as web services or the DotNet
Business Connector. The DotNet Business Connector is another client that has no user interface.
It is designed for other applications to access AX Business Logic.
End users can use any application as the user interface that interacts with the AOS
through the DotNet Business Connector.
Developers can access developer tools through the MorphX IDE in the Microsoft Dynamics
AX client or through Visual Studio tools in Visual Studio.
Finally, we have the help server and web service components. The help server hosts
Microsoft Dynamics AX help files through the IIS, or the Internet Information Services. When a
user accesses help from within the rich client, the AOS generates a call to the help server to
display the help pages.
While the AOS is an end point for web services, web services can also be hosted within IIS
when they need to be exposed via http protocol. When hosted within IIS, the AOS is the web
service end point that provides the data that is served to other applications by IIS in a
standardized format.
Lesson 4: Data Partitions

Microsoft Dynamics AX 2012 R2 enables data isolation by using data partitions. For example, an
organization that's a holding company might have several subsidiaries. If the management of
the organization does not want the employees of one subsidiary to have access to the data of
other subsidiaries, they can use data partitions to provide the boundaries that are required for
data isolation. However, data partitions still allow the metadata that supports the business
processes to be shared.
Partitions divide and isolate the business data of an installation by using special
processing that the AOS applies to data queries. Business data that is shared among companies
is only shared between companies that are in the same partitions.
Each Microsoft Dynamics AX client session starts in one partition. Users must start a new
AX client session for each partition they wish to access. Once a session is started, the session
may only access the data and the partition it was started in. For instance, a client session that
was started in subsidiary A may only access the data in partition 1.
Each partition contains at least one company or legal entity. A legal entity occurs in only
one partition. When you create a legal entity, the system assigns it to the current partition.
While a legal entity cannot be moved to another partition, its data can be exported from one
partition and then imported to another company in another partition.
Just to note, partitions were added starting in Microsoft Dynamics AX 2012 R2. When you
upgrade from a version that did not support partitions, you must assign the existing companies
or legal entities to one or more partitions during the upgrade.
Lesson 5: Development Environments

The AX application is built of elements that are stored in the model store in the SQL Server
database. For example, the elements that are stored in the application might be fields and
tables that define data structure, forms and menus that define how a user interacts with the
application, classes and methods, which are code objects that define Business Logic. The
Application Object Tree, or the AOT, provides a visual representation of the elements that
comprise the application. Object oriented design and inheritance are key concepts that form the
basis of the application.
Model elements can be modified or added using the AOT. You can also use Microsoft
Visual Studio as a development environment. While most of the development for AX can be
using the MorphX ID, concepts such as SQL Server Reporting Services and Enterprise Portal
components can only be developed using Visual Studio.
Once developed in Visual Studio, they can be integrated back into the AX AOT by adding
the projects from Visual Studio to the AOT.
For more information on which environment to use, download the white paper titled
Selecting the Best Development Technology For Your Application Development Scenario for AX
2012. That is available on MSDN.
Labels are used to provide the language text that end-users see when using the
application. All text presented to the client displays the translation of a label code. The label
codes usually are used wherever the same text is used with the same meaning. This makes it
easier to manage multiple languages and to adapt to a company's specific language.
As an example, the label code @SYS78211 is translated as direct delivery in the English
U.S. label file. This label code is used in various places throughout the application. It is used on
field names and menu items displayed on forms such as the sales order header form.
All label codes are already translated into all other languages, which AX supports. If an
end user opens the application in Spanish, they would see the Spanish translation wherever this
label code is used. Developers can create new label files to translate label codes into other
languages or customer-specific terminology.
Tools including the Label Editor and the Label Wizard are available within the MorphX
development environment and can be used to add or change label files.
The MorphX IDE is accessed through the developer workspace, which provides access to
the AOT and other developer tools. It is used to make changes and add to the application. This
is the most commonly used development environment.
Common operations such as building or modifying tables, forms and menus can be
performed by using drag-and-drop techniques with little or no coding. X++ is the programming
language that's used in the MorphX ID to write more advanced Business Logic. You can access
the MorphX IDE from the Microsoft Dynamics AX client using the Windows menu in the command
bar and selecting new developer workspace.
Alternatively, you can also use the shortcut keys Ctrl+Shift+W. We'll take a deeper look
at the MorphX IDE in the next module.
X++ is the object oriented programming language that is used in the MorphX
development environment. X++ has C sharp like syntax and incorporates SQL data
manipulation statements. A full list of developer tools in the MorphX development environment
can be found in the developer help documentation.
Some of the tools that are available are the X++ code editor, which is a text editor used
to write X++ code. It supports color-coding and allows you to look up and select various objects
such as method names and enumeration values as your type.
Then we have a debugger, which is an application used by developers to step through X+
+ code to help resolve code errors.
There's also a reverse engineering tool that enables you to visualize data and process in
Microsoft Dynamics AX by creating UML data models, UML object models, and ER data models.
The table browser displays data from all fields in a selected table, and the table browser
can be used to run SQL-like statements.
The Visual Studio development environment is integrated through Visual Studio tools
through Microsoft Dynamics AX and it supports managed code. Close integration between
MorphX and Visual Studio means developers can take advantage of the benefits of each
development tool and work in the environment that best suits the development scenario.
Some development scenarios must take place in Visual Studio, though. This includes
creating and customizing SQL Server Reporting Services reports, most Enterprise Portal web
development, and any managed code development.
The application Explorer is available within Visual Studio. This gives developers the
ability to browse AX metadata. The application Explorer displays information that's similar to the
AOT that we see in the MorphX IDE. In addition, any projects that are created in Visual Studio
can be saved back into the AOT, and they are stored in the Microsoft Dynamics AX model store
on SQL Server.
While developing in Microsoft Dynamics AX, you can group all of your modifications into
one or more development projects. To create a new development project, you can click on the
project icon in the development workspace or press Ctrl+Shift+P. There are two types of projects
that you can create: Private projects or shared projects. Private projects are visible to the user
who creates them, and the shared projects are visible to everyone.
To create a new shared project, you can right-click on the shared note, and select new
project.
Once you open the project, you can drag elements from the AOT into this project. This
creates a reference to the element in the AOT. Modifying elements in the project is the same as
modifying them directly in the AOT.
Lesson 6: Model Driven Architecture

AX is designed with a unique layer and model structure that separates and controls the
updates and modifications made in the application. This structure provides a powerful and
flexible architecture for developing Business Logic. The key benefit of the layer and model
structure is that it lets developers change and extend the functionality in AX while maintaining
upgradeability to new versions.
The application object layers hold all the elements that are displayed in the AOT. There
are eight application object layers that are available. Each of these layers also has a patch layer
that makes it a total of 16 layers. The layers are a hierarchy of levels in the application that you
can use to make modifications and additions without interfering with the application elements in
the lower level.
When you make an element modification on one level, the modification overshadows the
element on a lower level. When the application is compiled, only the top-level version of an
application element is used.
There are three layers that are available only to Microsoft to deliver the base application.
Those are the SYS layer, or the system layer, the GLS layer, or the globalization layer, and the
SPK layer, or the feature pack layer.
Then there are three layers available to partners and ISVs. The SLN layer, or the solution
layer, which includes Microsoft-endorsed industry solutions; the ISV layer, or the independent
software vendor layer, including generic or vertical solutions developed by ISVs. The VAR layer,
or the value added reseller layer, includes multicustomer solutions developed by VARs.
Then there are two layers available to both partners and customers who have a license to
access the AX source code. The Cust layer, or the customer layer, includes customer specific
functionality, and the USR layer, or the user layer, includes installation specific functionality and
customizations.
Let's take the example of customizations across different layers to see how this works in
a running application. In this example, let's assume there are three layers: The SYS layer, the
ISV layer, and the VAR layers, which have application objects. In the SYS layer, you have two
objects: The Cust table and Cust form. In the ISV layer, you have a report called the
FleetReport, and the customization that was made to Cust form. This customization
overshadows the definition of Cust form in the SYS layer.
In the VAR layer, we've made a customization to the FleetReport. When the application
runs, the Cust table definition is from the SYS layer. The Cust form is from the ISV layer, and the
FleetReport is from the VAR layer.
Any modifications in a particular layer override the functionality, but the code in the
underlying layer is not deleted. If later, for instance, you uninstall the model from the VAR layer,
the code in the ISV and SYS layers will take precedence when the application runs.
There are a lot of benefits to using layers within AX. One of them is source code
protection. The elements in the standard implementation in the SYS, GLS and SPK layers can
only be changed or deleted by the Microsoft Dynamics AX development team. The layers help
protect the original source code and keep it separate from modification.
Similarly, ISV solution code is separated in a model within the ISV layer. Any customerspecific changes to the ISV solution would be in a higher layer.
Another benefit is faster and easier upgrades. Upgrades and service packs contain
changes in the lower layers where the base code resides. This means that any changes by
partners or customers are maintained throughout the upgrade.
There are powerful compare and merge tools that are available to guide developers
through the upgrade. These tools highlight elements that are modified in higher layers and that
might therefore require some action to merge the changes.
As an example, the item number is an extended data type that exists in the SYS layer,
this field of a string, which is 20 characters in length. If a company that uses Microsoft Dynamics
AX requires 30 characters for their item numbers, the field length would be changed to 30
characters, and the change is saved in the Cust layer.
The item number data type now exists in both the SYS layer and the Cust layer. The Cust
layer is a higher layer, so when the application is compiled, the 30-character length is used. If in
a future version, Microsoft extends the length of the item to 40 characters, the upgrade tool
would highlight that there is a change in the SYS layer to 40 characters and that there is an
existing change in the Cust layer to 30 characters.
The developer would then have the option to keep the Cust layer change or delete the
Cust layer and revert to the new field length in the SYS layer of the new release.
In addition to layers, AX also uses the concept of models. A model is a logical grouping of
elements within a layer. Models help in situations where multiple ISV solutions or projects must
operate together. This architecture allows many solutions to coexist within each layer. An
element can exist in exactly one model in a given layer. The same element, though, can exist in
a customized version in a model on a higher layer.
New models are easy to create in the MorphX ID and are applied when modifying or
adding objects in the AOT.
Models can be exported, installed, or uninstalled from the model store. Models are
identified by a name and a publisher and can have a set of properties that can be changed,
including a version number.
Let's take an example to see how models work. A company has two lines of business.
They manufacture and sell medical products in one of the lines of business, and in the second
line of business, they also service specialized equipment to produce medical products.
In AX, the SYS layer would contain the base AX application. Solution A is an advanced
vertical solution for the production of food and drug products. Among other things, this solution
adds a new field to the item table to store the government approval number. This is stored in the
ISV layer and in the model called medical.
Solution B is an advanced vertical solution for managing the ongoing service of
equipment, which is sold to customers. This solution adds a new field for the default service
period. This is also stored in the ISV layer and in the model called service. You can use models
to view the modifications made by all of the ISV solutions and easily see where each change
originated.
You can create a model using the development workspace by clicking on tools, model
management, and then selecting create model. After that, you can enter the name of the model,
the company, the layer in which the model is in, the version number, a full description, and a
shorter description.
The combination of name and publisher makes a unique model. To change the current
model, you can use the status bar, click on the model, and select a new model.
Lesson 7: Licensing and Configuration

The basic security architecture in Microsoft Dynamics AX includes license codes and
configuration keys. License codes control the modules that can be used within Microsoft
Dynamics AX. If a license code for a module is not purchased, none of the functionality related
to that license code is available.
Configuration keys in Microsoft Dynamics AX control the functionality and features in the
system. These keys ensure that the AX solution is not cluttered with functionality that
companies do not use. Configuration keys have descriptions to describe the functionality
affected by enabling or disabling them. Each configuration key is attached to a license code, so
if the license code is not purchased, the configuration key is unavailable.
Each configuration key controls access to a specific feature, and once it's enabled or
disabled, the feature is automatically added or removed in the user interface. The underlying
tables attached to that configuration key still exist in the database but are not available from the
application.
Lesson and Module Summary

This module provided a high-level introduction to the Microsoft Dynamics AX architecture. We
looked at the three-tier architecture and the various components that make up this architecture
in a typical deployment. We then discussed a number of development concepts such as the
Application Object Tree, or the AOT, the MorphX IDE and the Visual Studio IDE. After that, we
talked about the model driven architecture of AX and how it enables more secure development
and faster upgrades.
Finally, we looked at the basic license codes and configuration keys architecture.
Module 1 Key Take Away
o Functional Features
Unified database across modules
Dimension based
Supports multi-currency and multi-language
o AX has a three tier architecture
Database
Application Object Server (AOS)
Clients
o Application Object Server is responsible for:
Security
Session Management
X++ Runtime
Web services
o Data Partitions
Help isolate data
One or more legal entities can be in each partition
Legal entities in one partition cannot see application data and global
application data from another partition
Partitions can still share system data such as application ports and
code
o Development Environments
Application Object Tree (AOT)
Used for majority of the development
Visual Studio
Used to write managed code, SQL Server Reporting Services

Reports and Enterprise Portal code
Code written in Visual Studio can be integrated back into the AOT
o Development Projects
Can be used to group modifications
Can be shared projects or private projects
o Licensing and Configuration
License codes enable modules that have been purchased
Configuration keys control functionality and features on a system wide

basis
o Model Driven Architecture
Layers help isolate code written in one layer from another layer
Customizations in a higher layer take precedence at runtime
Makes upgrades easier
Models are a logical grouping of elements within a layer. Allows

multiple solutions to co-exist. Models can be installed and uninstalled
from model store.
Module 1: Practices
Practice 1.1: Create a New Model and Development Project
Module 1: Things to think about:

__________________________________________________________________________________________
__________________________________________________________________________________________
_________________________________________________________________________________________
_________________________________________________________________________________________
_________________________________________________________________________________________
_________________________________________________________________________________________
_________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
_________________________________________________________________________________________
_________________________________________________________________________________________
Module 2: Data Dictionary

Module 2: Data Dictionary Video Transcript
This chapter introduces the tools and procedures used to create tables, data types, relations,
enums and views that are required in Microsoft Dynamics AX.
In this model, we'll look at the features of MorphX and the Application Object Tree in more
detail. Then we'll review the basics of working with tables in AX. After that, we'll talk in depth
about the primitive and extended data types that are supported in AX. Next, we'll look at
creating tables in AX, setting indexes, relations, and using base enums.
Finally, we'll learn how to create and modify views.
Lesson 2: Introduction to MorpX and the Application Object Tree

The Application Object Tree, or the AOT, is a tree view of all the application elements in AX. Each
branch node in the AOT contains a different application element type. Within the AOT, a
developer can create or modify AX application elements using simple drag and drop functionality.
The system has default settings for all of the application object properties.
This module focuses on the elements contained in the data dictionary node.
Some of the other application elements are discussed in later modules.
First, let's take a look at how to use the AOT. There are four ways of accessing the AOT.
The first is from Windows, and then selecting the new development workspace. The second is a
shortcut Ctrl+Shift+W. The third way of opening the AOT is by using the shortcut Ctrl+D.
The fourth way of accessing the AOT is from command prompt. You need to go to the
client bin directory of your Microsoft Dynamics AX installation and type AX32.EXE with the
development switch.
Let's open the AOT from the Windows new development workspace. When you select
that option, the development workspace, or the MorphX IDE, is opened, and you will see one
instance of the AOT that's been opened.
Let's look at some of the features of the AOT. You first have a toolbar with a number of
options. The first option on the toolbar is the open command. You can also use Ctrl+O. This
command is used to directly open elements from the AOT. For instance, you can select any of
the forms in the AOT and click open to open the particular form.
The next option is the properties sheet. You can also use the Alt+Enter shortcut. The
property sheet command opens the property sheet for the selected element in the AOT.
The third option is save all. This saves all of the pending changes in the AOT.
The fourth option is the import command. This is used to import XPOs from a file into AX.
XPOs are the standard way of exporting and importing elements from the AOT into the file
system.
The last command is the AOT is the compile option. This can be used to compile the
selected elements in the AOT.
There are also a number of commands that are available from the right-click menu. Let's
look at some of them. Depending on which node you right-click on, you will get different options.
For instance, if you right-click on a class, you have the ability to create a new class. All the
nodes in the AOT also let you open the node in a new window. Let's try this.
When you select open in new window, the selected node is opened in a separate instance
of the AOT, and this is very useful when you want to do drag-and-drop operations between
elements in the AOT.
The third option that's quite common is the export option that's available in the right-click
menu. This allows you to export one or more elements from the AOT into an XPO file.
Next, you have compile, which is available on some nodes, which support it. This
compiles the selected nodes within the MorphX IDE.
You also have the ability to find the nodes. Clicking on find brings up a find dialogue
where you can look for nodes that contain specific text or are named in a certain way and things
like that.
Some of the nodes also have additional properties or additional commands available. In
the add-ins sub-menu of the right-click menu, you have a number of different options. One
interesting option is the check best practices option, which lets you run the system defined best
practices on your customizations. We'll discuss some of the commands that are available a little
later in the course.
Let's now take a deeper look at the nodes that are available in the data dictionary. First
we have tables. Tables are used to store data in the system. Data is typically entered, edited
and deleted through forms. We will discuss tables in a lot more detail later in this module.
Then we have maps. Maps are used to link tables. For instance, you might have two
different tables which are very similar in structure but have fields that are maybe named
differently but have the same data types. If you want to write a class that has some processing
logic against both of these tables, you could build a map that links the two tables that are similar
and then build your processing logic against this map.
Next, we have views. Views are read-only data representations that combine multiple
table objects. Views present a selected set of roles and columns by joining different tables
through data sources and relations between them. Frequently views represent a subset of fields
from a single table to simplify reporting.
Next, we have extended data types. These are customized data types based on the
primitive MorphX data types. We'll talk more about extended data types a little later in this
module.
Base enums are a list of literals that can be used throughout the development
environment in MorphX. The elements in an enum type are created by using the AOT where the
name of the type and the literals can be defined in the definition.
Next, we have license codes. License codes control which elements can be enabled or
disabled. If a license code is not purchased for a module, then any element attached to that
license code cannot be used.
Configuration keys enable or disable features in the application for all users. Each key
controls access to a specific feature, and once it's disabled, the feature is automatically removed
from the user view.
Next we have security keys. The security keys under the data dictionary are a legacy
from previous versions from AX. We will discuss the new security framework, the role-based
security framework, later in this course.
Table collections are used for virtual companies, and then finally, perspectives are a
collection of tables and views with properties set on them, which are used by AX to generate
analysis services cubes. Perspectives are described in more detail in a later course on reporting.
Lesson 3: Introduction to Tables

The AX SQL database created during installation contains the complete table repository. Tables
are at the core of the AX application and enable storage of a company's information and
transactions.
Tables storing data about company transactions, inventory, general ledger, journals and
more form the base of the Microsoft Dynamics AX application. These are referred to as base
tables, or application tables. Some frequently used tables include Cust table, which is use for
basic customer information, Vend table, which stores basic vendor information, Invent table,
which is used for the general inventory catalog, and Purch table, which is used for purchase order
creation.
Other tables in AX contain system data as well as metadata. System tables are
differentiated from application tables by the SYS prefix that starts the name of the table. You can
learn more about the application tables that are part of AX from the AX ERD website. This site
hosts entity relationship, or ER diagrams, for core tables of the application modules in Microsoft
Dynamics AX 2012 R3 CU8. You can use the site to quickly list all of the foreign key relationships
for a table involving both its child and parent tables. You can also use this site to determine
which module a table is in and which tables are in a particular module.
There are multiple elements in Microsoft Dynamics AX that define a table. Fields, field
groups, indexes, full text indexes, relations, delete actions, and methods. Fields can be used to
create or modify the physical columns in the database table. The fields defined within the fields
node are the columns belonging to the physical table. One note of caution here: Any fields
created, deleted or modified using MorphX in the table node are reflected in the database when
the changes are saved. This can potentially damage the AX application if not used correctly.
Field groups are logical groupings of physical database fields. AX uses field groups to
cluster fields into logical groups so that these groups can be used on forms and reports. An
example of such a group is the group measurement located on invent table.
Invent table holds data relating to products, and the measurement fields are height,
width, depth and density of the products.
If a modification is made to a field group, application elements that refer to the field
group are automatically updated to reflect the new content of the group. This is done using the
IntelliMorph technology that adjusts the layer of forms and reports, which use the modified field
group.
Adding new fields to a field group can be a powerful technique for updating forms that
use field groups within a field.
Every field on a table should belong to a group.
Next, indexes in AX are the physical indexes that exist on the tables in the database.
Indexes can accelerate a search on a table's data. More detailed information on indexes is
discussed later in this module.
Full text indexes contain location information about each significant word in a string field
of a table. Some queries can use this information to run more efficiently and to complete
quicker. These queries that search for words embedded in the middle of string fields. A full text
index can be created by creating a new full text index under the full text index node on the table
and adding fields to this index.
Relations define relationships between tables. AX supports a number of different
relations. We will discuss these in more detail later in this module.
Delete actions govern how data is handled when a deletion event occurs in a parent
table. There are four types of delete actions: None. With this delete action, the row in the table
is deleted but nothing occurs in the specified table. With a cascade delete action, the row in this
table is deleted and all related data in the specified table is also deleted. This ensures that there
are no orphan records that remain after deletion. With a restricted delete action, the row in this
table is deleted only if there is nothing that relates to it in a specified table. This is used when a
parent record should only be deleted when no child records exist, and the child record is
important to keep. For example, transaction records. The next delete action is
cascade+restricted. This works similar to restricted when the table is not part of a cascade
delete. Cascade+restricted works similar to cascade delete when the table is part of a cascade
delete operation from a parent table. Note it's really important to create delete actions and
specify them correctly to ensure data integrity.
Then we have methods. AX uses methods within a table to perform functions specific to
that table. Methods can be used for data lookups to other tables or manipulation of data during
specific events. Table methods are covered in more detail in later development courses.
Finally, AX 2012 introduces the concept of table inheritance. A table can extend another
table by specifying the extend property on the table. This means one table inherits all of the
fields and properties and methods of the table that it extends. New fields and methods that are
added to this extending table will not be visible from the parent table that it is extended from.
Lesson 4: Data Types: Primitive and Extended

AX uses data types to define how data is stored and restricted within the database. There are
primitive and extended data types that are supported by AX. The basic set of primitive data
types in AX map to underlying data types that exist in the physical database. These primitive
data types can be expanded to create extended data types which are reusable data types having
a specific definition.
Some of the primitive data types supported by AX include string, which is basically a set
of characters. Then you have integer, which is a number without a decimal point, and is 32 bits
wide. Then you have a real primitive type, which is a number with a decimal point. Date,
contains day, month and year. Time, contains hours, minutes and seconds. Then you have
UTCDateTime, which is a combination of date and time types, and it also contains time zone
information.
Then you have an enum data type, which is a set of literals that are represented
internally in the database as integers. A container data type is the composite data type that can
be a dynamic list of items containing other primitive data types or composite data types.
GUID is a globally unique identifier. Then you have Int 64, which is a number without a
decimal point but is 64 bits wide. And you have a Boolean data type, which only contains the
values true and false.
Extended data types, or EDTs, extend primitive data types or other EDTs. The benefit of
creating EDTs is the reuse of their properties. For example, the label for one EDT can be
inherited from the EDT that it extends. A table field that is created based on an EDT will also
inherit the properties from that EDT
A key benefit to using an EDT is more efficient maintenance. The properties of many
fields can change at one time by changing the properties on the EDT that these fields use.
Most fields in AX are based on EDTs.
In the next set of demonstrations and practices for this course, we will look at creating a
customization that can be used in veterinary surgery. The surgery procedure will need to keep
track of each animal that arrives, the owners of the animal, the species, the breed, and details of
each visit, including the date, reason, and the cost.
To do this we will need to create a number of new tables. First, the species table, which
will contain entries for dog, cat, and so on. Then we have the breed table, which contains the list
of breeds and is related to the species table. Then we have a pet table, which is related to the
customer table and the breed table. And finally, the visit transactions table, which will contain
details of each visit for each pet.
In this demonstration, we'll create a new extended data type to store the ID of the
species table. Let's jump into the AOT now.
I am going to open a new development workspace from the Windows new development
workspace option. In the AOT, let's right-click on the extended data types node and select new
string to create an extended data type of type string.
Next let's right-click on this Type 1 EDT and select properties to go into the properties
sheet. Here I'm going to change the name of the EDT to VetSpeciesID. I'll also create a label for
this EDT and call it SpeciesID. As best practice, it is a good idea to use the Label Editor to create
a new label and use the label ID here. That enables you to translate the labels into other
languages at a later point in time.
Next we're going to scroll down in the properties sheet. There's a property called extend.
What this does is it lets you extend this EDT from another EDT. We're going to extend the
SpeciesID from SysGroup EDT. The SysGroup EDT has a string size of 10, and so since we're
extending the vet SpeciesID from SysGroup, you'll automatically get a string size of 10.
After this, I can save the EDT from the AOT. When we get an option to synchronize the
database, I can click on yes. This takes a little bit of time, and once it's done, we're ready to
start using the EDT.
With that, we are done with the demonstration to create a new EDT.
Lesson 5: Creating Tables

In this demonstration, we will create a new table that will store the records for the species.
There are two fields on this table called SpeciesID, which is an extended data type of
VetSpeciesID, and name, which extends from the name EDT. Let's take a look.
We'll first open a new development workspace and then expand the data dictionary node,
and then right-click on tables and select new table to create a new table. This creates a table
called Table 1. In the property sheet, let's change the name of this table to VetSpeciesTable.
We'll also change the label of this table to Species. Next we need to add a couple of fields to this
table. To do that, I'm going to close the property sheet, open a new AOT window by clicking on
the AOT window in the toolbar. I can alternatively press Ctrl+D. Then I'm going to expand the
extended data types, and then the first field we're going to add is the VetSpeciesID. Let's
expand the tables, the table VetSpeciesTable, and then drag the VetSpeciesID into the fields node
of the VetSpeciesTable. This creates a new field called VetSpeciesID. Let's open the property
sheet. We're going to change the name of this field to SpeciesID.
You'll also see that the extended data type for this field has been set as VetSpeciesID.
The next field we want to add to this table is the name field, so we are going to go into
the extended data types, find name, and then drag it on to the fields of VetSpeciesTable. With
that we're done with defining the table. We can save our changes. As soon as we save our
changes by pressing Ctrl+S, the table is synchronized into SQL. With that, we're done with the
demonstration to create a new table.
Lesson 6: Indexes
Indexes and databases are used to locate records. They are stored separately in the database
and contain a key that can be quickly located in the index and a reference to the record. For
example, the Cust Idx index of the customer table contains the account number of the customer.
The account number is unique and sequenced. This is then used to quickly look up the customer
record through the reference.
There are two types of indexes: Unique and non-unique. If a unique index is created
based on a column, AX ensures no duplicate key values occur in that column. Also, updates on a
column that contain a unique index, which violates the uniqueness of the column, cause an error.
Non-unique indexes are created for performance reasons. They provide a quick way of retrieving
data instead of performing a full table search of all the records in the table.
Do not create an index if it is not needed because they use system space and must be
updated every time data is created, edited or deleted. This can slow down the updating process.
However, in most cases, the performance gained when selecting records far outweighs the
performance lost when updating.
When an index is created, it is recommended to give the index a name reflecting the
names of the fields in the index followed by the suffix Idx. An index can be based on either one
or more fields that are part of the table the index is being created on.
Creating an index in AX always relates to the table where it's created. The index can only
be created on fields that exist in the table. These indexes can be unique or non-unique, and are
based on a single column or multiple columns that exist within the table. Let's take a look at how
to create an index on the SpeciesID field in the VetSpeciesTable.
Let's go into the AOT, and under data dictionary tables, we're going to find the
VetSpeciesTable. Here, right-click on the indexes node and select new index. This creates an
index called Index 1. Let's rename this index to SpeciesIdx. Then we're going to drag the
SpeciesID into the SpeciesIdx index, and then in the property sheet for the SpeciesIdx index, let's
set the allow duplicates to no, and we'll also set the alternate key to yes.
With that, we're done with creating a new index. Let's save the table. This concludes the
demonstration to create a new index.
A primary index is one or more columns that uniquely identify one record in a table from
all the other records. A primary index is a unique index for a table that is either a surrogate key
or one of the indexes that are marked as alternate keys. To set an index as a unique index, you
can set the index property called allow duplicates to no. To set an index as the alternate key,
you can set the alternate key property of the index to yes.
A typical example of a primary key is on the CustTable, where the customer's Account
Num field is used as the primary key. The Account Num field is used in the account Idx index,
which is a unique index. This index is then set as the primary index for the CustTable in the
properties of the table.
When a primary index is not specified, AX uses a surrogate key as the primary index. The
surrogate key is used on many of the relations between tables.
Let's now set the index created in the previous demonstration on the VetSpeciesTable to
be a primary index. The first thing we need to do is make sure that the SpeciesIdx index is a
unique index, so it has the allow duplicates property set to no, and also we want to make sure it's
marked as an alternate key, so the alternate key property is set to yes. To set the SpeciesIdx
index as a primary index, go into the VetSpeciesTable, and then find the primary index, property,
and change this to SpeciesIdx. Then save your changes, and with that, you're done with the
demonstration to set a primary index on the VetSpeciesTable.
Lesson 7: Relations
Relations between tables are used to associate roles in one table to roles in another table.
Relations are used to enforce business rules across tables. They can also be used to create auto
joins and forms, look up values in other tables, or to validate data by providing constraints. They
can also be used to automatically propagate changes from one table to another by defining
cascading relations, and they can be used to generate field help.
Relationships can be created between tables using MorphX. A key thing to note here is
that relations are defined within the AX application and not at the physical database level.
Under the relations node, you can create different types of relationships between the
parent table and other tables in AX. Normal specifies related fields in another table. Multiple
fields can be included in this relation. For example, the table logistics postal address has a
relation called state that defines the relation to the logistics address state table. The values
allowed in the state field are limited, depending on which country is entered.
Field fixed and related field fixed are conditional relations. Conditional relationships can
be created by adding a condition to a table relation. Only records that fulfill the condition are
included in the relation.
A condition on a relation filters the records on either the table that contains the relation
or the related table, depending on the type of condition. Field fixed specifies that the condition is
on the table that contains the relation. Related field fixed specifies that the condition is on the
related table.
Field fixed and related field fixed are normally an enum.
Foreign key specifies a correspondence between a foreign key field in the present table to
the primary key field in another parent table. A foreign key can be a primary key or a single field
alternate key. When it is a primary key, the relation is on the primary key field. For example, a
customer account. When it is a single field alternate key, the relation is on the surrogate key,
which is usually the rec ID
Let's now take a look at creating a relation between the breed and the species table. A
breed is related to the species table in that a breed of Labrador is related to the record dog in the
species table. You should not be able to have a breed of Labrador be related to a species of cat,
for instance.
Let's start with updating the VetSpeciesID EDT to set the reference table to be
VetSpeciesTable. To do this, I'm going to go into the data dictionary, extended data types, and
find VetSpeciesID. I'm going to right-click on this and go to the properties sheet and set the
reference table to VetSpeciesTable. Then we're going to expand the table references node, rightclick on table references, and create a new table reference.
Then we need to make sure that the related field is set to SpeciesID. After that we can
save our changes to be VetSpeciesID EDT. When we get a dialogue to synchronize the database,
I'm going to click on yes. At this point I can use the species -- VetSpeciesID EDT on the
VetBreedTable. To do this, I'm going to open a second AOT window, expand the tables, and
navigate to VetBreedTable. Here under fields, I'm going to drag the VetSpeciesID field into the
fields node. As soon as I do this, I'll get a dialogue asking me if I want to create a foreign key
relation, which is exactly what I want to do, so I'm going to click on yes.
This will automatically create a relation between the VetBreedTable and the
VetSpeciesTable, so if I go into the relations node and now see a new relation for VetSpeciesTable,
which says VetBreedTable.VetSpeciesID equals VetSpeciesTable.SpeciesID. I'm also going to
rename this field from VetSpeciesID to just SpeciesID. I can now save this table, and with that,
I've created and completed creating a relation. I could also have created a relation manually by
right-clicking on the relations node on the table. However, when we create a reference on the
EDT and set it as the primary key, once the EDT is added to the table, the system will
automatically prompt you to create a reference.
Lesson 8: Base Enumerations

Base enumerations, also called base enums, are predefined text values for a field that are
referenced through an integer value in the database. The screen shot shows the gender-based
enum with options for unknown, male, and female.
When referencing this enum in code, you can use the values unknown, male and female,
but when it's stored in the database, the database would store the corresponding integer value
of this enum.
Lesson 9: Views
An AX view is a virtual table that provides the data records and fields that are specified by a
query. Like a table, a view uses fields and rows to represent data records. However, the data in
a view is not stored as a database object but is dynamically created when the view is accessed.
A view uses a query to retrieve data fields from one or more database tables.
In AX you can use views wherever tables are used. For example, you can use a view in a
form, a report, or even in X++ code. Views are synchronized into SQL just like tables. When a
view is synchronized, the view definition is saved to the database. Synchronization of an existing
view causes the definition of that view to be dropped and recreated in the database.
Some of the benefits of views are that you can get focused data. A view is used to
retrieve and return only the data that is relevant for a particular user or scenario.
Next, a view enables the views of a complex query to create highly customized set of
data. For example, a view often represents data as a single table that is retrieved from multiple
joined tables and may use many conditions.
Furthermore, a view can improve performance by returning only the relevant fields to the
user. When a view is created, the view definition is generated and stored in the database. When
that view is then accessed, the view dynamically retrieves the data that satisfies the view
definition
Because of this, a view can provide better performance than calling an equivalently
complex query.

This module discussed the Microsoft Dynamics AX data dictionary and the related objects in the
Application Object Tree. We first looked at working with the AOT. After that, we discussed tables
and related artifacts such as data types, fields, field groups, indexes and relations that are
required to build tables. We looked at a set of demonstrations to create tables, to build a
customization for managing a veterinary clinic using AX.
Finally, we discussed the concept of views and how it can help present a simplified view of a
complex query.

o Introduction to MorphX and the AOT
AOT contains all the elements of the AX application.
Data dictionary contains elements related to the data model such as

Tables, EDTs, Maps, Enums, Views
o Tables
Store data
Synchronized with the SQL database
AxErd website contains information about data models
Delete Actions are important to set correctly
o Data Types
Primitive data types
Extended Data Types
Recommended to use EDTs
EDTs can extend from primitive types or other EDTs
o Indexes
Improve performance of reads from the database
Can be used to create primary indexes
Surrogate keys are based on RecId
o Relations
Used to associate data between tables
Enforce business rules
Create auto joins, lookups and validate data through constraints
Normal relation, Field Fixed, Related Field Fixed and Foreign Key
relations are supported
o Base Enums
Predefined set of values.
Can be referred to using a literal name in code
Stored as an integer in the database
o Views
Synchronized to SQL
Data retrieved dynamically at runtime based on the view definition
Can be used to retrieve focused data from complex queries from

multiple tables
Module 2: Practices
Practice
Practice
Practice
Practice
Practice
2.1:
2.2:
2.3:
2.4:
2.5:
Create a New EDT

Create a New Table
Create a Primary Index
Create a Relation
Add an Enum
Module 2: Things to think about:

__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
________________________________________________________________________________
Module 3: User Interfaces

Module 3: User Interfaces Video Transcript
This module discusses developing user interfaces using the AX model driven architecture without
having to write code. In this module, we'll look at using the features of MorphX and the AOT to
create user interfaces. We'll review the basics of working with forms in AX, then we'll talk more
about joining multiple data sources in a form. After that, we'll review how to create menu items
for forms. Next, we'll look at the various form templates that are available in AX. Finally, we'll
discuss the components of list pages and how to create FactBoxes.
Lesson 2: Forms
Forms are the primary method of interaction between AX and the end user. By understanding
and exploring existing forms, new forms can be developed while retaining the same look and feel
as standard AX forms.
Forms are composed of a few categories of elements: Methods, data sources, parts,
designs and permissions. Form methods are blocks of X++ code that, for example, are executed
when opening or closing the form.
Form methods are discussed in later development courses.
This module discusses data sources, designs and parts. The next module will discuss
permissions.
Several different standard form designs are available for use in different situations. To
better understand forms and their design, let's take a look at a few forms that are available in
the application.
In this demonstration, let's take a deeper look at a few of the forms that are available in
AX to understand the elements of a form. Let's start by taking a look at the CustTableListPage.
To do that, I'm going to go into the accounts receivable module, and under common, customers,
select the all customers menu item. This opens the CustTableListPage, customers list page, and
what you see is at the center of this list page is a grid which displays the list of customers.
Above this grid, we have a filter pane which I can use to filter the data that's shown in the
grid. For instance, if I want to show only customers whose name starts with Contoso, I could
type Contoso here and press enter, and this will filter the grid to only show customers whose
name starts with Contoso.
Above the filter pane, I have an action pane which has a set of action pane tabs, and
each of these action pane tabs have a set of buttons which help you perform actions related to
the particular list page.
Different list pages may have a different set of buttons.
For instance, on the customers list page, we have the ability to create a new customer,
edit the selected customer, maintain their -- set up their bank accounts and so on.
To the right of this list page are a set of FactBoxes. FactBoxes display information from
other tables that are related to the currently highlighted customer record.
At the bottom of this list page is a preview pane that displays additional information from
the customer table for the selected record.
As I change the selected record, the information in the FactBoxes and the preview pane
changes.
Let's now take a look at the design for this particular list page. To do that, I'm going to
select personalize, click on the information tab, and then click the edit button next to the form
name. We can see that the form name is CustTableListPage.
Clicking the edit button opens the CustTableListPage in the AOT. All forms have a similar
set of root nodes. They have methods, data sources, parts, designs and permissions. Data
sources contain the list of queries and tables from which the form sources its data
Let's expand the design node. We can now look at the action pane, and you'll notice that
the action pane has a set of action pane tabs which correspond to the action pane tabs on the
actual list page.
We have the home tab, the sell tab, the invoice tab and collect tab. Similarly, you have
the home tab, which is the customer, the sell, the invoice, and collect.
Expanding the home tab, we have a set of button groups such as new group, maintain
group, customer accounts group. This corresponds to the button groups on the home tab, the
new, the maintain and the accounts.
Expanding one of these button groups, we see a set of menu item buttons, the edit, edit
list and delete, which correspond to the edit, edit in grid and delete.
Then we have the grid control, which contains a set of string controls which are bound to
the corresponding fields on the table, and you have the same set of controls on the grid. You
have the name, the customer account and telephone, and if we look at the AOT, we have the
name, the customer account and the telephone.
Let's now take a look at a different form. To do that, we're going to take a look at the
detail form for customers. I'm going to hit edit on the Contoso Europe customer. This opens the
customer detail form. Here you'll notice that there's also an action pane at the top and a set of
FactBoxes on the right, but the center of this form is a set of fast tabs which display additional
information about the customer.
If we look at the design for this particular customer by clicking the personalize option,
and clicking the information tab, and selecting the edit button, you'll notice that the form is now
CustTable. Here we have a set of design elements. We have the action pane header, and then a
tab. The tab contains details, and then a tab header, which contains a set of tab pages. Each of
these tab pages corresponds to the fast tabs that you see on the form. For instance, we have
the general, address and communication tab pages, which are general addresses and contact
information on the customers form.
If we expand the general fast tab and look at the upper group and the identification
group, you'll see that there's an account number and a record type field. If we expand the
general, you'll see that there's an account and record type field here.
Let's now take a look at a simpler form. To do this, we're going to go into the sell tab and
click on sales price and then sales price. This opens the sales price form, which as you can see,
is a much more simpler form. There's a grid which displays data, and then a detail section at the
bottom that displays additional data based on what is selected in the grid.
Let's view this in the design node. Here again, we have a design, and then if we expand
the tab and look at the grid, you'll notice that there are a set of fields on the grid like the relation
and currency. These correspond to the fields on the grid like the relation and the currency.
With that, we come to the end of the demonstration on examining form design.
Because forms present data to users, they must provide a source for the data. These
collections of data are called data sources, and they link to the tables in the AOT.
For instance, when we expand the data sources node for the PriceDiscTable form and
view the properties for the PriceDiscTable data source, we will see a number of properties. For
instance, the allow create and the allow delete control whether you can create new roles or
delete old roles from the price agreement form. The table property specifies the table the data
source is based on, in this case the PriceDiscTable.
The index property controls the index that is used for sorting data within the form.
More than a single data source can be used on a form. The linking of data sources is
performed by using the join source properties. Joining data sources on a form is examined later
in this module. The InventDem data source on this form is joined to the PriceDiscTable, and the
system uses relations between the tables to join the records together. Expanding the
PriceDiscTable data source will display fields that list all of the fields on the table. Properties can
be set here to control the behavior of the field when it is used as a control on the form, including
allowing the field to be edited and whether it was visible or not.
In this demonstration, we'll create a form that will be used to view, create and edit
records in the VetSpeciesTable.
To create the form, let's go into the AOT. In the AOT, we're going to go into the forms
node, right-click on the forms node, and select new form. The form that opens, let's go into the
properties sheet and change the name of the form to VetSpeciesTable. We'll then go into the
data dictionary and find the VetSpeciesTable. To do that, I'm going to open the data dictionary in
a new window. I'm going to close the properties sheet to get some more space, expand tables. I
have the VetSpeciesTable. I'll then expand the forms node and drag the VetSpeciesTable into the
data sources node of the VetSpeciesTable form.
Then I'm going to expand the designs node and click on design, right-click, and say new
control, and select grid. This creates a new grid control for the VetSpeciesTable. I can then open
the VetSpeciesTable data source in a new window and then drag the fields name and SpeciesID
from the VetSpeciesTable data source into the grid.
For the design node, I'm going to change the property for the caption to species. I can
now save the changes to this form, and then let's open this form by right-clicking on the form
and selecting open. This lets us create new species. For instance, I can create a species called
cat with a SpeciesID called cat, then create another species called dog with the SpeciesID dog,
and press close. Let's take a look at the table, the VetSpeciesTable. Open this, and you'll see
that two new records got created for cat and dog in the table.
With that, we come to the end of the demonstration to create a new form. As you can
see, it's really easy to create new forms within AX and bind them to tables without having to
write any code.
Lesson 3: Joining Data Sources

In the previous demonstration and practice, we created two separate forms, one for
creating species and the other for creating breeds. Now, instead of creating two forms for the
species and breed tables, both tables could be placed on the same form and joined together to
make the viewing and creating of records simpler.
Let's try to do that now in a demonstration.
In this demo, we're going to modify the VetSpeciesTable form to add a second data
source. The second data source is going to be the VetBreedTable. This will let us edit both
species and breeds from just one form. To do this, the first thing we're going to do is find the
VetSpeciesTable form. Under data sources, you'll see that there's just one data source here, the
VetSpeciesTable. I'm going to add a second data source to the VetBreedTable. To do this, let's
open a new AOT window by pressing Ctrl+D. Then from the data dictionary, we're going to
expand tables and drag the VetBreedTable from the data sources -- from the tables into the data
sources. Then in the property sheet for VetBreedTable, we'll set the join source to be
VetSpeciesTable
The system will automatically use the relations created in the previous module to link the
correct records together.
After that, we're going to go into the designs node and right-click on the design and add a
new control, a grid control. We'll set the data source for this grid control to be VetBreedTable,
and then let's move this grid control down, and then we're going to add the field from the breed
table, the breed ID and the name into the new grid by dragging those fields into Grid 1.
We then want the two grids to be shown side by side. To do that, I'm going to go into the
design node and change the columns property from one to two. With this, I'm done with
modifying my form to add the second data source. Let's save it, and then open the form to take
a look.
The left-hand side shows data from the species table. On the right side, we see data
relevant to the selected species from the breed table. So if we, for instance, create a new breed
called Labrador for dog, when I go into cat, you'll see that there are no breeds for cat, but as
soon as I select dog, I'll see the breeds that have been created for dog.
If I go into the table for the VetBreedTable and open it, I'll see that the SpeciesID has been
set correctly to dog for Labrador.
With this, we conclude the demonstration on how to add a second data source to a form.
Lesson 4: Menu Items

You can use menu items to activate application objects from the user interface. Menu properties
include properties such as name, which is the name of the menu item, the label, which is what
appears for the menu item in the application, the object type, which defines the type of object
this item points to such as a form or a report, and the object, which is the actual object that this
item points to.
There are three types of menu items that can be created: Display menu items, which are
used for forms; output menu items, which are used for reports; and action menu items, which are
used for running processes or executing X++ code.
Output and action menu items are discussed in other development courses.
Display menu items open objects that appear on screen, typically forms. For example,
clicking the customer's menu item in the accounts receivable module opens the CustTable list
page form. This display menu item points to the form object CustTableListPage. There are two
important properties to notice: The object type is a form, and the object is CustTableListPage.
In this demonstration, we'll create a menu item for the VetSpeciesTable form and add this
menu item to the accounts receivable area page.
Let's start by expanding the menu items node. I'm going to open this in a new window,
and then we'll expand forms to find the VetSpeciesTable form. I'm going to drag the
VetSpeciesTable form on to the display node of the menu items. This creates a new menu item
for the VetSpeciesTable form.
Let's go into the properties sheet and change the label to species. We've now created a
menu item for the VetSpeciesTable form. Let's now add this menu item to the accounts
receivable menu. To do that, I'm going to go back to my first AOT, expand menus, accounts
receivable. We'll put this menu item on the setup section. I'm going to create a new submenu.
We'll call this submenu vet surgery, and we'll change the submenu name to vet surgery. I'm then
going to drag the VetSpeciesTable display menu item under vet surgery.
Let's now save our changes to the menu. I can then start a new application instance, go
into accounts receivable. You now see under setup a new submenu called vet surgery, and the
species menu item. If we select this, it's going to open the VetSpeciesTable form. With that, we
come to the end of the demonstration to create a new menu item.
Lesson 5: Form Templates

Form templates enable you to create the correct form type with the appropriate controls
and to keep the design consistent across the application. Let's review some of the templates
that are available in AX. The list page form template is used as a main entry into a module.
Then you have a details form master template, which is used to view and edit master data. The
details form transaction template can be used to view and edit transactional and worksheet data.
The simple list details template can be used for reference and setup data. Simple list templates
can be used for basic inquiries. Table of contents templates can be used for module
configuration parameters. Dialogue templates are used for quick user interaction, and then you
have the drop dialogue template, which can be used to enter or update a very small amount of
data.
AX ships with a number of forms that make use of these templates. Let's review
examples of these templates now within AX.
First, let's look at a list page template. An example of this is under accounts receivable,
common customers, all customers. This displays a list page for all of the customers. Then we
have the details form master template. An example of this is what you would find when you click
on edit customer. This lets you edit the details for a master record.
Then let's look at the details form transaction template. For this we're going to go back
into the application and go into sales and marketing, and then common, sales orders, all sales
orders, and then click on edit for one of the sales orders.
Then let's take a look at a simple list details. For this, we're going to go into general
ledger, setup, currency, and then click on currencies. Then we have a simple list template for
which we can find in master planning, and then under inquiries, go to processes, and then click
on planned orders log.
The next form template we'll look at is the table of contents form template, which we can
find under accounts payable, setup, accounts payable parameters. Here we have a set of items
on the left with content to the right.
Then we have a dialogue template, which we can find under product information
management, products, products, and then click on new product.
To create a form using a template, we can do this from the AOT. Let me open a new
instance of the AOT. And then under forms, we would select new form from template and select
the type of template that we want to use.
With that, we come to the end of the demonstration on the different types of form
templates.
Lesson 6: List Pages

List pages are the primary method of displaying data in AX. They can show lots of data from
many tables in a number of different formats. They have consistent designs and functions and
can easily be displayed in the Enterprise Portal. A typical list page consists of the following
elements: The grid displays a list of records. It displays only a few of the most important fields
for each record. The filter pane is used to enter search criteria. This filters the list in the data
grid to show only the records which an end user is interested in. The preview pane displays more
fields about the selected record. This helps to ensure you've selected the correct record in your
search.
FactBoxes display more information about the selected record from related tables. The
action pane contains menu items you can use to do typical tasks related to the highlighted
record.
In this demonstration, we'll learn how to add a menu item to an existing list page. Let's
take a look at how you can add the menu item to the pets form that we created in the practice to
the CustTableListPage form.
Let's first open the CustTableListPage, and then we'll open this in design mode. I'm going
to click on personalize, click on information and click edit. On this list page, I'm going to expand
the designs node, and on the action pane, I want to create a new action pane for vet surgery.
We'll create a new action pane tab, and move this tab one down, and then in the properties
sheet, I'm going to set the name to be apTabVet and set the caption to be vet surgery.
Next I'm going to expand the apTabVet and then look in the second AOT. I'm going to find
the menu item that we created before in the practice for the VetCustPetTable, and I'm going to
drag this into the button group. This creates a new menu item button for the VetCustPetTable.
I'm going to look at the properties for this, and then we want to set the data source property to
be CustTable. And then we'll also set the big property to yes.
Setting the data source property to CustTable makes sure that the currently selected
CustTable is passed on to the menu item, and setting the big property to yes makes sure that the
button that's displayed on the action pane is a big button.
Then we'll save the changes to this particular list page.
We can also set the normal image to a file. Let's pick one of the PNG images that are
there and then save our changes.
Let's now go back into the application workspace. Go into all customers, and open the
customers list page. You'll now see there's a new action pane menu item with a button for pets.
I can click on pets, and it's going to show me the list of pets for the selected customer, and it's
automatically set to customer account, so I can create a new pet. Let's select dog as the
species, and give a name to the pet.
If I select DE 001 and click on pets, it's going to show me the pets for DE 001. I've
already created a couple of pets. Now, you'll notice that it's only showing me the pets for DE 001
and not for US 027. This is done because we set the data source property on the menu item
button to be CustTable.
With this, we are done with the demonstration to add a menu item to an existing list page.
Lesson 7: FactBoxes
A FactBox is a small selection of data related to the current record in the list page. There
are three types of FactBoxes.
InfoParts have its own data source and a number of controls. They are limited in what
can be displayed. However, InfoParts are simple and quick to create and can also be displayed in
the Enterprise Portal.
A form part is a link to a form. The form can have the same controls as a standard form.
However, since this is displayed in a FactBox, adding too many controls can crowd the part.
Cues display a count of the number of records related to the current record in the list
page. For example, it might show the number of outstanding invoices for a customer.
In this demonstration, we'll create a new FactBox and add it to a list page. Let's create a
simple FactBox to display the customer specs.
Before we can create a FactBox, we first need to create a query. Since this FactBox is
going to show the list of pets for a customer, we're going to create a query that's going to be
returning data from the VetCustPetTable table that we had created previously in our practice. To
create a query from the AOT, you need to right-click on the queries note and select new query.
Then in the properties sheet for this query, let's rename the query to VetCustPetInfoPart. Then
we need to add the VetCustPetTable table into the data sources for this query. To do that, I'm
going to open a second AOT window, expand the data dictionary tables, and drag the
VetCustPetTable into the data sources node.
The next thing we need to do is set the fields dynamic property to yes. This makes sure
that all of the fields that are on VetCustPetTable are included in the query.
The next thing that we need to do is locate the VetBreedTable and add it as a data source
under VetCustPetTable.
Let's drag this VetBreedTable under the data sources of VetCustPetTable.
We are then going to set the dynamic property on the VetBreedTable to also yes, and
then on the VetBreedTable, we're going to set the relations property to yes. We now have a
query that's going to return all of the pets for a customer along with the information about the
breed for the given pet.
Now I can save this query by pressing Ctrl+S. After this, I can create a new InfoPart.
We're going to do that by expanding the parts node, right-click under InfoPart, and select new
InfoPart.
We're going to go to the properties sheet for this InfoPart, and I'm going to call this
VetCustPetInfoPart. For the caption, we're going to call this pets, and we're going to change the
query to be the query that we created, which is VetCustPetInfoPart. I've now created the
InfoPart, and I can expand the InfoPart.
On the layout node, I'm going to right-click on the layout node and select new group. On
this new group, we want to create a set of fields to display the name of the pet as well as the
breed of the pet. Because this is going to be a list of pets, I'm going to change the repeating
property to be yes. This makes sure that the InfoPart renders as a table.
Then I'm going to add a couple of fields to this InfoPart. The first field is going to be
based on the VetCustPetTable and the data field is going to be the name of the pet. The second
field is going to be based on the VetBreedTable, and the name field of the BreedTable will be the
data field.
We can now save the changes to the InfoPart. At this point we are ready to add the
InfoPart to our list page. Before we do that, we need to create a new menu item for the InfoPart.
To do this, I'm going to navigate to the menu items and then drag the InfoPart from the InfoPart
node into the display node of the menu items. I can now save this.
Next I'm going to locate the VetCustPetTable table and create a new index on customer
account. So far we've not created an index on CustAccount on VetCustPetTable. Adding an index
is going to make accesses to this table on the customer account number more efficient. So let's
create a new index. We'll call this index CustIdx, and then we're going to drag the CustAccount
as a field within the index.
Let's save changes to this table. And now let's add the InfoPart to the CustTableListPage.
To do this, I'm going to navigate to the form for the CustTableListPage in the AOT, and then I'm
going to drag the menu item that we created on to the parts node. We'll drag the
VetCustPetInfoPart on to the parts node of CustTableListPage. This adds the InfoPart on to the
CustTableListPage. I can now save the list page.
And then in the property sheet for the new reference, we're going to set the data source,
relation to the VetCustPetTable.CustAccount. Let's now save the changes to this list page and
then open the list page from AX. I'm going to go back into the list page, and you'll see there's a
new FactBox that shows the list of pets.
When I select U.S. 027 it's showing me that there's one pet. If I select DE 001, it's going
to show me the two pets that are part of the DE 001 customer.
With this, we come to the end of the demonstration on creating a new FactBox.

In this module, we discussed building user interfaces in the AOT. We first looked at the
various elements of a form and examined these for a selection set of forms in the AOT. Then we
saw how to create a new form and add a second data source to the form.
After that, we discussed the process for creating a new menu item for a form.
Next we reviewed the different form templates that are available in AX. Finally, we
examined list pages and discussed the process of creating FactBoxes.

o Forms
Contain Methods, Data Sources, Parts, Designs, and Permissions
Used to display data and manipulate data from the Application
Can set properties on data sources to control whether the form allows
create, delete, edit operations
o Joining Data Sources
One form can be used to display data from multiple datasources.
Use the JoinSource property to link datasources.
Specify the datasource on the grid or control
o Menu Items
Used to provide access to forms, reports etc. from within the

application
Action typically used for running processes
Display typically used for forms
Output typically used for reports
o Form Templates
Used to provide consistent design across application
Supports a number of out of the box templates:
List Page
Details Form Master
Details Form Transaction
Simple List Details
Simple List
Table of Contents
Dialog
Drop Dialog
o List Pages
Primary method of displaying data in AX. Can show lots of data from
many tables
Contain Fact Boxes, Action Pane, Grid, Filter Pane and Preview Pane
o Fact Boxes
Display data related to selected record
Info parts, Form Parts and Cues
Module 3: Practices
Practice 3.1: Create a Form

Practice 3.2: Create a Form from a Template
Things to think about:

__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
Module 4: Security
Module 4: Security Video Transcript

This module discusses the security architecture of AX and how you can use it to define access to
the AX application and data. We'll first describe the elements of role based security in Microsoft
Dynamics AX. Then we'll look at the process to set up a new user and assign the user to a role.
After that, we'll discuss how you can edit duties on a role and privileges on a duty.
Next we'll look at how to edit permissions assigned to a privilege. Finally, we'll discuss
how you can use the AX security framework to investigate the access granted to a user and
search for roles with access to a menu item.
Role based security provides an extensible framework for defining access to the Microsoft
Dynamics AX application and data. The security role relates to a job role that an end user has
within an organization. The role includes duties, privileges and permissions required to perform
the tasks required in that role.
The maintenance of roles and duties is typically undertaken by the system administrator
in the rich client. The maintenance of privileges and permissions is typically undertaken by a
developer in the developer workspace. The framework and related tools assist the security
administrator to ensure that the system is secure.
Lesson 2: Definitions
Let's take a look at some of the definitions related to the role based security framework.
Role based security is defined with the following base concepts: An end user is given one or
more security roles. A security role represents a behavior pattern that a person in the
organization can play. For example, you have the accounts receivable manager security role.
A security role includes one or more duties. A duty is a responsibility to perform one or
more tasks. Examples of the accounts receivable manager's duties are to maintain the customer
master and inquire into the chart of accounts. A duty can include one or more privileges.
Privileges satisfy the access that is required to perform a duty. For example, the duty of
maintaining the customer master requires privileges to maintain customer addresses and to
maintain customer bank accounts.
A privilege may in turn include one or more permissions. Permissions include the access
level to one or more securable objects that are required to perform the function associated with
an entry point. For example, the privilege of maintaining customers requires that we give full
control to the customer form, access through the entry point of a display menu item. It also
requires full control to create a new address, access to the entry point of an action menu item.
Let's review the security concepts again from within the AX application. We'll look at
entry points, permissions, privileges, duties and roles and how they relate with each other.
We'll start with looking at these concepts in the AOT, and first take a look at the concept
of entry points. An entry point is an element that is triggered by a user action to start a
particular function such as a form or a service. There are three categories of entry points
available in AX. The first is menu items, which point to forms, reports and classes that an end
user can access from the rich client.
The second category are web content items such as URLs or actions that an end user can
access from the Enterprise Portal.
The third category are service operations that are used in document service classes in
the Application Integration Framework, or AIF. AIF exchanges data with external systems by
sending and receiving XML documents.
Next let's take a look at permissions.
Permissions refer to the access levels that can be applied to securable objects such as
tables, forms, fields, reports or server side methods that are accessible through an entry point.
Permissions are maintained by a developer in the Application Object Tree.
Let's take a look at permissions on a particular form, on a specific form to understand this
better. We'll take a look at the permissions on the CustTable form in this example.
On the CustTable form, there is a node called permissions, which if we expand, we see
there are four different permissions that are possible. There's read, update, create and delete.
What this is saying is that this particular form, the CustTable form, can be opened in either read,
update, create or delete mode, and when it is opened in each of these modes, we can give
specific access to the various controls, stables, server methods and associated forms on this
particular form.
For instance, if the form is open in read mode, the user would have effective access of
read to the company info table. They would have effective access of read to CustTable and
effective access of read to the DirPartyPostalAddressView.
If we look at the permissions when the form is opened in update mode, the CustTable
provides effective access of update, but the user only has an effective access of read to the
DirPartyPostalAddressView.
There are a number of different effective access that are available to be set here. For
instance, you have no access; this implies that the user does not get any access to the data.
Read access implies that an end user can view data. Update access implies that an end user can
view and edit data. Create access implies that an end user can view, edit, create new data.
Correct access implies that an end user can view, edit, create, new and correct date effective
records without creating new records. And finally, the delete option implies that an end user can
view, edit, create, new and delete data.
Permissions that give access to reports or classes need to only have access or not have
access. Like I mentioned, reports are typically given read access, and classes are typically given
delete access.
Permissions that give access to tables or fields can make use of all the access levels. The
possible permission levels are defined on the entry point target. For example, a form might allow
permission levels to read, update, create or delete. The level to be granted to an end user is
defined on the permission itself.
Let's now take a look at privileges. You can find privileges under the security node in the
AOT. A privilege is a group of related permissions that are required to perform a duty. Privileges
can be assigned directly to roles. However, for easier administrative maintenance and also to
use desegregation of duties feature, it is recommended to group privileges into duties and then
assign duties to roles.
Privileges are typically maintained by the developer in the AOT. However, they can also
be maintained by a system administrator in the rich client. A best practice is for privileges to be
maintained in the AOT and to assign privileges to duties.
Let's take a look at a couple of examples for privileges. We'll continue with the CustTable
example. Here we're going to look at the privileges for CustTableMaintain and CustTableView.
The CustTableMaintain privilege has as entry points the CustTable menu item. If you look
at this entry point in the property sheet, you'll see that it's pointing to the CustTable menu item
display and providing access level of delete. What this means is if a user has the privilege for
CustTableMaintain through the duties or the role that he is assigned, then when they try to click
on the CustTable menu item, display menu item, they would open that target, which would be
CustTable, with a permission set of delete. They'd get all of the permissions that are defined on
the CustTable form under the delete node.
Now, if we look at the CustTableView privilege, we have the CustTable menu item as entry
point here, but you'll notice that the access level, when someone has the CustTableView
privilege, is read. What this means is if someone who has CustTableView access clicks on the
display menu item for CustTable, they would open the CustTable form with a permission level of
read.
Next let's take a look at duties. Before that, you'll also notice that you can have
permissions defined directly under privilege, but it's easier to define permissions on the target
item.
Let's take a look at duties. Duties are a group of related privileges that are required to
perform a task. Duties are usually grouped into process cycles, and process cycles are used in
the rich client to make it easier for a system administrator to view and find related duties when
setting up security.
Finally, we have -- under process cycle, you have a set of duties, and finally we look at
roles. Roles are a group of duties that are required by an end user to do his or her job based on
the end user's role in the organization. Roles can be organized into a role hierarchy in that a role
can contain sub-roles and inherit the permissions from the sub-role. For example, the accounting
manager role could be defined as a combination of a manager role and the accountant role. A
role hierarchy reduces the need for duplicating security access that makes access change
management simpler.
Now when a user is assigned a role, it is assumed that they would perform all of the
duties specified by the role, and that when performing a particular duty, they would get a set of
privileges, which in turn give them permissions to AX objects in a certain mode such as read,
update, create, delete and so on. With this, we come to the end of the demonstration to look at
the security concepts that make up the role based security framework in AX.
Lesson 3: Set up a New User

Before a user can access AX, they need to be set up as a new user within AX. Users are set up
using the rich client. They are typically imported from Active Directory. Once set up, a user is
assigned to one or more roles. An internal user is assigned to two specific roles in addition to his
or her functional role. The first is the system user role, which provides access to basic
functionality and tools so that the user can access and use base functions within Microsoft
Dynamics AX.
The second role is the employee role, which provides access to base functionality that all
internal roles can use. This includes functionality such as the employee self-service portal on the
Enterprise Portal.
Let's now take a look at the process for importing a new user from Active Directory into
Microsoft Dynamics AX. In this scenario, Tony has just started with Contoso in the accounts
receivable department. Chris, the IT engineer, is responsible for setting up new users and
assigning security. Chris has already set up Tony as a user in Active Directory, and now Chris
needs to give Tony access to Microsoft Dynamics AX.
Let's add Tony as a user in AX. To do this, first we need to open the Microsoft Dynamics
AX client.
To add Tony into AX, we're going to first start with the system administration module.
Within the system administration module, I'm going to navigate to common, users, and select
the users menu item to open the list of users. Here we want to import Tony from Active
Directory, so I'm going to select the import users button. This brings up the Active Directory
import wizard. Let's select next, and then we want to search for Tony, who is an Active Directory
user, within the Contoso.com domain. So I'm going to select Contoso.com and specify Tony for
the first name and click next. We're going to select the first user in the list and click next.
And then I'm going to select Tony again in the select users form and click next.
We now need to give an assigned set of roles to Tony. Chris is not yet sure what level of
access Tony needs, and so Chris is only going to give Tony the system user and the employee
role. After this, we're going to select next, and we want to assign Tony the same profile in all
companies. Here we're going to select the account receivable administrator as the profile.
This profile defines the role center that Tony sees on his home page.
Tony would in this case -- we have assigned Tony to be the -- to see the accounts
receivable administrator role center page in all of the companies that Tony will have access to.
We're going to click on next, and we're done with this wizard. I'm going to click finish. With that,
Tony will be imported into AX as a user.
Let's look for Tony. And we see that Tony is created as an Active Directory -- created from
an Active Directory into AX.
Lesson 4: Assign a User to a Role

Roles are typically maintained by the system administrator in the rich client. However, they can
also be maintained by a developer in the AOT. The security roles form, available in the rich
client, displays all of the roles that are defined in the application and the duties that are
associated with each role.
This form is accessible from the system administration module under setup, security,
security roles. New roles can also be created from the security roles form.
Once created, roles and associated duties can be viewed not just from the rich client but
also from the security node within the AOT.
Let's now take a look at how to add a new role to an existing user. In this scenario, Chris,
the IT engineer, is advised that Tony, who recently joined Contoso, is the new accounts
receivable manager. Chris needs to assign that role to Tony's user account.
To assign a role to Tony, we need to go back into the system administration module. In
the system administration module, Chris would click on the users form to open the list of users.
Here Chris would need to find Tony in the list of users, and then can double click on Tony to edit
the role assignments. Here we notice that Tony has access -- is assigned the employee and the
system user role. This was done when Chris imported the user using the import wizard in the
previous demonstration.
To assign a new role, we can click on the assign roles button, and here we want to assign
the accounts receivable manager role to Tony. So I'm going to select that role and click OK.
Once I do that, Tony has been assigned the accounts receivable manager role, and I can close
this form.
We can now log in to AX as Tony to see the access that we have. I'm going to run AX as a
different user, and then log in as Tony. You'll now see that Tony has limited access to the system
administration module, but has full access to accounts receivable and a few other modules that
are in AX. So we've successfully assigned Tony to the accounts receivable module, and with that
we conclude this demonstration.
Lesson 5: Change Duties on a Role

The system administrator maintains the assignment of duties to roles in the rich client.
However, this activity can also be done by a developer in the AOT. Duties can be added or
removed from a role in the security roles form that's available in the rich client.
Duties assigned to a role can also be edited in the security node of the AOT.
Let's now take a look at how you can add duties to an existing role. In this scenario, Tony
will be working closely with service related customers, and so he needs access to view service
orders which is not included in the standard accounts receivable manager role. Chris is asked to
add the service order access to the accounts receivable manager role.
To add a duty to an existing role, we need to use the security roles form in the system
administration module. So let's go there. The security roles form can be found under system
administration, setup, security, security roles. This form displays all of the roles in the system on
the left-hand side, and for the selected role, it displays the role content, which is a set of duties
that are part of this particular role.
Since we want to modify the accounts receivable manager role, I'm going to select that
role and click add, to add the duty. The inquire into service orders duty is part of the conversion
cycle, so I'm going to expand this and find the inquire into service orders. We expand this, and
we can see all of the privileges that are a part of this particular duty. We're going to select the
inquire into service orders and click on close.
With that, we've added the inquire into service orders to the role content for the accounts
receivable manager. Duties can also be assigned to a role in the security node under the roles
node in the AOT.
Here you can drag-and-drop duties from the security duties node to the role. Just note, if
you make changes to roles from within the rich client, to see these changes, you may need to
refresh the elements in the AOT so that the changes made in the client are visible. To do that,
you can clear the caches by using the tools menu under caches and selecting refresh elements.
With this, we are done with the demonstration to add duties to an existing role.
Lesson 6: Change Privileges on a Duty

The assignment of privileges to duties is maintained by a developer in the security node
of the AOT. The security privileges form available in the rich client displays all duties defined in
the application and the privileges associated with each duty. Duties are grouped by process
cycle to make them easier to find. This form can be accessed from the system administration
module under setup, security, security privileges in the rich client application.
Let's now take a look at how to add a privilege to a duty. In this scenario, Chris is asked
to add access to the service order margin report for everyone who has access to view service
orders. Chris realizes that the best way to do this is to add a privilege with permission to access
the report to the inquire on service order duty.
Let's take a look at how you can do this within AX.
To add a privilege to a duty, we're going to go into the AOT. In the AOT, we're going to
find the duty, SMA ServiceOrderProgressInquire. This is located under the security node, duties,
SMA ServiceOrderProgressInquire. We want to now add the SMA ServiceOrderMarginGenerate
privilege to this duty. To do this, we're going to open a second AOT and find the privilege from
the privileges node. I'm going to look for SMA ServiceOrderMarginGenerate, and then I'm going
to drag this privilege into the SMA ServiceOrderProgressInquire. Once I do that, I can save the
duty, and with that, we are done with modifying a duty to add a privilege.
Lesson 7: Assign a Permission to a Privilege

The assignment of permissions to privileges is typically maintained by a developer in the AOT.
However, this can also be maintained by a system administrator using the security privileges
form in the rich client. Menu items and web content items can be dragged and dropped on to
the entry point node on a privilege in the AOT. The permission level can then be set on these
entry points using the property sheet.
Let's now quickly take a look at how to examine the permissions on a duty. In this
scenario, Chris wants to view the permissions included in the privilege for maintaining customer
records financials, which is assigned to the duty maintain customers.
To look at the permissions, let's expand the security node and navigate to the privileges,
and we want to look at the privileges for the CustTableMaintain privilege. Here if we expand the
privilege, we can see that there are entry points. If we expand the entry points and find the
CustTable entry point and look at the property sheet, we'll see that this entry point is for the
display menu item called CustTable, and the access level that's granted is delete.
If we now take a look at the CustTable form, we'll notice that there are permissions for
read, update, create and delete. What the privilege CustTableMaintain grants to a user is access
to the CustTable form in delete mode. The permissions that the user has when they open the
CustTable form in delete mode are specified under the form, under the delete section of the
permissions node.
Lesson 8: Investigate Access

Auditing security can be a difficult task. AX provides a lot of good security tools to assist in this
process. The security roles and the security privilege forms in the rich client provide FactBoxes
that give further information about the relationships between permissions, privileges, duties and
roles. In addition, there are tools available within the AOT to view from a menu item all of the
related security roles and objects. This is useful if you need to know all the users who have
access to a particular form, report or action.
Let's do a quick demonstration on how to view all of the roles with access to the
CustTableListPage.
We're going to find the CustTableListPage menu item, and then from there find the related
security roles that have access to the CustTableListPage. To do this, I'm going to expand the
menu items. The CustTableListPage is under the display node, and I'm going to look for the
CustTableListPage. I can then right-click on this list page, and under add-ins select security tools,
and click on view related security roles. This displays a list of all roles with access to the
CustTableListPage.
If we choose, we can also click on export to Microsoft Excel, to export this list to Excel.

This module discussed the AX security framework. We reviewed the security concepts such as
roles, duties, privileges, permissions and entry points. We then discussed a number of securityrelated activities such as creating a new user and assigning roles to a user.
Next, we looked at modifying duties in a role, editing privileges assigned to a duty, and
editing permissions assigned to a privilege. Finally, we looked at how you can use the AX
security tools to search for roles that have access to a menu item.
o Definitions
Roles
Duties
Privileges
Permissions
Entry Points
o Setup a new User
Integrated with Active directory
Done in rich client
Assigned to one or more roles
System user and Employee roles used
o Assign a User to a Role
Typically maintained by system administrator in rich client but can also

be maintained by developer in AOT
Duties are associated with each role
o Change Duties on a Role
Typically maintained by system administrator in rich client but can also

be maintained by developer in AOT
Duties can be edited using Security roles form in client or using

Security node in AOT
o Change Privileges on a Duty
Typically maintained by developer in AOT
Duties grouped by process cycle
Can be viewed from Security privileges form in the client
o Assign a Permission to a Privilege
Typically maintained by developer in the AOT
Permission level set on the entry point
o Investigate Access
Security roles and Security privilege forms can be used to provide

information about relationships between roles, duties, privileges and
permissions
Tools available in the AOT to investigate access
Module 4: Practices
Practice 4.1: Create a New Security Role
Things to think about:

__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
Practices
Practice 1.1: Create a New Model and Development Project
Scenario
The following step procedures and practices will demonstrate how to create a modification that
can be used in a veterinary surgery. The surgery procedure will need to keep track of each
animal that arrives, the owners of the animal, the species, the breed, and details of each visit
including the date, reason and the cost.
In this practice you will create a model and a development project to keep your modifications
organized. During the remainder of the course, any elements you modify or create should be
added to this project.
Isaac, the Systems Developer, needs to make a number of modifications to the system. He wants
to be able to group all the elements he creates and modifies together in one place, and also
make it easy to move the modifications to test and production systems later.
Step by Step
1. Create a model for Dynamics AX Development I training practices
a. Click Tools > Model Management > Create Model.
b. Enter Dev1 in the model name, your name in the publisher and
Dynamics AX Development I training practices in the description.
c. Click OK.
d. Click Close on the infolog dialog.
2. Create a project for Dev I training
a. Press Ctrl-Shift-P to open the development projects window.
b. Right-click the Shared node and select New > Project.
c. Rename the project to Dev I Training.
Practice 2.1: Create a New EDT

Scenario
Create a new Extended Data Type(EDT ) that will be used for the breed Id. Set the label and help
as appropriate. Ensure the size of the field is consistent with the standard application.
Step by Step
1. Create an EDT for VetBreedId
a. Open a new development workspace.
b. In the AOT, expand the Data Dictionary node.
c. Right-click the Extended Data Types node.
d. Select New > String. A new EDT called Type1 is created.
e. Right-click Type1 and select Properties.
f. Modify the property Name to VetBreedId.
2. Extend from SysGroup and change label to Breed Id
a. Modify the property Extends to SysGroup.
b. Modify the property el to Breed Id.
c. Close the property sheet and click Save in the AOT to save your changes.
d. On the Database Synchronization dialog, click Yes.
Practice 2.2: Create a New Table

Scenario
Create a new table that will store the breed of the pet. The table should have the fields BreedId
(type VetBreedID) and Name (type Name).
Step by Step
1
Create VetBreedTable
d. Open a new development workspace.
e. In the AOT, expand the Data Dictionary node.
f. Right-click on the Tables node and select New Table. A new Table
called Table1 is created.
g. Right-click Table1 and select Properties.
h. Modify the property Name to VetBreedTable.
i. Modify the property el to Breed.
j. Close the property sheet.
3. Add VetBreedId and Name to VetBreedTable
a. Press Ctrl-D to open another AOT. Ensure window is not maximized by

clicking the restore down button to enable you to view both AOT
windows.
b. Expand the Data Dictionary node.
c. Expand the Extended Data Types node.
d. Locate the VetBreedID EDT.
e. Drag the VetBreedID EDT to the Fields node of the VetBreedTable
table. A new field called VetBreedId is created.
f. Right-click the VetBreedId field and click Properties.
g. Note that the Extended Data type for this field is set to VetBreedId.
h. In the Name property, set the name of the field to BreedId.
i. Close the property sheet.
j. Locate the Name EDT in the second AOT.
k. Drag the Name EDT to the Fields node of the VetBreedTable table. A
new field called Name is created.
Practice 2.3: Create a Primary Index

Scenario
Set the index created in the last practice as a primary index for the table. Create a primary index
for the Breed Table.
Step by Step
1
Create Index called BreedIdx

l. Locate the VetBreedTable table in the AOT.
m. Right-click the Indexes node in the table and select New Index. A new
index Index1 is created.
n. Rename the index to BreedIdx.
o. If you used the property sheet to rename the index, close the property
sheet.
4. Add BreedId to the Index and make it a primary index

a. Drag the field BreedId to the index BreedIdx node.
b. To set as a unique index, in the properties sheet for the BreedIdx
node, set the property AllowDuplicates to No.
c. In the properties sheet for the for the BreedIdx node, set the property
AlternateKey to Yes.
d. Close the property sheet and click Save in the AOT to save your
changes.
e. In the property sheet for the table, set the PrimaryIndex property on
the table to BreedIdx.
f. Close the property sheet for the table.
Practice 2.4: Create a Relation

Scenario
Create a new table that will store data about the pets belonging to each customer. The table will
need to have the following fields: Customer Account (Type CustAccount), PetName (Name),
Species (VetSpeciesId), Breed (VetBreedId). You should create two relations - one a foreign key
to the species table, and one a normal relation to the breed table so that it is limited based on
the species field entered.
Step by Step
1. Create VetCustPetTable
a. Open a new development workspace.
b. In the AOT, expand the Data Dictionary node.
c. Right-click the Tables node and select New Table. A new Table called
Table1 is created.
d. Right-click Table1 and select Properties.
e. Modify the property Name to VetCustPetTable.
f. Modify the property el to Pets.
g. Close the property sheet.
2. Add CustAccount, VetSpeciesId, Name and VetBreedId fields to the
VetCustPetTable
a. Press Ctrl-D to open another AOT.
b. Expand the Data Dictionary node.
c. Expand the Extended Data Types node.
d. Locate the CustAccount EDT.
e. Drag the CustAccount EDT to the Fields node of the
VetCustPetTable table.
f. Locate the VetSpeciesId EDT.
g. Drag the VetSpeciesId EDT to the Fields node of the
VetCustPetTable table. A new field called VetSpeciesId is created.
h. Right-click the VetSpeciesId field and click Properties.
i. In the Name property, set the name of the field to SpeciesId.
j. Close the property sheet.
k. Locate the VetBreedID EDT.
l. Drag the VetBreedID EDT to the Fields node of the VetCustPetTable
table. A new field called VetBreedId is created.
m. Right-click the VetBreedId field and click Properties.
n. In the Name property, set the name of the field to BreedId.
o. Close the property sheet.
3. Create a relation to the VetBreedTable
a. Right-click the Relations node on the VetCustPetTable node and
select New Relation.
b. In the properties sheet for the new relation, set the Name property to
VetBreedTable and the Table property to VetBreedTable.
c. Right-click the VetBreedTable relation, select New > Normal.
d. In the property sheet for the new normal relation, set the Field to
BreedId and the RelatedField to BreedID.
e. Save your changes.
Practice 2.5: Add an Enum

Scenario
The pet table needs to store whether the animal is male or female.
Add the Gender Enum to the VetCustPetTable table.
Step by Step
1. Locate the Gender enum in the Base Enums node in the AOT.
2. Drag the Gender enum to the Fields node in the VetCustPetTable table.
3. Save your changes to the table.
Practice 3.1: Create a Form

Scenario
Create a new form to display and edit breed records.
Create a new form that can be used to view, create and edit records in the VetBreedTable table.
Step by Step
1. Create a form called VetBreedTable
a. In the AOT, right-click the Forms node and select New Form
b. Rename the form to VetBreedTable.
c. In a second AOT, locate the table VetBreedTable.
2. Add the VetBreedTable table to datasources
a. Drag the table VetBreedTable to the DataSources node on the
VetBreedTable form.
3. Add the BreedId and Name to the design
a. Expand the Designs node on the VetBreedTable form.
b. Right-click the Design node and select New Control > Grid. A
new Grid control is created.
c. Expand the DataSources > VetBreedTable > Fields node.
d. Drag the fields BreedId and Name to the grid control.
e. On the properties sheet for the Design node, in the Caption
property, enter "Breed".
f. Save your changes to the form.
4. Open the form by pressing Ctrl+O.
Practice 3.2: Create a Form from a Template

Scenario
A form is needed to view which pets belong to which customers. The form will be called from the
customer form.
Create a form using a SimpleListDetails template. In the grid on the left it should show the Pet
Name and Gender from the VetCustPetTable table. In the details section on the right of the form,
it should show the Breed name. Additionally, create a menu item for the form, however do not
add the menu item to a menu - you will use the menu item in the next section.
Step by Step
1. Create a Form from SimpleListDetails template called VetCustPetTable
a. Right click the Forms node of the AOT and select New Form from
Template > SimpleListDetails.
b. Rename the form VetCustPetTable.
c. Drag the table VetCustPetTable from a second AOT to the

datasources node of the new form.
d. Set the data source property on the grid control on the form to
VetCustPetTable. The grid control can be found by expanding
Designs > Design > Group:Body > Group:GridContainer.
2. Add the BreedId, Name and Gender fields to the design
a. Drag the BreedId, Name and Gender fields to the grid of the designs
node.
b. Save your changes to the form.
3. Create a menu item for the form
a. Drag the VetCustPetTable form to the Menu Items > Display node
in a second AOT to create a menu item for the new form.
b. In the property sheet for the new menu item, set the label property to
Pets.
c. Close the property sheet and save your changes to the menu item.
Practice 4.1: Create a New Security Role

Scenario
June Low is employed in the new role of veterinary receptionist. June will be receiving patients at
the front desk and will need access to maintain customer information and pet information. She
will also need to view breeds and species. Chris, the IT Engineer, needs to create a new role for
the veterinary receptionist and add duties so that she can access these areas of the application.
June is already created in Microsoft Dynamics AX and is assigned the system user and employee
roles. Chris needs to assign her the new role.
Step by Step
1. Create a
a.
b.
c.
d.
2.
3.
4.
5.
6.
MaintainPets Privilege
Open the AOT.
Expand Security > Privileges.
Right-click Privileges and select New Privilege.
In Properties change the name to MaintainPets and the label to
Maintain pets.
e. In Properties change the name to ViewPetTypes and the label to
View pet types.
Add the VetCustPetTable menu item to the entry points with delete access
a. Expand Maintain pets to display Entry points.
b. Open a second AOT.
c. Expand Menu items > Display.
d. Drag-and-drop vetCustPetTable menu item to the entry points
node and specify Delete access in the property sheet.
Add the VetSpeciesTable menu item to the entry points with read access
a. Expand View pet types to display Entry points in the first AOT.
b. Drag-and-drop vetSpeciesTable menu item to the entry points node
and specify Read access in the property sheet.
Create MaintainPets duty
a. Expand Security > Duties.
b. Right-click Duties and select New Duty.
c. Rename the new duty to MaintainPets.
d. Set the label property to Maintain pets.
e. Drag-and-drop the MaintainPets privilege to the Maintain pets duty.
f. Drag-and-drop the ViewPetTypes privilege to the Maintain pets duty.
Add MaintainPets to the TaxRevenue process cycle
a. Expand Security > Process cycles.
b. Drag-and-drop the Maintain pets duty to the TaxRevenue cycle.
Create a VetReceptionist security Role
a. Open the Security roles form in the rich client & path is System
administration/Setup/Security/Security Roles.
b. Click New.
c. Specify the AOT name VetReceptionist and the description of the

Veterinary receptionist.
d. Click the Add button.
e. Expand Revenue cycle.
f. Select Maintain pets.
g. Select Inquire into customer master.
h. Click Close.
7. Assign June user to the Vet Receptionist role
a. Click Assign users in the Action Pane.
b. Select the Vet Receptionist role.
c. Click the Manually assign button.
d. Select June and click Assign to role.
e. Click Close.

80670AE AX2012R3CU8 DEV1 ReferenceMaterial

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

80670AE AX2012R3CU8 DEV1 ReferenceMaterial

Diunggah oleh

Hak Cipta:

Format Tersedia

Online Companion Guide

Module 1 Key Take Away.....................................................................................................................................11

Module 2 Key Take Away......................................................................................................................................19

Module 3: User Interfaces Video Transcript...........................................................................................21

Module 3 Key Take Away......................................................................................................................................26

Module 4 Key Take Away......................................................................................................................................32

Practice 2.5: Add an Enum....................................................................................................................................39

Module 1: Architecture Video Transcript

Lesson 2: Features of Dynamics AX

Lesson 4: Data Partitions

Lesson 5: Development Environments

Lesson 6: Model Driven Architecture

Lesson 7: Licensing and Configuration

Lesson and Module Summary

Module 1 Key Take Away

Unified database across modules

Supports multi-currency and multi-language

o AX has a three tier architecture

Application Object Server (AOS)

o Application Object Server is responsible for:

Help isolate data

One or more legal entities can be in each partition

Application Object Tree (AOT)

Used for majority of the development

Used to write managed code, SQL Server Reporting Services

Can be used to group modifications

Can be shared projects or private projects

o Licensing and Configuration

License codes enable modules that have been purchased

Configuration keys control functionality and features on a system wide

o Model Driven Architecture

Customizations in a higher layer take precedence at runtime

Makes upgrades easier

Models are a logical grouping of elements within a layer. Allows

Module 1: Things to think about:

Module 2: Data Dictionary

Lesson 2: Introduction to MorpX and the Application Object Tree

Lesson 3: Introduction to Tables

Lesson 4: Data Types: Primitive and Extended

Lesson 5: Creating Tables

Lesson 8: Base Enumerations

Lesson and Module Summary

Module 2 Key Take Away

AOT contains all the elements of the AX application.

Data dictionary contains elements related to the data model such as

Synchronized with the SQL database

AxErd website contains information about data models

Delete Actions are important to set correctly

Primitive data types

Extended Data Types

Recommended to use EDTs

EDTs can extend from primitive types or other EDTs

Improve performance of reads from the database

Can be used to create primary indexes

Surrogate keys are based on RecId

Used to associate data between tables

Enforce business rules

Create auto joins, lookups and validate data through constraints

Predefined set of values.

Can be referred to using a literal name in code

Stored as an integer in the database

Data retrieved dynamically at runtime based on the view definition

Can be used to retrieve focused data from complex queries from