hile the default behavior of Microsoft Dynamics CRM 4.0 is completely functional, it’s also general; more often than not, you’ll find you need to augment it based on specific business demands. Microsoft Dynamics CRM 3.0 supported custom business logic in the form of callouts and workflows, but Microsoft Dynamics CRM 4.0 adds even more robust support for custom business logic in the form of plug-ins. Workflows in Microsoft Dynamics CRM 4.0 are now based on Windows Workflow Foundation 3.0 which increases their power to extend MS CRM’s behavior.
|Author’s Note: Microsoft Dynamics CRM 4.0 online does not support plug-ins; however, it does support workflows.|
In this first part of a two-part article you will see how to capitalize on the unified event framework for plug-ins to expose entity events to a broker service, which publishes these events, and to notify clients subscribing to these events. A good integration scenario would be to publish CRM entity audit information to a SharePoint list which can then be showcased to a variety of audiences. The broker service is a topic-based publisher/subscriber (pub-sub). A pub-sub-based architecture allows any subscriber bound to the contract to access CRM audit information.
You can find more information on topic-based publish-subscribe operations here
|What You Need|
The Unified Event Framework API
Microsoft Dynamics CRM 3.0 offered separate interfaces for extending the custom behavior using callouts and workflows. In contrast, Microsoft Dynamics CRM 4.0 has a unified event framework for both plug-ins and workflows, which reduces the overhead of using separate interfaces and makes the model very flexible.
Here are the key features of the unified event framework:
- Custom extensions (plug-ins/workflows) are portable because they use the same runtime.
- Workflow activities and plug-ins are deployed to the database, thereby making the distribution very easy.
- Both asynchronous and synchronous processing are supported. Plug-ins registered for synchronous processing execute immediately, whereas plug-ins registered for asynchronous processing are queued.
Pre and Post Events
|Figure 1. : Event Execution Pipeline. CRM messages flow through the system as shown in the diagram.|
A call to a CRM service is treated as a message. The unified event framework exposes a five-stage event pipeline that processes the message in a synchronous or asynchronous fashion.
There are a few important things to keep in mind about plug-ins:
Plug-in correlation: Certain scenarios might cause a plug-in step to execute in an infinite loop. For example a plug-in registered for an update event on an account updates the account on being executed. Always use the plug-in context to create a proxy to the CrmService because it can detect infinite loops. You can use the CreateCrmService method of the plug-in context to create a CrmService proxy. If you need to create a CrmService instance in the plug-in, set the service’s CorrelationTokenValue property to a new instance of CorrelationToken class. The plug-in context CorrelationId, Depth and CorrelationUpdatedTime are passed in as instance parameters. The CorrelationToken class makes use of soap headers to maintain the context association with the caller.
Shared Variables: The plug-in context has a SharedVariables property bag that holds properties that plug-ins registered at different stages of the pipeline can share.
Offline support: You can register plug-ins for execution in offline mode. This feature allows support for plug-ins in Microsoft Dynamics CRM for Outlook. The plug-in context has an IsExecutingInOfflineMode property to check if the plug-in is being executed in offline mode.
For Further Reading
For more information, these two links are good places to start: