Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What does the filtering attributes on the CRM 2011 plugin registration tool do?

I assumed that for an Update plugin, it specified a list of attributes, that if are changed, cause the plugin to fire.

So if I register a plugin against Foo, with only one filtering attribute specified against Bar, every time a Foo entity is updated, CRM performs a check to see if Bar has been updated, if it has, it runs my plugin. So with the code below, I would expect my plugin to execute once.

Foo foo = new Foo();
foo.Bar = 0;
foo.Id = service.Create(foo);
foo.Bar = 1;
service.Update(foo.Bar); // My plugin would execute
service.Update(foo.Bar); // Bar hasn't changed, I would assume the plugin will not  execute

Am I right in this assumption?

like image 428
Daryl Avatar asked Dec 07 '12 22:12

Daryl


People also ask

Why plug-in step registrations should include filtering attributes for update messages?

In order to prevent extra processing in the environment, minimize the logic needed in a plug-in and all the update to complete as quickly as possible, it is highly recommended that plug-in step registrations also include filtering attributes for update messages.

What happens if no filtering attributes are set for a plug-in?

If no filtering attributes are set for a plug-in registration step, then the plug-in will execute every time an update message occurs for that event. A combination of no filtering attributes and auto-save functionality could lead to unnecessary plug-in executions causing undesirable behavior and degrade performance.

Why does my CRM UI send the same value twice?

The CRM ui doesn't usually send a value unless it has changed (forcesubmit overrides this behaviour). In your example Daryl the plugin will fire twice as the filtering attribute is present in both requests. Show activity on this post.

What are the advantages of filtering attributes on post update events?

If you use “Filtering Attributes” on post update events, you don’t need to compare the value of fields using PreEntityImage and PostEntityImage. The other biggest advantage is that your plugin does not execute on every update event. Here is some code. This code creates a note for a contact when parentcustomerid field is updated.


1 Answers

While your initial analysis is loosely correct (i.e. filtering attributes cause the plugin to fire only if one or more filtering attributes have changed) this is not fully accurate.

When an entity is changed, e.g. the email address on a contact, the platform (and therefore your plugin) only receives the delta. In my example there would be an Entity in the Target InputParameter which only contains a single attribute (email). This is the case even if the contact record contains much more data - only that which is changed is sent to the platform. (as an aside, this is where Pre and Post entity Images come in as they allow you to access values on the entity that weren't changed, without having to issue a Retrieve).

So with this in mind it is instead correct to say that filtering attributes mean that the plugin will only fire if one or more of the filtering attributes are present in the request. The CRM ui doesn't usually send a value unless it has changed (forcesubmit overrides this behaviour). In your example Daryl the plugin will fire twice as the filtering attribute is present in both requests.

like image 133
Greg Owens Avatar answered Oct 21 '22 02:10

Greg Owens