2 mins read

AOT Maps – the consistent approach to access same data

The AOT maps residing in the data dictionary is very useful element under DD node after tables, enums and EDTs. Perhaps they aren’t as widely used as they should be in usual application programming. However, they have the power to solve some key daily problems in AX running in the production environment.

Map defines X++ elements that wrap table objects at runtime. We can associate a map field (just a like a table field) to a data field in one or more tables. This enables us to use same field name to access fields with multiple names in multiple tables. Unlike tables, maps are not database objects and hence they dont synchronize with the sql server.

Lets consider an example. In AX application, we have a map called CustVendGroup. As it name shows, it appears to be the combination of both Customer and vendor related data.

Underneath mappings, we can define multiple mappings to multiple tables to associate map fields with different tables’ fields. In this example, we actually have two tables (CustGroup & VendGroup), storing same information but for different entities. Now writing consistent logic for both of these tables is easier for us and we dont have to do separately for each of them. Suppose we want to do a validation around ClearingPeriod field, write a method on the map.

boolean validateClearingPeriod(CustVendGroup _group)
// do validation on CustVendGroup.ClearingPeriod and return boolean

Now use that validation based on map in your business logic.

CustGroup custGroupTable;
VendGroup vendGroupTable;
CustVendGroup custVendGroupMap;
custGroupTable.ClearingPeriod = “Period 1”;
vendGroupTable.ClearingPeriod = “Period 2”;

if (custVendGroupMap.validateClearingPeriod(custGroupTable))
// do something here

if (CustVendGroupMap.validateClearingPeriod(vendGroupTable))
// do something here

We are using the same method here with different tables buffers as parameters. AX does automatic binding here from map fields to table fields.


  • Simplicity – single interface to fields in multiple tables
  • Consistency – table fields with varying names can be accessed
  • Re-usability – code written on map methods runs against map fields.