An introduction to Workflows in EPiServer CMS
- Workflows in everyday business
- Workflows in EPiServer
- Workflows from a developers point of view
- Validating Context
- Microsoft .NET Framework 3.5 Redistributable Package
- Windows SDK for Windows Server 2008 and .NET Framework 3.5
- Microsoft Visual Studio 2008
Workflows in everyday business
Consider the following scenario: You run an internet web shop selling laptops. A customer visits your site, finds a computer she likes and places an order. Later the same day the customer receives an e-mail letting her know the purchase has gone as expected and that the order is being processed. A day or two after that the slip from the postal service arrives in her mail letting her know the laptop has arrived at her local post office.
This is one of a myriad of possible scenarios where a Workflow would be very useful.
The scenario contains a number of different events and activities:
- The customer places an order and fills out her credit card number.
- Your web system checks that the credit card is valid and sends a request to the bank for the money.
- After a while a confirmation arrives from the bank telling the system that there are sufficient funds in the account.
- The system sends a notification to storage with the customers address along with information on what the customer ordered.
- The storage personnel package the order and send it off with the delivery service. They also log into the system and confirm that the order has been sent.
- The system sends an email with the confirmation to the customer.
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 whatchful eye of the Workflow runtime.
In the scenario pictured above, the chain of events would be initially triggered by the customer placing an order. An activity (e.g. check credit card and account balance) would lie waiting for the order event to be triggered. Depending on the result of this check the chain could either go on to the next step, or in case of a failed check start another Workflow with the final purpose of letting the customer know the purchase was denied by the bank.
All in all, one of the purposes of Workflows is to imitate real life events as opposed to code events.
Workflows in EPiServer
The Windows Workflow Foundation (WF) module is built upon the workflow functionality shipped with the .NET 3.0 framework. The purpose of the module is to make it possible to build and run custom workflows within the EPiServer environment. There are a number of EPiServer related activities to make it possible for workflow instances to interact with the EPiServer environment.
If you are familiar with these libraries, you already know how to build Workflows in EPiServer. What differs in EPiServers implementation is basically the added functionality to connect Workflows to the EPiServer framework as well as a number of predefined activities correlating to specific EPiServer events added to the Visual Studio toolbox.
Earlier versions of EPiServer implemented a Workflow, i.e. the publishing sequence where you could add specific conditions for pages that had to be met before they were processed in the next step in the chain of events. The major difference in EPiServer CMS compared to these older versions is the ability to create your own Workflows.
In addition to the possibility of creating your own Workflows, EPiServer will be shipped with a number of complete workflows to be used either on live web sites or as reference material for building your own implementations.
The module supports both precompiled workflows and XAML based workflows. Before instances can be created of a workflow type, the workflow definition has to be registered.
Workflows Shipped with EPiServer
There are four workflows shipped with EPiServer:
This Workflow is an approval Workflow for pages where approval tasks are created immediately for all specified approvers. When all (or a specified number of approvers) approves the page the page is published and the workflow is completed. If an approver don't approve the page, 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.
This Workflow 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 don't approve the page 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.
This Workflow helps editors, working with a multi-lingual web site, to manage pages in different languages. When a page is added or modified in one language, the Workflow will inform, by task and email, 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.
This Workflow will create tasks with request for feedback on some topic (e.g. a page). When feedback is posted, the owner of the Workflow (usually the person who started it) will be notified.
Workflows from a developers point of view
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 its 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.
Simple schema over the Workflow capsulation in EPiServer.
At an early 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 activities in the Workflow from 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 didnīt break down while an activity was excecuting we are safe.
Actually; even if the system shuts down during an execution the activity would roll back it's 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 requires 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.
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 it is not, the validator alerts you to this and the activity cannot be used in the incompatible Workflow.
Before you can use a Workflow in EPiServer it needs to be registered. After compiling your dll you have to place it in the bin catalogue of your site (as with every addition to EPiServer) for EPiServer to recognize it. After restarting your web site new Workflow definitions can be created of your custom type in the admin part of EPiServer and new instances can be created.