invoke-d365generatereportdataentity lacks extended fields

[smholvoet]

The invoke-d365generatereportdataentity cmdlet currently leaves out any fields which were added to a data entity through extensions.

Is there a way to include these?

I'm guessing you'll somehow need to include the contents of Metadata/<model>/AxDataEntityView? Willing to raise a PR for this one.

[Splaxi]

Good observation. I don't have any insights to share on where to start with this.

Maybe the community on yammer or Twitter can point us in the right direction?

[FH-Inway]

After a first look, it seems to have to do how the Metadata API is used in the cmdlet. A comment in @goshoom's blog shows a bit of sample code how the API can be used to get extension information. They also have a blog post that shows how to iterate over table fields and I believe that also includes fields from extensions. Hopefully, something similar can be done for entity fields.

[FH-Inway]

I dug a little deeper. Turns out the blog post already works with an entity. Contrary to what I wrote before, it iterates over the fields of an entity, not a table. So very close to what we need. I played around with it and got a version of the cmdlet working that also lists the extension fields.

To make a long story of a few hours of trial and error short: We need to replace

d365fo.tools/d365fo.tools/functions/invoke-d365generatereportdataentity.ps1

Line 104 in 5620cd6

$element = $metadataProvider.DataEntityViews.Read($elementName)

with

            $element = [Microsoft.Dynamics.AX.Metadata.Storage.Extension.ExtensionMethods]::ReadDataEntityViewWithExtensions($metadataProvider, $elementName, $null, $null);

We should also look at Invoke-D365GenerateReportDataEntityField, which uses the internal function Get-AXDataEntities to do something similar.

A bit of background

Note that the cmdlet currently uses the metadata disk provider to reflect on the entities. The blog post uses the runtime provider. Only the runtime provider has Create methods that create a metadata provider that takes extensions into account.

The difference between the provider types is that the disk provider uses the raw xml files, while the runtime provider uses the compiled binaries.

So another solution would be to switch to the runtime provider. This would mean that the entities have to be compiled first before running the cmdlet. This could potentially break the cmdlet for people that require it to run on the uncompiled sources.

Instead, I dug up the ReadDataEntityViewWithExtensions method from the API. I haven't tested if it works with an uncompiled entity/extension, but since it works with the disk provider, I would assume so.

PS: Always a joy working with the undocumented metadata API. Gave me the opportunity to do some dll decompilation... 😐