Retrieve a workflow object of type $workflow_type and ID $workflow_id. (The $workflow_type is necessary so we can fetch the workflow using the correct persister.) If a workflow with ID $workflow_id is not found undef is returned.

The $context argument is optional, you can pass an exisiting instance of Workflow::Context to be reused. Otherwise a new instance is created.

The $wf_class argument is optional. Pass it the name of a class to be used for the workflow to be created. By default, all workflows are of the Workflow class.

Any observers you've associated with this workflow type will be attached to the returned workflow object.

This fires a 'fetch' event from the retrieved workflow object. See WORKFLOWS ARE OBSERVABLE in Workflow for more.

Pass in filenames for the various components you wish to initialize using the keys 'action', 'condition', 'persister', 'validator' and 'workflow'. The value for each can be a single filename or an arrayref of filenames.

The system is familiar with the 'perl' and 'xml' configuration formats -- see the 'doc/configuration.txt' for what we expect as the format and will autodetect the types based on the file extension of each file. Just give your file the right extension and it will be read in properly.

You may also use your own custom configuration file format -- see SUBCLASSING in Workflow::Config for what you need to do.

You can also read it in yourself and add the resulting hash reference directly to the factory using add_config(). However, you need to ensure the configurations are added in the proper order -- when you add an 'action' configuration and reference 'validator' objects, those objects should already be read in. A good order is: 'validator', 'condition', 'action', 'workflow'. Then just pass the resulting hash references to add_config() using the right type and the behavior should be exactly the same.

Returns: nothing; if we run into a problem parsing one of the files or creating the objects it requires we throw a Workflow::Exception.

Similar to add_config_from_file() -- the keys may be 'action', 'condition', 'persister', 'validator' and/or 'workflow'. But the values are the actual configuration hashrefs instead of the files holding the configurations.

You normally will only need to call this if you are programmatically creating configurations (e.g., hot-deploying a validator class specified by a user) or using a custom configuration format and for some reason do not want to use the built-in mechanism in Workflow::Config to read it for you.

Returns: nothing; if we encounter an error trying to create the objects referenced in a configuration we throw a Workflow::Exception.

Stores the state and current datetime of the $workflow object. This is normally called only from the Workflowexecute_action() method.

This method respects transactions if the selected persister supports it. Currently, the DBI-based persisters will commit the workflow transaction if everything executes successfully and roll back if something fails. Note that you need to manage any Workflow::Persister::DBI::ExtraData transactions yourself.

Retrieves the action $action_name from workflow $workflow. Note that this does not do any checking as to whether the action is proper given the state of $workflow or anything like that. It is mostly an internal method for Workflow (which does do checking as to the propriety of the action) to instantiate new actions.

Adds all configurations in @config_hashrefs to the factory. Also cycles through the workflow states and creates a Workflow::State object for each. These states are passed to the workflow when it is instantiated.

We also require any necessary observer classes and throw an exception if we cannot. If successful the observers are kept around and attached to a workflow in "create_workflow()" and "fetch_workflow()".

If you have either a large set of config files or a set of very large config files then you may not want to incur the overhead of loading each and every one on startup if you cannot predict which set you will use in that instance of your application.

This approach doesn't make much sense in a persistent environment such as mod_perl but it may lower startup costs if you have regularly scheduled scripts that may not need to touch all possible types of workflow.

To do this you can specify a callback that the factory will use to retrieve batched hashes of config declarations. Whenever an unknown workflow name is encountered the factory will first try to load your config declarations then continue.

The callback takes one argument which is the workflow type. It should return a reference to a hash of arguments in a form suitable for add_config_from_file.

Setting package variable $VALIDATE_ACTION_CONFIG to a true value (it is undef by default) turns on optional validation of extra attributes of Workflow::Action configs. See Workflow::Action for details.