Wednesday, 11 November 2015

Method Types in Dynamics AX Classes


There are many different types of methods. Some of the more common types are
1. Static Methods
2. Main Method
3. Display Methods
4. Accessor Methods

1. Static Methods

Static methods are attached to a class. However, they do not need that class to be instantiated to execute that method. They are not within the scope of the class, so any class variables are not available in a static method.
Static methods are declared static by using the Static method modifier.
Static methods are called using the class name followed by two colons (::) and then the methods name.
The following example shows a static method declaration, and a call to that static method.

static public void myStaticMethod()
{
}
myClass::myStaticMethod()

2. Main Method

The main method is a static method that can be used to call a constuctor. It is special because its name is required to be "main". It is used by the system when the class is run directly from a menu item and it takes a parameter of type args. 
Args is a class that is used to pass parameters between objects, for instance, various parameters can be set on the properties on a menu item. When the menu item calls a class, the args class containing those property values is passed to the main method using the args parameter.

3. Display Methods

Display methods are used on forms. They are commonly created on the table, and can also be defined on the form. Display methods return a value that is displayed on the form or report. They are often used to display a calculation, or to look up a single field from another table. 
The following example shows how to display the item name on a form that displays data from a table containing the item id.

// BP Deviation documented
display itemName itemName()
{
inventTable inventTable
select name from inventTable
where inventTable.itemId == this.itemId;
return inventTable.name;
}

The first line in this code is a comment to the compiler indicating that a Best
Practice deviation is considered and evaluated as reasonable. The deviation is
because a display method is able to return any data from any table or field in the system, and so the security implications should be considered.

4. Accessor Methods

Accessor methods enable other elements to set or get the values of variables in a class and it is common that they do both. The following example accepts a value as a parameter, sets a class variable to this value and then returns the value. The parameter has a default value set to the class variable value, so if the method is called without a parameter, it returns the value of the class variable. If it is called with a value in the parameter, then the
class variable is set to this value.

public str myName(str _myName = myName)
{
myName = _myName;
return myName;
}

Monday, 9 November 2015

Best Practices for Table Methods


Following are the types of Table Methods:

  • Application-defined methods – created by a developer specifically for a particular table.
  • System-defined methods – automatically available on every table. These methods are inherited from the xRecord system class.

Application-Defined Methods
Use the properties available on tables and table fields rather than creating code for the same purpose. If you do need to create a method on a table, it must be directly related to that table.
If a table has a unique key, create the following methods:

  1. staticfind
  2. staticexist
  3. static checkExist
  4. static txtNotExist

By default, these methods run on both the client and the server. You can state this explicitly in the method declaration (client server), but don't specify a single tier (client or server). It is a best practice to create these methods on tables. A best practices error does not occur if the method is not called.

Monday, 12 October 2015

Dynamics Ax Virtual Company & Table Collections


This article describes how Dynamics Ax Virtual Company and Table Collection work. We will also
discuss how to move data from normal company to virtual company when you introduce virtual 
company in existing Ax implementation.

Virtual Company:
Dynamics Ax stores data as per company in tables. But there might be occasions when you want to
share data across companies, like country, state, zip codes data. This sharing of data is achieved by 
creating a virtual company and storing data in this virtual company. Normal companies are then 
configured to read/write data from this virtual company. The only purpose of virtual company is to 
share data across companies, you cannot log into this virtual company.

Before seeing how to do virtual company setup, I would like you to show another trick that can be
used to share data across Ax. There is a property on Ax tables called "SaveDataPerCompany", 
you can use this property to save data globally in Ax. To share data set this property to "No".



Note: This data is shared by all the companies in Ax. This option will delete DataAreaId field and 
default (DataAreaId, RecId) index from the table. If you want more control on shared data, like
which companies can share and which can not then use virtual company. 

Virtual Company setup:

Step 1: Create Table Collection

Decide which tables you want to share and create a table collection for these functionally related tables.
For example; if you want to share Global Address Book across companies then you can utilize the 
existing table collection "DirPartyCollection".



To create a table collection, go to AOT\Data Dictionary\Table Collections and on right click select 
"New Table Collection", then just drag your required tables in this collection.

Step 2: Create Virtual Company, configure/attach normal 
companies and table collection

Create a virtual company that will hold the shared data for normal companies.
Note: Before doing the below steps, make sure you are the Ax administrator and the only user online.

Go to Administration -- Setup -- Virtual company accounts, and create a virtual company.



Decide which companies needs to share data and attach those normal companies with this virtual
company.



Attach the table collection with this virtual company.




Your Ax client will re-start and you are done with setting up the virtual company account.

Now, when you have virtual company in place, all new data will be saved in this virtual company.
Only companies attached to the virtual company can use this shared data. All other companies which
are not attached will work normally, these companies will continue to read/write data as per company 
bases.

How to move existing data to virtual company?
When you setup a new virtual company, Ax does not move data automatically from normal company to 
virtual company. This is done by system administrator manually.

There are many ways to do this data move, but I will discuss only two approaches here.

Ax Import / Export:
This is standard Ax approach.
  1. Manually export existing normal company data from Ax.
  2. Remove duplicate records from this exported data set. 
  3. Delete exported data from normal companies.
  4. Import the exported data back in Ax, while logged into one of the participating companies. 
  5. Create records deleted in point 2 again in Ax using your logic. How you want to handle duplicate? 
For example, if you have customer 'Rah' in more than one normal company, what you want to do with this?
Direct SQL:
Use this approach if you have good knowledge about SQL queries and Ax table structures/relationships.
Below are few points that will help you understand what to do and how to do.
  • All Ax tables store data as per company unless otherwise specified. For this, Ax uses a special field
       called DataAreaId. In case of virtual company, it does not matter from which normal company you 
       log-in, it is always the virtual company id which is stored in DataAreaId field of shared tables. 
  • Ax also assigns a unique 64bit number to each record in table. For this, Ax uses a special field called 
       RecId. This RecId is unique in the table and is generated by Ax when you insert a new record in Ax. 
       It is not related to DataAreaId / Company.
  • For unique records between all participating normal companies, update the DataAreaId to the 
        virtual company id.
  • For duplicate records, create them again in Ax using some Ax job or Ax import/export technique.

Attached below are some SQL queries that might help you moving the Global Address Book records from 
normal companies to the virtual company by changing the DataAreaId.

Creating a Custom Inbound AIF Service in Microsoft Dynamics AX 2012

Overview

Application Integration Framework (AIF) services are used to communicate with external systems or applications. Microsoft Dynamics AX 2012 has the following types of services:
  1. Document services
  2. Custom services
  3. System services
An AIF service can be Inbound or Outbound. An Inbound service is used when you want to send data to an external system and Outbound services are used when you want to retrieve data. This tutorial will guide you in creating Custom Inbound AIF services in Microsoft Dynamics AX 2012. Custom services are used when:
  1. The complexity of the entities is relatively low.
  2. When you want to have full control of the service contract.
  3. When data contracts needs to be shared with different entities.

Pre-requisites

  1. Microsoft Dynamics AX 2012
  2. AIF services must be installed and configured on IIS

Important Concepts

  1. Service operation

    Service operations are class methods that expose any business logic in a service. To define a service operation, add theSysEntryPointAttribute attribute at the top of a method. Any existing method can be converted to a service operation by adding this attribute at the beginning of the method. 
    &absp;
    Note:
     The service operation name cannot include Create, Find, Update or Delete. These names are reserved to be used by AIF Document services. AX will make an exception when they are called from a client.
  2. SysEntryPointAttribute

    SysEntryPointAttribute defines the authorization checks that will be performed when a method is called from the server. This attribute must be set on all the service operations. If the value is “true”, it means that authorization checks will be performed for all the tables accessed in the method and if set to “false”, no authorization checks will be performed.
  3. AifCollectionTypeAttribute

    AifCollectionTypeAttribute is used when you want to use a collection as a return type or in a parameter of a service operation. This attribute defines the type of data a collection contains.

Scenario

As part of this tutorial the service will return the list of customer names in Dynamics AX.

Steps

  1. First we will create a new class which will contain Service operations.

  2. Open AOT. Go to Classes and create a new class. Let’s name it CustomerServiceDemo.

  3. Set the RunOn property of the class to Server. This will make sure the class always executes on the server.
  4.  
     
  5. Add a new method and name it as getCustomerNameList. This method will query customers’ names and return a Type list string. Write the following code in the method:
  6. The SysEntryPointAttribute tells AX that this method is a service operation method.

  7. Now we will create a new service and add the above created service operation to it.

  8. Go to Services, right click and select New Service.

  9. Name it as CustomerServiceDemo.

  10. Open the properties of the newly created service and select the CustomerServiceDemo class in the Class field.

  11. Now expand the CustomerServiceDemo service node and add a new Operation by right clicking on Operations and selectingAdd Operation.

  12. All service operations present in the class will be listed. Select the getCustomerNameList service operation by checking the Addfield in the grid and press OK.

  13. The next step is to create a service group and deploy the service to the Inbound Port.

  14. Go to Service Groups, right click and select New Service group.

  15. Name it as CustomerServiceDemoGroup.

  16. Set the AutoDeploy to Yes (Service will start automatically when AOS is started) and set the Description as Customer name service.

  17. Right click the newly created service group and select New Service Node Reference.

  18. In the newly created service node, set the Service property to CustomerServiceDemo. The Name property will automatically default to the Service name.

  19. Now right click the service group and select Deploy Service Group.

  20. A success message will appear if the service group is successfully deployed.

  21. To verify it, go to System administration à Setup à Services and Application Integration Framework à Inbound ports.

  22. The Service group name CustomerServiceDemoGroup will appear here as Port name with a green check mark. This shows that service group is deployed and active. If a red ‘x’ is appearing, select Activate from the action pane to activate the port.

  23. The WSDL URI is the URL of the service which can be used by external systems to access the service.

  24. To test whether the service is running properly, open the Visual Studio Command Prompt by going to All Programs à Microsoft Visual Studio 2010 à Visual Studio Tools à Visual Studio Command Prompt.

  25. Write wcftestclient and press enter. WCF Test Client will open.

  26. Now, go to File àAdd Service.

  27. In the Add Service dialog box, paste the WSDL URI of the port and press OK.

  28. The WCF Test Client will open the service with the list of operations available.

  29. Double click the getCustomerNameList. It will open the operation details in the right hand side pane.

  30. Click the Invoke button. The result of the service will appear in the Response pane.

  31. Pat yourself on the back. You are finished!