Skip to content
Archive of posts tagged model

Model element types in AX2012

As you probably know, Dynamics AX 2012 stores data about application objects in database, instead of in .aod files used before. It also added few new elements to AOT – form parts, Visual Studio projects and so on.

In older versions, you were able to see and query some information about AOT objects in UtilElements table (and few related tables). In AX2012, a new set of tables is available, with SysModelElement table roughly corresponding to UtilElements table. Nonetheless the UtilElements table hasn’t been removed.

So what’s the difference?

Actually, neither SysModelElement nor UtilElements are actual tables – both are views defined in AX database. SysModelElement simply displays data from ModelElement table, while UtilElements view is much more complicated and uses ModelElement and several other tables (that’s why it is so slow). It only simulates how UtilElements table looked in previous versions. If you’re interested in details, look at the design of the view in the database.

You may notice a difference between UtilElements and SysModelElement in the way how they represent element types. UtilElements contains a field called recordType and its type is UtilElementType enum. On the other hand, SysModelElement’s ElementType field is a lookup to SysModelElementType table, which is actually a view again. When constructing SysModelElementType view, ElementType field from ElementTypes table is mapped to SysModelElementType.RecId, so the reference in AX looks like the usual surrogate key.

All IDs from UtilElementType enum have a corresponding record in SysModelElementType table – for example, UtilElementType::Class has ID 45 and there is a record in SysModelElementType with RecId 45 and Name “Class”. But if you dig deeper, you’ll find that SysModelElementType contains more values than UtilElementType, which means two important things:

  1. Some model elements types have no corresponding value in UtilElementType enum.
  2. UtilElements table does not contain some type of elements.

In most cases you simply don’t have to care too much. But you can’t expect to find information about, for example, events in UtilElements. Or you may get errors like “Method ‘UtilElement’ is not supported for treenode (Path: …)” when working with some TreeNode instances, because there is no valid mapping to UtilElementType.

For completeness, here is the list of all types existing in SysModelElementType table but missing in UtilElementType enum:

6 WorkflowProcess
8 SysXal
10 LegacyMenu
39 LegacyFeatureKey
52 WebReport
77 CompositeQueryNode
80 SecurityTask
83 PartReference
96 Event
97 EventHandler
100 CueReference
104 VisualStudioProjectFolder
105 VisualStudioProjectFile
106 InfoPartLayout
107 InfoPartGroup
108 InfoPartField
109 InfoPartAction
110 MenuItem
111 MenuSeparator
112 MenuReference
114 VisualStudioProjectType
116 EventHandlerMethod
120 FormMethod
121 VisualStudioProjectLink
122 SubMenu
123 SubWebMenu
124 SubWebModule
125 FormDesign
126 FormControl
143 FormDataSources
144 SecurityPermissionSet

Moving a model to another layer

It looks like models in Dynamics AX 2012 don’t support moving between layers. Code is not being moved to another layer every day, but it’s also not an exceptional situation. We still have our old tools like export and import of .xpo files, but models just complicate this process instead of simplifying it (because you have to handle model’s properties, e.g. name and version).

I’m going to show a simple workaround, although it’s not suitable for all teams and all situations. If you know a better way, please let me know.

Let’s say you have a model called “Move” containing some objects in USR layer and you would like to move it all to ISV layer. It can be achieved by the following procedure:

  1. Add the model to TFS version control
    You need to create a subfolder in the repository folder, then click Version Control > Add model to version control in AX development workspace and set the model ID and the repository subfolder.
  2. Uninstall the model
    You can use this Powershell command: Uninstall-AXModel -Model Move (Move is the name of the model)
  3. Restart AOS
    The following command restarts all local AOSes: Restart-Service aos*
  4. Change layer in model manifest file
    Go to Source Control Explorer in Visual Studio, ensure yourself that you use the same workspace as Dynamics AX and locate the folder with the “Move” model. Then open Model.xml, find the layer and change the value from Usr to Isv.
    You don’t have to check this modification in if it’s not a permanent change. (That makes sense if you are just releasing a model to a different layer in another application, not moving it.)
  5. Synchronize AX with TFS
    Run AX development workspace and choose Synchronize from Version Control menu. Check Force and pick the folder to synchronize with:

And that’s all – model and its definition, as well as all its objects, are in the ISV layer.

To be absolutely correct, we didn’t move the model. We deleted the model and when AX was started, it has read the (modified) manifest file, created a new model based on this file and the synchronization added all objects to this new model.