Cheshire3 Configuration: Workflow

|  | ## Cheshire3 Configuration: Workflow

Introduction

Workflows can be configured to define a series of processing steps that are common to several Cheshire3 databases/systems, as an alternative to writing customised code for each.

Workflow Configuration Tutorial including examples and explanation.

<workflow>

Base wrapping tags for workflows; analagous to <process> and <preprocess> in Index configurations.
Contains an ordered list of objects. The results of the first object is given to the second and so on down the chain. It should be apparent that subsequent objects must be able to accept as input, the result of the previous.

<object>

A call to an object within the system. <object>s define the following attributes:

- type [ mandatory ]
  Specifies the type of the object within the Cheshire3 framework. Broadly speaking this may be a preParser, parser, database, recordStore, index, logger, transformer, workflow.

- ref
  A reference to a configured object within the system. If unspecified, the current session is used to determine which server, database, recordStore and so forth should be used.

- function
  The name of the function to call. If unspecified, the default function for the particular type of object is called.

For existing processing objects that can be used in these fields, see the object documentation.

<log>

Log text to a Logger object.
A reference to a configured Logger may be provided using the 'ref' attribute. If no 'ref' attribute is present, the database's default logger is used.

<assign>

Assign a specified value to a variable with a given name. Requires both of the following attributes:

- from [ mandatory ]
  the value to assign

- to [ mandatory ]
  a name to refer to the variable

<fork>

Feed the current input into each processing fork.
[ more details to follow ]

<for-each>

Iterate/loop through the items in the input object.
Like <workflow> contains an ordered list of objects. Each of the items in the input is run through the chain of processing objects.

<try>

Allows for error catching.
Any errors that occur within this element will not cause the workflow to exit with a failure. Must be followed by an <except> element, which may also be followed by an <else> element.

<except>

Error handling.
This element must follow a <try> element. Specifies action to take in the event of an error occuring within the preceeding <try>.

<else>

Success handling.
This element may follow a <try> <except> pair. Specifies action to take in the event that no errors occur within the preceeding <try>.

<continue/>

Skip remaining processing steps, and move on to next iteration while inside a <for-each> loop element. May not contain any further elements or attributes. This can be useful in the error handling <except> element.
e.g. if a document cannot be parsed, it cannot be indexed, so skip to next document in the documentFactory.

<break/>

Break out of a <for-each> loop element, skipping all subsequent processing steps, and all remaining iterations. May not contain any further elements or attributes.

<raise/>

Raise an error occuring within the preceeding <try> to the calling script or workflow. May only be used within an <except> element. May not contain any further elements or attributes.

<return/>

Return the result of the previous step to the calling script or workflow. May not contain any further elements or attributes.