CallerOrigin has been removed in CRM 2011 Beta.
According to Experts, since the CRM 4 implementation was neither extensible nor reliable\secure. The recommendation is to not rely on caller origin when you extend business logic in the server (since it is easy for a client to spoof this data)
If you absolutely need it and can guarantee \ do not care about spoofing, create a custom field and pass additional origin info from the client.
Please note that we have a new property isOfflinePlayback in PluginContext to identify if a plugin was triggered as part of the Offline Playback.
Please have a look at the IExecutionContext. It has below properties:1. IsExecutingOffline
2. IsOfflinePlayback
For more information you can see in the CRM 2011 Beta Sdk. Topic = "IExecutionContext Members "
Hope it helps.
Showing posts with label Plugins. Show all posts
Showing posts with label Plugins. Show all posts
Wednesday, October 20, 2010
Monday, June 7, 2010
Passing / Sharing Data Between Plug-ins
The message pipeline model provides for a PropertyBag of custom data values in the execution context that is passed through the pipeline and shared among registered plug-ins. This collection of data can be used by different plug-ins to communicate information between plug-ins and enable chain processing where data processed by one plug-in can be processed by the next plug-in in the sequence and so on. This feature is especially useful in pricing engine scenarios where multiple pricing plug-ins pass data between one another to calculate the total price for a sales order or invoice. Another potential use for this feature is to communicate information between a plug-in registered for a pre-event and a plug-in registered for a post-event.
The name of the parameter that is used for passing information between plug-ins is SharedVariables. This is a collection of System.Object. A common type of object that is used to fill the collection is DynamicEntity. 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.
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.
Example
[C#]
using System;
using Microsoft.Crm.Sdk;
using Microsoft.Crm.SdkTypeProxy;
public class AccountSetStatePreHandler : IPlugin
{
public void Execute(IPluginExecutionContext context)
{
// Create or retrieve some data that will be needed by the post event
// handler. You could run a query, create an entity, or perform a calculation.
//In this sample, the data to be passed to the post plug-in is
// represented by a GUID.
Guid contact = new Guid("{74882D5C-381A-4863-A5B9-B8604615C2D0}");
// Pass the data to the post event handler in an execution context shared
// variable named PrimaryContact.
context.SharedVariables.Properties.Add(
new PropertyBagEntry("PrimaryContact", (Object)contact.ToString()));
// Alternate code: context.SharedVariables["PrimaryContact"] = contact.ToString();
}
}
The name of the parameter that is used for passing information between plug-ins is SharedVariables. This is a collection of System.Object. A common type of object that is used to fill the collection is DynamicEntity. 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.
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.
Example
[C#]
using System;
using Microsoft.Crm.Sdk;
using Microsoft.Crm.SdkTypeProxy;
public class AccountSetStatePreHandler : IPlugin
{
public void Execute(IPluginExecutionContext context)
{
// Create or retrieve some data that will be needed by the post event
// handler. You could run a query, create an entity, or perform a calculation.
//In this sample, the data to be passed to the post plug-in is
// represented by a GUID.
Guid contact = new Guid("{74882D5C-381A-4863-A5B9-B8604615C2D0}");
// Pass the data to the post event handler in an execution context shared
// variable named PrimaryContact.
context.SharedVariables.Properties.Add(
new PropertyBagEntry("PrimaryContact", (Object)contact.ToString()));
// Alternate code: context.SharedVariables["PrimaryContact"] = contact.ToString();
}
}
Writing the Plug-in Constructor
The Microsoft Dynamics CRM platform has special support for a plug-in constructor that accepts two string parameters. If you write a constructor for your plug-in that accepts two string parameters, you can pass any two strings of information to the plug-in at run time. The following code shows these two parameters.
Example
[C#]
using System;
using Microsoft.Crm.Sdk;
using Microsoft.Crm.SdkTypeProxy;
namespace CustomPlugin
{
public class ContactCreate: IPlugin
{
public ContactCreate(string unsecure, string secure)
{
// Do something with the parameter strings.
}
public void Execute(IPluginExecutionContext context)
{
// Do something here.
}
}
}
The first string parameter of the constructor contains public (unsecure) information. The second string parameter contains non-public (secure) information. However, the secure string is not passed to a plug-in that executes while offline.
The information that is passed to the plug-in constructor in these two strings is specified when the plug-in is registered with Microsoft Dynamics CRM. When you use the PluginRegistration tool to register a plug-in, you can enter the secure and unsecure information in the Secure Configuration and Unsecure Configuration fields provided in the Register New Step form. The PluginDeveloper tool only supports the unsecure string through its CustomConfiguration attribute of the Step tag in the register.xml input file.
Example
[C#]
using System;
using Microsoft.Crm.Sdk;
using Microsoft.Crm.SdkTypeProxy;
namespace CustomPlugin
{
public class ContactCreate: IPlugin
{
public ContactCreate(string unsecure, string secure)
{
// Do something with the parameter strings.
}
public void Execute(IPluginExecutionContext context)
{
// Do something here.
}
}
}
The first string parameter of the constructor contains public (unsecure) information. The second string parameter contains non-public (secure) information. However, the secure string is not passed to a plug-in that executes while offline.
The information that is passed to the plug-in constructor in these two strings is specified when the plug-in is registered with Microsoft Dynamics CRM. When you use the PluginRegistration tool to register a plug-in, you can enter the secure and unsecure information in the Secure Configuration and Unsecure Configuration fields provided in the Register New Step form. The PluginDeveloper tool only supports the unsecure string through its CustomConfiguration attribute of the Step tag in the register.xml input file.
Sunday, February 3, 2008
MS CRM 4.0 Plugins not working
If you are working with the default Plugin sample which is shipped with MS CRM 4.0 SDK, unforunately if it doesn't work then simple regenerate the Strong Name Key (snk).
Steps:
1. Open the Sample Plugin Solution.
2. Right Click on the Solution -> Properties.
3. Click on "Signing" Tab (look at Left Navigation Bar).
4. Select "New" from "Strong name key file dropdown"
Enter "SamplePluginKey" in Name text box
uncheck "Protect my key file with a password"
Click on "OK"
Click on "Yes" which it asks for replacing the existing strong name key file.
5. Save All Files.
6. Compile the Solution.
Here you are all set to go :)
Isn't it simple ?
Comments are most welcome !!!!!!!!
Posted by
Dynamics 365 Solution Architect | Azure / ALM/DevOps | Power Platform
at
5:14 AM
1 comment:
Labels:
Plugins
Subscribe to:
Posts (Atom)