Pipeline simulation fails to call registered steps if Target is null (e.g. on custom API messages)

[synesthesia]

Scenario is a custom API plugin, and a further plugin registered PostOperation Async on the same message.

I've been able to test the API plugin by setting up a FakeMessageExecutor on the relevant message in which I set up a plugin context and call the plugin. When I run the calling code to send this message, the APIU plugin gets executed correctly.

If I set up Plugin Registration for the postop plugin though, I can still test the main plugin by this method but the later registration is not called.

I think the issue is at https://github.com/DynamicsValue/fake-xrm-easy-plugins/blob/08b7a3f36d9fd10bd941b52224f96bb9f2a6e865/src/FakeXrmEasy.Plugins/IXrmFakedContextPipelineExtensions.cs#L191-L198 where the downstream plugin is only called if target is an Entity or EntityReference.

Even if I were to fakeup a Target in my FakeMessageExecutor, the UsePipelineSimulation code always calls IXrmFakedContextPipelineExtensions.GetTargetForRequest(request), and that method (for obvious reasons I guess) only handles built-in messages.

When I have thought it through a bit more will be happy to offer a PR, if you think this is the right track.

[jordimontana82]

Hi Julian (@synesthesia),

Thanks for raising this. Indeed, I see what you mean. The GetTargetForRequest was introduced mainly in the latest versions to support Pre and Post Images , which only apply to CRUD operations, which wouldn't be needed for custom API plugins actually, so we could probably refactor the ExecutePipelineStage methods to support that scenario.

Could you provide a sample unit test to reproduce if possible?

We're going to introduce several other improvements as part of pipeline simulation, and so this could be part of the next release.

[synesthesia]

@jordimontana82 happy to start my contribution with a demonstration failing test, but unlikely to be before end of the month as have a crunchy deadline at work :-)

[jordimontana82]

That's no problem at all, @synesthesia

[jordimontana82]

@synesthesia Thanks a mill for that PR.

You're right, it's only invoking plugin operations if there is a target.

I think we could workaround this problem by just passing in the OrganisationRequest's parameters into the InputParameters of the plugin when the request received is not one that requires a target (mostly CRUD operations), as you mentioned in the issue. The target was mostly needed to take a snapshot of the data for new plugin images functionality, but that doesn't apply to custom actions / APIs.

Then, in a future release, we could add other enhancements to actually maybe introduce specific methods to register custom APIs and their associated input / output parameters, because then we could also validate their metadata (i.e. ranges, max length, mandatory / optional params etc).

But I'm happy to introduce that workaround first.

Thoughts? :)

[synesthesia]

Firstly @jordimontana82 huge apologies for delay in responding - I took most of the summer off and it has been mad since (of course).

I think that workaround makes a lot of sense.

I'd be happy to have a look on PR, but don't want to hold this up if it's something you can see a quick workaround .

[jordimontana82]

@synesthesia No worries. I do have this in my radar, just wanted to release some very needed changes first for 2.2.0 and 3.2.0 versions but this is in the backlog.

[jordimontana82]

Sorry for the delay on this one @synesthesia , I have reviewed your PR in detail, and I've added custom apis to 2.3.x version in another PR: https://github.com/DynamicsValue/fake-xrm-easy-plugins/pull/27

Need to tweak build for older versions and review code coverage before merging.

But I've introduced a new method to register custom api's which will hopefully make it very easy to use them along with the new plugin registration functionality to automatically register plugin steps that will be shipped along with that release as well...

[jordimontana82]

@synesthesia Adding #75 to cater for other scenarios related to Custom Apis

[jordimontana82]

Closing as already resolved in 2.3