Enable or Disable Plug-in (steps) in CRM through CRM UI

How to disable Plug-In in CRM without using Plug-in registration tool

We can enable or disable the plugin steps through CRM Web UI
This is the step if you use the CRM UI to disable the plugin step: 

1. Go to Settings --> Customization --> Customize the System 
2. In the left navigation you can see 'Plug-in Assemblies' and 'SDK Message Processing Steps' 
3. Go to SDK Message Processing Steps 
4. Then, you can select the plugin step you want to disable (We can select more than 1 (multiple select) as well)

5. Just click the Deactivate ribbon and next to process 
             

 

6. We can see the status of those steps now 

7. Here is the status: 
      

If you want to disable through Plug-In Registration Tool, just follow below steps

• We can use the plugin registration tool found in the SDK for the CRM version you currently have.

• Run the tool on any client/server and connect up to the organisation with the plugin you want to disable, you can connect via the discovery service URL found in

              Settings > Customization > Developer Resources

• You will need to authenticate as a user with the permissions required to disable plugins.When you have connected you can click the plugin in the hierarchy and disable each of its steps.

Thanks..!!

Plug in pipeline execution

Plug in pipeline execution

Event Execution Pipeline Stages

The event pipeline is divided into multiple stages, of which 4 are available to register custom developed or 3rd party plug-ins. Multiple plug-ins that are registered in each stage can be further be ordered (ranked) within that stage during plug-in registration.

Event	Stage name	Stage number	Description
Pre-Event	Pre-validation	10	Stage 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. The pre-validation stage occurs prior to security checks being performed to verify the calling or logged on user has the correct permissions to perform the intended operation.
Pre-Event	Pre-operation	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.
Platform Core Operation	MainOperation	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-Event	Post-operation	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.
Post-Event	Post-operation (Deprecated)	50	Stage in the pipeline for plug-ins which are to execute after the main operation. Plug-ins registered in this stage may execute outside the database transaction. This stage only supports Microsoft Dynamics CRM 4.0 based plug-ins

Plug-in Assembly Isolation mode and Storage Component

Plug-in Isolation mode

There are 2 isolation mode available in CRM 2011,

Sandbox : Supported for Microsoft Dynamic CRM Online

None: Supported for CRM 2011 on-premises

Storage Component:

There are 3 storage options available in MS CRM 2011 for deploying assembly,

•              Database
•               Disk
•               GAC

• Database:-

The assembly dll is stored in the database, rather than the file system. The major advantages are that the assembly need only be deployed once if you have multiple CRM servers, and that no additional action is required to restore / redeploy the assembly either during disaster recovery, or if redeploying to an alternate server. This is the preferred option in production environment.

• Disk:-

The assembly dll is placed in the \server\bin\assembly directory on each server. You have to ensure the dll is placed in correct place on all CRM servers, so the deployment overhead is a little greater. I normally use this option in development environments as you can redeploy newer versions solely by file transfer rather than re registering. Also, if debugging the assembly, .pdb file needs to be placed in same location, with this option it’s easy to ensure the dll and pdb are from the same build.

• GAC:-

The assembly is placed in the Global Assembly Cache on each CRM server. The GAC does allow multiple versions of an assembly, but CRM doesn't. So you don’t really gain anything by using GAC.

Note: - There is one further consideration, if your plugin assembly has other dependent assemblies, then you can place this dependent assembly in the GAC whichever of the above options is used. However, if you use the Disk option, then the dependent assemblies can also be deployed into the \server\bin\assembly directory.

Plug-in Images

Plug-in Images

Images are snapshots of the entity’s attributes, before and after the core system operation. Following table shows when in the event pipeline different images are available:

Message	Stage	Pre-Image	Post-Image
Create	PRE	No	No
Create	POST	Yes	Yes
Update	PRE	Yes	No
Update	POST	Yes	Yes
Delete	PRE	Yes	No
Delete	POST	Yes	No

The benefits of images

One of the best uses for this is in update plug-ins. As mentioned before, update plug-in target entity only contains the updated attributes. However, often the plug-in will require information from other attributes as well. Instead of issuing a retrieve, the best practice is to push the required data in an image instead.

Comparison of data before and after. This allows for various audit-type plugins, that logs what the value was before and after, or calculating the time spent in a stage or status.

PreEntityImages :

It is basically used to capture the data when the form loads. That is the data which is present by default when the form loads.  The syntax for using the PreEntityImages in CRM 2011 is changed as compared to CRM 4.0. Remember the PreEntityImages cannot be registered for “create” operation.

Syntax Used in CRM 2011 :

Suppose you registered the Plugin and added a Image with name “PreImage ”

Entity preMessageImage;

if (context.PreEntityImages.Contains(“PreImage”) && context.PreEntityImages["PreImage"] is Entity)

{

preMessageImage = (Entity)context.PreEntityImages["PreImage"];

accountnumber = (String)preMessageImage.Attributes["accountnumber"];

}

Here Entity is an Class that is available in the Microsoft.Crm.Sdk.dll

PostEntityImages :

The Post Image contains the attributes value which are finally changed. We can capture the changed data before the database operation takes place. And can do any kind of validation based on the changed data. Remember it can only be registered  for update message and cannot be registered on create message.

Syntax Used in CRM 2011 :

Suppose you registered the Plugin and added a Image with name “PostImage ”

Entity postMessageImage;

if (context.PostEntityImages.Contains(“PostImage”) && context.PostEntityImages["PostImage"] is Entity)

{

postMessageImage = (Entity)context.PostEntityImages["PostImage"];

accountnumber = (String)postMessageImage.Attributes["accountnumber"];

}

The PreEntityImages and PostEntityImages are Very useful in Scenarios where we want to compare the data that is changed by the user. Based on the changes the custom operation can be performed.

Event Pipeline in Plug-in

Plug-in Event Pipeline

The event pipeline allows you to configure when in the event the plug-in code will execute. The event pipeline is divided into the following events and stages:

Pre-event/Pre-Validation
This stage executes before anything else, even before basic validation if the triggering action is even allowed based on security. Therefore, it would be possible to trigger the plug-in code even without actually having permission to do so and great consideration must be used when writing a pre-validation plug-in.  Also, execution in this stage might not be part of the database transaction.

Example uses:
Some "delete" plug-ins. Deletion cascades happen prior to pre-operation, therefore if you need any information about the child records, the delete plugin must be pre-validation.

Pre-event/Pre-Operation
This stage executes after validation, but before the changes has been committed to database. This is one of the most commonly used stages.

Example uses:
If and "update" plug-in should update the same record, it is best practice to use the pre-operation stage and modify the properties. That way the plug-in update is done within same DB transaction without needing additional web service update call.

Post-Event / Post-Operation
This stage executed after changes have been committed to database. This is one of the most used stages.

Use of Workflow & Plug-ins

Requirement	Plug-in	Workflow
Needs a synchronous action to happen before or after an event occurs	x
The same piece of logic will be executed for different events and possibly on different entities	x	x
The logic needs to be executed while offline	x
Needs elevation of privileges (impersonation)	x
Needs to execute on events other than assign, create, update, setstate	x
The process/logic may take a long time to complete or will be a persistent process (multiple long running steps)		x
Needs an asynchronous action	x	x
End users will need to modify the process logic		x
Child sub processes will be triggered		x

Difference Between Plug-ins & Workflows in CRM 2011

Criteria	Plug-in	Workflow
Execution	Executes immediately before or after the core operation (synchronous).Can also be queued to execute after the core operation (asynchronous).	Queued to execute after the core operation (always asynchronous).
Performance	Synchronous plug-ins can increase the platform’s response time because they are part of the main platform processing. (W3WP.exe) Asynchronous plug-ins have less impact on server response time because the code is run in a different process.(AsyncCRMServices.exe)	Less impact on server response time because the code is run in a different process. (AsyncCRMServices.exe)
Security restrictions	To register a plug-in requires a System Admin or System Customizer security role and membership in the Deployment Administrator group.	To register a workflow requires a System Admin or System Customizer security role and membership in the Deployment Administrator group.
Length of processing time	A plug-in registered for synchronous or asynchronous execution is restricted to complete its execution within a 2 minute time limit.	Works well for either short or long processes.
Process and data persistence	Plug-ins execute to completion. Plug-ins must be written to be stateless where no in-memory data is persisted.	Workflows can be paused, postponed, canceled, and resumed through SDK calls or by the user through the Web application. The state of the workflow is automatically saved before it is paused or postponed.
Impersonation	Plug-ins can perform data operations on behalf of another system user.	Workflows cannot use impersonation.
Transaction	Plugins can be registered in-transaction so they are able to roll-back the main operation if the plugin fails.	Workflows are executed post-transaction so they cannot roll back the main operation.
Image	You can register pre-images for plugin steps.	Pre-image is available only from custom workflow activities (not supported in CRM Online)