RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Extending Microsoft Dynamics CRM 4.0 with Plug-Ins : Page 2

Microsoft Dynamics CRM 4.0 has a very flexible infrastructure that lets you extend the out-of-the-box behavior to meet ever-changing organizational business needs.


Implementing the IPlugin Interface

Every custom plug-in must implement the IPlugin interface to subscribe to the platform events fired during runtime execution. The IPlugin interface ships with Microsoft Dynamics CRM 4.0 SDK. It exposes an Execute method that takes the execution context as an argument. The plug-in context contains information regarding the request message being passed through the event execution pipeline. It also contains information regarding any parameters passed to the request message, and snapshots of the entity before and after the core platform operation. The snapshot is useful for creating an entity audit trail and publishing it to the subscribers.

The following code shows an implementation of the IPlugin interface:

public class DynamicPlugin : IPlugin 
   #region IPlugin Members
   public void Execute(IPluginExecutionContext context)
         AuditMessage message = AuditEntityChanges(context);
         //Log Exception
   private AuditMessage AuditEntityChanges(
      IPluginExecutionContext context)
   private void PublishAuditedMessage(AuditMessage message)

The execute method creates an audit message by comparing the pre and post entity images, and then publishes the audit message to a topic. Subscribers listening to the topic can access the audit information.

Entity Snapshots and the CRM Message Broker

The plug-in context exposes two properties—PreEntityImages and PostEntityImages—that contain information regarding the entity attributes before and after the core operations execute. The AuditEntityChanges method creates the audit message by passing the snapshots to a CompareEntities method in the CRMHelper class, which compares the snapshots and returns information about the attribute changes. Listing 1 shows the code for the CompareEntities method.

In addition to attribute changes, the AuditMessage object also holds information such as the transaction type, the entity audited, and who made the change. The PublishAuditedMessage method publishes this information to a topic (named CrmAudit in this example). The PublishAuditResults method shown below illustrates how a boker publishes the AuditMessage:

public static void PublishAuditResults(
   AuditMessage auditedResults)
   string endpointAddressInString = "EndpointAddress";
   EndpointAddress endpointAddress = new 
   NetTcpBinding netTcpBinding = new NetTcpBinding();
   Message message = new Message();
   message.TopicName = "CrmAudit";
   message.EventData = auditedResults;
   IPublish _proxy = ChannelFactory<IPublish>.
      CreateChannel(netTcpBinding, endpointAddress);

The broker's Publish method accepts a Message object with its TopicName property set to the topic name and the EventData property set to the boxed auditedResults AuditMessage.

If you open the CRMExtension.MessageBroker project in the downloadable sample code included with this article you'll notice that the message broker exposes publish and subscribe message services and a broker service responsible for managing the subscribers. The publish message service has a Publish method responsible for publishing the CRM audit information to the topic.

All subscribers listening on the CrmAudit topic must implement the IPublish interface to gain access to the AuditMessage information. Listing 2 shows a sample SharePoint subscriber that listens to the CrmAudit topic and writes the AuditMessage information to a SharePoint list. You can write additional subscribers to write the audit information to stores such as SQL Server or a log file.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date