In my last article I mentioned that I’m going to write a framework that will simplify the way you can develop plug-ins on Dynamics CRM by taking out the angle of plug-in development. That way you can focus on your business functionality instead of having to focus on technical stuff.
To understand how plug-ins work, it is important to know what the execution order of events is.
|Pre validation – stage 10
in the pipeline for plug-ins that are to execute before the main system operation. Plug-ins registered in this stage may execute outside the database transaction.
Pre operation – stage 20
Main operation – stage 30
For internal use only.
Post operation – stage 40
Almost all events go through all of these stages. Stage 30 “Main Operation” is a stage that is reserved for CRM. This is the stage where the actual event happens, e.g. data in the entity is updated, created, deleted etc.
Events in stage 20, 30, 40 run in a context of a database transaction. This means that if anything fails, the action will be rollbacked and no harm is done to the system.
Stage 10 “Pre validation” runs before the database transaction. No data has been modified yet. The ideal place to check if we are allowed to do our magic.
The actual event itself is a message within CRM, below a list of the most important messages I’m going to implement within my framework
creates a new entity
Deletes an entity
Retrieves a single entity
Retrieves multiple entities
Change the state of an entity (from active to inactive and vice versa)
Backward compatibility: Change the state of an entity (from active to inactive and vice versa)
Updates an entity
When we look at a standard plugin implementation, we can implement multiple events by checking the message name in the execute event. We have to do a string comparison to check what message was sent and then we can take the appropriate action.
If we distinguish multiple stages in the lifecycle of an event (pre validation, pre operation, post operation) the code expands even more
IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
IOrganizationServiceFactory serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof (IOrganizationServiceFactory));
IOrganizationService service = serviceFactory.CreateOrganizationService(context.UserId);
if (context.MessageName == "Create")
//write the logic what you want this plugin to do on Create
if (context.MessageName == "Update")
//write the logic what you want this plugin to do on Update
if (context.MessageName == "Delete")
//write the logic what you want this plugin to do on Delete
else if (context.Stage==20)
else if (context.Stage==40)
As you can see in the skeleton above, the code is getting quite messy. If you mix your business logic with the skeleton code you probably will end up with code that is hard to understand and hard to maintain.
My goal is to tuck away all the ugly code and provide you with a clean plug-in class that inherits from a technical base class. In the next article I’m going to implement the technical base class.
Thank you for reading.