microsoft / microsoft/powerplatform-vscode

Missing actions in generated model files

Open
#413 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
TypeScript
Stars
277
Forks
60
Avg merge
1d 1h
Merged PRs (30d)
14

Description

I have the problem with pac modelbuilder build verb on an environment with a lot of entities - in my case, I'm using Dynamics CRM + Omnichannel + Marketing + Portal. The command used is e.g.

pac modelbuilder build -a -o . -enf "dummy"

the result (please note: 136 messages and only 2 actions written to files):

Connected to... xxxx
Connected as xxxx
Begin Reading Metadata from MetadataProviderService
        Begin Reading Metadata from Server
        Read 0 Entities
        Read 0 Global OptionSets
        Read 136 SDK Messages
        Completed Reading Metadata from Server - 00:00:34.0372615
Completed Reading Metadata from MetadataProviderService - 00:00:34.0436174
Begin Writing Code File
        Processing 0 Entities
        Wrote 0 Entities - 00:00:00.0000116
        Processing 136 Messages
        Wrote 2 Messages - 00:00:00.0730951
        Processing 0 Global OptionSets
        Wrote 0 Global OptionSets - 00:00:00.0000138
        Code written to C:\dev\test\Messages\msdyncrm_GetReactions.cs.
        Code written to C:\dev\test\Messages\msdyn_CreateTrainEffortModelConfig.cs.
Completed Writing Code File - 00:00:00.1031454

but with some sample message filtering:

pac modelbuilder build -a -o . -enf "dummy" -mnf "msdyn*"

the result (please note: 859 messages and 821 actions written to files):

Connected to... xxxx
Connected as xxxx
Begin Reading Metadata from MetadataProviderService
        Begin Reading Metadata from Server
        Read 0 Entities
        Read 0 Global OptionSets
        Read 859 SDK Messages
        Completed Reading Metadata from Server - 00:00:32.4963200
Completed Reading Metadata from MetadataProviderService - 00:00:32.5003595
Begin Writing Code File
        Processing 0 Entities
        Wrote 0 Entities - 00:00:00.0000236
        Processing 859 Messages
        Wrote 821 Messages - 00:00:00.3648441
        Processing 0 Global OptionSets
        Wrote 0 Global OptionSets - 00:00:00.0000256
        Code written to C:\dev\test\Messages\msdyncrm_GetReactions.cs.
        (several hundred lines)
        Code written to C:\dev\test\Messages\msdyncrm_GetPages.cs.
Completed Writing Code File - 00:00:01.4401909

I believe the root cause of the issue is the fetchxml which pac is using to query Dataverse for messages:

<fetch distinct='true' version='1.0'>
	<entity name='sdkmessage'>
		<attribute name='name'/>
		<attribute name='isprivate'/>
		<attribute name='sdkmessageid'/>
		<attribute name='customizationlevel'/>
		<link-entity name='sdkmessagepair' alias='sdkmessagepair' to='sdkmessageid' from='sdkmessageid' link-type='inner'>
			<filter>
				<condition alias='sdkmessagepair' attribute='endpoint' operator='eq' value='2011/Organization.svc' />
			</filter>
			<attribute name='sdkmessagepairid'/>
			<attribute name='namespace'/>
			<link-entity name='sdkmessagerequest' alias='sdkmessagerequest' to='sdkmessagepairid' from='sdkmessagepairid' link-type='outer'>
				<attribute name='sdkmessagerequestid'/>
				<attribute name='name'/>
				<link-entity name='sdkmessagerequestfield' alias='sdkmessagerequestfield' to='sdkmessagerequestid' from='sdkmessagerequestid' link-type='outer'>
					<attribute name='name'/>
					<attribute name='optional'/>
					<attribute name='position'/>
					<attribute name='publicname'/>
					<attribute name='clrparser'/>
					<order attribute='sdkmessagerequestfieldid' descending='false' />
				</link-entity>
				<link-entity name='sdkmessageresponse' alias='sdkmessageresponse' to='sdkmessagerequestid' from='sdkmessagerequestid' link-type='outer'>
					<attribute name='sdkmessageresponseid'/>
					<link-entity name='sdkmessageresponsefield' alias='sdkmessageresponsefield' to='sdkmessageresponseid' from='sdkmessageresponseid' link-type='outer'>
						<attribute name='publicname'/>
						<attribute name='value'/>
						<attribute name='clrformatter'/>
						<attribute name='name'/>
						<attribute name='position' />
					</link-entity>
				</link-entity>
			</link-entity>
		</link-entity>
		<link-entity name='sdkmessagefilter' alias='sdmessagefilter' to='sdkmessageid' from='sdkmessageid' link-type='inner'>
			<filter>
				<condition alias='sdmessagefilter' attribute='isvisible' operator='eq' value='1' />
			</filter>
			<attribute name='sdkmessagefilterid'/>
			<attribute name='primaryobjecttypecode'/>
			<attribute name='secondaryobjecttypecode'/>
		</link-entity>
		<order attribute='sdkmessageid' descending='false' />
	 </entity>
</fetch>

After testing this query, it doesn't return paging-cookie, which implies a limit of 50k records - https://learn.microsoft.com/en-us/power-apps/developer/data-platform/org-service/paging-behaviors-and-ordering#legacy-paging .. A slight modification of the query (m internal order - in sdkmessagerequestfield link-entity) after execution returns a paging cookie:

<fetch distinct="true" version="1.0">
  <entity name="sdkmessage">
    <attribute name="name" />
    <attribute name="isprivate" />
    <attribute name="sdkmessageid" />
    <attribute name="customizationlevel" />
    <link-entity name="sdkmessagepair" alias="sdkmessagepair" to="sdkmessageid" from="sdkmessageid" link-type="inner">
      <filter>
        <condition alias="sdkmessagepair" attribute="endpoint" operator="eq" value="2011/Organization.svc" />
      </filter>
      <attribute name="sdkmessagepairid" />
      <attribute name="namespace" />
      <link-entity name="sdkmessagerequest" alias="sdkmessagerequest" to="sdkmessagepairid" from="sdkmessagepairid" link-type="outer">
        <attribute name="sdkmessagerequestid" />
        <attribute name="name" />
        <link-entity name="sdkmessagerequestfield" alias="sdkmessagerequestfield" to="sdkmessagerequestid" from="sdkmessagerequestid" link-type="outer">
          <attribute name="name" />
          <attribute name="optional" />
          <attribute name="position" />
          <attribute name="publicname" />
          <attribute name="clrparser" />
        </link-entity>
        <link-entity name="sdkmessageresponse" alias="sdkmessageresponse" to="sdkmessagerequestid" from="sdkmessagerequestid" link-type="outer">
          <attribute name="sdkmessageresponseid" />
          <link-entity name="sdkmessageresponsefield" alias="sdkmessageresponsefield" to="sdkmessageresponseid" from="sdkmessageresponseid" link-type="outer">
            <attribute name="publicname" />
            <attribute name="value" />
            <attribute name="clrformatter" />
            <attribute name="name" />
            <attribute name="position" />
          </link-entity>
        </link-entity>
      </link-entity>
    </link-entity>
    <link-entity name="sdkmessagefilter" alias="sdmessagefilter" to="sdkmessageid" from="sdkmessageid" link-type="inner">
      <filter>
        <condition alias="sdmessagefilter" attribute="isvisible" operator="eq" value="1" />
      </filter>
      <attribute name="sdkmessagefilterid" />
      <attribute name="primaryobjecttypecode" />
      <attribute name="secondaryobjecttypecode" />
    </link-entity>
    <order attribute="sdkmessageid" descending="false" />
  </entity>
</fetch>

.. but maybe such modification can affect the non-deterministic resultset (https://learn.microsoft.com/en-us/power-apps/developer/data-platform/org-service/paging-behaviors-and-ordering#ordering-and-multiple-table-queries). Perhaps a better solution would be built-in exclusion of standard messages like Create, Update, Delete and so on.

The issue also applies to the crmsvcutil.exe tool and other tools that use it, e.g. https://github.com/daryllabar/DLaB.Xrm.XrmToolBoxTools/issues/307https://github.com/daryllabar/DLaB.Xrm.XrmToolBoxTools/issues/307

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the pac modelbuilder build entry point and the FetchXML query shown in the issue, then compare results with and without the -mnf "msdyn*" filter. Investigate paging behavior for the SDK message query; done means the generated model files include the expected messages and actions rather than only a small subset.

Written by the indexing model from the issue text.

Assessment

Domain
backend-api-design, cli
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.