4

I'm trying to understand the plug-in sample from here. There's this condition:

// The InputParameters collection contains all the data passed in the message request.
if (context.InputParameters.Contains("Target") &&
                context.InputParameters["Target"] is Entity)

Speaking generally, not just with regard to this sample, on what prior knowledge should I base my decision to access a specific property? How could I have known to test whether the InputParameters contains a "Target" key (I assume I'm not supposed to guess it)?

And on what basis could I have known to ask whether the "Target" mapped value is of Entity type, and not some other type?

I found this post from 2 years ago, and I've found this webpage, saying (emphasis is mine):

Within a plugin, the values in context.InputParameters and context.OutputParameters depend on the message and the stage that you register the plugin on. For example, "Target" is present in InputParameters for the Create and Update messages, but not the SetState message. Also, OutputParameters only exist in a Post stage, and not in a Pre stage. There is no single source of documentation that provides the complete set of InputParameters and OutputParameters by message and stage.

From my searchings, a single source still doesn't exist, but maybe the possible values can be found using the Dynamics Online platform, somewhere deep down the Settings menu, maybe? Any source would be great.

Community
  • 1
  • 1
OfirD
  • 9,442
  • 5
  • 47
  • 90

3 Answers3

7

I know this is an "old" question that already has been answered, but I think this can be helpful. I've built a small web page that contains all the messages with all the Input/Output parameters. You can access it from here:

enter image description here

Federico Jousset
  • 1,661
  • 14
  • 21
4

The best practice for doing this is to use a strongly typed approach. If, for example, you want to know which propertes are available on a CreateRequest, you would do:

var createReq = new CreateRequest() { Parameters = context.InputParameters };
createReq.Target; // Has type Entity

Take a look at the full blog post explaining this approach: Tip: Proper handling of Plugin InputParameters

Original answer:

It depends on which request we are talking about. See Understand the data context passed to a plug-in on MSDN.

As an example, take a look at CreateRequest. One property of CreateRequest is named Target, which is of type Entity. This is the entity currently being operated upon by the platform. To access the data of the entity you would use the name “Target” as the key in the input parameter collection. You also need to cast the returned instance.

Note that not all requests contain a Target property that is of type Entity, so you have to look at each request or response. For example, DeleteRequest has a Target property, but its type is EntityReference.

In summary: Look at the actual request, e.g the CreateRequest.

Henrik H
  • 5,747
  • 1
  • 21
  • 33
  • Well, if `"Target"` is the only property of `CreateRequest` that is relevant here (i.e., holds a reference to the entity), why then the `if` condition is needed? What may happen if it is omitted? – OfirD Oct 27 '16 at 10:51
  • I do not see the _if (context.InputParameters.Contains("Target")_ part being needed. A CreateRequest should always contain Target in its InputParameters. – Henrik H Oct 27 '16 at 11:00
  • 2
    I think the `if (context.InputParameters.Contains("Target")` part is to prevent errors if you have the same code being registered for multiple request types. For example, if you register your plugin on `Retrieve` and `Create` but you want different things to happen, you could (potentially) write a single plugin for both operations – jasonscript Nov 02 '16 at 00:09
2

In 2011 someone actually generated typed properties based on the message type. Kind of neat: https://xrmpalmer.wordpress.com/2013/05/27/crm2011-plugin-inputparameter-and-outputparameter-helper/

It would show you want parameters are possible per message.

Daryl
  • 18,592
  • 9
  • 78
  • 145