Data Migration Observations for Microsoft Dynamics 365 for Operations (AX7)
This post is based on some of my initial findings with the Data Migration functionality and Data Entity platform in Microsoft Dynamics 365 for Operations (AX7).
In Microsoft Dynamics AX 2012 R3 I preferred to override the insertUpdate method of the DIEF entity class to gain access into the values of the staging and target tables to make business logic decisions. Now that Microsoft Dynamics 365 for Operations uses the Data Entity platform for integration scenarios, there is a new group of objects to use for insight into the data values at integration runtime.
Data Entities are SQL Views
First I think it is helpful to know that when you run the Data Entity wizard to create the data entity, a SQL view is created once the project in Visual Studio is synchronized with the database. For this example, I created a new data entity called CPRCustomersEntity. This entity is based on the CustTable table for the primary data source and I selected only two fields I care about (AccountNum and CreditRating) from that table. Later I will show how the custom entity will not allow new customer records to be inserted so it only supports updates through the added code.
The SQL view is created with the following select statement:
The joins are in the select statement of the view because of the data source relations to the DirpartyTable and DimensionSetEntity tables in the data entity. Those could be removed but I wanted to leave them in to illustrate how the SQL joins are created based on the data source relations of the entity.
Here is the entity in the designer view of Visual Studio:
Using Data Entity methods to add custom code
The two methods that I found available to use for my scenario are postLoad and persistEntity. I tried some others there were available from the Override context menu and it looks like there could be other methods to use like insertEntityDataSource and mapEntityToDataSource. But for now these two provide a means to add code or at least look at values at different times of the import.
I determined that the postLoad method runs prior to persistEntity. It could be used at a time when you need to know what the current data in the entity is and act on it if needed. Below the entity is returning a credit rating of ‘U\A’ for customer account ‘DE-001’.
The persistEntity method can be used to view what the target data will be after the staging data has been loaded.
The value for the credit rating will be ‘Poor’ as this was the value I had in my import file. The debugger can be used to view the values:
I also added the if statement to run the super method if there is an existing RecId. If there is no RecId, then we know this is a new record and this custom entity does not write new records to the CustTable table. An error message is then raised that the Customer Account does not exist.
Lastly, if the Customer Account is ‘US-002’, we will set the Credit Rating to ‘Excellent’. The import file had the value set to ‘Poor’ but this is an example of changing the target data via code:
Finally, the custom error message can be found by going into the Execution details of the job and clicking on the ‘View staging data’ link to click on the record with the error:
I hope this post was helpful in showing one way to add code to manipulate data and integration processing for the new Data Migration functionality in Microsoft 365 for Operations.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.