serving the solutions day and night


Saturday, March 16, 2013

Dynamics CRM Plugin Registration Tool

Download and Export
  1. Download and install latest Dynamics CRM SDK  from Microsoft.
  2. Export "pluginprofiler.solution" package (get it from sdk\bin) to your CRM solution.
Connect to the Microsoft Dynamics CRM Server
  1. Run the PluginRegistration.exe tool from sdl\bin folder of the SDK download.
  2. To run the Plug-in Registration tool, you must first install the Windows Identity Foundation
  3. Click Create New Connection.
  4. Click connect to the Microsoft Dynamics CRM Server, you should see a list of available organizations that you belong to in the Connections pane.
Register a Plug-in Assembly
  1. Select an organization in the Connections pane.
    From the Register menu, and then click Register New Assembly.
  2. In the Register New Plugin dialog box, click the ellipses […] button to select the complied plugin dll.
  3. Click Register Selected Plugins. Click OK to close the dialog boxes.
Register the Plug-in for an Event
  1. Select (installed Assembly) plugin in the tree view, move to the Register menu, and then click Register New Step.
    Complete the Register New Step dialog box as shown in the following figure.
  2. If you want to register the plug-in to execute immediately (for testing purposes), select Synchronous.
  3. Click Register New Step.
  4. Expand the (installed Assembly) plugin node to see the plug-in and step nodes you created If you registered the plug-in to run asynchronously, and did not select the Delete AsyncOperation if StatusCode = Successful option on the Register New Step form, there will be a new system job named “FollowupPlugin: Create of account”. To view the related system job, click Settings, and then click System Jobs. Double-click the system job previously mentioned.
Register New Image
  1. Select (installed Assembly) plugin in the tree view, move to the Register menu, and then click Register New Image.
  2. Complete the Register New Image (Pre or Post) dialog box as shown in the following figure.
  3. Final Tree View in the Plug-in Registration Tool should now look like this:
Plugin Pipeline Event
PreEvent - Stage 10: Pre-validation
PreEvent - Stage 20: Pre-operation
Platform Core Operation - Stage 30: MainOperation
PostEvent - Stage 40: Post-operation

The following table shows how the equivalent values used in the Plugin Registration tool:

RegisterFile.crmregister valuesPlugin Registration Tool values

Install Profiler
  1. From the plugin registration tool, click the Install Profiler. (if "pluginprofiler.solution" package is not exported in your solution, you can't install it).
  2. Once it finished, make sure Plugin Profiler exists.
  3. Select the plugin step needed to debug, click Profiler to enable profiling. Or Rigth click on step and click on "Start Profiling".
  4. Navigate to CRM system, perform the account creation which will trigger the plugin to be execute. Download the error log file (ErrorDetails.log) and save in desktop.
  5. Run the visual studio solution, attach debug process named "PluginRegistration". Set a break point in the code.
  6. Open the plugin registration tool, click the Debug button.
  7. Browse the profile location with the erro log we downloaded in item 4. Choose the assembly location and click start plugin execution.
  8. System will auto step into visual studio breakpoint line.

Difference between Secure and Unsecure Configuration
Secure ConfigurationUnSecure Configuration
The Secure Configuration information could be read only by CRM Administrators.(Eg: Restricted data from normal user could be supplied here)

Let's assume that your solution is unmanaged and it contain a plugin, later the solution was exported as managed Solution to another environment. In this scenario, the secure configuration information would nOT be available in the new environment. The simple reason behind this is to provide more security to the contents of secure Configuration.
Unsecure configuration information could be read by any user in CRM. Remember its public information (Eg: Parameter strings to be used in plugin could be supplied here)

Let's assume that your solution is unmanaged and it contain a plugin, later the solution was exported as managed Solution to another environment. In this scenario, the unsecure configuration values would be available in the new environment.

Plug-in Isolation, Trusts, and Statistics
  1. The execution of plug-ins and custom workflow activities in an isolated environment. 
  2. In this isolated environment, also known as a sandbox, a plug-in or custom activity can make use of the full power of the Microsoft Dynamics CRM SDK to access the organization web service. 
  3. Access to the file system, system event log, certain network protocols, registry, and more is prevented in the sandbox. 
  4. Sandbox plug-ins and custom activities do have access to external endpoints like the Windows Azure cloud.
Registering the plug-ins in the sandbox, known as partial trust, or outside the sandbox, known as full trust.

Run-time Statistics
  1. Microsoft Dynamics CRM collects run-time statistics and monitors plug-ins and custom workflow activities that execute in the sandbox. 
  2. This information is stored in the database using PluginTypeStatistic entity records. These records are populated within 30 minutes to one hour after the sandboxed custom code executes. 

Web Access
  1. Sandboxed plug-ins and custom workflow activities can access the network through the HTTP and HTTPS protocols. 
  2. These default web access restrictions are defined in a registry key on the server that is running the Microsoft.Crm.Sandbox.HostService.exe process. 
  3. The registry key path on the server is:

    The key value is a regular expression string that defines the web access restrictions. The default key value is:


    By changing this registry key value, you can change the web access for sandboxed plug-ins.

    The sandbox processing service role defaults to outbound calls being enabled. If you do not want to permit outbound calls by setting the following registry key to 1 (DWORD) on the server that hosts the sandbox processing service role. Next, restart the Microsoft Dynamics CRM Sandbox Processing Service.


Sync vs Async plugin
Synchronous processing execute immediately  - Asynchronous processing are queued.
Synchronous plugin the platform core operation need to wait for the completion of plugin execution.
so you can get better performance by registering a plugin to execute asynchronously.

A scenario where the plugin is used to transfer the contact information from the CRM system to a contact mailing system.

Sync plugin  - The voter will be copied to Mailing system as soon as it is created in CRM. If it fails in Mailing system, you'll get the error then and there. But the CRM system will wait till contact gets created in Mailing system, thus making each transaction slow. This delay may be noticeable to the CRM user depending upon the amount of delay.

Async Plugin  - After the contact is created in CRM, it will be queued and send to Mailing system. It may take more time for this contact to get created in Mailing depending on queue status, other resource availability, etc. But here the CRM system will not wait and move on with the processing. The user creating the contact will not get any delay in saving the contact record.


No comments: