These are the regular and permanent tables created in the SQL server transaction database.

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 following guidelines to set the table group property for the new tables:

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:

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:

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.

The natural key is a term used to represent the keys which are meaningful to the users. Most of the replacement keys are natural keys.

The system fields as key fields such as RecId are not meaningful to the users, but are good to use as a primary key and a foreign key. Since surrogate keys are not attached to the business, even if the natural key changes, the references to the surrogate key do not need to be updated.

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:

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:

The simple list and details forms contain the simple list and details page forms on a single page. These forms are useful for reference data with multiple fields. For example, payment terms, as shown in the following screenshot:

The table of content forms use vertical buttons on the left to navigate and display the content on the right side of the page. The following screenshot displays the pattern that is recommended for the parameters forms:

The list pages in Enterprise Portal are exactly the same as the rich client list pages and provide a similar functionality.

The details forms in Enterprise Portal provides patterns similar to the details form in the AX client:

This is typically used to create a header record before creating a line record. The following screenshot is an example of a two-phase create header creation dialog:

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:

The simple list reports are usually internal production reports used for data analysis. The following screenshot displays the On-hand Inventory reports, which display the on-hand information about the products:

The group list type reports are also used for internal production reporting. This report layout is used to display summarized transactional details and include sub totals and grand totals. The following screenshot displays Customer transactions grouped by customers:

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: