X++ tips and best practices to improve performance in AX

Dear Friends,

As we go for lot of customizations, and get stuck in performance aspects, ultimately having a huge effect on the usage of the ERP; though of sharing the best practices which a developer should consider while going for customizations. The document have been prepared considering 2012 R2/R3; so while going for developments in 3.0/4.0/2009, please consider only the relevant points from the list.

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.

Adding Web Service reference directly in AX 2012, without using proxy DLL

Dear Friends,

Thought of sharing a small yet tricky way to add a web service reference directly from AX 2012 without using proxy DLL, for consuming the same.

Normally, when we right click on AOT "References", we can add only the DLL references from there.

But if we create a project, and add a "Reference" group, and then right click on it, we will get both the options; of adding the DLL reference as well as adding the web service reference.

Once we click on "Service Reference", the following form opens, which helps us inputting the WSDL URL along with the Namespace and other details.

 

E-mail notification upon customer creation from AX or EPOS or MPOS

Dear Friends,
 As we know that there is a standard AX functionality (after configuring e-mail notification profiles), which helps us sending e-mail notifications from AX once the customer gets created through online channels (along with many other scenarios; like sales order creation, order confirmation etc).

 

But this does not works, in case we need to use it upon creation of new customers from AX, or from EPOS or MPOS. To achieve this, we need to do some customizations following the standard coding technique (which can be injected for customer creation, based upon the requirement); and this will help us using this standard functionality of e-mail notification.

·         We need to put data in “RetailEventNotificationTable” to use the standard e-mail notification functionality.

·         There is an abstract class called “RetailENInfo”; which takes care of all these e-mail notifications which gets triggered. We need to inject the code in “construct” method to initiate our code.

·         There is one more abstract class called “RetailOENInfo” (which extends “RetailENinfo”), and gets used for configuring the parameters and other default values. We need to inject our codes in “getToAddr”, “initParameterMap” methods to put our business logic for sending the e-mail to the customer e-mail being provided in customer master. Also we need to create one “parm” method over here, for fetching the complete tuple related to the customer account.

·         We need to create one new class (extending the standard “RetailOENInfo” class (as being done for all other event notifications). In this class, we need to do method overriding for the standard method “resolveSalesOrder” of “RetailOENInfo” class; and we also need to do method overriding for standard method “eventNotificationType” of “RetailENInfo” class.

·         Once all these codes are completed, the following code can be injected (as this example is creating record in “RetailEventNotificationTable” table from “newCustomer” method of “RetailTransactionServiceCustomer” class, which gets used for new customer creation from EPOS or MPOS). In case there is a requirement of sending the notification upon creation of customers from AX; this portion of code can be injected in “insert” method of “CustTable” table as well.

Best practices related to AIF integration

Dear Friends,
 
As we see a large number of AIF integrations with various 3rd parties and AX; thought of sharing the best practices that normally should be followed -
 

S.No	Category	Verification Areas
1.	Modification of framework objects	Modification of standard framework objects are not suggested, as it might lead to problem and also might lead to issues during code upgrade.
2.	Modifications after running the wizard	Modifications in the class methods and other areas may be needed, after running the wizard and creating the relevant objects.
3.	Naming conventions	Standard naming conventions should be followed.
4.	XML documentation	XML documentation should follow the standard AX standard.
5.	Coding best practices	Other standard coding best practices should be considered.
6.	Using Web Services	Web services are synchronous, requiring that both applications be running at the same time.   Use in transactional scenarios, while exchanging data.   Do not use in cases in which there is fear of denial of service attacks, or fear that the service host may go down.
7.	Recommendations while configuring AIF	It is unsafe to deploy AIF using Web services outside the intranet without installing additional middleware such as BizTalk Server to ensure proper security. As installed with Microsoft Dynamics AX, AIF Web services are intended for intranet deployment only.   Deploy Web services in the intranet only and configure the Web server so that it is not facing the Internet. By default, AIF services implement the “basicHttpBinding” binding configured to use WCF message-level security. Administrators should follow the standard WCF configuration in IIS.   Secure outbound Web services so that only authorized users can send data from Microsoft Dynamics AX by setting security key permissions on the AIF services. This is done by assigning users permissions to specific services. Authentication and encryption are especially important for business-to-business scenarios in which data is transmitted over the public Internet. For HTTP ports, you can add HTTPS settings through Internet Information Services (IIS).   For asynchronous requests that use the file system adapter, AIF uses the file owner as the submitting user to process the request. The service is executed in the context of the submitting user if a separate logon user is not specified on the Inbound ports form.   Make sure that data that is sent to and from AIF integration ports is encrypted and can be accessed only by authenticated and authorized users.   Restrict the use of integration ports to authorized users and companies. In this way, an integration port can send or receive data only for specific customers, vendors, or warehouses, and you can avoid spoofing attacks.   To restrict the data fields that can be read or modified through an integration port, use data policies.   Before you add an Extensible Stylesheet Language Transformation (XSLT) as part of pipeline processing, make sure that the XSLT is secured. Also make sure that the XSLT can handle documents that contain incorrect or malicious data. Thoroughly test any transformations to make sure that they do not contain code that can run and cause exploitable errors on the system.   By default, scripting is disabled on the component that is used for XSLT transforms, to help protect the system against scripting attacks.