Month: July 2016

Sample plugin to create record when other entity record was created

The below example shows how to create an Contact record whenever we had an account record getting created.

Find the code as below.

Step 1:


using System;
using Microsoft.Xrm.Sdk;// include this dll from SDK
namespace plugin_721
{
public class Class1 : IPlugin
{
public void Execute(IServiceProvider service1)
{
IPluginExecutionContext context = (IPluginExecutionContext)service1.GetService(typeof(IPluginExecutionContext));
if (context.InputParameters["Target"] is Entity)
{
Entity entity = (Entity)context.InputParameters["Target"];
entity.LogicalName = "account";
try
{
Entity createcontact = new Entity("contact");
if (context.PrimaryEntityId != null)
{
createcontact["firstname"] = "pavan";
}
IOrganizationServiceFactory servicefactory = (IOrganizationServiceFactory)service1.GetService(typeof(IOrganizationServiceFactory));
IOrganizationService service = servicefactory.CreateOrganizationService(context.UserId);
service.Create(createcontact);
}
catch (Exception ex)
{
//code you for displaying when exception was caught, not compulsory
}
}
}
}
}

view raw

Plugin.cs

hosted with ❤ by GitHub

Step 2: 

Dont forget to sign in the assembly.

Build the code in the visual studio to get the dll file.

Step 3:

Open Plugin registration tool from  crm 2016 SDK\SDK\Tools\PluginRegistration

  1. create a new connection
  2. give the organization login details select O365 if online
  3. Select your region
  4. Displays the organizations if found
  5. Click Register–>Register new Assembly–>Select your DLL
  6. Select sandbox & Database if online–> Register
  7. Goto the Assembly and create a new step for that
  8. Select the details asked, can select required pipeline execution order, stage, execution mode, deployment
  9. Enter register step
  10. Your plugin was registered
  11. Go and check, when you had created a new account, this code would create a contact pavan(You can give whatever you want).

Cheers,

PMDY

 

Restricting infinite loops in MS CRM plugins

IExecutionContext.Depth Property:

Today would like to share with all of Dynamics CRM folks about the important Depth property used to prevent plugins going into infinite loop.

This is property name which tracks the Depth property of plugins in ms crm.

Gets the current depth of execution in the call stack and available in the context which is being passed to plugin.

Syntax:

int Depth { get; }

Notes:
This property is basically used by the platform for infinite loop prevention. very time a running plug-in 
or when workflow issues a message request to the web services that triggers 
another plugin or workflow to execute, the Depth property of the execution 
context is increased. If the depth property increments to its maximum value
within the configured time limit, the platform considers this behavior an 
infinite loop and further plug-in or Workflow execution is aborted.The max-
imum depth (8) and permissible time limit (one hour) are configurable by the Microsoft 
Dynamics CRM administrator by default.

If required, this setting can be changed by a powershell command
PowerShell command -- Set-CrmSetting. 

Depth is the number of times a plugin/custom workflow has been called in 
one transaction. Depth is often used to stop infinite loops where a plugin 
updates a value which triggers the plugin to run again. When a plugin/custom 
workflow triggers another plugin/trigger then the depth property is increm-
ented by one.The depth value has a maximum value called 
WorkflowSettings.MaxDepth. 
The CRM SDK (Depth)states this is set to maximum depth of 8 within one hour
and common method to avoid a recurring plugin is to check if  a plugins 
depth > 1.
This would stop the plugins from being run if was triggered from any other
plugin. The plugin would only run if triggered from the CRM form only.


Alternate solution is to use shared variables which can pass data between plugins
registered in different stages in a transaction. Eg.You can use ShareVariables 
to pass information between plugins registered on different stages but in the 
same transaction e.g a pre plugin can pass information to a post plugin.


Details can be observed better @ use shared variables in plugins

Update: 11/26/2018

Scenario:

Think of situation where the Plugin is registered on Update of an Entity with filtering attributes set to a field in the Entity.

Due to some bad coding logic, the Plugin registered is also updating the same field.

This would call the same plugin once more causing infinite loop.

This is where using Depth becomes significant.

Thank you.

Cheers,

PMDY