Fernitudela.dev

I have seen a few times the FK relationships handled wrongly in the DMF data entities, using, for example, the mapEntityToDataSource method to look for the RecId of the related table, or other solutions of that kind… please, STOP doing that, there’s a way already contemplated to manage them easily and effectively and we are going to see it in this post. Also, we are going to see how to combine it with Composite Data Entities in order to be able to import data through DMF of related tables in a single call, without having to create the header record and wait for the system to generate the Key in order to fill the related field in the lines.

FK Relations in Data entities correct solution

Data entities are supposed to de-normalize the table structure of D365FO, making the data more accessible for integrations. Therefore, it makes no sense to include a RefRecId as a field in the data entity expecting it to be filled in the integrations. What we are going to do instead is to add the related data source to our data entity (as read only) and expose the Alternate Key of the related table, putting the RefRecId relation field as internal/private, this way we will let F&O know that we want to fill the relation field and not to create a new record in the related table. In fact this is the way the Data Entity creation wizard will create it by default, but I consider highly important to understand how it works in order to apply it to already existing Data Entities that need to handle new relations.

Let’s see an example, imagine that we have a table related with the Customer groups table RecId like this:

The entity should look like this, Related DS as read only:

Relation fields of our table as internal/Private:

And it should work like this, for example, using the Excel add-in (OData):

And in the actual table we can see it worked:

Composite data entity. Multi-level related table insert.

Now let’s imagine that we need an integration that creates header and lines records in a single call, since we don’t know the header Id until is created, we can’t do it… or do we?

we can, using Composite Data Entities through DMF.

Let’s see how to create the Composite Data Entity in 5 simple steps:

1. Add relations between the used Data entities.

By the Key fields (don’t forget to set the cardinality and the relation type, it’s important):

(In this case I am going to create a new entity for the CustGroups, called FTDCustGroupEntity. Because the OOB one is not prepared to be used in a composite entity, some of the next steps are missing)

2. Add relations between the staging tables.

By the Key fields, and also the DefinitionGroup and ExecutionID:

3. Add the fields RowId and ParentRowId to the staging tables

Add these 2 Integer fields to the Staging table, they are used during the execution to handle the relationships (you can copy paste them from SalesOrderHeaderV2Staging for example).

4. Create index in the stagings including RowId, ParentRowId, DefinitionGroup, and ExecutionId

This is a recommendation of Microsoft, for performance reasons.

5. Create the actual Composite data entity.

Add new Composite Entity, and add the different data sources in the correct order (and don’t forget to set the relations):

Now let’s try it!

We are going to import this XML file using DMF, it contains 1 new header and 3 lines:

Before importing, let’s go to DMF, and generate the mappings:

Go to child entities (if it appears blank, go back and open it again, it’s a funny bug), and generate the mappings.

Now let’s create a new import project, using the file above, setting the type to XML Element, and let the magic work:

So, I guarantee you that if you follow every step you’ll have a working composite entity for your integrations! See you in future posts or youtube videos, and thanks for your attention.