6 Practical Tips When Using DIEF for Dynamics AX 2012 R3
I have been working with DIEF in Dynamics AX 2012 R3 over the last several weeks. After logging a few hours I have learned a some new tips and will share them in this blog post.
In one of the projects, the requirement was to create a custom entity for the table that contains the information to associate an AX user with a Worker. This is a one-to-one relationship defined in the DirPersonUser table to the DirPerson table. The DirPersonUser table is a Date Effective table in AX with a ValidTimeStateType of UtcDateTime and just four fields.
After running the Custom Entity Wizard for this DirPersonUser table it produced a private project in the AOT with several objects. The staging table looked like the following:
I knew the import file from the external system would only have the Personnel Number representing the Worker record and the User string representing the AX user. Example of the Excel file:
Since the PersonnelNumber field is not in the new entity table for staging, I added it manually. I also deleted the DirPartyTable_ fields to simplify the staging table as I thought those were unnecessary. I decided at that point I will use a method in the new entity class to handle the PersonnelNumber to RecId translation that is required by the PersonParty field of the DirPersonUser table. I wrote the following method to handle this translation:
REPLACE WITH CODE HERE.
DIEF Tip #1
When you add custom methods to a DIEF entity class, the name of the method must start with ‘generate’ so it shows up in the DIEF mapping visualization form. Use a container for the return type if you want to map the data to the target table.
The custom method shown in the mapping form – note the return value from the method maps to a field in the target table:
Finally, when I went to run the process in AX to generate records from the Staging table to the Target table I came across another problem. It showed that there were 0 records in my Staging table when I knew there were records:
To troubleshoot this issue, I ran a SQL Profiler trace and was able to see something interesting with the select statement. I noticed the Date fields coming into play and decided that those were not necessary and causing the incorrect results.
I then removed the following date fields from the Staging table so it was no longer a date effective table and removed these fields from the unique index.
DIEF Tip #2
Sometimes SQL Profiler is helpful to troubleshoot issues with Dynamics AX. If find it useful in working on DIEF in addition to the X++ code debugger. To use it, add the TSQL and Stored Procedure events in the trace. Start the trace, reproduce the error, and then stop the trace. It takes practice to use this tool but I think it is overlooked when troubleshooting AX development.
The date fields I removed from the staging table:
DIEF Tip #3
The staging table can be changed to meet your business requirements. In my example I added the PersonnelNumber because I knew I wanted to use it from the source file in my custom method. I removed additional fields and altered the Index so the select statement would return my desired records.
In other DIEF projects I have seen a problem where the results of the Staging to Target process would show records being updated when I knew they were only created. This is due to a missing or incorrect Relation defined from the Staging to Target table.
DIEF Tip #4
If you run into a problem where you see an incorrect number of records updated or created, check the Relations defined on the Staging table. Create a relation where the records from the two tables would form a one to one relationship
DIEF Tip #5
You can override the insertUpdate method of the entity class to handle customization scenarios. The following example checks for existing records in the target table and provides only update code. If there is not an existing record, then raise an error that will be show in an Infolog during the DIEF processing.
public Common insertUpdate(Common _target, boolean _callInsertLogic = false, boolean _callValidateLogic = false)
// check if PersonnelNumber from import file exists
select firstonly existHcmWorker
where existHcmWorker.PersonnelNumber == entity.PersonnelNumber;
// HcmWorker record update
target.CustomField = entity.CustomField;
target.Person = existHcmWorker.Person;
ret = super(_target, _callInsertLogic, _callValidateLogic);
// %1 not found. Entity does not support new records.
throw error(strFmt("@SYS76877", entity.PersonnelNumber));
DIEF Tip #6
The last tip is related to the DefaultDimension field on a target table. If you need to provide this value, there is functionality built into the framework to handle it. Select the desired dimension fields and a delimiter in the Source data format form under DIEF in AX. This will create a dimension format similar to what you would provide in the source file. Here is a simple one field dimension:
Source file example:
If the entity class has a generateDefaultDimension method, you can map your source and target fields in the mapping form. Or you can also use this method in your custom code similar to the following example:
hcmEmployment.DefaultDimension = DMFDimensionHelper::generateDefaultDimension(entity.DefaultDimension, dmfDataSourcePropertiesGlobal, "");
Good luck with your DIEF projects in Dynamics AX!