The X++ system library includes three APIs that can
be used to reflect on elements. They are described in the following
sections.
1. Table Data API
Suppose that you want to find all classes whose names begin with Invent and that have been modified within the last month. The following example shows one way to conduct your search.
static void findInventoryClasses(Args _args)
{
UtilElements utilElements;
while select name from utilElements
where utilElements.RecordType == UtilElementType::Class
&& utilElements.Name like 'Invent*'
&& utilElements.ModifiedDateTime >
DateTimeUtil::addDays(DateTimeUtil::getSystemDateTime(), -30)
{
info(strfmt("%1", utilElements.Name));
}
}
|
The UtilElements table provides access to all elements. The RecordType field holds the concept. Other fields in the UtilElements table that can be reflected on are Name, CreatedBy, CreatedDateTime, ModifiedBy, and ModifiedDateTime.
Because of the nature of the table data API, the UtilElements
table can also be used as a data source in a form or a report. A form
showing the table data is available from Tools\ Development
Tools\Application Objects\Application Objects. In the form, you can use
the standard query capabilities to filter and search the data.
Some
elements have sub-elements associated with them. For example, a table
has fields and methods. This parent/child association is captured in
the ParentId field of the sub-element. The following job finds all static method elements on the CustTable table element by selecting only table static method elements whose ParentIdCustTable table ID. equals the
static void findStaticMethodsOnCustTable(Args _args)
{
UtilElements utilElements;
while select name from utilElements
where utilElements.recordType == UtilElementType::TableStaticMethod
&& utilElements.ParentId == tableNum(CustTable)
{
info(strfmt("%1", utilElements.name));
}
}
|
Notice the use of field lists in the select statements in the examples in this section. Each record in the table also has a binary large object (BLOB) field that contains all the metadata, source code, and bytecode. This BLOB field can’t be interpreted from X++ code, so you don’t need to fetch it. When you specify a file list to the select statement with fields from the primary index, fetching the actual record is avoided, and the select statement returns the result much faster. The primary index contains these fields: RecordType, ParentId, Name, and UtilLevel.
The UtilLevel field contains the layer of the element. The following job finds all parent elements in the USR layer.
static void findParentElementsInUSRLayer(Args _args)
{
UtilElements utilElements;
while select recordType, name from utilElements
where utilElements.ParentId == 0
&& utilElements.utilLevel == UtilEntryLevel::usr
{
info(strfmt("%1 %2", utilElements.recordType, utilElements.name));
}
}
|
Elements can have IDs. The UtilElements table can’t provide ID information. To get ID information, you must use the UtilIdElements table. The two tables are both views on the elements in the .aod files; the only difference is the inclusion of the ID field in the UtilIdElements table. The following code is a revision of the previous job that also reports IDs.
static void findParentElementsInUSRLayer(Args _args)
{
UtilIdElements utilIdElements;
while select RecordType, Id, Name from utilIdElements
where utilIdElements.ParentId == 0
&& utilIdElements.UtilLevel == UtilEntryLevel::usr
{
info(strfmt("%1 %2 %3",
utilIdElements.RecordType,
utilIdElements.Name,
utilIdElements.Id));
}
}
|
Although
we have discussed two tables that contain the .aod files in this
section, all the application data files have a table reflection API
similar to the ones we have mentioned. Table 1 lists some additional reflection tables.
Table 1. Reflection Tables
| Table Name | Description |
|---|
| UtilElements, UtilIdElements | Tables containing the .aod files, which contain elements. |
| UtilElementsOld UtilIdElementsOld | Tables containing the .aod files in the Old application folder. This information is useful during code upgrades. |
| UtilApplHelp | Table containing the .ahd files, which contain online Help information for users. |
| UtilApplCodeDoc | Table containing the .add files, which contain developer documentation information for elements. |
| UtilCodeDoc | Table containing the .khd files, which contain developer documentation information for Dynamics AX system APIs. |
All the tables listed in Table 1
have an associated class. These classes contain a set of static methods
that are generally helpful. All the classes have the same name as the
table, prefixed with an x.
Suppose you want to report the AOT path for MyForm from the table utilIdElements. You could use the xUtilIdElements function to return this information, as in the following code.
static void findAOTPathForMyForm(Args _args)
{
UtilIdElements utilIdElements = xUtilIdElements::find(
UtilElementType::Form, FormStr(MyForm));
if (utilIdElements)
info(xUtilIdElements::getNodePath(utilIdElements));
}
|
Note
When
you use the table data API in an environment with version control
enabled, the values of some of the fields are reset during the build
process. For file-based version control systems, the build process
imports .xpo files into empty layers in Dynamics AX. The values of the CreatedBy, CreatedDateTime, ModifiedBy, and ModifiedDateTime fields are set during this import process and therefore don’t survive from build to build. |
