How to Customize the Workflow Manager
In this last blog post from the series of blog posts focused on Advanced Workflow module, I will show you how you can customize the
WorkflowManager class to provide the last missing piece in the process of
creating a custom Parallel Approval action.
Intro
In my previous blog post I showed you the steps needed to create a custom workflow action. The goal was to create an action to provide a support for
Parallel approval. You can read more details
here. When a user rejects the document, and it is sent to the custom approval step before the custom action, the list of managers stored in the document data is not cleared and the
Parallel approval action doesn't work as expected. This is where the manager customization takes action.
Customizing providers, helpers and managers
In Kentico CMS you can customize several classes using the approach mentioned in our
documentation. In version 7, you basically have two options for customizing the providers. The first is to programmatically provide the instance of a custom provider. The second is to use the extensibility section in the web.config file. For helpers and managers, only the latter can be used.
To make customization more straightforward, version 8 will bring an even better and easier way for all three customization methods, without the need of web.config file modification.
Please note: The customization of the managers is not possible in version 7 without hotfix 7.0.5 or later applied!
Custom WorkflowManager
To customize the manager class there are two basic steps to follow:
Change the web.config file
First of all I need to define the
cms.extensibility configuration section:
<?xml version="1.0"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<configSections>
<!-- Extensibility section -->
<section name="cms.extensibility" type="CMS.SettingsProvider.CMSExtensibilitySection" />
<!-- Extensibility section END -->
</configSections>
Now I can define the assembly and class for the custom manager implementation:
<!-- Extensibility section BEGIN -->
<cms.extensibility>
<managers>
<add name="WorkflowManager" assembly="App_Code" type="CustomWorkflowManager" />
</managers>
</cms.extensibility>
<!-- Extensibility section END -->
</configuration>
As you can see, I've decided to implement the custom manager using the
App_Code folder. The reason was to be able to easily include the implementation to the export package, available for download at the end of this blog post.
Implement the logic
Since I already have the custom class registered in the system, I need to provide the implementation.
Because I want to customize the
WorkflowManager class, I need to inherit from this class:
/// <summary>
/// Custom workflow manager
/// </summary>
public class CustomWorkflowManager : WorkflowManager
{
Also I need to provide the default class constructor to be able to create the instance of the custom class:
/// <summary>
/// Constructor
/// </summary>
public CustomWorkflowManager()
: base(null)
{
}
Now I need to customize the behavior of the manager, when the process is moved to previous step. This is why I need to override the
MoveToPreviousStepInternal method:
protected override WorkflowStepInfo MoveToPreviousStepInternal(TreeNode node, WorkflowStepInfo step, string comment)
{
// Get custom parallel approval action definition
var parallelAction = WorkflowActionInfoProvider.GetWorkflowActionInfo("ParallelApprovalAction", WorkflowTypeEnum.Approval);
// There is custom action for Parallel approval
if (parallelAction != null)
{
// Get previous step
var previousStep = GetPreviousStepInfo(node);
// There is custom action and the document was rejected to the action step of this custom action
if (NextStepIsCustomAction(previousStep, parallelAction))
{
// Clear managers list
ClearManagersList(node);
// Move to previous approval step
return MoveToPreviousApprovalStep(node, previousStep, comment);
}
}
// Move to previous step the standard way
return base.MoveToPreviousStepInternal(node, step, comment);
}
The code simply checks whether there is the
Parallel approval action definition. If there is, and the next step of the previous one is the
Parallel approval action step, it clears the list of managers stored in the document data and moves the document to the previous step. You can find the complete code of the implementation in the export package linked below.
Summary
That's it. By following just two basic steps, you can customize the manager class and provide your additional functionality to the system. As mentioned previously, these steps will be more straightforward in version 8, making the customization even easier.
Please find the export package
here. It contains a workflow process definition with the
Parallel approval action, the
Parallel approval action definition and the implementation itself, together with the
WorkflowManager class customization described in this blog post. Feel free to download it and customize it for your needs.
I believe you find the series on the Advanced Workflow module useful.