Form letter classes and its hierarchy in ax 2012

One of the most commonly used classes in AX are the FormLetter classes. The
FormLetter classes define how to post different status updates against sales orders
and purchase orders.

The normal flow when a posting is being performed is that the parm tables are
Populated with data, and then the update itself is performed.

Below example will shows how to Post the Invoice from sales order, similar logic's can be used to post the Invoice from Purchase order.

static void postSalesInvoice(Args _args)
{
// Define a classvariable according to the
// type of posting being performed
SalesFormLetter_Invoice invoice;
SalesTable salesTable;
;
// Select the salesTable to update
salesTable = SalesTable::find(“SO-101297″);
// Create a new object of the SalesFormLetter_Invoice
// by using the construct-method in SalesFormLetter
invoice = SalesFormLetter::construct(DocumentStatus::Invoice);
// Post the invoice
invoice.update(salesTable,
SystemDateGet(),
SalesUpdate::All,
AccountOrder::None,
false,
true); // Set to true to print the invoice
}

The next screenshot shows the class hierarchy of FormLetter with all its sub classes:  we can easily customize the above logic to post different status updates against sales orders
and purchase orders

Sales (Confirmation, Picking list, Packing slip, Invoice )
Purch (Purchase order,Receipt list, Packing slip, Invoice)

Version Control System in AX

A Version Control System (VCS) enables a team of developers to work, at the same time, on the code base in one or more projects. Using a VCS can have the following advantages, depending on which VCS you use:

• Concurrent development
• Isolated development
• Change description
• Change history
• Change list support
• Quality bar enforcement

MorphX, the Microsoft Dynamics AX Integrated Development Environment (IDE), can integrate various Version Control Systems (VCS). You can integrate:

• Microsoft Visual Studio Team Foundation Server (TFS)
• Microsoft Visual SourceSafe
• MorphX VCS
• Another third-party VCS

Version Control Considerations

If you use the VSS or TFS version control systems, you should consider the following before you develop code or write documentation:

• Version control is file-based.
• You must install Microsoft Visual Studio or Microsoft Visual Studio Team Explorer.
• Each developer must have an Application Object Server (AOS) and database server.

MorphX VCS allows for out-of-the-box version control system integration. MorphX VCS is intended for one to ten developers who use a shared AOS. Instead of checking out objects and storing them in a repository, MorphX VCS signals to other users that a specific element is being worked on by another user. It provides change description functionality, change history functionality, and quality bar enforcement.

Microsoft Dynamics AX can integrate with VSS, TFS, and MorphX VCS, but you can extend the version control functionality to use other version control systems.

The following table compares the features available from the different version control options:

	MorphX	MorphX VCS	Visual SourceSafe	TFS
Concurrent development	No	No	Yes	Yes
Isolated development	No	No	Yes	Yes
Change description	No	Yes	Yes	Yes
Change history	No	Yes	Yes	Yes
Quality bar enforcement	No	Yes	Yes	Yes
Branching	No	No	No	Yes
Work item integration	No	No	No	Yes
Labeling support	No	No	Yes	No

Adding Elements to the Version Control System

To add Elements to the version control system

1. In the AOT, right-click the element and then click Add to Version Control.
2. Select the folder in the version control system that you want to add your element to.Right-click the element and then click Check In. This opens the Check in form.
3. After you check in the element, it can be checked out of the version control system.
   
   

After you check in the element, it can be checked out of the version control system.

The element is added to the current model. The current model and layer are displayed in the status bar in Microsoft Dynamics AX and may also be displayed together with the element in the AOT.

You cannot have two models under version control in the same layer if elements occur in both models. You must develop outside of version control when this is the scenario. For example, during upgrade you might have fields that occur in the original table and the upgrade table.

If you add an element in a lower layer to version control and then customize the element in a higher layer, you may encounter problems when you synchronize. If you develop in multiple layers, we recommend that you create separate VCS branches for each layer.

If you cannot check in a new element, it might have failed some of the quality checks set in the system settings for the version control system. These settings are typically chosen by an administrator, and are set in the System settings form.

Checking Out and Checking in the Label File

Create or edit labels by using the Label editor. When you create a new label, a temporary label ID is assigned to it.

To add a label file to version control

1. Click Tools > Label > Label editor.
2. Click Add to version control.

To check out the label file

1. Click Tools > Label > Label editor.
2. Click Check out.

When finished, check the label file back in. When you check in a new label, the temporary label ID and references to it are mapped to a globally unique label ID.

To check in the label file

1. On the Label editor form, click Check in.
2. Type a description of the work you completed, and then click OK.

Resolving References to a Temporary Label ID that is Not Valid

If you have references to a temporary label ID that has already been checked in, those references are not valid because the temporary label ID is replaced with a globally unique label ID when you check it in. This can happen when references to the temporary label ID are not in the scope of the check-in.

To resolve references to temporary labels

1. Manually locate references to a temporary label ID that should reference the new globally unique label ID.
2. Update the references to point to the new globally unique label ID.

To check out an element from the AOT

• In the AOT, right-click the element, and then click Check Out.

The Check Out command synchronizes the local copy with the version control system copy before checking it out. You can select multiple items in the AOT and check them out in one step.

Index

What is an index?

Before we start talking about indexes, let’s think about the a question: What is an index?

Take a look at the yellow papers; there are millions of phone numbers in it, and they are categorized on City, Business, Business type etc. If you want to find something, you look into the categorized area; there you find some information with a page number. Next you find the page, and start reading this page till you find the thing you need. This categorized information acts the same like an index, and reading the page till you find what you needed is called a page scan. So when I have a phone number and I need the business that belongs to that number, I have to read all the pages of the yellow pages till I have found it. There is simply no support of categorized items. This scanning of the complete yellow pages is called a table scan in a database.

But what will happen if I get new business information into my yellow pages.  Or the name of a business has changed. My categorized area needs to be update for giving correct information. In a database we call this reindexing This reindexing can become heavy if the data has to be moved from on page to another page. This is also the reason why fields of an index value should have the property allow edit on create.

A highly optimized index is a cluster index, there is no additional storage, and the data is stored physical in the correct order.  If we look closely at the physical storage of a clustered index, we see that the data is grouped in pages; every page belongs to an index key value. When we have a lot of inserts into a clustered indexed table we get also performance issues. The database has some free space between the pages, but when this free space is consumed, the storage of the data gets fragmented into the database. Reindexing the database can solve this.

In general, an index knows on which page in the SQL database the record exists. By using indexes only the SQL database pages that have related information, are scanned to find the record. So let’s pretend we have an index on a Boolean field of a table.  The records with yes and no values exist on all pages, so the index will use all pages. (Index scan)

Types of Indexes

There are mainly 2 types of indexes which are as follows:

Clustered Index – A clustered index is a special type of index that arranges the way records in the table are physically stored. You can create only a single clustered index against one or more columns of a table or a view. A maximum of 16 columns can be a part of a clustered index. A clustered index is identified in the sys.partitions table and has an Index_ID value of ‘1’. When Clustered indexes are created a B-Tree structure is created and the leaf nodes of a B-Tree contain the data pages.

Non Clustered Index – A nonclustered index is a special type of index in which the logical order of the index does not match the physical stored order of the rows on disk. When Non Clustered indexes are created a B-Tree structure is created and the leaf node of a B-Tree of a nonclustered index does not consist of the data pages. Instead, the leaf nodes contain a pointer to the data pages. You can create up to 249 nonclustered indexes for a table or a view. These indexes are created to support the queries that are used to retrieve data from a table or a view. A nonclustered index is identified in the sys.partitions table with anIndex_ID value of 2 to 250.

A table which has no Clustered Index is referred to as a Heap.

It becomes important to know the basics of how indexes work as a correct index will boost performance and a wrong index will drastically reduce performance.

select * from sys.indexes ind where ind.object_id = (select OBJECT_ID from sys.tables tab where  tab.name = ‘CustTable’)

Note the column ‘type_desc’ which gives the type of Index in CustTable. The same indexes can be viewed within the AOT as shown in Figure 2. However the levels of details shown in SSMS are more and are required by administrators to get details on Indexes. Dynamics AX Kernel by default adds the RecId as a Non Clustered Index which can be seen from SSMS.

How Indexes Improve Performance

Indexes can optimize not only SELECT, but also UPDATE and DELETE statements. The reason is that the SQL Server must find the records prior to modifying or deleting them. Keep in mind however, that SQL Server has to maintain clustered and non-clustered indexes every time data is INSERTED, UPDATED or DELETED. Having numerous indexes on a table can cause significant overhead on the SQL Server during data modifications.

When a query is sent to SQL Server, the query optimizer comes up with the most efficient execution plan. SQL Server does not have to use an index to satisfy a query; in fact, if it is quicker to scan the entire table, SQL Server will do so. Usually if a query requires returning more than about 1% of table rows and there is no covering index, it is quicker to scan the whole table than to seek on the nonclustered and then lookup the missing columns from the clustered index/heap.

The popular understanding is that adding more indexes to a table will improve performance but this is not true. In fact over-indexing can degrade performance drastically. So how do we know how many indexes to add and where the thin line is which differentiates between over- & under-indexing? Well, there is no magic formula for defining the number of indexes but it depends on a lot of important factors like data type in the tables, work load, query structure etc.  With CRUD statements, indexes undergo fragmentation and when the level of fragmentation increases above a threshold the query performance degrades. We will be discussing more on index fragmentation later on in this chapter.

Indexes in Dynamics AX

Indexes are created inside AX in the AOT Tables Node. Prior to index creation, index design has to be done as to determine the columns we want to index, what type of index we should consider, the number of columns in an index and the queries which we will use. It is relatively easy to create indexes inside AX, but some pointers must be kept in mind.

• Do the task of index design diligently. There is no magic formula which will tell you the number of indexes you must create for a table. You must work out and consider all possible scenarios.
• Ensure that you select the Primary Index & Cluster Index property in the Table Property sheet as shown below.
• Apart from properly indexing tables, also consider table caching properties to improve performance.
• Ensure all tables have a Cluster Index and a Primary Key.
• Reduce the number of fields in queries
• Monitor indexes and ensure that unused indexes are removed.

Apart from these tips, there are some best practices which will help you decide what indexes to create in AX. These are discussed under the best practices section in this chapter.

Best Practices for Index creation in AX

• Keep indexes lean. Try to build indexes on one or few columns. Wide indexes take longer to scan than narrow indexes.
• The number of indexes on a table should not be very high. Usually 7-9 indexes in a standard Master, Transaction table is recommended. For Setup & Parameter tables, limit the number of indexes to the important columns only.
• Create a clustered index on every table. However, choose the column(s) for the clustered index judiciously.
• Try to create the clustered index on the column which is used most frequently for retrieving data.
• Try to create the clustered index on the column with high selectivity; that is the column that does not have many duplicate values.
• Try to create the clustered index on the column that will never be updated or will be updated infrequently. Every time the clustered index key is updated, SQL Server must maintain not just the clustered index but also the non-clustered indexes since non-clustered indexes contain a pointer to the clustered index. This is yet another reason why you shouldn’t create the clustered index on multiple columns.
• By default, SQL Server creates the clustered index on the PRIMARY KEY column(s) unless the clustered index is created prior to creating the primary key. It is often beneficial to have the clustered index on the primary key, but sometimes you’re better off saving the clustered index for other column(s
• SQL Server has to perform some maintenance when index keys are updated, so each additional index could impose a slight performance penalty on the performance of INSERT, UPDATE and DELETE statements. Nevertheless the cost of index maintenance could be far less than the performance improvement you’ll reap for your SELECT statements.
• Be sure to eliminate duplicate indexes, that is, multiple indexes created on the same set of columns. Such indexes provide no additional benefit but use up extra disk space and might hinder performance of INSERT, UPDATE and DELETE statements.
• Check the default fill factor level configured at the server level. To control the rate of fragmentation of an index, you can use an index option called the fill factor. Modifying fill-factor is a DBA task and must be done carefully. For Dynamics AX the recommended value is 80%. You can enable this from the UI or use the CREATE INDEX or ALTER INDEX statements to set the fill-factor value for individual indexes. To modify the server-wide default value, use the sp_configure system stored procedure. To view the fill-factor value of one or more indexes, use sys.indexes.

Fill factor only affects the leaf nodes. For the intermediate nodes please refer to PAD_INDEX.

Detail Microsoft Dynamics AX Architecture

Understanding the internal architecture of Microsoft Dynamics AX 2012 can help you make decision when planning and developing a Microsoft Dynamics AX 2012 system. Here are some pointers on Dynamics AX 2012 architecture primarily for Dynamics AX 2012 architects & solution developers.

System architecture
This diagram provides a high-level over of a Microsoft Dynamics AX 2012 system with all components installed, and describes how communications flow between the components. 

Model store architecture

The model store is the part of the Microsoft Dynamics AX database where all application elements for Microsoft Dynamics AX are stored. Customization's are also stored in the model store. The model store replaces the Application Object Data (AOD) files that were used in earlier versions of Microsoft Dynamics AX.

Layer information and model information are integral parts of the model store. The Application Object Server (AOS) has access to the model store. The AOS manages layer flattening or overshadowing at run time. That is, when you make an object modification in one layer, the modification overshadows the object on a lower layer at run time. You could, for example, decide to change a caption on a standard form. The change is saved on your layer only, and the revised—or flattened—form replaces the standard form at run time. The AOS also provides all the Microsoft Dynamics AX subsystems with model data, such as form rendering, report rendering, and X++ code.

Microsoft Dynamics AX contains sixteen layers. Each layer consists of one or more logical parts called models. A model is generated for each layer. For example, VAR Model is the model that the system generates for the VAR layer. The system-generated models let you install and work with the base Microsoft Dynamics AX system. When you customize the Microsoft Dynamics AX program, you can take advantage of the capabilities of models.

The following table describes the application object layers in Microsoft Dynamics AX 2012:

Layer	Patch Layer
USR	USP
CUS	CUP
VAR	VAP
ISV	ISP
SLN	SLP
FPK	FPP
GLS	GLP
SYS	SYP

Application Object Server (AOS) architecture

This diagram describes the functionality with the AOS windows service, and describes how communications flow within it.

Note: Clients communicate with an AOS by using remote procedure calls (RPCs), Windows Communication Foundation (WCF), or AOS services. In previous releases, other components and third-party programs could communicate with an AOS by using either .NET Business Connector or Application Integration Framework (AIF). For this release, we recommend that third-party programs use AOS services to communicate with AOS.

Client architecture

This diagram describes the functionality within the client, and describes how communications flow within it.

Client/server communication

 

The client communicates with various Microsoft Dynamics AX components in the following ways:

·         The client uses the remote procedure call (RPC) protocol to communicate with Application Object Server (AOS). The client never accesses the database or metadata directly. AOS sends the application objects and data to the client.

·         The data layer that the client uses is based on data sources that are specified in metadata for forms and queries. In addition, any X++ code that is required to retrieve data can use the built-in language support to query and adjust data.

·         The client uses a report Web Part to interact with the report server. By calling the web services that are exposed by the report server, the report control in the Web Part displays information that is contained in Reporting Services reports. These reports can include either transaction data from the Microsoft Dynamics AX application or OLAP cubes from Microsoft SQL Server Analysis Services. Cubes provide business analytic's and key performance indicators (KPIs).

·         The client provides workflow forms, alerts, and controls so that users can participate in the business process by using the Workflow system. The Workflow system is a Microsoft Dynamics AX component that enables workflow processes by using Windows Communication Foundation classes.

·         The client provides a Help viewer, which is an application that displays context-sensitive Help topics. The Help topics are retrieved from a Help server that is located on-premises.

·         The client also provides Role Centers, or role-based home pages, for users. Role Centers provide role-specific tasks, activities, alerts, reports, and business intelligence that help users increase their productivity. To interact with the Role Centers that are provided by Enterprise Portal and hosted on Internet Information Services (IIS), the client uses a browser control.

Services and AIF architecture

 This topic describes the high-level architecture of services and Application Integration Framework (AIF).

Enterprise Portal architecture

This diagram provides a logical overview of a Microsoft Dynamics AX 2012 system with an Enterprise Portal server, and also describes the various components of the Enterprise Portal architecture.

Security architecture

This following diagram provides a high-level overview of the security architecture of Microsoft Dynamics AX 2012.

Workflow system architecture

This following diagram provides a high-level architecture of the workflow infrastructure.

Analytic's architecture

The following diagram shows the Microsoft SQL Server Analysis Services cubes that are included with Microsoft Dynamics AX, and the components that are used to access them.

Reporting architecture

The following diagram illustrates the architecture of the reporting functionality in Microsoft Dynamics AX.

Microsoft Dynamics AX 2012 R3 Release Video

Three Tier architecture

In Microsoft Dynamics AX, there is a 3-tier Architecture which are as follows:

1. Database server : The database server contains the table data. 
2. An application object server (AOS) :The AOS is used to execute application objects, such as queries and           classes.
3. A client.  Application objects in the user interface, such as forms and reports, run on the client computer. 

The following illustration shows the three-tier architecture. 

Advantage of Three tier Architecture

1. When you separate the application data from the application objects, it is easier to distribute upgrade versions of your application. This is because you can distribute forms, queries, classes, and reports that are based on the same set of underlying tables without affecting application data. In addition, separating data from other application objects can reduce network load.
2. You can use the AOS for sharing objects and information as an effective tool to increase performance. Microsoft Dynamics AX and SQL server databases can be used together to provide powerful programming languages to validate data and enforce business rules. For more information