AX Design Pattern


AX 7
·         Describe the use of Life cycle services
·         What is the use of VSTS?
·         Code and Data upgrade from AX 2012 to AX 7
·         Develop and Deploy your code modifications
·         How models are replaced in AX7
·         What is extensions?
·         How to connect Azure in LCS?
·         Describe about Power BI


AX 2012

1.       Improve Performance
S.No
Verification Areas
1.
Avoid client server mix.
2.
Almost all CRUD operations should run in server. In case of ‘InMemory’ and ‘TempDB’ tables, this needs to be decided based upon where the table is getting created.
3.
Methods having client interaction should not be executed in server. Method codes should be separated based upon execution tier, if required.
4.
Display or Edit methods should not have CRUD operations
5.
Field list should be specified for customized X++ SQL.
6.
FirstOnly should be used wherever applicable.
7.
Set based database operations can fall back to row based operation, if necessary skipXX methods are not called.
8.
Row based operations can be converted to set based operations, wherever applicable.
9.
Nested SELECTs should be avoided, wherever possible to be converted to JOINs. In case we need fields from a JOIN, use specific field lists; else use EXISTS JOIN or NOTEXISTS JOIN, based upon the requirement.
10.
FIND should be replaced with SELECTs, taking only those fields which are required; instead of taking the complete tuple (in case we need only a few fields). This also should depend upon the “Table Group” and “Cache Lookup” property combinations of the related tables.
11.
If code is used to INSERT/UPDATE/DELETE, make sure that validateXXX method is called before the operation.
12.
INSERT/UPDATE should not happen in Modified or Validate related methods.
13.
Validations should not happen in Modified related methods.
14.
If Insert method is overridden and is performed in a loop, suggested to use RecordInsertList.
15.
Do not write Direct SQL code in forms for retrieval of data. Direct SQL or SPs can be used for reports while fetching huge volume of data.
16.
Use Post and Pre event functionality for base method modifications (like ValidateField, ValidateWrite, InitValue etc).
17.
For Queries: Set the fields’ property ‘Dynamic’ to ‘No’ and include only those fields required/used for that table.
18.
Display methods on grid should be cached.
19.
SQL queries should be avoided in forms. This slows down the loading of Forms.
20.
Set appropriate table groups for the tables.
21.
Set appropriate cache lookups for the tables.
22.
New tables should be created with non-RecId primary key like surrogate keys, in case there is no primary key.
23.
Alternate keys are suggested to be created for new tables, in case of the requirement.
24.
Clustered indices as suggested to be kept for new tables, preferably same as that of the primary key (to retrieve data in a faster way).
25.
Relations are ideally suggested to be based on PK-FK, wherever applicable.
26.
New fields are not suggested to be added in standard tables. Extension tables are suggested for the same.
27.
Please see that TTSBEGIN/TTSCOMMIT used in a clear and well balanced manner. Multiple TTS blocks should be avoided wherever applicable.
28.
Avoid TTSABORT.

2.       Form and SSRS sequence
Report - Init, Run, Prompt, Fetch, send, Print
3.       Role based security
4.       OOPS Concepts
5.       Cache

Single-record Caching
Record caching is enabled for a table when all the following statements are true:
The CacheLookup property on the table is enabled by setting it to one of the following values:
 NotInTTS, Found, FoundAndEmpty.

Records are cached for all unique indexes when all the following criteria are met:
·         The table is cached by having its CacheLookup property set to NotInTTS, Found, or FoundAndEmpty.
·         The select statement that selects the records uses an equal operator (==) on the caching key. The fields in the where clause of the select statement match the fields in any unique index.

Caches are used on both the client and the Application Object Server (AOS). The Microsoft Dynamics AX runtime manages the cache by removing old records when new records are added to the cache.

Client Cache
A client-side cache can be used only by the client. The client cache is used when a select is executed from the client tier. If no record is found in the client cache, the client then searches the server cache for the record. If the record is not located in the server cache, it is retrieved from the database. You can configure the number of records to be maintained in the cache by using the Server configuration form. The form is found in the application workspace at:
 System administration > Area page > Setup > System > Server configuration. In this form, continue to:
 Performance Optimization > Performance Settings > Client record cache factor.

Server Cache
A server-side cache can be used by any connection to the server. The server cache is used when a select is executed on the server tier. If no record is found in the server-side cache, the record is retrieved from the database. You can configure the maximum number of records that are maintained in a server cache by using the Cache Limits section of the Server configuration form. The default value is 2000 records for a given company per table group or per Application Object Server (AOS).

Set based caching

In Microsoft Dynamics AX, groups of records can be cached all at once with set-based caching. Set-based caching can be implemented in two ways:
·         At design time, by setting the table's CacheLookup property to EntireTable.
·         In code, by using the RecordViewCache class.
Flush keyword is used to flush the cache.

Caching display method.
Keyword – cacheAddMethod is used cache the display method.

AX2012 also allows to use SysClientCacheDataMethodAttribute attribute in the display method declaration. Then, forms should cache such methods automatically.
Attribute's constructor accept one optional parameter (_updateOnWrite), which corresponds to the second parameter of cacheAddMethod().
Example:
[SysClientCacheDataMethodAttribute(true)]
display DirPartyType type(){...}


6.       Methods
refresh() will not reread the record from the database.  It basically just refreshes the screen with whatever is stored in the form cache.
reread() will only re-read the CURRENT record from the DB so you should not use it to refresh the form data if you have added/removed records.  It’s often used if you change some values in the current record in some code, and commit them to the database using .update() on the table, instead of through the form datasource.  In this case .reread() will make those changes appear on the form.
research() will rerun the existing form query against the data source, therefore updating the list with new/removed records as well as updating existing ones.  This will honour any existing filters and sorting on the form.
executeQuery() is another useful one.  It should be used if you have modified the query in your code and need to refresh the form.  It’s like
research() except it takes query changes into account.
7.       Relations and Form join types
8.       Architecture
AOS
The Microsoft Dynamics AX Object Server (AOS) is the second-tier application server in the Microsoft Dynamics AX three-tier architecture.
The 3-tier environment is divided as follows:
1. First Tier – Intelligent Client
2. Second Tier – AOS
3. Third Tier – Database Server

In a 3-tier solution the database runs on a server as the third tier; the AOS handles the business logic in the second tier. The thin client is the first tier and handles the user interface and necessary program logic.
9.       Keys and Index

An index is a table-specific database structure that speeds the retrieval of rows from the table. Indexes are used to improve the performance of data retrieval and sometimes to ensure the existence of unique records.
What is the difference between Index and Index hint?
Adding the “index” statement to an Axapta select, it does NOT mean that this index will be used by the database. What it DOES mean is that Axapta will send an “order by” to the database. Adding the “index hint” statement to an Axapta select, it DOES mean that this index will be used by the database (and no other one).

A clustered index is a special type of index that reorders the way records in the table are physically stored. Therefore table can have only one clustered index. The leaf nodes of a clustered index contain the data pages. 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. The leaf node of a nonclustered index does not consist of the data pages. Instead, the leaf nodes contain index rows.

10.   Partition and Virtual company
11.   Study DIXF - Customize it for new table, change the sequence
Steps to create  custom entity

To Add custom field

12.   AX 2009 to AX 2012 Migration
Data pre-processing, AOD upgrade, script, data upgrade for custom tables and fields
13.   AIF
Inbound and Outbound ports, Adaptor, Data policies, return types (single and bulk)
14.   IDMF
The Microsoft Dynamics AX Intelligent Data Management Framework (IDMF) lets system administrators optimize the performance of Microsoft Dynamics AX installations. IDMF assesses the health of the Microsoft Dynamics AX application, analyses current usage patterns, and helps reduce database size.
IDMF has moved. It is now available from the Downloadable tools sections of Microsoft Dynamics Lifecycle Services. Go to https://lcs.dynamics.com/.

15.   Data Migration Techniques
DIXF, DMF
AIF
Atlas
Scribe
Custom X++ code
Excel Add ins
EDI

16.   Index
17.   Key
https://msdn.microsoft.com/en-us/library/hh812105.aspx
Primary Key
A primary key is one type of key. The other type of key is an alternate key. There is a maximum of one primary key per table, whereas a table can have several alternate keys. The primary key is usually the type of key that other tables, called child tables, refer to when a foreign key field in those other tables need a relational identifier.

Alternate Key
A table can have several alternate keys. Any one alternate key can switch to being the primary key, if the alternate key is comprised of only one field.
A table can reference the alternate key of another table. However, it is more common for a table to reference the primary key of another table. As an option, an alternate key can be chosen as the ReplacementKey of a table.
In practice each alternate key relies on a unique index for its implementation and enforcement. However, a unique index alone does not make an alternate key. The AlternateKey property must be set to Yes to make a unique index be an alternate key.

Foreign Key
In Microsoft Dynamics AX a relation represents a foreign key.

Replacement 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.


Surrogate Key
The fact that it is a 64-bit integer (int64) value means table operations normally perform faster than other types of field such as string fields. This is the main strength of surrogate keys.

18.   Form relations
19.   Query optimizations
20.   Server debug
21.   Layers
USR, CUS, VAR, ISV, SLN, FPK, GLS, SYS
22.   Patch & Hotfix Installation
We strongly recommend that you install all updates in a test or backup environment before you install them in production environments. Then validate the update against the implementation, customizations, data, and processes that are currently used in your organization.

If multiple Client, AOS and DB. Install update for one AOS and DB and export and import the model.
23.   Resolve conflicts
Conflict are created in the conflict layer (Conflict 1)
To view the list of conflict.
axutil.exe view /model:"Facility Management (Conflict 1)" /verbose
24.   SSRS report class & send email thru class
25.   CIL Compile
CIL – Common Intermediate Language
XppIL Folder
26.   Sysoperation framework
27.   Model, Model Store, labels
28.   EP Customizations
29.   SQL Programming
30.   Query Tuning
31.   Workflows
32.   Active Directory
33.   MorphX Concepts

34.   Architecture
35.   Layer and Models
36.   Team Foundation server
37.   Table Properties
Table Types

Refer links,







·         Handle AIF Document service different namespace (xslt)
·         Refresh updated data for selected records
·         Record level security in AX 2012
·         Handle role based security (Among 5 fields and one display method – allow edit for 3 fields only)
·         AIF return large data

2 comments:

  1. Thank you for sharing any good knowledge and thanks for fantastic efforts.
    Microsoft Dynamics AX Online Training

    ReplyDelete
  2. Thank you for sharing the knowledge ,can you send your mail id to mdrhiyas.k@gmail.com

    ReplyDelete