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.