Download - Ax40 Enus Ins 01
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 1/28
Chapter 1: Overview
Page 9
CHAPTER 1: OVERVIEW
Objectives
The objectives are:
• Explain the installation improvement areas within Microsoft
Dynamics™ AX 4.0.
• Distinguish between core and additional roles.
• Examine the improvements made to the database, file server,
Application Object Server (AOS), and the client.
Introduction
This section gives a basic overview of the new technical features in Microsoft
Dynamics AX 4.0. Installation improvements help Microsoft Dynamics AX 4.0
increase security in the product by removing the 2-tier and 3-tier rich installation
and integrating with Microsoft®
Active Directory®. Additionally, database
improvements help increase the performance, scalability, and user experience
through the following:
• Index: provides enhanced changes to data consistency
• RecID: increases performance and scalability
• Unicode: provides more language options
Additionally, this section examines the improvements made to the file server,
Application Object Server (AOS), and the client to show how these
improvements help enhance the user experience.
This section offers a comparison between the two different types of installation:
the single computer install and the custom install, and discusses when to use
them. Finally, there is a brief description of the computer roles in the Microsoft
Dynamics AX 4.0 environment.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 2/28
Installation & Configuration for Microsoft Dynamics AX 4.0
Page 10
Scenario
Partners want to understand changes that were made to Microsoft Dynamics AX
4.0 in order to help prepare them to install, upgrade, and sell Microsoft Dynamics
AX 4.0.
The VAR system implementer wants to understand the changes to the database
and setup procedures so that he or she can be proficient in installing and
implementing Microsoft Dynamics AX 4.0.
VAR salespeople want to understand the differences between Microsoft
Dynamics AX 3.0 and Microsoft Dynamics AX 4.0. This will help them in
providing new features and benefits to potential customers.
Installation Improvements
There are many noticeable changes in the installation of Microsoft Dynamics AX4.0. However, users may not recognize some of the changes such as:
• The use of 3-tier installation only
• Tighter integration with Active Directory
A less noticeable change is that the 2-tier and 3-tier thick installations are no
longer part of Microsoft Dynamics AX 4.0, where only the 3-tier thin installation
will be available.
The 2-tier and 3-tier rich installation options are removed to enhance security and
performance and also to ease installation of the product. Breaking away from the
2-tier and 3-tier thick installations helps in the following ways:
• Security enforcement can be better implemented by the AOS instead
of the clients.
• The numbers of computers that will access the application files are
limited to just the AOS computers.
Another major, yet unnoticeable change during setup is the integration with
Active Directory. This required integration enhances security and administration,
where users only have to log on to their computers to access Microsoft Dynamics
AX 4.0 (Microsoft®
Windows®
logon).
Active Directory integration also aides in user administration. To add a new user,
enter the user alias as it appears in the Active Directory, or use the Active
Directory Import Wizard built into Microsoft Dynamics AX 4.0.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 3/28
Chapter 1: Overview
Page 11
Select Installation Type
One noticeable change to the Microsoft Dynamics AX 4.0 setup is that the
installation runs from a single setup wizard for either distributed or single-
computer topologies. The Select installation type form is where the options for
Single computer installation or Custom installation (distributed) are located.
The Single computer installation simplifies the installation process for partners
and consultants. Successful installs no longer require a deep technical knowledge
of Microsoft Dynamics AX 4.0 architecture.
NOTE: Because of potential performance issues, do not use the Single computer
installation in a live environment. For a live installation the expectation is that each
component is installed on its own computer.
When implementers choose the Single computer installation, a single computer
will receive the following components:
• The database server • File server
• Object server
• Client, and
• .NET Business Connector
For salespeople, partners, and consultants who need a portable MicrosoftDynamics AX 4.0 installation, the Single computer installation is a simple way to
perform the setup.
FIGURE 1-1: SELECT INSTALLATION TYPE
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 4/28
Installation & Configuration for Microsoft Dynamics AX 4.0
Page 12
Implementers will use the Custom installation for live installations. Use the
Custom installation when installing:
• Each role on its own computer
• Additional object servers• An additional client computer
When implementers use the Custom installation in a live environment, the
expectation is that each role resides on a separate computer. This configuration
provides better performance and scalability over the Single computer
installation.
If implementing a distributed object server environment, the implementer is to
use the Custom installation to install each additional object server. The same is
true when installing additional client computers.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 5/28
Chapter 1: Overview
Page 13
Test Your Knowledge − Installation Improvements
Please answer the following questions individually or as a class.
1. List possible benefits and drawbacks of Single computer installation.2. What are some reasons for using a Single computer install at a
customer site?
Select Computer Role
Each computer in Microsoft Dynamics AX 4.0 has its own role. The role that
each computer plays depends on the Microsoft Dynamics AX 4.0 component
installed on that computer.
FIGURE 1-2: SELECT COMPUTER ROLE
Core roles are required components for Microsoft Dynamics AX 4.0 to function.
A core Microsoft Dynamics AX 4.0 system consists of:
• An instance of an Application Object Server (AOS)
• An application file server
• A database
• At least one client
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 6/28
Installation & Configuration for Microsoft Dynamics AX 4.0
Page 14
Without these elements the system will not run.
Table 1.1: Core Role Descriptions and Requirements, describes the typical
Microsoft Dynamics AX 4.0 components along with the requirements for each
core role.
Component Description Requirements
Database server The database server role
stores the Microsoft
Dynamics AX 4.0 data as
part of an existing database
installation.
For this role on a
Microsoft®SQL Server ®
database, setup creates or
connects to a database.
File server The file server contains the
Microsoft Dynamics AX 4.0
application files.
The files must be on a share
that can be accessed by all
computers that are running
Application Object Server
instances.
Object server The computer that runs theApplication Object Server
service controls all aspects
of Microsoft Dynamics AX
4.0 operation. During setup,
connections are established
to the database and file
servers.
For this role, Setup installs
• Application Object
Server instance
• Server Configuration
Utility
Client The computer that is runningMicrosoft Dynamic AX
Client will have the
Graphical User Interface(GUI) that links the user to
Microsoft Dynamics AX
4.0. During setup,
connections are established
to an Application Object
Server instance.
For this role, Setup installs:
• Microsoft Dynamic AX
Client
• Client ConfigurationUtility
TABLE 1-1: CORE ROLE DESCRIPTIONS AND REQUIREMENTS
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 7/28
Chapter 1: Overview
Page 15
Additional roles are a new concept starting in Microsoft Dynamics AX 4.0.
When implementers utilize the additional roles in the Microsoft Dynamics AX
4.0 installation, they have a host of new functionality available to them. Table
1.2: Additional Role Descriptions shows a list of the additional roles available for
Microsoft Dynamics AX 4.0 and a short description of each.
TABLE 1-2: ADDITIONAL ROLE DESCRIPTIONS
The Custom Client is the Business Connector within Microsoft AX 4.0. The
Business Connector is a Microsoft Dynamics AX 4.0 component that enablesapplications to interact with Application Object Server instances. Microsoft
Dynamics AX 4.0 includes two versions of Business Connector: the .NET
Business Connector and the COM Business Connector.
.NET Business Connector
The .NET Business Connector provides a set of managed classes that allow for
easier access to X++ functionality in Microsoft Dynamics AX 4.0. The.NET
Business Connector is a stand-alone component used in the development of third-
party applications that integrate with Microsoft Dynamics AX 4.0.
COM Business Connector Developers have the option to use the COM Business Connector component to
enable applications running outside Microsoft Dynamics AX 4.0 to interact with
an Application Object Server (AOS) instance. The COM Business Connector
provides a set of COM interfaces to X++ functionality in Microsoft Dynamics
AX 4.0 and is included for backward compatibility only.
Component Description
Reporting server A computer that has reporting server installed provides:
• Additional reporting functionality
• Additional analysis functionality
Enterprise Portal
Server
A server that hosts an Enterprise Portal Web site to
access Microsoft Dynamics AX 4.0 functionality from
the Web.
Application
integration server
A server that is running the Application Integration
Framework (AIF) is:
• A document-based integration interface
• Used to create business-to-business or application-
to-application Microsoft Dynamics AX 4.0
solutions.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 8/28
Installation & Configuration for Microsoft Dynamics AX 4.0
Page 16
There are many changes to the Business Connector in Microsoft Dynamics AX
4.0, including:
• The addition of the .NET Business Connector to support applications
built with the Microsoft .NET Framework or ASP.NET.
• All versions of the Business Connector are now required to useMicrosoft Windows authentication.
NOTE: Any existing COM applications that use the Microsoft Dynamics AX 3.0 version
of the Business Connector must be written to use Windows authentication before theywill work with Microsoft Dynamics AX 4.0.
• The system installs the.NET Business Connector into the Global
Assembly Cache (GAC), and the COM Business Connector no
longer requires registration.
• The Business Connector Proxy is a previously created Windows
domain user account used to enable Business Connector to act on
behalf of unauthenticated Microsoft Dynamics AX 4.0 users.
Test Your Knowledge − Computer Roles
Please answer the following questions individually or as a class.
1. Provide an explanation of a computer role in a Microsoft Dynamics
AX 4.0 environment.
2. What are the differences between the core roles and the additional
roles?
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 9/28
Chapter 1: Overview
Page 17
Database Improvements
The database has undergone many changes to help improve performance, such
as:
• Improvements in the quality of indexes and index management for enhanced performance and scalability.
• A more optimistic formula for checking concurrency in database
rows when many users are performing forms-based updates
• Better language support by using Unicode
• RecID changes have increased the number of available RecIDs for
customer's data
Index Improvements
The index improvements are designed for improving the performance andscalability of Microsoft Dynamics AX 4.0, with specific focus on index
management. Creating well-formed indexes help make deadlocks disappear,
leading to increased query performance and scalability.
Although improving the indexes in Microsoft Dynamics AX 4.0 is important, it is
also important to document a process that can help developers create well formed
indexes. Such a document is being created and will address the following:
• Guidelines and rules for creating indexes
– Selecting the Index key columns
o Covering indexes
o Selectivity factor
– Tuning Indexes
– Helping to determine when an index is clustered or non-clustered
– Helping to correctly form join and search conditions
– Eliminating selects (unless it is for a form)
• How-to for using SQL Server tools
– Capturing business process activities with the Microsoft
Dynamics AX 4.0 Profiler
– Capturing database access activities of a business process in the
SQL Profiler
• How to use the SQL Server Index Analyzer to create well formed
indexes
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 10/28
Installation & Configuration for Microsoft Dynamics AX 4.0
Page 18
Optimistic Concurrency
User Interface (UI) based updates frequently involve:
• Loading data from the database
• Presenting the data to the user
• Saving the changes a user has made to the data
Because of the potential for a lengthy time span between loading and updating
data, database locks are usually not held. To ensure that the data remains consist
in a multiuser scenario, optimistic concurrency control (OCC) is frequently used
to detect if other users have changed the data before saving the changes to the
database.
Prior Microsoft Dynamics AX versions used pessimistic concurrency to control
locks on resources, as they are required, for the duration of a transaction. In this
case, unless deadlocks occur, the transactions can complete successfully. Someobstacles of the prior design:
• Requires a second read upon updating. This means another round-
trip to the database.
• Holds update locks in the database when performing in-memory
comparison of the updated columns instead of holding locks on
update. This expands the time the locks are held.
• Iterates through all the updated columns and performs the
comparison. This consumes extra computation time.
The new OCC implementation for UI based updates addresses the previouslymentioned concerns by adding a RecVersion column to all tables in the database.
This column identifies the version of a record (row) and is incremented every
time there is a row update. Upon updating, the RecVersion is sent in the update
statement to SQL Server and SQL Server checks to see whether there is an
update conflict by comparing it with the RecVersion in the database.
Benefits of using OCC are that it:
• Does not require a second read from the database, therefore saving a
round-trip to the database.
• Locks rows only when the system issues an update, making the
locking period shorter.
• Does not have to compute all columns during an update, as it is only
required to compare one column value.
• Enforces the correct consistency semantics on a per row basis when
strictly used.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 11/28
Chapter 1: Overview
Page 19
Unicode
For Microsoft Dynamics AX 4.0, the database is configured to use Unicode. The
use of Unicode is helpful because:
• A single Microsoft Dynamics AX 4.0 installation can support data in
many languages
• It adds support for Asia and some Eastern European regions
• It contains a better X++ platform for multilingual regions
The effects to the database of current Microsoft Dynamics AX 4.0 users are that:
• All character data (string and memo, this includes members of
containers) has to be Unicode
• All databases of older installations have to be converted to Unicode
before a user upgrading to Microsoft Dynamics AX 4.0.
• An upgrade preparation tool must be run against the database beforerunning the Microsoft Dynamics AX 4.0 upgrade checklist
RecID Improvements
The database counter for RecIDs is currently a 32-bit integer which allows for a
total of 4,294,967,296 IDs. Past versions allow small groups of RecIDs to
become lost due to system failures. These losses are seldom significant enough to
cause problems.
However, the data import utility can lose a large number of RecIDs quickly. For
example, if a Microsoft Dynamics AX 4.0 sample data import file contains36,848 records, it may consume up to 4,124,726 RecIDs on import. The
SysRecIdRepair utility within Microsoft Dynamics AX is used to reclaim the lost
RecIDs, but its effectiveness may be offset by how long it takes to run. To most
customers, running out of RecIDs is not a concern but there are several large
customers who may be affected.
When users change the RecID in the database from a 32-bit to a 64-bit integer
and allocate RecIDs by company instead of per database, it results in a significant
increase in the number of available RecIDs, from 4,294,967,296 to
18,446,744,073,709,551,615 IDs. RecID changes for Microsoft Dynamics AX
4.0 helps:
• Reduce the problems related to the Import feature
• Allow for the allocation of an almost unlimited number of RecIDs
• Handle allocation with the best possible performance and scalability
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 12/28
Installation & Configuration for Microsoft Dynamics AX 4.0
Page 20
Test Your Knowledge − Database Improvements
Answer the following questions individually or as a class.
1. Discuss the differences between optimistic and pessimisticconcurrency control. What are the benefits of using optimistic
concurrency control in Microsoft Dynamics AX 4.0?
2. Discuss why changing from 32-bit RecIDs to 64-bit can be useful. Is
this change something that will benefit all customers?
File Server Improvements
In a single environment, implementers can install multiple instances of Microsoft
Dynamics AX 4.0. Companies install multiple instances when they want to have
separate installations for the Live, Test, and Development environments. Each
instance of Microsoft Dynamics AX 4.0 consists of:
• An AOS
• Application file server
• Database that are not shared
• A client that can be shared
Administrators can then use the Microsoft Dynamics AX 4.0 Configuration
Utility to point the client to each different instance.
It is now recommended that the Microsoft Dynamics AX 4.0 Setup is used to
install all application file servers, instead of creating new applications by copyingthe standard application file directory and modifying it.
NOTE: Installing all application files by using Setup provides a consistent location for Microsoft to use when providing updates.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 13/28
Chapter 1: Overview
Page 21
Select Region
Select region is a new part of the file server installation. As part of the standard
file server installation, implementers can install tax and financial functionality for
the following list of countries:
Australia Austria Belgium Canada Denmark
Finland France Germany Ireland Italy
Malaysia Netherlands
New
Zealand Norway Singapore
South
Africa Spain Sweden Switzerland Thailand
United
Kingdom
United
States
TABLE 1-3: LIST OF COUNTRIES
However, if users need tax and financial functionality for additional countries,
they can be installed by using the form shown in Figure 1.3: List of Countries.
FIGURE 1-3: SELECT REGION
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 14/28
Installation & Configuration for Microsoft Dynamics AX 4.0
Page 22
In the Select region form, administrators can select which region to install by
highlighting that region in the Additional region form. Highlighting the region in
the left pane displays a list of the countries included in that region in the right
pane. In order to complete the installation of the additional tax and financial
functionality for that region, select Next.
NOTE: Microsoft Dynamics AX 4.0 supports only one additional region per installation.
Application Object Server Improvements
The Application Object Server (AOS) has received many improvements for
Microsoft Dynamics AX 4.0, including:
• The AOS load balancing has been replaced with an improved version
• The AOS is now a true Microsoft Windows service
• Improvements in communication between the client and server
FIGURE 1-4: CREATE AN INSTANCE OF APPLICATION OBJECT SERVER
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 15/28
Chapter 1: Overview
Page 23
AOS Load Balancing
One major improvement is that AOS load balancing has changed. The AOS
service is mission critical and having a fully functioning load balancing system is
essential to provide good availability and scalability for customers.
The AOS load balancing can be set up in one of two ways. Either the AOS
instances can be added to a cluster but run without a load balancer or the AOS
instances can be to a cluster with one of the AOS instances set to be a load
balancer.
If the cluster is set up without a load balancer, then the client configuration is
used to instruct the clients to connect to one or more AOS instances that have
load balancing enabled. The advantage to this scenario is that no extra hardware
is required. A disadvantage is if an AOS needs to be removed from the cluster
then all the clients connecting to that AOS have to be manually configured to
connect to a different AOS.
If the cluster is set up with a load balancer, then the client configuration will
instruct the clients to connect to an AOS that is set up to be the load balancer. An
advantage to this design is that when an AOS is added or removed from the
cluster the client configurations do not need to be changed. A disadvantage tothis type of system is that additional hardware may be required to set up a
computer as a load balancer.
Port Assignments
Each unique Application Object Server (AOS) Service named instance installed
on a single server is assigned a static port. The default port used for the first AOS
named instance in Microsoft Dynamics AX 4.0 is 2712, the same as it was with
Microsoft Dynamics AX 3.0. If there is a collision for the default port number or when a second, and subsequent, AOS Service named instance is installed on the
same server, the Microsoft AX 4.0 installer program will dynamically assign
another port number for the AOS Service named instance.
Ports for named instances may be changed through the AOS Configuration
Manager. If the port has changed for an AOS Service named instance, then it is
necessary to restart that specific AOS Service named instance.
If an instance of AOS Service is configured to listen on a static port, and that port
is in use by another program running on the server, the AOS Service will log an
error into the computer's event log.
True Windows Service
Another change for Microsoft Dynamics AX 4.0 is that the Application Object
Server (AOS) is now a Microsoft Windows service that runs in its own Windows
session instead of a separate executable file. The AOS now uses a standard
Windows service management user interface (MMC snap-in services.msc) for
configuration, control, and management of the service.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 16/28
Installation & Configuration for Microsoft Dynamics AX 4.0
Page 24
Implementing the AOS as a Microsoft Windows Service is useful because:
• Windows Service applications run in the security context of a
specific user account that differs from a user who is logged on or the
default computer account.
After installation of Microsoft Dynamics AX 4.0, the default user account has all the permissions that are required to access Microsoft
Dynamics AX 4.0 functionality.
• Eliminating the dependency on the Microsoft Dynamics AX 4.0
Server Manager removes a security threat by which an attacker can
send a command to the AOS to shut it down.
• A Windows Service application runs in its own Windows Session
and takes advantage of the Service Control Manager to maintain
status information and to provide the user interface for managing the
AOS.
• Windows Services can be configured to start at system startup or
upon demand, and they continue to run even when no user is loggedinto the system.
• Server status can be reported to the Windows event log. This lets
administrators view errors and warnings that can help in
troubleshooting problems.
Improved Communications
Previously, the Microsoft Dynamics AX Client and Server communicated with
each other using sockets. The Microsoft Dynamics AX 4.0 network
transportation layer uses the Microsoft remote procedure call (RPC) service, a
powerful technology for creating distributed Client/Server programs. This changeallows for:
• Runtime support for channel security
• Data serialization
• Client-side connection pooling
• Server-side thread pooling
• Asynchronous calls
• An exception-handling mechanism across the Client and Server
The amount of abstraction the RPC service provides makes it easier to identify
and implement potential performance improvements for Client/Server
communications. Finally, RPC service requires a formal contract between Client
and Server. This moves Microsoft Dynamics AX 4.0 one step closer to a true
Web service model.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 17/28
Chapter 1: Overview
Page 25
Test Your Knowledge − Application Object Server Improvements
Answer the following questions individually or as a class.
List two advantages of changing to a true Windows service. Discuss why these
changes are considered improvements.
Client Improvements
Select Display Language
All languages are automatically supported in the Application Object Server. The
only language decision to make during installation is for the default client
language. This improved language support speeds setup, reduces deployment
errors, and generally simplifies deployment.
FIGURE 1-5: SELECT DISPLAY LANGUAGE
NOTE: Select display language is only required for the first Microsoft Dynamics AX 4.0
client installed on a computer. Any other client installed on this computer automatically
uses the language selected on the Select display language form.
NOTE: Users can switch between display languages by changing the user settings in theMicrosoft Dynamics AX 4.0 client.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 18/28
Installation & Configuration for Microsoft Dynamics AX 4.0
Page 26
Select Help Language
With Microsoft Dynamics AX 4.0, it is now possible to install Help files for
multiple languages. Changing between languages is straightforward in the
Microsoft Dynamics AX 4.0 client. If additional help languages are needed, just
run the Setup program again and select the new language.
FIGURE 1-6: SELECT HELP LANGUAGE
NOTE: Users can switch between Help languages by changing the user settings in the
Microsoft Dynamics AX 4.0 client.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 19/28
Chapter 1: Overview
Page 27
Development Improvements
Version Control System
Microsoft Dynamics™ AX MorphX®, the Microsoft Dynamics AX 4.0
Integrated Development Environment, now has an integrated version controlsystem. Using the version control system is not required and if it is not used then
there won't be any change to how code was developed in previous versions. If the
version control system is used, then there are two major changes in the way
developers write code and documentation:
• Objects need to be checked out before they can be edited.
• There is a local copy of the entire the Application Object Tree
(AOT) stored on the client computer, in a repository folder. This is
composed of one .xpo file for each AOT object, and .ald files that
contain the labels.
The repository folder is kept in sync with local changes. Objects areupdated when they are checked out, or they can be synchronized
with the global repository in the version control system.
Microsoft Dynamics AX 4.0 is integrated with Microsoft Visual
SourceSafe 2005, but the version control functionality can be extended to use
other version control tools.
Key Technical Features
One Tool, Several Interfaces, and One Database
Microsoft Dynamics AX 4.0 is one tool with several interfaces and one database.Integration is straightforward and once the product is understood, users have all
they need to know to become a productive Microsoft Dynamics AX 4.0 user.
Layering
A layering system is used in the Application Object Tree (AOT) to ensure that
developers can make modifications and additions without interfering with the
application objects in the layers below the one being worked in. This also means
that all original components are available if there is ever the need to return to the
original functionality.
The concept of inheritance is central to the design of the AOT. Inheritanceinfluences two aspects of the AOT. Through the layers a developer can extend
the innermost levels. Also, individual components can extend other components.
For example, an extended type, which is what Microsoft Dynamics AX 4.0 calls
data types, can extend another type and change just some of the properties
resulting in a new data type. With any change made, the inheritance ensures that
all derived components are immediately updated.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 20/28
Installation & Configuration for Microsoft Dynamics AX 4.0
Page 28
A Microsoft Dynamics AX 4.0 application is also flexible and easy to modify
due to the tight integration within the IDE between different component types.
For example, if a change is made to the length of a database field from ten
characters to twenty, this is automatically reflected on all forms and reports in the
application that display this field. The database tables also change to
accommodate the additional field length.
Microsoft Dynamics AX 4.0 is designed with a unique layering structure that
manages all updates and modifications in the application. The layering structureis a powerful tool with enormous flexibility. The standard Microsoft Dynamics
AX 4.0 application components are stored in the core layer called the system
layer, which is controlled and released by Microsoft.
There are also layers for country-specific, industry-specific, and customer-specific modifications. These layers are stacked on top of the core layer. The top
most layer is where the end user stores their own modifications − for example a
user-specific change to a standard report or a new report.
The system automatically looks for the most recent modifications in the toplayers. It distinguishes changes made at the company, dealer, country, and system
level. While the top layers can be changed and modified, the standard Microsoft
Dynamics AX 4.0 functionality always remains the same. At any point in time, it
is possible to go back to the original version without running a new installation.
FIGURE 1-7: MICROSOFT DYNAMICS AX 4.0 LAYERS
Application Object Layers: What They Are and How They Work
Application object layers hold everything in the Application Object Tree.
The layers are a hierarchy of levels in the Microsoft Dynamics AX 4.0
application source code to ensure that modifications and additions can be madewithout interfering with the application objects on the level below the one being
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 21/28
Chapter 1: Overview
Page 29
worked on. The idea is that when an object modification is made on one level,
the modification overshadows the object on a lower level. For example, it is
possible to choose to add Email information to a standard form. The addition is
saved on only the level being developed; the revised form replaces the standard
form but it is always possible to go back to the original one on the level below by
simply removing the new form.
The layers are designed with the Microsoft Dynamics AX 4.0 customer groups in
mind. Basically three customer groups have an interest in adding and modifyingapplication objects: Application developers who create the standard application,
Business partners, and Microsoft Dynamics AX 4.0 end users.
FIGURE 1-8: LAYER GROUPS
Each of these three groups has two layers in which they can add and modify.
SYS
The standard application is implemented at the lowest level, the SYS layer. The
application objects in the standard application can never be deleted.
GLS
When Microsoft certifies and distributes a solution that has not been developed
in-house, this solution is distributed in the GLS layer. GLS is short for GLobal
Solutions.
DIS
When the application is modified to match country-specific legal demands, these
modifications are saved in a separate DIS layer (DIStributor). If an application
object, for example a form, is modified in the DIS layer the modifications are
saved in the DIS layer only and Microsoft Dynamics AX 4.0 ensures that the
modified version of the forms is used.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 22/28
Installation & Configuration for Microsoft Dynamics AX 4.0
Page 30
LOS
A layer where the distributor can implement local partner solutions, LOS is short
for LOcal Solution.
BUS
When a business partner creates his or her own generic solution, the
modifications are saved in the BUS layer and − again − Microsoft Dynamics AX4.0 ensures that the top level application objects are used.
VAR
Microsoft Dynamics VARs (Value Added Resellers) can make modifications or
new developments to the VAR layer specified by the customers or as a strategy
of creating an industry-specific solution. Such modifications are saved in the
VAR layer.
CUS
The supervisor or administrator of an end user installation may wish to make
modifications generic to the company. Such modifications are saved in the CUS
(CUStomer) layer.
USR
Lastly the end user may wish to make his or her own modifications, for example
to his or her own reports. The modifications are saved in the USR (User) layer.
Each layer is saved in a separate file called Ax<layer>.aod, for example
Axsys.aod for the SYS layer, Axdis.aod for the DIS layer and so on. The .aod
extension is an acronym for Application Object Data file.
In addition to the six layers, each layer has a patch layer.
For each layer, there is a corresponding label file.
Additional Patch Layers
In addition to the eight layers, each layer has a patch layer. The patch layers are
called SYP, GLP, DIP, LOP, BUP, VAP, CUP, and USP.
The patch layers are designed to make it easy to incorporate updates in the
current application. The basic idea is that when a minor update or correction is
made, it is distributed in a patch file, for example Axsyp.aod. When a patch file
is present, the modified objects in the patch file take precedence over the regular
objects and are automatically used.
The patch files use the same number series as the regular files.
The major benefit of the patch layer concept is that it is easy to create and
distribute an update - for example using the Internet − without interfering with
the existing application. When an update is incorporated into the regular layer
file, simply delete the patch file (Ax??p.aod ) and the index file (Axapd.aoi).
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 23/28
Chapter 1: Overview
Page 31
Use the Top Level Version of an Object at All Times
A single index file called Axapd.aoi automatically ensures that the top-level
version of an application object is always used. The USR layer is the top layer
and the SYS layer the bottom one. This means that when a user opens, for
example a form object, Microsoft Dynamics AX 4.0 first checks whether there is
a USR version of the form, then a CUS version, then a VAR version and so on
until finally the SYS, or core, version is used.
The majority of application objects (table, field, index, and enum type, Extended
Data Type) have unique ID numbers in addition to names. Microsoft Dynamics
AX 4.0 uses eight number series corresponding to the eight layers.
Layer Object Numbers
SYS 1 – 7999
GLS 8001 – 15999
DIS 16001 – 17999
LOS 18001 – 19999
BUS 20001 – 29999
VAR 30001 – 39999
CUS 40001 – 49999
USR 50001 - 59999
TABLE 1-4: LAYER OBJECT NUMBERS
When an object is initially created, Microsoft Dynamics AX 4.0 automatically
manages IDs and assigns a new ID according to the above table.
NOTE: When modifying an existing object the object keeps its original id and is not
assigned a new id in the layer.
MorphX and the AOT
The development environment in Microsoft Dynamics AX 4.0 is the MorphX®
Development Suite, which is an Integrated Development Environment (IDE). It
integrates many different functions related to development, such as designing,
editing, compiling, and debugging within a common interface. The IDE is
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 24/28
Installation & Configuration for Microsoft Dynamics AX 4.0
Page 32
available in the same window as the main application components making it easy
to test changes, resulting in very rapid application development.
The Application Object Tree (AOT) contains all the application components in
Microsoft Dynamics AX 4.0. The AOT shows a graphical tree view of the
contents of all the application files. It allows access to all properties and text,
such as program code, associated with each object. A developer uses the AOT tocreate or change components but the administrator may also need to use the AOT
for some configuration and tuning functions.
In the AOT, the developer can create new application objects by using drag-and-
drop and by setting object properties. To make the developer ′s job even easier
and faster, the application object properties have preset defaults so usually only a
few properties have to be changed to get the desired functionality.
Object-Oriented Architecture
One of the fundamental pieces of Microsoft Dynamics AX 4.0 is its object-
oriented architecture. This architecture is a key part of the MorphX Development
Suite and is the key ingredient enabling quick system configuration andcustomization changes.
The changes can be seen in the larger technology framework making up
Microsoft Dynamics AX 4.0, such as the layering of application components.
The object-oriented architecture goes much deeper than this though, supporting
full polymorphism and inheritance on such items as field types, tables, and even
reports.
Configuration and Security in Microsoft Dynamics AX 4.0
Configuration and Security Key Concept
With Microsoft Dynamics AX 4.0, the Configuration and Security system is
introduced. This system is an extension of the feature key system that has existed
since the first version of Microsoft Axapta.
The new security system was created to make the system more intuitive and
flexible, and easier for the administrator to set up. The feature keys are replaced
by two types of keys: configuration and security keys. This means, that the
double-function the feature keys previously had, is now replaced by two types of
keys each having one function.
The Microsoft Axapta 2.5 standard version had more than 1,000 feature keys.
Microsoft Dynamics AX 4.0 only has a few, but well-defined keys. To maintain
the flexibility, security can now be set up on each menu item.
License Codes
License information can be entered manually, or loaded from the license file.
This is done from the Administration menu, Setup, System, License Information
form.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 25/28
Chapter 1: Overview
Page 33
Configuration Keys
Configuration keys are used to disable or enable functionality and, according to
the name, used for configuration of the system.
In most cases, license codes control the configuration keys. Therefore, it is not
possible and does not make sense to disable a configuration key. A configuration
key, however, can control a number of child configuration keys, and they can be
either disabled or enabled as required. An example may be a company buying the
Trade module license code; the company wants most of the functionality in this
module, but does not do business with other countries, and chooses therefore to
disable the foreign trade configuration key.
FIGURE 1-9: CONFIGURATION KEYS
Security Keys
Security keys are used to control access to functionality for users. The security
keys have replaced feature keys almost everywhere except for indexes, fields,and types:
• Indexes − the performance of indexes must be available for all users,
just as in version 2.5.
• Fields − security on fields must be set up from the User group
permissions form, under the table they belong to.• Types − security can only be applied to fields, making the concept of
indirect access obsolete.
Security keys control access to menu items and tables, and setup is done from the
Administration menu, click SETUP→SECURITY→USER GROUP PERMISSIONS. Access
for menu items and tables can be set to: No access, View, Edit, Create, and Full
control.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 26/28
Installation & Configuration for Microsoft Dynamics AX 4.0
Page 34
Record Level Security
The Record level security system can be used in addition to the other permissions
set up in Microsoft Dynamics AX 4.0. For each combination of company, user
group, and table, a query can be set up limiting data access for the specific
combination. Specify, for example, that a certain user group within a company
only has access to see customer numbers from 1000 to 4999. Row level security
is set up from the Administration menu, click SETUP→SECURITY→RECORD LEVEL
SECURITY.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 27/28
Chapter 1: Overview
Page 35
Conclusion
Changes to the installation process, the introduction of roles, and improvements
to the client languages are just a few improvements made to Microsoft Dynamics
AX 4.0 to help enhance:
• System and user performance
• Client and server communication
• Language control on client machines
The section titled "Planning the Microsoft Dynamics AX 4.0 Install" shows
implementers how to use these improvements and then add new hardware and
software requirements to make Microsoft Dynamics AX 4.0 run more efficiently.
8/14/2019 Ax40 Enus Ins 01
http://slidepdf.com/reader/full/ax40-enus-ins-01 28/28
Installation & Configuration for Microsoft Dynamics AX 4.0
Quick Interaction: Lessons Learned
Take a moment and write down three Key Points learned from this chapter:
1.
2.
3.