Overview

User Point of View

• Workflow::Factory - The factory is your interface for creating new workflows and fetching existing ones. You also feed all the necessary configuration files and/or data structures to the factory to initialize it.
• Workflow - When you get the workflow object from the workflow factory you can only use it in a few ways -- asking for the current state, actions available for the state, data required for a particular action, and most importantly, executing a particular action. Executing an action is how you change from one state to another.
• Workflow::Context - This is a blackboard for data from your application to the workflow system and back again. Each instantiation of a Workflow has its own context, and actions executed by the workflow can read data from and deposit data into the context.

Developer Point of View

• workflow - The workflow is a collection of states; you define the states, how to move from one state to another, and under what conditions you can change states.

  This is represented by the Workflow object. You normally do not need to subclass this object for customization.

• action - The action is defined by you or in a separate library. The action is triggered by moving from one state to another and has access to the workflow and more importantly its context.

  The base class for actions is the Workflow::Action class.

• condition - Within the workflow you can attach one or more conditions to an action. These ensure that actions only get executed when certain conditions are met. Conditions are completely arbitrary: typically they will ensure the user has particular access rights, but you can also specify that an action can only be executed at certain times of the day, or from certain IP addresses, and so forth. Each condition is created once at startup then passed a context to check every time an action is checked to see if it can be executed.

  The base class for conditions is the Workflow::Condition class.

• validator - An action can specify one or more validators to ensure that the data available to the action is correct. The data to check can be as simple or complicated as you like. Each validator is created once then passed a context and data to check every time an action is executed.

  The base class for validators is the Workflow::Validator class.

Just a Bunch of States

When you create a workflow you have one action available to you: create a new ticket ('create issue'). The workflow has a state 'INITIAL' when it is first created, but this is just a bootstrapping exercise since the workflow must always be in some state.

The workflow action 'create issue' has a property 'resulting_state', which just means: if you execute me properly the workflow will be in the new state 'CREATED'.

All this talk of 'states' and 'transitions' can be confusing, but just match them to what happens in real life -- you move from one action to another and at each step ask: what happens next?

You create a trouble ticket: what happens next? Anyone can add comments to it and attach files to it while administrators can edit it and developers can start working on it. Adding comments does not really change what the ticket is, it just adds information. Attachments are the same, as is the admin editing the ticket.

But when someone starts work on the ticket, that is a different matter. When someone starts work they change the answer to: what happens next? Whenever the answer to that question changes, that means the workflow has changed state.

Discover Information from the Workflow

This is an example of discoverability. This workflow system is setup so you can ask it what you can do next as well as what is required to move on. So to use our ticket example we can do this, creating the workflow and asking it what actions we can execute right now:

 my $wf = Workflow::$self->_factory()->create_workflow( 'Ticket' );
 my @actions = $wf->get_current_actions;

We can also interrogate the workflow about what fields are necessary to execute a particular action:

 print "To execute the action 'create issue' you must provide:\n\n";
 my @fields = $wf->get_action_fields( 'create issue' );
 foreach my $field ( @fields ) {
     print $field->name, " (Required? ", $field->is_required, ")\n",
           $field->description, "\n\n";
 }

Provide Information to the Workflow

Whenever the Workflow::Factory creates a new workflow it associates the workflow with a Workflow::Context object. The context is what moves the data from your application to the workflow and the workflow actions.

For instance, the workflow has no idea what the 'current user' is. Not only is it unaware from an application standpoint but it does not presume to know where to get this information. So you need to tell it, and you do so through the context.

The fact that the workflow system proscribes very little means it can be used in lots of different applications and interfaces. If a system is too closely tied to an interface (like the web) then you have to create some potentially ugly hacks to create a more convenient avenue for input to your system (such as an e-mail approving a document).

The Workflow::Context object is extremely simple to use -- you ask a workflow for its context and just get/set parameters on it:

 # Get the username from the Apache object
 my $username = $r->connection->user;

 # ...set it in the context
 $wf->context->param( user => $username );

 # somewhere else you'll need the username:

 $news_object->{created_by} = $wf->context->param( 'user' );

Controlling What Gets Executed

• Get data from the user
• Fetch a workflow
• Set the data from the user to the workflow context
• Execute an action on the context

When you execute the action a number of checks occur. The action needs to ensure:

• The data presented to it are valid -- date formats, etc. This is done with a validator, more at Workflow::Validator
• The environment meets certain conditions -- user is an administrator, etc. This is done with a condition, more at Workflow::Condition

Once the action passes these checks and successfully executes we update the permanent workflow storage with the new state, as long as the application has declared it.

Purpose

 package FindSinead;

 sub update {
     my ( $class, $wf, $event, $new_state ) = @_;
     return unless ( $event eq 'state change' );
     return unless ( $new_state eq 'CREATED' );
     my $context = $wf->context;
     return unless ( $context->param( 'first_name' ) eq 'Sinead' );

     my $user = $context->param( 'user' );
     my $username = $user->username;
     my $email    = $user->email;
     my $mailer = get_mailer( ... );
     $mailer->send( 'foo@bar.com','Found her!',
                    "We found Sinead under '$username' at '$email' );
 }

And then associate it with your workflow:

 <workflow>
     <type>SomeFlow</type>
     <observer class="FindSinead" />
     ...

Every time you create/fetch a workflow the associated observers are attached to it.

Events Generated

• create - Issued after a workflow is first created.

  No additional parameters.

• fetch - Issued after a workflow is fetched from the persister.

  No additional parameters.

• save - Issued after a workflow is successfully saved.

  No additional parameters.

• execute - Issued after a workflow is successfully executed and saved.

  Adds the parameters $old_state, $action_name and $autorun. $old_state includes the state of the workflow before the action was executed, $action_name is the action name that was executed and $autorun is set to 1 if the action just executed was started using autorun.

• state change - Issued after a workflow is successfully executed, saved and results in a state change. The event will not be fired if you executed an action that did not result in a state change.

  Adds the parameters $old_state, $action and $autorun. $old_state includes the state of the workflow before the action was executed, $action is the action name that was executed and $autorun is set to 1 if the action just executed was autorun.

• add history - Issued after one or more history objects added to a workflow object.

  The additional argument is an arrayref of all Workflow::History objects added to the workflow. (Note that these will not be persisted until the workflow is persisted.)

Configuring

We load these classes at startup time. So if you specify an observer that doesn't exist you see the error when the workflow system is initialized rather than the system tries to use the observer.

For instance, the following defines two observers:

 <workflow>
   <type>ObservedItem</type>
   <description>This is...</description>

   <observer class="SomeObserver" />
   <observer sub="SomeOtherObserver::Functions::other_sub" />

In the first declaration we specify the class ('SomeObserver') that will catch observations using its "update()" method. In the second we're naming exactly the subroutine ('other_sub()' in the class 'SomeOtherObserver::Functions') that will catch observations.

All configured observers get all events. It's up to each observer to figure out what it wants to handle.

Object Methods

Execute the action $action_name. Typically this changes the state of the workflow. If $action_name is not in the current state, fails one of the conditions on the action, or fails one of the validators on the action an exception is thrown. $autorun is used internally and is set to 1 if the action was executed using autorun.

After the action has been successfully executed and the workflow saved we issue a 'execute' observation with the old state, action name and an autorun flag as additional parameters. So if you wanted to write an observer you could create a method with the signature:

 sub update {
     my ( $class, $workflow, $action, $old_state, $action_name, $autorun )
        = @_;
     if ( $action eq 'execute' ) { .... }
 }

We also issue a 'change state' observation if the executed action resulted in a new state. See "WORKFLOWS ARE OBSERVABLE" above for how we use and register observers.

Returns: new state of workflow

get_current_actions( $group )

Returns a list of action names available from the current state for the given environment. So if you keep your "context()" the same if you call "execute_action()" with one of the action names you should not trigger any condition error since the action has already been screened for conditions. If you want to divide actions in groups (for example state change group, approval group, which have to be shown at different places on the page) add group property to your action

<action name="terminate request" group="state change" class="MyApp::Action::Terminate" /> <action name="approve request" group="approval" class="MyApp::Action::Approve" />

my @actions = $wf->get_current_actions("approval");

$group should be string that reperesents desired group name. In @actions you will get list of action names available from the current state for the given environment limited by group. $group is optional parameter.

Returns: list of strings representing available actions

get_action( $action_name )

Retrieves the action object associated with $action_name in the current workflow state. This will throw an exception if:

• No workflow state exists with a name of the current state. (This is usually some sort of configuration error and should be caught at initialization time, so it should not happen.)
• No action $action_name exists in the current state.
• No action $action_name exists in the workflow universe.
• One of the conditions for the action in this state is not met.

get_action_fields( $action_name )

Return a list of Workflow::Action::InputField objects for the given $action_name. If $action_name not in the current state or not accessible by the environment an exception is thrown.

Returns: list of Workflow::Action::InputField objects

add_history( @( \%params | $wf_history_object ) )

Adds any number of histories to the workflow, typically done by an action in "execute_action()" or one of the observers of that action. This history will not be saved until "execute_action()" is complete.

You can add a list of either hashrefs with history information in them or full Workflow::History objects. Trying to add anything else will result in an exception and none of the items being added.

Successfully adding the history objects results in a 'add history' observation being thrown. See "WORKFLOWS ARE OBSERVABLE" above for more.

Returns: nothing

get_history()

Returns list of history objects for this workflow. Note that some may be unsaved if you call this during the "execute_action()" process.

get_unsaved_history()

Returns list of all unsaved history objects for this workflow.

clear_history()

Clears all transient history objects from the workflow object, not from the long-term storage.

set( $property, $value )

Method used to overwrite Class::Accessor so only certain callers can set properties caller has to be a Workflow namespace package.

Sets property to value or throws Workflow::Exception

Properties

Configuration Properties

Some properties are set in the configuration file for each workflow. These remain static once the workflow is instantiated.

type

Type of workflow this is. You may have many individual workflows associated with a type or you may have many different types running in a single workflow engine.

description

Description (usually brief, hopefully with a URL...) of this workflow.

time_zone

Workflow uses the DateTime module to create all date objects. The time_zone parameter allows you to pass a time zone value directly to the DateTime new method for all cases where Workflow needs to create a date object. See the DateTime module for acceptable values.

Dynamic Properties

You can get the following properties from any workflow object.

id

ID of this workflow. This will always be defined, since when the Workflow::Factory creates a new workflow it first saves it to long-term storage.

state

The current state of the workflow.

last_update (read-write)

Date of the workflow's last update.

context (read-write, see below)

A Workflow::Context object associated with this workflow. This should never be undefined as the Workflow::Factory sets an empty context into the workflow when it is instantiated.

If you add a context to a workflow and one already exists, the values from the new workflow will overwrite values in the existing workflow. This is a shallow merge, so with the following:

 $wf->context->param( drinks => [ 'coke', 'pepsi' ] );
 my $context = Workflow::Context->new();
 $context->param( drinks => [ 'beer', 'wine' ] );
 $wf->context( $context );
 print 'Current drinks: ', join( ', ', @{ $wf->context->param( 'drinks' ) } );

You will see:

 Current drinks: beer, wine

Internal Methods

THIS SHOULD ONLY BE CALLED BY THE Workflow::Factory. Do not call this or the "new()" method yourself -- you will only get an exception. Your only interface for creating and fetching workflows is through the factory.

This is called by the inherited constructor and sets the $current_state value to the property "state" and uses the other non-state values from "\%config" to set parameters via the inherited "param()".

_get_workflow_state( [ $state ] )

Return the Workflow::State object corresponding to $state, which defaults to the current state.

_set_workflow_state( $wf_state )

Assign the Workflow::State object $wf_state to the workflow.

_get_next_state( $action_name )

Returns the name of the next state given the action $action_name. Throws an exception if $action_name not contained in the current state.

add_observer( @observers )

Adds one or more observers to a "Workflow" instance. An observer is a function. See "notify_observers" for its calling convention.

This function is used internally by "Workflow::Factory" to implement observability as documented in the section "WORKFLOWS ARE OBSERVABLE"

notify_observers( @arguments )

Calls all observer functions registered through "add_observer" with the workflow as the first argument and @arguments as the remaining arguments:

   $observer->( $wf, @arguments );

Used by various parts of the library to notify observers of workflow instance related events.

DEPENDENCIES FOR THE EXAMPLE APPLICATION

CGI

CGI::Cookie

DBD::SQLite

HTTP::Daemon

HTTP::Request

HTTP::Response

HTTP::Status

Template (Template Toolkit)

For Win32 systems you can get the Template Toolkit and DBD::SQLite PPDs from TheoryX:

•

<http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?urn:/PPMServer58>

XML::Simple

The XML::Simple makes use of Lib::XML::SAX or XML::Parser, the default.

In addition an XML::Parser can makes use of plugin parser and some of these might not be able to parse the XML utilized in Workflow. The problem have been observed with XML::SAX::RTF.

The following diagnostic points to the problem:

        No _parse_* routine defined on this driver (If it is a filter, remember to
        set the Parent property. If you call the parse() method, make sure to set a
        Source. You may want to call parse_uri, parse_string or parse_file instead.)

Your XML::SAX configuration is located in the file:

        XML/SAX/ParserDetails.ini

REPOSITORY

<https://github.com/jonasbn/perl-workflow/tree/master/>

OTHER RESOURCES

• CPAN Ratings

  <http://cpanratings.perl.org/d/Workflow>

• MetaCPAN

  <https://metacpan.org/release/Workflow>