Microsoft Dynamics AX 2012 Learning Portal

Friday, 22 February 2013

Import From Excel File Using X++ in AX 2012

Here is the code snippet for importing data from Excel in AX 2012.

In this example I have a ProductType table with fields (ID, ProductType ,Description )

static void ProductType(Args _args)

{

SysExcelApplication application;

SysExcelWorkbooks workbooks;

SysExcelWorkbook workbook;

SysExcelWorksheets worksheets;

SysExcelWorksheet worksheet;

SysExcelCells cells;

COMVariantType type;

Name name;

FileName filename;

ProductType productType;

int row;

int _productTypeId;

str _productType;

str _description;

;

application = SysExcelApplication::construct();

workbooks = application.workbooks();

//specify the file path that you want to read

filename = "Path\\filename.xlsx";

try

{

workbooks.open(filename);

}

catch (Exception::Error)

{

throw error("File cannot be opened.");

}

workbook = workbooks.item(1);

worksheets = workbook.worksheets();

worksheet = worksheets.itemFromNum(4); //Here 3 is the worksheet Number

cells = worksheet.cells();

{

row++;

_productTypeId = any2int(cells.item(row, 1).value().toString());

_productType = cells.item(row, 2).value().bStr();

_description = cells.item(row, 3).value().bStr();

productType.ID = _productTypeId;

productType.ProductType = _productType;

productType.Description = _description;

productType.insert();

type = cells.item(row+1, 1).value().variantType();

}

while (type != COMVariantType::VT_EMPTY);

application.quit();

}

Thursday, 21 February 2013

Difference between Enumerator and Iterator in AX 2012

Difference between Enumerator and Iterator(use for list, Maps or Sets element’s traversing)

· We can traverse our List, Map or Set collections by using either an enumerator or an iterator .

· We can’t add/Delete elements in the List or Maps or Set using Enumerator class but we can do it via iterator class

· It is a best practice to use the Enumerator class instead of the Iterator class, because enumerators are automatically created on the same tier as the map (when calling the List.getEnumerator method)

· Enumerators require less code than iterators to initiate there instance, they perform slightly better.

Why Enumerator introduced?

When collection classes were first introduced in Dynamics AX, the iterator was the only option. But because of a few unwarranted drawbacks that appear as hard-to-find errors, enumerators were added, and iterators were kept for the backward compatibility. Just see the below listed code snippet

List list = new List(Types::Integer);
ListIterator iterator;
ListEnumerator enumerator;
;
//Populate List
…..
…..

//Traverse using an iterator.
iterator = new ListIterator(list);

while(Iterator.more())
{
print iterator.value());
iterator.next();
}

//Traverse using an enumerator
enumerator = list.getEnumerator();

while(enumerator.moveNext())
{
print enumerator.current();
}

The 1st difference is the way iterator and enumerator instances are created. For the iterator, you call new, and for the enumerator, you get an instance from the collection class by calling the getEnumerator method.

In most cases, both approaches will work equally well. However, when the collection class resides on the opposite tier from the tier on which it is traversed, the situation is quite different.For example, if the collection resides on the client tier and is traversed on the server tier, the iterator approach fails because the iterator does not support cross-tier referencing. The enumerator does not support cross-referencing either, but it doesn’t have to because it is instantiated on the same tier as the collection class. Traversing on the server tier using the client tier enumerator is quite network intensive, but the result is logically correct because some code is marked as “Called From”, meaning that it can run on either tier, depending on where it is called from. You could have broken logic if you use iterators, even if you test one execution path. In many cases, hard-to-track bugs such as this surface only when an operation is executed in batch mode.

The 2nd difference is the way traversing happens which is another potential threat as the onus lies on the developer to ensure that he moves the pointer by using .next() method else the code can land into endless loop.So again enumerator is clear winner here

But there is still one scenario while iterator holds edge over enumerator, if you want to delete/insert items from list.See the code snippet below:

List list = new List(Types::Integer);
ListIterator iterator;
;

list.addEnd(100);
list.addEnd(200);
list.addEnd(300);

iterator = new ListIterator(list);
while(iterator.more())
{
if(iterator.value() == 200)
iterator.delete();
iterator.next();
}
print list.toString(); //{100,300}
pause;
}

Model and Model Store in AX 2012

Need of Models:

Models were introduced in Microsoft Dynamics AX to help partners and customers more easily install and maintain multiple solutions side by side in the same layer.

Models:

A model is a set of elements in a given layer. Each layer consists of one or more models. Each layer contains one system-generated model that is specific to that layer. Every element in a layer belongs to only one model. In other words, no element can belong to two models in the same layer, and every element must belong to a model.

A model is permanently associated with the layer that is created in. If you need to move one of your models from one layer to another, you have to perform the following steps:

1. you must create a project from the model in the AOT,

2. export the project as an xpo file,

3. create a target model in the desired layer,

4. delete the original model to avoid having to resolve layer conflicts, and

5. Import the xpo file to the target model.

If you are moving elements between models in the same layer, you can use the Move to model command in the AOT.

Model Store:

Models are stored in the model store. The model store is the part of the Microsoft Dynamics AX database in which all application elements for Microsoft Dynamics AX are stored. Customization are also stored in the model store. The model store replaces the Application Object Data (AOD) files that were used in earlier versions of Microsoft Dynamics AX. Models that have been installed in the model store are used at run time.

Note: Models can be exported to files that have the .axmodel extension. These files are called model files. Model files are deployment artifacts.

Managing Label files with Model:

In Microsoft Dynamics AX 2012, label files, or ALD files, are part of models. A label file must be added to a model before the model can be installed. After a model has been installed, Application Label data (ALD) files are pulled from the model store to the local of Application Object Server (AOS) instance when the AOS is started. When the AOS is shut down, the ALD files are pushed back to the model store.

ALD files from earlier versions of Microsoft Dynamics AX are not part of a model file. However, you can import these files into the model store from the Label Files section of the Application Object Tree (AOT). Use the Create from file shortcut command.

Note: The ALD file from an earlier version of Microsoft Dynamics AX must not be located in the application folder of AOS. Otherwise, you cannot import the file.

Working with label files across solutions

It is recommend that you use one label file per solution to simplify installation.

If you find that you require multiple label files, it is recommend that you create a single shared, cross-solution label file and package it as a model file. Then, when you install solutions, you must install two models: the solution itself and the label model.

If you want to ship additional languages, you can add the languages to the solution model, increment the model's version number, and then re import the model.

Thursday, 14 February 2013

Company or Legal entity (DataAreaID) in Dynamics Ax

In Dynamics AX we can use same the information for different Companies (or legal entities). Even though all the data is stored in same physical database, Axapta will determine which data is associated with which company:

· Axapta manages this by using the system field dataAreaId to define which company the data belongs to.

· Company or a legal entity can be said as a record in the CompanyInfo table.

· dataAreaId field will be found in each and every table which is used to store data create/updated from an Axapta form.

· And whenever a new record is added, dataAreaId is automatically initialized to the current company id.

· Whenever a user requests to view data from forms and reports or when the application fetches data using a select statement, Axapta will always return data from the current company, as a filter for dataAreaId is automatically added by the kernel.

· All the created companies will be stored in System Table name DataArea.

The below are few areas where multiple companies is useful:

1. If we wish to train new staff, we can create a new ‘test’ company to perform various examples at the same time the ‘live’ data is not damaged.

2. You may wish to have a ‘planning’ or ‘budget’ company where you can prepare future business models.

3. You may have more than one physical company that handles completely different business, but uses the same systems functionality. You can have separate information to support each company