Defining and using custom code activities and types in a Workflow Manager 1.0 workflow

Updated: October 26, 2012

Workflow Manager 1.0 workflows are authored using a fully declarative model, but if a custom code based activity or custom data type is required, server administrators can add this custom type to the supported types by using the steps described in this topic. Each type can be added explicitly, which is recommended, especially for the production. Alternatively, the protection against executing arbitrary code can be disabled which has a similar effect as if all types from all assemblies on the server were allowed. This approach may simplify the development process, but has security implications, so typically it is not suitable for production.

In this topic

• Supporting Custom Code Activities

• Supporting Custom Data Types

• Removing a Custom Code Activity or Data Type

• Supporting Custom Code by Disabling the Protection against Executing Arbitrary Code

Supporting Custom Code Activities

Workflow Manager 1.0 allows users to publish and use their own declarative activities and declarative workflows. It also provides a rich set of out of the box workflow activities that can be used in users' activities and workflows. Workflow Manager 1.0 also defines a ‘Trusted Surface’, which includes the set of supported types and activities.

Extending the set of allowed types and activities has potentially a huge impact on the security, performance, scalability and availability of Workflow Manager 1.0 and should not be considered unless absolutely necessary, for example, when workflows need to perform sophisticated calculations or data transformation that would be impractical to author in an declarative activity. In this case, advanced users may want to use a custom code activity instead. The server administrator can extend the set of allowed types to include this code activity, providing that the administrator fully trust this code activity.

To extend the set of allowed types, an administrator needs to perform the following steps:

1. Copy the assembly that contains the type (for example, a custom code activity) together with all dependent files to the following two folders:

   • C:\Program Files\Workflow Manager\1.0\Workflow\WFWebRoot\bin

   • C:\Program Files\Workflow Manager\1.0\Workflow\Artifacts

2. Create a file named AllowedTypes.xml in C:\Program Files\Workflow Manager\1.0\Workflow\WFWebRoot\bin

3. Edit AllowedTypes.xml to and add the desired types within the <AllowedTypes> xml element, as shown in the following example.

   <AllowedTypes>  
     <Assembly Name="Contoso.DataTransformations">  
       <Namespace Name="Contoso.DataTransformations.Activities">  
         <Type>DoDomainSpecificCalculation1</Type>  
       </Namespace>  
     </Assembly>  
   
     <Assembly Name="Contoso.StronglyTypedAssembly, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">  
       <Namespace Name="Contoso.FinancialCalculation.Activities">  
         <Type> GetPresentValueOfABond</Type>  
       </Namespace>  
     </Assembly>  
   </AllowedTypes>  
   

4. Copy AllowedTypes.xml to the second folder: C:\Program Files\Workflow Manager\1.0\Workflow\Artifacts

5. Restart the Workflow Manager 1.0 server during the next planned maintenance window.

Now the type(s) added in the step 3 can be used in newly published activities and workflows.

Supporting Custom Data Types

Custom data types can also be added to the set of allowed types. The same set of steps should be followed as above in order to enable use of that type in workflows. However, additional activities may need to be added to the allowed types list in order to access properties of that custom data type or initialize it. Property references will not be automatically handled by the expression translator; therefore VB expressions cannot be used for this. For example, if a custom type Employee has Name and Salary properties and there is a need to access these properties from a workflow, then GetEmployeeName and GetEmployeeSalary custom code activities should be authored and added to the allowed types list.

Removing a Custom Code Activity or Data Type

To remove a previously added type from the list of allowed types, the following steps need to be performed:

1. Edit AllowedTypes.xml in two locations (C:\Program Files\Workflow Manager\1.0\Workflow\WFWebRoot\bin and C:\Program Files\Workflow Manager\1.0\Workflow\Artifacts) on each of servers and remove the reference to the type or types you wish to remove from the list of allowed types.

2. Stop WorkflowServiceBackend service on all servers

3. Stop WorkflowMgmtPool application pool on all servers – this will render the Workflow Manager 1.0 server not available, so it should be done during a maintenance window

4. Remove all custom files on all servers previously copied to C:\Program Files\Workflow Manager\1.0\Workflow\WFWebRoot\bin and C:\Program Files\Workflow Manager\1.0\Workflow\Artifacts

5. Start WorkflowMgmtPool application pool on all servers

6. Start WorkflowServiceBackend service on all servers

7. Remove all declarative activities and workflows that were using the removed type or types so they no longer reference it or publish a new version of these activities and workflows that no longer reference the removed types.

Supporting Custom Code by Disabling the Protection against Executing Arbitrary Code

Workflow Manager 1.0 allows an administrator to disable the protection against executing arbitrary code. This can be a convenient option during development of solutions that use custom code to avoid the burden of adding over time additional needed types to the list of allowed types. When the protection against executing arbitrary code is disabled it has a similar effect as if all types from all assemblies on the server were added to the allowed types list. This has corresponding security implications and should be used only when Workflow Manager 1.0 is configured such that only trusted users have permissions to upload workflow activities or modify databases used by Workflow Manager 1.0.

To disable the protection against executing arbitrary code

To disable the protection against executing arbitrary code in Workflow Manager 1.0, an administrator must perform the following steps:

1. Open the Workflow PowerShell command window.

   Note

   For instructions on opening the Workflow PowerShell command window, see Configuring Workflow Manager 1.0 using PowerShell.

2. Execute the Set-WFServiceConfiguration cmdlet with the following parameters:

   • For ServiceUri, specify the Uri of the workflow server, for example https://myserver.mydomain.mycompany.com:12290.

   • For Name, specify WorkflowServiceAllowUnsafeTypes.

   • For Value, specify true.

To re-enable the protection against executing arbitrary code

To re-enable the protection against executing arbitrary code in Workflow Manager 1.0 server, an administrator must perform the following steps:

1. Open the Workflow PowerShell command window.

   Note

   For instructions on opening the Workflow PowerShell command window, see Configuring Workflow Manager 1.0 using PowerShell.

2. Execute the Set-WFServiceConfiguration cmdlet with the following parameters:

   • For ServiceUri, specify the Uri of the workflow server, for example https://myserver.mydomain.mycompany.com:12290.

   • For Name, specify WorkflowServiceAllowUnsafeTypes.

   • For Value, specify false.