I’ve just been creating some custom entities with the Dynamics AX 2012 Data Import Export Framework and came across the following error when moving from Staging to Target.
I found this was caused by there being no title fields on the DMF Entity Table.
when I populated the fields, hey presto, my import worked 
Version 1 of the Data Migration Framework (DMF) for Microsoft Dynamics AX 2012 was supplied by Microsoft in the USR Layer as an optional tool available through its InformationSource portal.
https://informationsource.dynamics.com/RFPServicesOnline/RFPSLHost.aspx#/View/ToolsDownload.xaml
The new version of this tool, now renamed as the Data Import Export Framework (DIAF), is supplied in the FPK layer.
During trials that we did with version 1 of the DMF tool for a customer, we concluded that leaving the tool in the USR Layer was not really an option for us so so we elevated it to the VAR layer and left it in it’s own model. But we found that new objects created for new MDF entities were created in the AOT in the layer and model where the DMF objects reside, regardless of which model you are currently developing in. Although this is a bit odd, it is not an issue in itself unless you want to keep modifications in a different model.
When an object has been created and moved to the model required and then deployed if, for any reason in the future, the original entity is regenerated you must remember to move the AOT objects to the correct model again otherwise you will run into conflicts when trying to re-deploy the objects.
I will be testing what happens with version 2 of the tool to see what happens with this version of the tool as I would assume that it will not create new objects in the FPK layer….but you never know. If anyone gets around to looking at this before us, we would love to hear about it.
The new Dynamics AX 2012 Data Migration Framework can be configured to execute ValidateField for the target record fields by going to Data migration framework/Setup/Target entities.
Click on the button Modify target mapping and then Mapping details.
Normally this is fine but we have encountered some standard Ax tables (in this case InventItemBarCode) where the developer has coded field value defaulting logic in the validateField method. This can lead to some unexpected results and so it is worth watching out for if you enable this level of validation.
Clearly it is poor programming practice to design validate logic that defaults/changes values on the record buffer. Not only is it making it hard to maintain software but it is also likely to cause unexpected problems in data imports. Validate logic should return a Boolean true or false and never amend the data buffer contents but the standard AX code has strayed from this golden rule in some instances. If you are going to enable the validate field option in DMF its worth checking the table’s validate field method first for unwanted operations if you run into something unexpected.
