ExecuteOrganizationRequest response is null when PowerApps throws and exception

[peterbjorkmarker]

Microsoft.PowerPlatform.Dataverse.Client" Version="0.4.20"

Repro:

• Create a plugin that always throws an exception on Create
• Use the ServiceClient.ExecuteOrganizationRequest method to execute a CreateRequest

Expected: The client should parse the response and provide exception details

Actual: Response is null

Sample code: `

var entity = new Entity("in_sample");
            entity.Attributes["in_sampleid"] = Guid.NewGuid();
            entity.Attributes["in_date"] = new DateTime(2021, 1, 1);
            var connectionString = GetConnection();
            var service = new ServiceClient(connectionString);

       var soapExecute = service.ExecuteOrganizationRequest(new CreateRequest()
            {
                Target = entity
            }) as CreateResponse;

[MattB-msft]

This is by design for that call, a null response indicates failure. The exception is in client.LastExecption. This behavior was brought forward from the crmsvcclient and maintained to support forward migration from crmsvcclient to dataverse serviceclient

If you use the client.Execute(org request), on failure it would throw an exception.

[peterbjorkmarker]

Ah that explains it. Thanks!

I went down the route of using ExecuteOrganizationRequest due to working around this behavior: https://github.com/microsoft/PowerPlatform-DataverseServiceClient/issues/143 (_serviceClient.ExecuteOrganizationRequest(request, "", false); - so I use SOAP instead of WebAPI.

I am using coding CrmSvcUtil generated early bound classes and OrganizationServiceContext, which is using ExecuteOrganizationRequest. I do realize I may be asking for trouble with this setup... so thanks for the support! :)

Closing the issue...

[MattB-msft]

@peterbjorkmarker , No what your doing is completely fine. using strongly typed objects is supported for all the call types that support organization request types.

The system translated to the appropriate protocol based on what your doing.

The issue described in #143 is something we have having a hard time reproducing.

thanks MattB.