Workflows

The workflow extensions in EPiServer CMS are based on Windows Workflow Foundation 3.5 (WF). Workflows in EPiServer will change in coming versions of the platform due to the upgrade of WF by Microsoft (in .NET 4.5).

Note that from update 40 (CMS core 7.15.0), workflows based on Windows Workflow Foundation 3.5 are disabled by default. Refer to Activating workflows for information on how to enable them.

Note that from update 81 (CMS core 9.0), workflows based on Windows Workflow Foundation 3.5 are removed.

Introduction

A workflow is the method of automating actions based on events. A chain of events can be set up leading from a start to an end action with each event waiting for a trigger in the chain before being activated, all under the watchful eye of the workflow runtime. Workflows are commonly used in many different areas, for instance, in content publishing procedures and in online e-commerce business processes.

A sample installation of EPiServer CMS offers workflow capabilities, for instance, to ensure that content goes through an approval process before it is published. Workflow instances, events, and activities are easily monitored. You can also create your own workflows. Workflows in EPiServer CMS are based on Microsoft Windows Workflow Foundation, for easy integration of custom workflows.

The Windows Workflow Foundation (WF) module is built upon the workflow functionality shipped with the .NET framework. The purpose of the module is to make it possible to build and run custom workflows within the EPiServer CMS environment. There are a number of EPiServer CMS related activities to make it possible for workflow instances to interact with the EPiServer CMS environment. If you are familiar with these libraries, you already know how to build workflows in EPiServer CMS. What differs in the EPiServer CMS implementation is the added functionality to connect workflows to the EPiServer CMS framework, as well as a number of predefined activities correlating to specific EPiServer CMS events added to the Visual Studio toolbox.

Workflows shipped with EPiServer CMS

The following workflows are shipped with EPiServer CMS:

EPiServer.WorkflowFoundation.Workflows.ParallelApproval is an approval workflow for pages where approval tasks are created immediately for all specified approvers. When all (or a specified number of approvers) approve the page, the page is published and the workflow is completed. If an approver rejects the changes, a task is created for the person who saved/created the page where this person (possibly after changing the page) can send out new approval requests.
EPiServer.WorkflowFoundation.Workflows.SequentialApproval is an approval workflow for pages where approval tasks are created one by one according to the specified order of the approvers. When a person approves the page, the next approver in the list will receive an approval task. When all approvers have approved the page, it is published. If an approver rejects the changes, a task is created for the person who saved/created the page where this person (possibly after changing the page) can send out new approval requests.
EPiServer.WorkflowFoundation.Workflows.ReadyForTranslation helps editors, working with a multi-lingual website, to manage pages in different languages. When a page is added or modified in one language, this workflow will inform, by task and e-mail, selected persons or groups that the page needs translation in different languages (there can be different persons/groups assigned for each language). If the page has not been translated after a preset time, the workflow will remind the person/group once again. If the page is still not translated in all languages after another preset time, the workflow will send a final alert to a group/person responsible for translations, informing him/her/them that the page was not fully translated.
EPiServer.WorkflowFoundation.Workflows.RequestForFeedback will create tasks with request for feedback on some topic (for example, a page). When feedback is posted, the owner of the workflow (usually the person who started it) will be notified.

About workflows

An activity in a workflow can listen for a particular event to take place. When this happens, the activity is activated, performs the action it is programmed to do and (if it is not the last in the chain) triggers another activity. Each and every activity can be programmed to delay for as long as the developer wishes. An activity that waits for input (for instance, waiting for a page-related event) will become idle and unloaded from memory. When the event occurs, the workflow instance will be loaded and invoked by the event. It will then continue to execute until it either becomes idle again, or is complete.

The figure above shows a simple schema over the workflow capsulation in EPiServer CMS.

At a first glance this may sound like standard programming; after all, what is code but instructions on actions to be performed based on conditions?
The major advantage of the workflow model is reusable code units that can be connected in several different ways. The design mode of workflows supplies the developer with a more intuitive environment where actual day-to-day actions trigger what should happen instead of obscure code blocks (at least on the surface). All the workflow activities in the example above can be reused in other workflows with different purposes.

Another aspect to take into consideration is the system itself and timespan. Many of the activities you may wish to implement are based on the actions of people and are not 100% predictable and might stretch over a long period of time. What happens if the system shuts down after a customer places an order in our imagined scenario? If every event were coded in regular style, we would be in trouble. With the workflow approach this is no longer a problem. Every activity in the workflow is independent of all others and as long as the system did not break down while an activity was excecuting we are safe. Even if the system shuts down during an execution the activity would roll back its action and no harm would follow, the activity would reactivate upon system restart.

Programming solutions that target events spanning over longer periods of time usually require the developer to save data to databases or other formats during several steps of the chain of events, as well as figuring out ways to code your application so that it wakes up when a certain event is raised. The workflow solution deals with this for you by adding its own default Persistance Points.

Validating context

Even though it is recommended to write activities that are as small and general as possible to maximize their reusability, you will most likely run into scenarios where you have to design specialized activities. There may, for instance, be a workflow needed by a customer that requires activities unique to their trade. In those cases validators come in handy. A validator is a special component that you can attach to your activity. When you drop an activity onto a workflow form, the validator checks the context and verifies that it is the intended environment that the activity was designed to run in. If not, the validator alerts you to this and the activity cannot be used in the incompatible workflow.

Implementing workflows

Before you can use a workflow in EPiServer CMS it needs to be registered. After compiling your DLL, you have to place it in the bin catalog of your website (as with every addition to EPiServer CMS) for EPiServer CMS to recognize it. After restarting your website, new workflow definitions can be created of your custom type in the Admin view of EPiServer CMS and new instances can be created.

You can find the workflow history list EPiServer.WorkflowFoundation.UI.WorkflowHistoryList in the EPiServer.UI assembly.