Expose Associate and Disassociate SDK Messages

I had a need to run plugins off of the Associate and Disassociate of a many to many relationship and quickly found out that those triggers aren't exposed. So, I did some poking around and found from Aaron Elder an unsupported hack to enable them. You basically change a couple of zero's to one's and then the triggers are exposed in the Plugin Registration tool and off you go. Here's Aaron's original post if you want to check it out. And here's another post from a Microsoft rep talking about this very topic.

Here's the SQL query that he wrote and posted for everyone to use:


-- ============================================================================-- Enable Associate and Disassociate Plug-in Events Script v1.0-- ------------------------------------------------------------------------------ (c) 2009 Aaron Elder-- ============================================================================-- DISCLAIMER:-- This script is provided "AS IS" with no warranties, and confers no rights.-- ============================================================================-- While this is obviously "unsupported", I think the fact that these events-- are not available is a bug and hopefully it will be fixed in a rollup.-- ============================================================================USE AscentiumCrmDev_MSCRMGO-- Find the deployments SDK Filter ID for the-- Associate and Disassociate Entity SDK MessagesDECLARE @DisassociateEntitiesFilterId uniqueidentifierDECLARE @AssociateEntitiesFilterId uniqueidentifierSET @DisassociateEntitiesFilterId = (SELECT SdkMessageId FROM SdkMessageBase WHERE [Name] = 'DisassociateEntities')SET @AssociateEntitiesFilterId = (SELECT SdkMessageId FROM SdkMessageBase WHERE [Name] = 'AssociateEntities')-- Enable the Associate and Disassociate Filters to be valid for custom processing-- Custom Processing means "you register plug-ins against it"-- Note: We only do this for the "generic" (OTC == 0) case, just to be saferUPDATE SdkMessageFilterBase SET IsCustomProcessingStepAllowed = 1
WHERE SdkMessageId = @DisassociateEntitiesFilterId AND PrimaryObjectTypeCode = 0

UPDATE SdkMessageFilterBase SET IsCustomProcessingStepAllowed = 1
WHERE SdkMessageId = @AssociateEntitiesFilterId AND PrimaryObjectTypeCode = 0

What I am going to add is the method to get the ID's from within your plugin. These messages don't use any image information so don't even register images for them. Just the message, entity name and the rest you can leave default.

Here's the code to get the ID's:

stringprimaryEntityid="";
stringsecondaryEntityid="";
switch(context.MessageName)
{
case"AssociateEntities":
if(context.InputParameters.Properties.Contains("Moniker1"))
{
associatedEntity1=(Moniker)context.InputParameters.Properties["Moniker1"];
primaryEntityid=associatedEntity1.Id.ToString();
}
if(context.InputParameters.Properties.Contains("Moniker2"))
{
associatedEntity2=(Moniker)context.InputParameters.Properties["Moniker2"];
secondaryEntityid=associatedEntity2.Id.ToString();
}
if(context.InputParameters.Properties.Contains("RelationshipName"))
{
relationshipname=context.InputParameters.Properties["RelationshipName"].ToString();
}
break;
case"DisassociateEntities":

if(context.InputParameters.Properties.Contains("Moniker1"))
{
associatedEntity1=(Moniker)context.InputParameters.Properties["Moniker1"];
primaryEntityid=associatedEntity1.Id.ToString();
}
if(context.InputParameters.Properties.Contains("Moniker2"))
{
associatedEntity2=(Moniker)context.InputParameters.Properties["Moniker2"];
secondaryEntityid=associatedEntity2.Id.ToString();
}
if(context.InputParameters.Properties.Contains("RelationshipName"))
{
relationshipname=context.InputParameters.Properties["RelationshipName"].ToString();
}
break;
}



With this being unsupported you never know what is going to happen and you're not going to find any documentation. I found rather quickly that I was able to overload the Disassociate message without too much trouble. So, I ended up in changing my plugin to run asynchronously and that got it to work without error. The errors I saw were related to time out errors or the server not being available. The event logs will even show you the webpage that is being called when you run the plugin that does all of the webservice stuff.



Fiddle with it, play with it, enjoy the new freedom! And cross your fingers that these messages become supported in the next version.



David Fronk
Dynamic Methods Inc.