fluentworkflow Wiki Rss Feed

Updated Wiki: Home

sdhebert — Tue, 01 Feb 2011 04:30:54 GMT

Project Description
Fluent workflow is a lightweight DSL used to describe a workflow and it's discrete action components to an IoC container for light, fast injectable state engine wire up in your application.

Documentation

Introduction
- What is a Workflow?
- Design Goals
- Building FluentWorkflow (*new)
- Roadmap to v1.0
Creating State Tasks
Configuring the Workflow
Using the FluentWorkflow StateEngine
- Enumerating valid triggers
- Firing a trigger at the FluentWorkflow StateEngine

Updated Wiki: Home

sdhebert — Tue, 01 Feb 2011 04:30:31 GMT

Documentation

Introduction
Creating State Tasks
Configuring the Workflow
Using the FluentWorkflow StateEngine
- Enumerating valid triggers
- Firing a trigger at the FluentWorkflow StateEngine

Updated Wiki: Building FluentWorkflow

sdhebert — Tue, 01 Feb 2011 04:29:16 GMT

FluentWorkflow is sourcecode can be downloaded from CodePlex using Mercurial. You can browse the source code online where there are instructions on how to install and use mercurial to pull the sourcecode locally to your machine.

FluentWorkflow uses a build system called ‘Rake’. This means you need to have Ruby installed on your machine along with Ruby Gems. You can use the Ruby Installer at the Ruby language site to get up and running. Once you have installed Ruby, drop to the command line and type:

gem install -- remote rake

This will install rake on your system and you are ready to build.

After you clone the FluentWorkflow repository to your local machine, you can perform a build by simply typing ‘rake’ at the command line when you are in the FluentWorkflow directory or any of its children. There are three variants of the command line:

rake

Running this command will run the build and run all unit tests. The build is successful if both complete successfully.

rake deploy

This command stamps the revision number to 0 and builds all associated DLLs with that number. This builds the project, runs the unit tests and kicks off a task to create the nuget package.

rake deploy revision=[number]

This command stamps the revision number with the provided revision value and builds all associated DLLs with that number. This builds the project, runs the unit tests and kicks off a task to create the nuget package. The nuget package is also properly configured with the same revision number.

Updated Wiki: Creating Exit State Tasks

sdhebert — Tue, 04 Jan 2011 07:56:45 GMT

In order to create an Exit State Task, we create a public class that derives from the interface IExitStateTask<TState, TTrigger, TTriggerContext>. Note that the workflow does not have to specified here.

There is a lone interface that needs to be implemented called ‘Execute’:

   1:  public interface IMutatingEntryStateTask<TState, TTrigger, TTriggerContext> : IStateTask<TState, TTrigger, TTriggerContext>

   2:  {

   3:      /// <summary>

   4:      /// Executes the specified entry state step info.

   5:      /// </summary>

   6:      /// <param name="entryStateTaskInfo">The entry state step info.</param>

   7:      /// <param name="flowMutator">The flow mutator.</param>

   8:      void Execute(EntryStateTaskInfo<TState, TTrigger, TTriggerContext> entryStateTaskInfo,

   9:                      IFlowMutator<TTrigger, TTriggerContext> flowMutator);

  10:  }

DI/IOC Note

Remember that you can constructor inject any services provided by the IoC container.

Updated Wiki: Creating Exit State Tasks

sdhebert — Tue, 04 Jan 2011 07:55:17 GMT

There is alone interface that needs to be implemented called:

   1:  public interface IMutatingEntryStateTask<TState, TTrigger, TTriggerContext> : IStateTask<TState, TTrigger, TTriggerContext>

   2:  {

   3:      /// <summary>

   4:      /// Executes the specified entry state step info.

   5:      /// </summary>

   6:      /// <param name="entryStateTaskInfo">The entry state step info.</param>

   7:      /// <param name="flowMutator">The flow mutator.</param>

   8:      void Execute(EntryStateTaskInfo<TState, TTrigger, TTriggerContext> entryStateTaskInfo,

   9:                      IFlowMutator<TTrigger, TTriggerContext> flowMutator);

  10:  }

DI/IOC Note

Remember that you can constructor inject any services provided by the IoC container.

Updated Wiki: Creating Exit State Tasks

sdhebert — Tue, 04 Jan 2011 07:53:14 GMT

There is alone interface that needs to be implemented called:

   1:  public interface IMutatingEntryStateTask<TState, TTrigger, TTriggerContext> : IStateTask<TState, TTrigger, TTriggerContext>

   2:  {

   3:      /// <summary>

   4:      /// Executes the specified entry state step info.

   5:      /// </summary>

   6:      /// <param name="entryStateTaskInfo">The entry state step info.</param>

   7:      /// <param name="flowMutator">The flow mutator.</param>

   8:      void Execute(EntryStateTaskInfo<TState, TTrigger, TTriggerContext> entryStateTaskInfo,

   9:                      IFlowMutator<TTrigger, TTriggerContext> flowMutator);

  10:  }

DI/IOC Note

Remember that you can constructor inject any services provided by the IoC container. For example, if you need to inject an email service that you’ve implemented behind an ICommentMessaging interface for example, your constructor would like like this:

Notice how the ICommentMessaging is foreign to FluentWorkflow – it’s a good example of an implementation you draw up in your system and register it with the container. From a testing perspective, you will notice that this is very easy to test – almost trivial. There is virtually no limit to the number of things you can do inside an ‘Execute’ method.

Updated Wiki: Creating Exit State Tasks

sdhebert — Tue, 04 Jan 2011 07:51:45 GMT

There is alone interface that needs to be implemented called:

   1:  public interface IMutatingEntryStateTask<TState, TTrigger, TTriggerContext> : IStateTask<TState, TTrigger, TTriggerContext>

   2:  {

   3:      /// <summary>

   4:      /// Executes the specified entry state step info.

   5:      /// </summary>

   6:      /// <param name="entryStateTaskInfo">The entry state step info.</param>

   7:      /// <param name="flowMutator">The flow mutator.</param>

   8:      void Execute(EntryStateTaskInfo<TState, TTrigger, TTriggerContext> entryStateTaskInfo,

   9:                      IFlowMutator<TTrigger, TTriggerContext> flowMutator);

  10:  }

When implementing this method, the exitStateTaskInfo parameter provides us with runtime context. This includes the runtime instance of TTriggerContext and state transition information.

It is within the Execute method that we can perform the details of the task at hand. There is no return value necessary, just be certain to handle exceptions appropriately and avoid throwing them back to FluentWorkflow.

DI/IOC Note

Updated Wiki: Creating Exit State Tasks

sdhebert — Tue, 04 Jan 2011 07:49:51 GMT

There is alone interface that needs to be implemented called:

When implementing this method, the exitStateTaskInfo parameter provides us with runtime context. This includes the runtime instance of TTriggerContext and state transition information.

DI/IOC Note

Updated Wiki: Creating Mutatable Entry Tasks

sdhebert — Tue, 04 Jan 2011 07:43:06 GMT

Purpose: An entry task that has the ability to declare that a trigger should be set on the workflow allowing for an automatic redirection of state. Subsequent Entry tasks will not be run on the current state when a trigger is set.

A mutating entry state task is functionality identical to a regular entry task with the exception that a “flow mutator” is handed to the execute method. The mutator allows the task to set a trigger that will initiate a new state change according to the rules of that trigger on the current state. Those rules are defined by the workflow configuration.

   1:  public interface IMutatingEntryStateTask<TState, TTrigger, TTriggerContext> : IStateTask<TState, TTrigger, TTriggerContext>

   2:  {

   3:      /// <summary>

   4:      /// Executes the specified entry state step info.

   5:      /// </summary>

   6:      /// <param name="entryStateTaskInfo">The entry state step info.</param>

   7:      /// <param name="flowMutator">The flow mutator.</param>

   8:      void Execute(EntryStateTaskInfo<TState, TTrigger, TTriggerContext> entryStateTaskInfo,

   9:                  IFlowMutator<TTrigger, TTriggerContext> flowMutator);

  10:  }

Changing the workflow is typically a task that involves interrogating the entryStateTaskInfo (and likely the Context property) to determine if the flowMutator should be set.

   1:  public class AutoApproveProcessor : IMutatingEntryStateTask<WorkflowState, StateTrigger, IDocumentContext>

   2:  {

   3:      public void Execute(EntryStateTaskInfo<WorkflowState, StateTrigger, IDocumentContext> entryStateTaskInfo, IFlowMutator<StateTrigger, IDocumentContext> flowMutator)

   4:      {

   5:          if(entryStateTaskInfo.Context.UserName == "foo")

   6:              flowMutator.SetTrigger(StateTrigger.Approve);

   7:      }

   8:  }

When control returns to FluentWorkflow, any subsequent entry steps dependent on the AutoApproveProcessor will not be run and the trigger will be applied to the state machine. This will initiate the state exit steps on the current step and raise the entry states on the next state.

Updated Wiki: Design Goals

sdhebert — Tue, 04 Jan 2011 06:46:37 GMT

FluentWorkflow is built with SOLID principles in mind from the ground up. This focus has lent itself to the ability to create state tasks that are very focused and, through dependency injection, extremely powerful.

FluentWorkflow is built on top of three key/core components:

The System.Composition namespace – this is for core metadata association offered in the .net 4.0 framework.
stateless – this is a state engine based on .net 3.5+ created Nicholas Blumhardt
Autofac – this is an Inversion of Control container build on .Net3.5+ capabilities

FluentWorkflow uses the DSL to generate a symbol table which is

Evaluated as a transitive closure to make sure state transitions are complete.
Execution ordering is accomplished using a constraint resolving algorithm. The algorithm is written entirely in Linq.
Errors in configuration including cyclical references, incomplete closure and others are raised through exceptions that point you directly to the state step configuration in question.

Due to the use of Func<..> injection combined with .net4 metadata and the AutofacContrib.Attributed project, the first release of FluentWorkflow is built to work with Autofac 2.4 or greater.

The dependency on Autofac can be moved when:

Other containers support the types of creation/relation patterns that autofac supports (see The Relationship Zoo)
Other containers support System.Composition based metadata storage or another metadata storage mechanism takes its place.

Updated Wiki: Roadmap to v1.0

sdhebert — Tue, 04 Jan 2011 06:13:19 GMT

The following steps need to happen to move from Beta to version 1.0.

Feedback – lets see how this works for others.
Build script completion – building out a build script for the core (fluentworkflow.core and .testhelpers) with version increment and copy of DLLs to the build directory.
Decision on how to handle the stateless fork with the stateless project.
Integration with Autofac 2.4
Creation of a NuGet package.

If you would like to contribute, please contact me via the contact page or email me directly at steve(dot)hebert (at) gmail(dot)com.

-Steve

Updated Wiki: Home

sdhebert — Tue, 04 Jan 2011 06:07:57 GMT

Documentation

Introduction
Creating State Tasks
Configuring the Workflow
Using the FluentWorkflow StateEngine
- Enumerating valid triggers
- Firing a trigger at the FluentWorkflow StateEngine

Updated Wiki: Design Goals

sdhebert — Tue, 04 Jan 2011 06:06:19 GMT

FluentWorkflow is built on top of three key/core components:

The System.Composition namespace – this is for core metadata association offered in the .net 4.0 framework.
stateless – this is a state engine based on .net 3.5+ created Nicholas Blumhardt
Autofac – this is an Inversion of Control container build on .Net3.5+ capabilities

Due to the use of Func<..> injection combined with .net4 metadata and the AutofacContrib.Attributed project, the first release of FluentWorkflow is built to work with Autofac 2.4 or greater.

The dependency on Autofac can be moved when:

Other containers support the types of creation/relation patterns that autofac supports (see The Relationship Zoo)
Other containers support System.Composition based metadata storage or another metadata storage mechanism takes its place.

For my systems, autofac has been extremely functional and met all of our requirements to date.

Updated Wiki: Home

sdhebert — Tue, 04 Jan 2011 05:30:35 GMT

Documentation

Introduction
- What is a Workflow?
- Design Goals
Creating State Tasks
Configuring the Workflow
Using the FluentWorkflow StateEngine
- Enumerating valid triggers
- Firing a trigger at the FluentWorkflow StateEngine

Updated Wiki: Introduction

sdhebert — Tue, 04 Jan 2011 05:04:07 GMT

FluentWorkflow is a library that allows you to define

a set of valid states
transitional triggers that define how to move between states
actions that need to be executed when exiting and entering states.

Given these components, FluentWorkflow goes beyond the generic state machine implementation and allows for discrete, interrelated actions to occur upon state change. In short, this bridges the gap between generic state machines and larger tools like Windows Workflow Foundation.

In order to accomplish this goal, FluentWorkflow provides a simple fluent configuration DSL for describing workflows and also ordering of state actions. You are also given the ability to do things like ‘auto-progressing’ from one state to another by a specific type of task.

FluentWorkflow is focused on providing an environment where workflow tasks can be very small and focused. These tasks can be ordered together to provide complex workflow scenarios that are easy to test, understand and even visuallize (visualization coming).

Updated Wiki: What is a Workflow?

sdhebert — Tue, 04 Jan 2011 04:49:12 GMT

A workflow is a combination of two discrete ideas:

A state machine
A set of tasks associated with each state.

When trying to merge the two concepts into a business application, task responsibilities typically leak into the StateMachine and sometimes the other way around. This causes the code to deteriorate – becoming difficult to maintain, understand and grow to meet changing business requirements.

Let’s take a typical blog engine where a comment may be moderated.

This is a clean diagram shows the discrete states in circles and the triggers for each state named in the arrows showing the transition points.

The diagram only captures part of the story, because the business requirements may state

When entering the review phase, AutoApprove previously cleared users so their comments don’t have to be reviewed.
If the review does not result in an AutoApprove, send the blog owner an email requesting a review.
Keep a history of when the document moved from state to state.

These are hypothetical requirements and quite simplified but they convey the heart of our point which is:

These tasks have relationships between each other.
They may invoke other transitions.
[The hidden requirement] The business requirements will change over time, so this needs to be flexible.

Now let’s look at a diagram that fills out the picture with our business rules:

Now that we have a graph that conveys the transitions across the state barrier, we can see a couple of key points:

Recording state changes occurs when we leave a state. This could happen in other ways, but this seems to make the most sense.
The state persistence is explicit here as the first step – only because it makes sense to save immediately given the rules, but our system should be flexible to change ordering.
State Change activities could be launched when entering a state.

Based on these requirements, we can create a DSL that looks like this:

Notice that we are defining states, the triggers that can act upon the states and the state tasks that must execute when entering or leaving the states. Also notice that interrelationships are being defined through the ‘DependsOn’ method – which allows for very easy modifications to the ordering of these tasks. This removes the desire to create ‘Uber-tasks’ that have many ordered responsibilities and instead we can drive to small, discrete tasks that are ordered by FluentWorkflow.

As you read through the documentation, you will see that the fluent configuration of FluentWorkflow is very close to this conceptual picture. With this picture, we even have enough information to generate the same graphs above – whether we use these for in-application visuals, build-time artifacts or both.

Updated Wiki: Home

sdhebert — Tue, 04 Jan 2011 01:19:12 GMT

Documentation

Introduction
- What is a Workflow?
Creating State Tasks
Configuring the Workflow
Using the FluentWorkflow StateEngine
- Enumerating valid triggers
- Firing a trigger at the FluentWorkflow StateEngine

Updated Wiki: What is a Workflow?

sdhebert — Tue, 04 Jan 2011 01:18:48 GMT

A workflow is a combination of two discrete ideas:

A state machine
A set of tasks associated with each state.

Let’s take a typical blog engine where a comment may be moderated.

This is a clean diagram shows the discrete states in circles and the triggers for each state named in the arrows showing the transition points.

The diagram only captures part of the story, because the business requirements may state

When entering the review phase, AutoApprove previously cleared users so their comments don’t have to be reviewed.
If the review does not result in an AutoApprove, send the blog owner an email requesting a review.
Keep a history of when the document moved from state to state.

These are hypothetical requirements and quite simplified but they convey the heart of our point which is:

These tasks have relationships between each other.
They may invoke other transitions.
[The hidden requirement] The business requirements will change over time, so this needs to be flexible.

Now let’s look at a diagram that fills out the picture with our business rules:

Now that we have a graph that conveys the transitions across the state barrier, we can see a couple of key points:

Recording state changes occurs when we leave a state. This could happen in other ways, but this seems to make the most sense.
The state persistence is explicit here as the first step – only because it makes sense to save immediately given the rules, but our system should be flexible to change ordering.
State Change activities could be launched when entering a state.

Based on these requirements, we can create a DSL that looks like this:

Notice that we are defining states, the triggers that can act upon the states and the state tasks that must execute when entering or leaving the states. Also notice that interrelationships are being defined through the ‘DependsOn’ method – which allows for very easy modifications to the ordering of these tasks. This removes the desire to create ‘Uber-tasks’ that have many ordered responsibilities and instead drive to small, discrete tasks that are ordered by FluentWorkflow.

Updated Wiki: Home

sdhebert — Tue, 04 Jan 2011 00:51:08 GMT

Documentation

Introduction
- Going Beyond the State Machine
Creating State Tasks
Configuring the Workflow
Using the FluentWorkflow StateEngine
- Enumerating valid triggers
- Firing a trigger at the FluentWorkflow StateEngine

Updated Wiki: Introduction

sdhebert — Tue, 04 Jan 2011 00:50:03 GMT

FluentWorkflow allows you to define

a set of valid states
transitional triggers that define how to move between states
the actions that need to be executed when exiting and entering states.

In short, FluentWorkflow goes beyond the generic state machine implementation and allows for discrete, interrelated actions to occur upon state change. In short, this bridges the chasm between generic state machines and larger tools like Windows Workflow Foundation.

In order to accomplish this goal, FluentWorkflow provides a simple fluent configuration dsl for describing workflows and also ordering of state actions. You are also given the ability to do things like ‘auto-progressing’ from one state to another by a specific type of task.

fluentworkflow Wiki Rss Feed

Updated Wiki: Home

Documentation

Table of Contents

Updated Wiki: Home

Documentation

Table of Contents

Updated Wiki: Building FluentWorkflow

Updated Wiki: Creating Exit State Tasks

Updated Wiki: Creating Exit State Tasks

Updated Wiki: Creating Exit State Tasks

Updated Wiki: Creating Exit State Tasks

Updated Wiki: Creating Exit State Tasks

Updated Wiki: Creating Mutatable Entry Tasks

Updated Wiki: Design Goals

Updated Wiki: Roadmap to v1.0

Updated Wiki: Home

Documentation

Table of Contents

Updated Wiki: Design Goals

Updated Wiki: Home

Documentation

Table of Contents

Updated Wiki: Introduction

Updated Wiki: What is a Workflow?

Updated Wiki: Home

Documentation

Table of Contents

Updated Wiki: What is a Workflow?

Updated Wiki: Home

Documentation

Table of Contents

Updated Wiki: Introduction