-
Classes and Intefaces
Kipon.Xrm - Kipon.Xrm.Actions
-
Kipon.Xrm.Attributes
- Kipon.Xrm.Attributes.AdminAttribute
- Kipon.Xrm.Attributes.ExportAttribute
- Kipon.Xrm.Attributes.IfAttribute
- Kipon.Xrm.Attributes.ImportingConstructorAttribute
- Kipon.Xrm.Attributes.MergedimageAttribute
- Kipon.Xrm.Attributes.OutputAttribute
- Kipon.Xrm.Attributes.PostimageAttribute
- Kipon.Xrm.Attributes.PreimageAttribute
- Kipon.Xrm.Attributes.RelationshipAttribute
- Kipon.Xrm.Attributes.SortAttribute
- Kipon.Xrm.Attributes.StepAttribute
- Kipon.Xrm.Attributes.TargetAttribute
- Kipon.Xrm.Attributes.TargetFilterAttribute
- Kipon.Xrm.Exceptions
- Kipon.Xrm.Extensions
Classes and interfaces
In this section, each class and interface of the concept will be explained in details.
Kipon.Xrm.IMethodCondition
Interface to be implemented by any class type used in a [If()] attribute on plugin step methods
The [If] attribute in the Kipon.Solid.Plugin framework is a powerfull and simple way to set preconditions on steps. The conditions defined are evaluated before the step is executed, and before any other services etc. is created. If you need to do very simple filtering on your step execution, you can decorate you plugin step method with the If flag and provide an implementation of the IMethodCondition interface. That way you can prevent the plugin method to be executed - unless it is relevant according to you preconditions. This ca improve the performance of your plugin, and simplify the code writting within the plugin code.
Lets take an example. Every time the revenue on an account is set to a value above 1.000.000,- we wish to do something, ex. send en email to the manager or similar
Lets define the pre-condition to listen for on the account record
namespace Kipon.PluginExample.Entities
{
public partial class Account : Account.IRevenueChanged
{
public interface IRevenueChanged : IAccountTarget
{
Microsoft.Xrm.Sdk.Money Revenue { get; }
}
}
}
Above interface is basically defining a target that is relevant whenever the revenue on the account is changed.
By using the above interface in the our plugin step methods, we are actually already filtering the method implicitly, because the method will only be called if the Revenue is changed. This condition is draining all the way down to the Dynamics 365 CE platform by setting the filter value on the plugin registration of the step when using the Kipon Solid deployment tool.
using Kipon.Xrm.Attributes;
using Microsoft.Xrm.Sdk;
using Kipon.Xrm.Extensions.Sdk;
namespace Kipon.PluginExample.Filters.Accounts
{
public class NewRevenueLargerThanOneMill : Kipon.Xrm.IMethodCondition
{
public bool Execute(IfAttribute ifAttr, IPluginExecutionContext ctx)
{
var revenue = ((Microsoft.Xrm.Sdk.Entity)ctx.InputParameters["Target"])
.Attributes.ValueOf<Microsoft.Xrm.Sdk.Money>(nameof(Entities.Account.Revenue));
if (revenue != null && revenue.Value > 1000000)
{
return true;
}
return false;
}
}
}
The NewRevenueLargerThanOneMill class is implementating Kipon.Xrm.IMethodCondition. As you can see, this interface has a single method "Execute" that is giving the Attribute definition and the CRM Execution context as input parameters.
Be aware that the platform will create a single instance of this class and use it for each call. As such, it has the same behavior as a plugin class. This means you should not create any local properties or fields, and you should ensure that things you do within the Execute method are "thread safe", because multi plugin might call the method at the same time.
The example above is simply extracting the Revenue field from the Target, and if the values is not null, and above 1.000.000,- it returns true, otherwise false
As you can see you must work on the low level of the Dynamics 365 CE interface, extracting things from the context your self. This is by design, and to allow early filtering while having the Kipon Solid platform doing as little work as possible.
Finally - lets use the implementation in our plugin
namespace Kipon.PluginExample.Plugins.Account
{
public class RevenueChangedPlugin : Kipon.Xrm.BasePlugin
{
[Kipon.Xrm.Attributes.If(typeof(Filters.Accounts.NewRevenueLargerThanOneMill))]
public void OnPostCreate(Entities.Account.IRevenueChanged target)
{
// code to send an email to the director about the good news
}
[Kipon.Xrm.Attributes.If(typeof(Filters.Accounts.NewRevenueLargerThanOneMill))]
public void OnPostUpdate(Entities.Account.IRevenueChanged target)
{
// code to send an email to the director about the good news
}
}
}
We have created a plugin, defining two steps "OnPostCreate" and "OnPostUpdate". They both takes Entities.Account.IRevenueChanged as input, meaning they will only be called if the Revenue was changed. This filtering is draining all the way down to the Dynamics 365 CE plugin registration. On top of that, we added the [If] attribute to both steps, defining that our method should only be called if the revenue is above 1.000.000,-. We can now impl. what should happen in such case.
© Kipon ApS 2020, 2021, 2022, 2023, 2024. All content on the page is the property of Kipon ApS. Any republish or copy of this content is a violation. The content of this
site is NOT open source, and cannot be copied, republished or used in any context without explcit permission from the owner.