Plug-ins are custom business logic (code) that can be integrated with Microsoft Dynamics CRM 2013 and Microsoft Dynamics CRM Online to modify or increase the standard behavior of the platform. You can also think of plug-ins as handlers for events triggered by Microsoft Dynamics CRM. You can have a plug-in subscribe to or register a known set of events to run your code when an event occurs.
First, basic usage
1. To inherit the IPlugin and implement the Excute method (1-3 rows)
2. Get execution context from service provide (5 rows)
3. We can check the name of the entity that triggered the plugin (7–11 line)
4. You can also check the triggered event, which is create, update, or delete (12–16 line)
5. The entity that gets the trigger in the input parameter (20 rows)
6. Get Iorganizationservice through service factory, when the parameter of the Createorganizationservice method is null, represents the system user when the parameter is context. UserId or Guid.Empty, represents the current user (21–23 line)
7. Finally, the Doaction method, the logic of the plug-in can be implemented here.
Public class New_marketing_plan_updatepost:iplugin
2: {
3: Public void Execute (IServiceProvider serviceprovider)
4: {
5: Ipluginexecutioncontext context = (Ipluginexecutioncontext) serviceprovider.getservice (typeof( Ipluginexecutioncontext));
7: //Check entity name
8: if (context. Primaryentityname.tolower ()! = "New_marketing_plan")
9: {
Ten: thrownew invalidpluginexecutionexception ("Entity is not Marketing Plan");
One: }
//Check that the message is correct
: if (context. Messagename.tolower ()! = "update")
: {
: thrownew invalidpluginexecutionexception ("message is notUpdate");
: }
: if (context. Inputparameters.contains ("Target") && context. inputparameters["Target"] is Entity)
: {
: Entity entity = (entity) context. inputparameters["Target"];
£ iorganizationservicefactory servicefactory = (iorganizationservicefactory) serviceprovider.getservice ( typeof(iorganizationservicefactory));
A: iorganizationservice userservice = servicefactory.createorganizationservice (context. USERID);
: Iorganizationservice Adminserivce = Servicefactory.createorganizationservice (null);
: DoAction (Adminserivce, UserService, entity);
: }
: }
: }
Second, remove the plugin
As described above, getting the current entity is used in this way:
1:entity entity = (entity) context. inputparameters["Target"];
However, for the delete event, it is not possible to obtain this, this time should be obtained by the following way:
1:entityreference er = context. inputparameters["Target"] as EntityReference;
New Entity (Er. LogicalName);
3:currententity.id = er. Id;
The first time I wrote a plugin to delete, this problem bothered me for a long time.
Debugging plug-ins with unit test
1. Download Rhino.mocks
2. Add a reference to the Unit test project
Microsoft.Crm.sdk.proxy
Microsoft.Xrm.Client
Microsoft.Xrm.Sdk
Rhino.mocks
System.Runtime.Serialization
And the project to be debugged, this is marketingmanage.
3. Initialize Unit test
Here, we use rhino.mocks to simulate IServiceProvider, Ipluginexecutioncontext, Iorganizationservicefactory, Iorganizationservice and other variables.
(1) Get CRM connection (12–14 line)
(2) using Rhino.mocks to simulate IServiceProvider, Ipluginexecutioncontext, Iorganizationservicefactory, IOrganizationService (16 –20 line)
1: Public IServiceProvider serviceprovider;
2: Public Ipluginexecutioncontext context;
3: Public iorganizationservicefactory factory;
4: Public iorganizationservice service;
5: Public String prefix = "new_";
6: Public String customentityname;
8: [TestInitialize]
9: Public void getorgservice ()
Ten: {
One: //cross-domain debugging using this URL, the same domain with HTTP://ME-CRM-01/CRM can
: String server = "url=http://crmdev:5555/crm;domain=xxx; username=crmtest02; Password=abc-123";
: var myconnection = crmconnection.parse (server);
: serviceprovider = mockrepository.generatemock<iserviceprovider> ();
: context = mockrepository.generatemock<ipluginexecutioncontext> ();
: factory = mockrepository.generatemock<iorganizationservicefactory> ();
: service = mockrepository.generatemock<iorganizationservice> ();
: New organizationservice (myconnection);
: }
4. Commissioning
Here's how to get to the Debug method:
(1) Simulation of an entity as triggering plug-in entities (4-13 rows)
(2) Directly debug the Doaction method in the plugin (15-16 lines)
1: [TestMethod]
2: Public void testapproepaymentrequest ()
3: {
4: new parametercollection ();
6: new xrmhelper (service);
7: Entity currentent = helper. Getinfobyattrvalue ("new_marketing_plan", "new_name", "20140910-000004") [0];
8: parambag.add ("Target", currentent);
Ten: context. Stub (x = x.inputparameters). Return (Parambag);
One: serviceprovider.stub (x = X.getservice (typeof(Ipluginexecutioncontext))). Return (context);
: serviceprovider.stub (x = X.getservice (typeof(iorganizationservicefactory))). Return (Factory);
: factory. Stub (x = X.createorganizationservice (null)). Return (service);
: new new_marketing_plan_updatepost ();
: MP. DoAction (service, service, currentent);
: }
Iv. Logging and tracking
Sometimes the plug-in is written, Unit test also passed, but registered plug-ins, running in the real environment, or error, such as the dynamic CRM 2013 Learning Notes (-) plug-in input entity parameter parsing encountered errors, then we need to use the tracking function.
The trace feature can provide runtime plug-in information to help diagnose the cause of plug-in failures, helping developers troubleshoot plug-in issues.
The traces described here are different from the ASP. Tracking is implemented in the Microsoft Dynamics CRM SDK by using the tracking service itracingservice . The developer adds Trace statements to the plug-in code, and then builds and deploys the plug-in. During execution, the user sees trace information only when the plug-in returns an exception to the platform at run time. For the synchronous registration plug-in, the trace information is displayed in the Microsoft Dynamics CRM Web Application dialog box. For asynchronous registration plug-ins, trace information is displayed in the details area of the system jobs form in the Web application. The number and characteristics of such information will depend on the code that the developer wrote for the plug-in.
The primary reason for implementing this type of trace is to support the quarantine (sandbox) plug-in and custom workflow activity features in Microsoft Dynamics CRM. Sandbox custom code cannot write information to the system event log or the file system. By implementing the tracking service, you provide a way for sandboxed plug-ins and custom workflow activities to output run-time information when an exception is thrown. In addition, the non-sandboxed plug-in also supports tracking capabilities.
Usage:
(1) initialization
1:itracingservice Tracingservice = (itracingservice) serviceprovider.getservice (typeof(Itracingservice));
(2) Add trace statement
1:tracingservice.trace ("inDoAction method");
In fact, we can catch a try in each method, this can quickly locate the method of error, and then through the trace statement to pinpoint.
For example:
1: catch (Exception ex)
2: {
3: thrownew invalidpluginexecutionexception ("" + ex. Message);
4: }
Here's a real case for me:
Dynamic CRM 2013 Learning Notes Series Rollup
Dynamic CRM 2013 Learning Notes (ii) Plugin basic usage and debugging