The key objective of the development process is to ensure a scalable, maintainable, and high-performing application. The following diagram shows the critical steps for the development process while developing customizations for Dynamics AX:
The first step of the development process is conceptualizing the application. You must understand the problem that you are trying to solve. At this stage, you need to identify the where and the what—where in the standard flow do you need to add your code, and what code can be reused from the standard one.
Dynamics AX provides numerous application frameworks and patterns that can be reused when developing any new functionality or extending any existing functionalities. If you do not understand the existing application pattern and frameworks, you may create a functionality that was not necessary, or one that already exists in the application.
Data design is the process of analyzing and defining the data structures as per your requirement. In some cases, you may need to add additional columns to existing tables, or you may need to create one or more new tables from scratch. The following section describes the best practices to be followed when designing the data in Dynamics AX.
Dynamics AX has thousands of standard tables to store the master or transactional data. With the release of Dynamics AX 2012, the number of tables has gone higher than the previous releases because of database normalization. It was mainly done to reduce the redundancy of data across various tables, and also to improve the performance. Many times, the requirement is to store or process additional data in certain application functionalities, and so, you may need to add additional columns to the existing SYS layer tables. Consider the following points when adding additional columns to the existing tables:
All the tables in Dynamics AX 2012 have a TableType property, which supports three values:
The value is shown in the following screenshot:
The In-memory tables in AX 2012 are the same as the temporary tables in AX 2009 and earlier versions. The in-memory temporary tables are instantiated in the active memory of the tier that the process is running on. The process can run on the client tier or the server tier. The objects are held in the memory until the size reaches 128 KB. The dataset is then written to a disk file on the server tier. You can use the In-Memory temporary tables when the amount of data is small, and the Microsoft SQL Server round trips should be avoided.
The following example code shows how data can be inserted and retrieved using X++:
static void TableTmpInsertRecord(Args _args) { TmpCustLedger custTmpLedger; ; custTmpLedger.Name = 'NameValue'; custTmpLedger.Balance01 = 2345000; custTmpLedger.insert(); while select * from custTmpLedger { Info(custTmpLedger.Name); } }
The TempDB tables are instantiated on the TempDB database of the SQL Server database. The TempDB tables utilize the power of the SQL tables and support joins, aggregation, and indexes with great performance. However, they have almost the same scoping mechanism as the in-memory temporary tables. The TempDB tables also provide the following capabilities which are available with the regular tables:
The following code example shows the use of a TempDB table in X++.
In the following example, all the customer accounts associated with the customer group Corp
are filtered into the TempDB table CustTableTmpFilter
, and then this table is used in join to filter CustTransOpen
:
static void TableTmpDBExample(Args _args) { CustTableTmpFilter custTableTmpFilter; CustTable custTable; CustTrans custTrans; CustTransOpen custTransOpen; Insert_ recordset custTableTmpFilter (CustAccount) Select AccountNum from CustTable Where custTable.CustGroup = "Corp"; While select sum(AmountCur) from CustTransOpen Join AccountNum from CustTrans where custTransOpen.RefRecId == custTrans.RecId && JOIN custTableTmpFilter where custTableTmpFilter.CustAccount == custTrans.AccountNum group by AccountNum { Info(strfmt("Customer:%1, Balance: %2", custTrans.CustAccount, custTransOpen.AmountCur)); } }
Use the Extended Data Types (EDTs) and base enums to create fields for the tables. The use of EDTs and Base enums reduces work and promotes consistency.
Avoid changing the existing standard base enum values. Modifying the base enum values can have an upgrade impact in the future. In case you need to add new enum values to a standard enum, leave a gap between the existing and the new values. The gap can be useful in avoiding conflict if a new value is added to a standard enum in a future version.
For adding a field to a country-specific or region-specific functionality, add the country/region context on the EDTs and the table fields.
Extended data types (EDTs): An EDT is a primitive data type or container with a supplementary name and some additional properties. For example, you could create a new EDT called Name
and base it on a string
. Thereafter, you can use the new EDT in variable and field declarations in the development environment.
Base enums: X++ does not support constants but has an enumerable type (enum), which is a list of literals. There are hundreds of enumerable types that are built into the standard application. For example, the enum NoYes
has two associated literals, where No has the value 0, and Yes has the value 1.
Dynamics AX 2012 introduced the Date Effectivity Framework for handling the date-effective data. A simple example of date-effective data can be a discount table, where the discounts can be effective and/or expired at a certain date/time. To enable the Date effectivity on a table, you need to set ValidTimeStateFieldType
to Date
or UTCDateTime
. This will automatically create date-effective fields in the table. The next thing that you need to do is add a unique index, and set the Alternate key property and the ValidTimeStateKey
property to Yes
. That's it! Your table now supports date effectivity:
When you create a new table, there are several table properties which need to be set for efficiency and maintenance. The following sections outline some of the key properties.
Use the following guidelines to set the table group property for the new tables:
Table Groups |
Description |
Examples |
---|---|---|
Parameters |
This contains the parameter data for the module or features. Typically contains one record per company. |
|
Group |
This contains data to categorize the master data. |
|
Main |
This contains tables containing the key master data. |
|
Transactions |
Tables containing the transaction data. |
|
Worksheet header |
Tables containing the transaction entry data headers. |
|
Worksheet lines |
| |
Miscellaneous |
Set the appropriate table caching properties for the new tables. This is one of the most important properties of the tables. Not using caching properly can lead to significant performance problems:
Indexes are the database objects in the table that provide the efficient retrieval of data. SQL Server provides two types of indexes:
Clustered indexes represent the way the data are physically stored in the tables. There can be only one cluster index per table. A clustered index is required in all the permanent Microsoft Dynamics AX tables. If you don't define a cluster index, RecId
is used as one. The clustered indexes are often defined on the primary key (PK) of a table. You can define a cluster index for a table by setting the Table Cluster Index properties as follows:
All the other indexes in a table are non-cluster indexes. Non-cluster indexes have a structure that is separate from the data rows. These indexes contain the non-cluster index key values and a pointer to the data rows, called a row locator.
Both the cluster and non-cluster indexes can either be unique non-unique. In Dynamics AX, a unique index is defined when the index's AllowDuplicates
property is set to Yes. When this property is set to No, a non-unique index is created.
Consider the following best practices when designing the indexes in Dynamics AX:
Found
, NotInTTS
, and FoundAndEmpty
caching will work only when a unique index exists.RecId
is used as the default cluster index, but in many cases it is not optimal. Analyze the appropriate key and designate it as the cluster index. For example, for CustTable
, most of the queries and searches will be based on the customer account number and not on RecId
. Hence, the index on the AccountNumber
field makes more sense as the cluster index rather than the RecId
index.NULL
and consumes no space. If there are a few duplicate entries in the clustered index, the incremental cost of a non-unique index is low. Do not add a column to a clustered index solely to make it unique.ValidTo
column is defined as an included column.Keys, as the name suggests, are a key part of a relational database and are used to enforce data integrity and table relations. In Dynamics AX, the keys are maintained at the application level and not in the SQL database. The following are the type of keys used in the Dynamics AX tables.
An index in Dynamics AX can be set as an alternate key by setting the Alternate Key property to Yes. An alternate key means that the other tables can create foreign key relations that reference this key as an alternative to referencing the primary key. A unique index with only one field can be defined as an alternate key. There can be multiple alternate keys in one table.
The primary key is usually the type of key that the child tables refer to when a foreign key field in other tables need a relational identifier. There can be only one primary key in one table. In Dynamics AX, the primary key can be defined on the Table Primary Index property. Only a unique index with the property Alternate Key set to Yes can be defined as a primary key.
A replacement key is an alternate key that the system can display on forms instead of a meaningless numeric primary key value. Each table can have a maximum of one replacement key. In Dynamics AX, replacement keys can be selected on the table property as ReplacementKey.
In Dynamics AX, foreign keys are represented by table relations. In order to create a foreign key in a child table, you need to add a relation node to the parent table. Foreign keys are used to provide lookups and validation for the parent table record when used from the child record.
Define the delete actions on the tables to delete the related records from the child tables. Delete actions are better than writing a code to delete the records from the child tables.
Delete actions rely on table relations so if you create a delete action, make sure that there is a relationship defined between the relevant tables.
The business logic is a part of a program or code that encodes the real-world business scenarios. In Dynamics AX, the business logic can be written at multiple levels, such as the form UI, enterprise portal ASP.Net code, table method, classes, SSRS reports, and so on.
While working with the customization requests for Dynamics AX, there are typically two kinds of scenarios presented to the developers. The first scenario is a standalone functionality, where new forms, tables, and business logic need to be developed and later integrated into the core modules. In the second scenario, the existing processes within the AX application need to be extended to support the requirement. In both cases, it's important for the developers to understand how the business logic for the core module and functionalities is implemented in the application layer. Understanding the implementation of the core functionalities and the framework is extremely important for the developers so that they can efficiently utilize, reuse, or extend these functionalities in their custom solution. In any case, customizations need to be added on a temporary basis. The customizations should be easy to isolate and remove when they are not needed anymore, or when the required functionality is added to the product in a later release. The following are some core technical application frameworks that a developer may need to know when creating custom features and functionalities.
Microsoft Dynamics AX contains a number sequence framework to generate alphanumeric number sequences. These sequences can be used for transaction documents, such as sales orders, purchase orders, invoices, and journals, or for master data entities such as customers, vendors, and employees. The primary purpose of the number sequence framework is to provide unique, user-friendly identifiers while maintaining a continuous or non-continuous alphanumeric sequence.
If your custom application needs to implement a number sequence, you can extend or utilize the number sequence framework to enable the number sequence code for your feature. The MSDN article at https://msdn.microsoft.com/en-us/library/aa608474.aspx provides a detailed description of number sequences.
The FormLetter framework is used for posting business documents such as sales orders and purchase orders. This framework contains a number of class hierarchies and controls for document processing.
The key features of this framework are as follows:
The RunBase framework provides a standardized approach for creating processes and batch jobs in Microsoft Dynamics AX.
The key features of this framework are as follows:
Refer to https://msdn.microsoft.com/en-us/library/aa863262.aspx to understand the RunBase framework in more detail.
Use the SysOperation framework for extending Microsoft Dynamics AX by adding a new functionality that may require batch processing. The SysOperation framework replaces the RunBase framework. It provides the infrastructure for creating user-interaction dialog boxes and integration with the batch server for batch processing.
The important features of the SysOperation framework include the following:
Use services and AIF to code the business processes. The services can be used for normal business processes as well as for integration scenarios. Microsoft Dynamics AX 2012 supports the following three kinds of services:
There are many such features and frameworks available in Dynamics AX. The following table lists a few of these frameworks and some useful links for additional details:
The following sections describe the best practices when you customize the business logic in Dynamics AX.
As explained earlier, Dynamics AX provides numerous application frameworks. When developing the custom features, you should be able to extend the existing frameworks or reuse the code for your customization. The suggestion is to try not to reinvent the wheel, but investigate and utilize what is already available in the system.
The use of events was a new concept that was introduced in the Dynamics AX 2012 release. Using events, you can create pre- and post-events to implement custom behavior.
Using events, you can add custom behavior to the standard business logic, without over- layering the base layer code to your custom layer. Events has the potential to lower the cost of upgrades to the later versions.
Events can be useful in supporting the following programming models:
TechNet provides detailed information on Eventing in AX 2012 at https://technet.microsoft.com/en-us/library/hh272875.aspx.
When the base layer code needs to be replicated or used in other places, it is always better to extend the existing classes and modify the derived class for the change in behavior, rather than creating completely new classes and then copying the entire code from the base class.
Extending the standard business logic by extending the class will makes it easier to upgrade the code. If you have created an extension, only the modified code must be restructured.
Create classes and methods so that the same piece of code can be reused in multiple places. Avoid creating long methods. They make the code difficult to read, hard to debug, and extremely difficult to upgrade and maintain.
Do not keep the commented code if you want to avoid the upgrade and maintenance costs. Keep the older version of the code in version control.
Create the customizations in the appropriate location. Create the code for reuse as much as possible, but create it at the lowest appropriate location. For example, if something is required only in a form, do not put it at the table level.
The following examples describe the locations at which we recommend that you place the code:
When designing the user interface in Dynamics AX, follow the standard AX form templates and the UX guidelines to create familiar and consistent form patterns for the customized features.
The following sections define the different form types available in standard Dynamics AX and their usage scenarios.
The list pages display a list of related data and provide the ability to quickly filter, take actions, and open the detail forms. They also display related information for the selected records as fact boxes. List pages are the starting point for performing the bulk of daily activities for the business users, such as creating and editing customers.
The following screenshot shows the standard customer list page:
The details forms are the primary methods for data entry. Using the details forms, the user can create, edit, and take action on data. The details forms also contain fact boxes on the right-hand side to display any related information. The following image shows a customer details form:
The details forms with lines have one form with a header and a line view which the user can toggle to switch between the views. An example of the sales order details form is seen in the following screenshot:
The simple list form is typically used to display the reference data. For example, the customer group is shown in the following screenshot:
The simple details forms are forms having a single page containing the details information. It is the recommended pattern for creating or viewing related or referenced data, as shown in the following screenshot:
Enterprise portal is the web interface for Dynamics AX. Enterprise portal UI guidelines follow patterns similar to the ones described in the AX client. The following sections define the three common page layouts in enterprise portal.
The list pages in Enterprise Portal are exactly the same as the rich client list pages and provide a similar functionality.
Typically, there are three types of report UI's in Dynamics AX: outgoing documents, simple lists, and grouped lists layouts.
The following screenshot displays the purchase order report layout in Dynamics AX. Most of the external facing reports, such as purchase order, sales order packing slip, sales order invoice and so on, use the same layout:
Unlike the earlier versions of Dynamics AX, AX 2012 security definition is a development task, and the ground work for the supporting security definition of the custom objects should be done as part of the development process.
The Dynamics AX role-based security is based on the following key concepts:
The security roles that are assigned to a user determine the duties that the user can perform and the parts of the user interface that the user can view. All users must be assigned to at least one security role for accessing Microsoft Dynamics AX.
Duties correspond to the parts of a business process. The administrator assigns duties to security roles. A duty can be assigned to more than one role.
To help the administrator locate the duties that must be assigned to roles, duties are organized by the business processes that they are a part of. In the context of the security model, business processes are referred to as process cycles. For example, in the accounting process cycle, you may find the maintain ledgers and maintain bank transactions duties.
In the security model of Microsoft Dynamics AX, a privilege specifies the level of access that is required to perform a job, solve a problem, or complete an assignment. Privileges can be assigned directly to roles. However, for easier maintenance, it is recommended that you assign the privileges to duties and duties to roles.
Each function in Microsoft Dynamics AX, such as a form or a service, is accessed through an entry point. The menu items, web content items, and service operations are collectively referred to as entry points.
In the security model for Microsoft Dynamics AX, permissions group the securable objects and the access levels that are required to run a function. This includes any tables, fields, forms, or server-side methods that are accessed through the entry point.
These are used to restrict the data that a user can see in a form or a report. This is a new method in Dynamics AX 2012 to limit the data, similar to what you have with record level security. With this feature, you create a query with restrictions. Then, you create a security policy that can be applied to a security role. For example, if you wanted to limit your accounts-payable clerks from seeing the retail vendors, you could create a query on the vendor group table with a range that limits the retail vendors. You would then create a policy that includes this query and the security role.
While the administrators can maintain the security role assignment for individual users, most of the work for creating the security objects needs to be done by the developer in the AOT. The following security related tasks need to be created by the developers: