The CRM 4.0 SDK gives a reasonable overview of registering a custom workflow activity, covering the following steps:
- Building / Deploying a plugin registration tool
- Registering the assembly
- Adding referenced assemblies to the GAC
- Stopping and restarting the CRM Async Service
However, one important point is omitted - adding your activity classes as an authorizedType within the web.config file. Workflow in CRM 4.0 uses the Windows Workflow Foundation (WWF) which, as a relatively new .Net technology, includes a reasonable security model to reduce the risk of malicious code being deployed within it.
The security model in WWF will only allow a permitted list of classes to be called as custom activities. In CRM 4.0 this list is stored in the web.config file in the root of the CRM website, and looks like this:
<System.Workflow.ComponentModel.WorkflowCompiler>
<authorizedTypes>
<authorizedType Assembly="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.Activities" TypeName="IfElseActivity" Authorized="True"/>
<authorizedType Assembly="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.Activities" TypeName="IfElseBranchActivity" Authorized="True"/>
</authorizedTypes>
</System.Workflow.ComponentModel.WorkflowCompiler>
For your custom activity to be permitted, you have to add an entry as an
<authorizedType Assembly="MyAssembly, Version=4.0.0.0, Culture=neutral, PublicKeyToken="7766554433221100" Namespace="MyActivities" TypeName="*" Authorized="True"/>
Note that I've used an asterisk (*) to indicate all classes in the given namespace and assembly are permitted; you could reference an individual class if you prefer. Also note that the assembly is referenced by the strong name, as the assembly has been digitally signed when it was compiled.
This raises the question 'what happens if you don't do this step?' If you don't, you can deploy the workflow plugin, and use it in a workflow rule, but you get an error when you try to publish the workflow rule. Unfortunately the message you get is unhelpful; it's a variation of 'An unexpected error has occurred'. If you dig deeper, and enable tracing on the server, you do get a useful message in the w3wp log, such as the following:
Workflow compilation failed:WF363: Type MyActivities.Demo, MyAssembly, Version=4.0.0.0, Culture=neutral, PublicKeyToken="7766554433221100 is not marked as authorized in the application configuration file.
Once you find it, this message is pretty useful, as it tells you most of the problem, and also references the assembly in exactly the same way as you need to in web.config
1 comments:
Would you share experiences with subsequent updates? We seem to have lots of trouble deploying custom workflow activities that work in one environment to the next one in our development cycle. We register the workflow activities, unpublish and delete the target workflows, then try to import the workflows. Then when we try to publish, we get an obscure error that requires us to turn on tracing to find it. Gee, why won't the CRM team use the event log to report exceptions? Anyway, here it is.
Crm Exception: Message: Could not find a plugin using assembly name and type, ErrorCode: -2147200995
I confirmed the custom workflow activities registered correctly. I googled and found this article
http://ebewley.blogspot.com/2009/01/custom-crm-workflow-activitiessteps-and.html
It seems to suggest that the CRM 4.0 custom workflow activity story is weak and that we can never hope to deploy from one environment to another. But I can't find resources to understand what is going on. Do you have any perspective or experience you can share?
Post a Comment