Plug-ins 101: Simplifying plug-in development – part 2

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.

ExecutionOrder 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
Stage in the pipeline for plug-ins that are to execute before the main system operation. Plug-ins registered in this stage are executed within the database transaction.

 

Main operation –  stage 30
In-transaction main operation of the system, such as create, update, delete, and so on. No custom plug-ins can be registered in this stage.

For internal use only.

 

Post operation –  stage 40
Stage in the pipeline for plug-ins which are to execute after the main operation. Plug-ins registered in this stage are executed within the database transaction.

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

  • Create
    creates a new entity
  • Delete
    Deletes an entity
  • Retrieve
    Retrieves a single entity
  • RetrieveMultiple
    Retrieves multiple entities
  • SetState
    Change the state of an entity (from active to inactive and vice versa)
  • SetStateDynamicEntity
    Backward compatibility: Change the state of an entity (from active to inactive and vice versa)
  • Update
    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

[code language=”javascript”]public void Execute(IServiceProvider serviceProvider)
{
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
if (context.Stage==10)
{
}
else if (context.Stage==20)
{
}
else if (context.Stage==40)
{
}
}
}
[/code]

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.

2 thoughts on “Plug-ins 101: Simplifying plug-in development – part 2

  1. Hosk says:

    I like the explanation of a plugin and the stages.

    I’m not sure about your framework at this stage but it will be interesting to see the next post to see where you go with it.

Leave a Reply

Your email address will not be published. Required fields are marked *