What is Difference between synchronous and asynchronous plugin execution?
Synchronous plug-ins are executed in a pre-defined order as part of the main Microsoft Dynamics CRM event processing. Asynchronous plug-ins are queued and executed independently.
What is an Event Framework?
It is a technology that enables your custom solutions to be developed and integrated into the Microsoft Dynamics CRM server.
What is Unified Event Framework?
The new event framework unifies the separate plug-in and workflow models into a single event model. The unification of event models results in improved system event processing efficiency, a common programming interface for both plug-ins and workflow extensions, and a common deployment programming interface.
Is it possible for a plug-in to execute within the database transaction?
Yes, it is possible for a plug-in to execute within the Microsoft Dynamics CRM database transaction even though the plug-in was registered in a non-transaction pipeline stage
When validation occurs for user under which a plug-in executes?
Validation (privilege checks) of the system user account under which a plug-in executes occurs after the Pre-Event stage. Use caution when registering a pre-event plug-in that modifies data in an external data store because the user has not yet been validated in Microsoft Dynamics CRM when the plug-in code executes.
What is the event execution pipeline?
When a web service method is called by a plug-in or other application it creates a message in the Microsoft Dynamics CRM platform. The message contains business entity information and core operation information. The message is passed through the event execution pipeline where it can be read or modified by the platform core operation and any registered plug-ins. The event pipeline is divided into 5 stages, of which only 2 are available to custom developed plug-ins
- Pre-Event (BeforeMainOperationOutsideTransaction)
- Pre-Event (BeforeMainOperationInsideTransaction) - For internal use only
- Platform Core Operations (MainOperation) - No custom plug-ins can be registered in this stage
- Post-Event (AfterMainOperationInsideTransaction) - For internal use only
- Post-Event (AfterMainOperationOutsideTransaction)
What are Parent and Child Pipelines?
The event execution pipeline architecture provides the capability for a pipeline to initiate the execution of one or more subordinate pipelines in order to process a request. The originating pipeline is known as the "parent" while the subordinate pipeline is called the "child". Web service method calls typically start a parent pipeline while (internal) platform calls start a child pipeline.
How to get information of Parent Pipeline from Child Pipeline?
The context that is passed to plug-ins of the child pipeline will include the parent context that was executed immediately prior to the child pipeline's invocation. This will enable you to track the parent and child pipeline executions and get more information about what is going on.
How will you get to know that Plug-in is registered as Parent or Child Pipeline?
A plug-in can be registered to be executed from a parent pipeline or a child pipeline. At run time, a plug-in receives information as to how it was invoked through the InvocationSource property of the context that is passed as a parameter to the plug-in.
How will you invoke web service method in Child Pipeline?
In a child pipeline, you must instantiate the CrmService or MetadataService manually. Do not use the IPluginExecutionContext.CreateCrmService or IPluginExecutionContext.CreateMetadataService methods.
What would be the order of execution in a parent-child pipeline execution?
As an example, assume that parent pipeline A invokes child pipeline B during pipeline A's core platform operation. The order of execution will be as follows:
- Pipeline A : all pre-events are processed.
- Pipeline A : core platform operation, child pipeline B executed.
- Pipeline B : all pre-events are processed.
- Pipeline B : core platform operation.
- Pipeline B : all post-events are processed.
- Pipeline A : all post-events are processed.
How to avoid the ‘Denial of Service’ or Deadlocks in a Plug-in?
Infinite loop detection is automatically enabled in plug-ins that call the CreateCrmService method of IPluginExecutionContext to create a proxy to the Web service. For plug-ins that create a Web service proxy by instantiating CrmService, infinite loop detection can be enabled by setting the Web service instance's CorrelationTokenValue property. Plug-in code can obtain the Correlationid, CorrelationUpdatedTime, and Depth property values required by the CorrelationTokenValue instance from the execution context
How would you handle exceptions in Plug-ins?
To handle an error condition, your plug-in can throw InvalidPluginExecutionException exception to show a custom exception message to the user. When the platform receives this exception, it displays the exception message (System.Exception.Message) to the user.
On which message you would require to register the plug-in when an entity state is changed?
SetState and SetStateDynamicEntity messages
On which message you would require to register the plug-in when an entity data is populated in Grid?
Execute and RetrieveMultiple messages
What are the pre-requisite to deploy a plug-in assembly?
- It should be written in any .net 2.0 (or above) CLR compliant language
- Plug-in assembly must be signed, either by the Signing tab of the project's properties sheet in Microsoft Visual Studio 2005 or the Strong Name tool (sn.exe).
- You must add references to the Microsoft.Crm.Sdk and Microsoft.Crm.SdkTypeProxy assemblies that are provided in the SDK\Bin folder of the Microsoft Dynamics CRM SDK samples.
- You also have to add a reference for System.Web.Services
- Plug-ins must implement the Microsoft.Crm.Sdk.IPlugin interface.
How to pass data between plug-ins?
The message pipeline model provides a PropertyBag collection of System.Object named “SharedVariables” in the execution context that is passed through the pipeline and shared among registered plug-ins. At run time, plug-ins can add, read, or modify properties in the SharedVariables property bag. This provides a method of information communication among plug-ins. This feature is especially useful in chain processing or to communicate information between a plug-in registered for a pre-event and a plug-in registered for a post-event.
Note Only types that are XML serializable should be placed in SharedVariables. All types derived from BusinessEntity are XML serializable.
The following code example shows how to use SharedVariables to pass data from a pre-event registered plug-in to a post-event registered plug-in.
No comments:
Post a Comment