Monday, 29 February 2016

Tips to resolve issues of adding new data sources in list pages

Dear Friends,

As we all know, to include new fields in a list page, we need to work in the queries (at times adding a new data source, specifying the proper joins and relations) and also may need to work in the interaction class.

At times, doing this also, we do not get the newly added data source in the existing list page's data sources (after doing a "Restore" in the form as well); although for new forms, it gets properly displayed.

To overcome this, we need to do the following thing - 

  • Right click on the data sources in the form.
  • Re-select the query once again, and save the form.
Once it is done, the data source will get properly refreshed, and only then the design level changes can be achieved.



Tuesday, 23 February 2016

Tips of using LCS and Visual Studio Online for code upgrade functionality in Rainier

Dear Friends, 

We all are very much excited about Rainier, and quite a few of us have already started working on AX 7.0 (Rainier) technical previews (CTPs). In earlier versions of AX, using Life Cycle Services (LCS) was not a mandate, but now with Rainier, it seems to be a mandatory thing. Thought of sharing few important tips and steps related to integration of Rainier with LCS, for upgrading of codes from AX 2012 - 

  • As of now, to connect LCS for obtaining the functionalities related to Rainier, one need to have an account on "OnMicrosoft" Azure domain account.
  • Project needs to be created in LCS.
  • VSO (Visual Studio Online) and LCS needs to be synchronized along with the project and get connected.
  • LCS does have a "Code Upgrade" tool, where the model store needs to be uploaded. 
  • It analyses, upgrades and creates Visual Studio project solutions (normally 2 solutions gets created, one for upgraded objects, and another one for upgrade conflict objects). 
  • Each solution will have model and layer specific projects.
  • As of now, LCS code upgrade facility is available only for AX 2012 codes.
  • Developers need to analyze and fix the issues, so as to obtain an error free build.
  • BP deviations also needs to be analyzed and needs to be addressed, depending upon the criticality and feasibility of the same.



Monday, 22 February 2016

Common issues and solutions while importing ISV license file

Dear Friends,

When we think about preparing an ISV solution, Microsoft Dynamics AX 2012 allows ISVs to create encrypted license files using x509 certificates, to protect their intellectual property. When customers deploy ISV modules to their environment, they are required to import the license file to enable the module. During the license import process, the certificate that is used to sign the file is checked against the root certification authority to verify its validity. In certain cases, however, the root authority may not be available in the system and thus requires an internet connection to check the validity through CA (Certificate Authority). The process steps are
  • Perform the standard installation.
  • Import the certificate (this needs to be imported under “Trusted Root Certification Authorities”).
  • Import the model or model store (certificate needs to be imported prior to this, as this will change the signature of model to “Yes”).
  • Import the license file (the license file needs to be generated by the ISV partner, seeking the required details from the customer or partner, where ISV will be deployed; and providing the certificate related inputs).
  • Synchronize the database.
  • Compile and full CIL of the application.


But at times, in spite of importing the certificate and the model/model store; we get stuck while importing the license file. To achieve this, the following steps needs to be followed –

  • Launch MMC.exe.
  • Go to File > Add/Remove Snap In.
  • Go to Certificates.
  • Click “Add”.
  • Select “Computer Account”.
  • Click “Next” and “Finish”.
  • Click Local Computer > Trusted Root Certification Authorities > Certificates > Import.
  • Follow the wizard to import the certificate.
  • Try importing the license file.


Thursday, 3 December 2015

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.


 

Tuesday, 1 December 2015

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.