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.

Find & Advance Find Search

Find perform a search on an attribute for which it is defined.

Advanced Find perform search on the conditions and the attributes for which user customizes or runs it.

Normal Find in faster as it looks for one attributes and matches with that and returns the result whereas Advanced Find searches for all the attributes and conditions while parsing through the records.

Find is applicable on only active records and it finds only on 2 or 3 column which we have defined in the find view and even it returns any those column which is there in the view but advanced find is applicable to all the records and it finds all the columns and even it returns all the column and filter criteria can be on any column.

Find is faster than Advanced Find.

Append & AppendTo Privileges

What is 'Append' and 'Append To' privilege in MSCRM? Give one example of it?

Ans: 'Append' and 'Append To' privileges works together. 'Append To' privilege will allow other entities to get attached with the entity. 'Append' privilege will allow the entity to attach the records to the entity with 'Append To' privilege. 

Ex:-

Let us say that you want to attach a note to a case then note entity should have 'Append' access right and case entity should have 'Append To' access right.

Let us take one more example to understand this. Suppose you have two custom entities called 'TestCustomEntity1' and 'TestCustomEntity2'. You want to attach the 'TestCustomeEntity2' records to 'TestCustomEntity1'records. For this you need to have 'Append' access right on 'TestCustomEntity1' entity and 'Append To' access right on 'TestCustomEntity2'.

Now guess will I be able to attach the records? 

Answer is " NO" because we need to create a 1:N relationship between 'TestCustomEntity1' and 'TestCustomEntity2'. Now the user who has above mentioned access right in his security role will only be able to add 'TestCustomEntity2' records to 'TestCustomEntity1'.

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.

Solutions in CRM 2011

Dynamics CRM 2011 Solution Packages (“solutions”, for short) are packages of customization that allow you to build and maintain Dynamics CRM/xRM applications, and to move them from one organization to another. In fact, not only are they the best practice approach to moving customization from one CRM organization to another; but short of re-creating every customization from scratch they are the ONLY way to move customization. So there really is no option not to use them: unless you want to manually recreate every customization any time you provision a new organization, you must use solutions in Dynamics CRM 2011.

     A solution is originally created within the context of a Dynamics CRM organization. It’s important to distinguish between the organization a solution is originally created in, and a different organization it gets imported to. I’ll refer to the first one as the “Developer” or “Publisher” organization. Any custom functionality a solution provides (custom entities, workflows, form script, plug-ins, etc.) can be exported as part of a single unit. This unit is referred to as the solution package, and consists of a zipped up collection of XML files. When exporting a solution package from the organization it was developed in, there are two options: you can export a “Managed Solution”, or an “Unmanaged Solution”.

Managed solutions have the following features:

·        When imported to a different organization (you might refer to this as the “Consumer” organization) all of the customization are automatically published.

·        They can be uninstalled. Uninstalling a managed solution is a clean and complete uninstall: that is, all of a managed solution’s components are removed from the Target organization when the managed solution is deleted.

·        They can selectively expose components for customization in the consumer organization.    This is specified in the developer organization, where solution components can be specified as customizable or non-customizable. Customizable solution components of a managed solution are fully exposed and customizable in the consumer organization.

·        Versioning is built in to the managed solution architecture. For example, if “Solution A, version 1″ is imported, and subsequently “Solution A, version 2″ is imported, Dynamics CRM will recognize version 2 as a new version of the same solution and import/publish just the new features.

    They cannot be modified in or exported from a consumer organization.

Unmanaged solutions have the following features:

·        When imported into a consumer organization, their components must be published.

·        They cannot be uninstalled. (Any of their custom components can be deleted, but this must be done one at a time, unlike the one-click uninstall for a managed solution.)

·        They can be modified in or exported from a consumer organization, either as an unmanaged solution or a managed solution.

The last bullet-points in both sections may be confusing at first: it seems a little odd at first that you can import a managed solution you’ve created yourself and cannot modify the solution package in the target organization, but it’s true: while you can modify customizable components of a managed solution, you cannot modify the solution package itself, except for in the original (developer/publisher) organization. On the other hand, unmanaged solutions can be further modified in any way in the consumer organization, OR exported from it, either as a managed or unmanaged solution. That’s what unmanaged solutions are for.

Generally speaking, you can say the following:

·        If you’re a commercial software developer, or an enterprise developer/customizer, you will probably use managed solutions to distribute your CRM 2011 customizations: they give you clean uninstall capability, versioning with automatic upgrades, and the ability to selectively lock down components.

·        If you just want to move your customizations from one CRM 2011 organization to another, and don’t want any restrictions on what you can do with them in the target/consumer organization, that’s what unmanaged solutions are for.

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)