Archive for March, 2011
Im taking a step back in time today, back to 2009 and a problem that has arisen again for me today. Im trying to register a “Add” plugin event against a custom many-to-many relationship. Out of the box this isnt supported in CRM 4.0 (apparently it was omitted before release due to more testing needed).
There is a work around that has been out there for while from Aaron Elder I wanted to share.
Step 1) Backup up your CRM Database
Step 2) Run the following SQL script against your MSCRM database
-- ============================================================================ -- 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_MSCRM GO -- Find the deployments SDK Filter ID for the -- Associate and Disassociate Entity SDK Messages DECLARE @DisassociateEntitiesFilterId uniqueidentifier DECLARE @AssociateEntitiesFilterId uniqueidentifier SET @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 safer UPDATE SdkMessageFilterBase SET IsCustomProcessingStepAllowed = 1 WHERE SdkMessageId = @DisassociateEntitiesFilterId AND PrimaryObjectTypeCode = 0 UPDATE SdkMessageFilterBase SET IsCustomProcessingStepAllowed = 1 WHERE SdkMessageId = @AssociateEntitiesFilterId AND PrimaryObjectTypeCode = 0
Step 4) Recycle the CRMAppPool for CRM and open up your Plugin registration tool.
Step 5) Register a Step with the message “AssociateEntity” or “DisassociateEntity”. As expected the many-to-many bridge tables are not exposed in the entity list, so you just leave this blank.
Step 6) Now the obvious issue here is ALL many-to-many relationships in your CRM system will trigger off this plug-in as it cannot be entity specific. I did some digging and the easiest way to limit this to a single relationship is to check the Target input parameters. Typically you would be looking for entity name in the context – this does not exist for many-to-many. The next best thing is the relationship name which can be found here:
string relationshipName = context.InputParameters.Properties[“RelationshipName”];
Do a comparison to the name of your many-to-many relationship and proceed with your custom code if a match is found.
From what I can see, CRM 2011 also supports the AssociateEntity and DisassociateEntity messages, so while this might be unsupported, atleast Microsoft have continuity in CRM 2011. I stress the code above is unsupported, use at your own risk.
People have been asking “Where is the metadata browser in Microsoft Dynamics CRM 2011?”. For those of you who don’t know what the original metadata browser was, see Metadata Browser. The original metadata browser was removed from CRM 2011.
I’m happy to announce that the latest update to the Microsoft Dynamics 2011 Software Development Kit (SDK) includes a managed solution that replaces and I hope improves upon the original metadata browser.
To read more check out Jim Daly’s blog over at Microsoft here.