[daisy] Status update on workflow

[Bruno Dumon]

Hi,

Here's an overview of what has been accomplished so far for workflow,
and what still needs to be done. Basically what we've done is
integrating jBPM, so the main workflow functionality comes from jBPM
(which I'm not going to write about here, see jbpm.org), and the below
only concerns the integration of jBPM into Daisy.

Things which have been done:

- Workflow is implemented as an extension component in the repository
server, based on jBPM. The database tables for jBPM are automatically
created on repository startup if not present (as InnoDB tables so that
transactions work). The database tables are created in the same database
as the rest of Daisy, so there is no additional effort for backup. jBPM
uses the same database connection pool as the repository server. The
repository-init script has been updated to do the necessary
configuration during installation.

- A workflow Java API has been defined, as well as a HTTP/XML API
allowing remote access. Clients interact always via this API, not
directly with jBPM (so it's not visible jBPM is used internally). The
Java API is both implemented 'native' as well as 'remote' (transparently
communicating over the HTTP/XML API) so that remote use is easy and
client code is the same wether it runs in the repository JVM or another
JVM (in other words, it works the same as the rest of Daisy).

- There is a Daisy-specific metadata layer on top of the jBPM process
definitions, which adds internationalised labels and descriptions for
various things (tasks, transitions, ...), and allows to configure the
variables that can be updated as part of a task interaction (i.e. with
datatypes, labels, selection lists, requiredness, that sort of things).
The i18n resource bundles are XML-based (same format as the Cocoon
bundles), so encoding is easy and mixed content in messages is possible.

- Process variables can point to Daisy documents and Daisy users.

- Scripts in process definitions can be written as Javascript, which is
familiar for our users from the document tasks, standalone scripts,
flowscript, ... (jBPM supports beanshell-based scripting by default,
which of course stays usable). The Repository and RepositoryManager
objects are available in scripts (through jBPM's transient context
variables).

- Management of workflow pools, which are essentially groups of users to
which tasks can be assigned (so these workflow pools are distinct from
the user roles).

- A flexible query system for searching processes and tasks. This allows
to search for processes and tasks using a (flat) set of conditions (with
a simple "match all" or "match any" approach), and with sorting and
selection (projection) of the data to be returned, and paging (chunking)
of results.

- Various GUI additions to the Daisy Wiki:
   - Administration screens to upload process definitions and to
     manage the workflow pools.
   - Screen to start a new workflow
   - Screens to view(/browse/search) tasks and processes
   - Screen to perform a task.

- Some sample workflows are deployed out-of-the-box:
   - document review workflow
   - generic task workflow
   - timed publication workflow (which does not yet work,
     see todo item on timers below)

- A dummy component has been added which prints a message to standard
out when the repository server is fully started. This has always been
useful as there is no feedback about this when starting the repository
server, and with the addition of workflow the startup takes a little
longer so it is even more useful now.


Things which still have to be done:

- Access control. This is one of the most important outstanding work
items. Currently all process instances and tasks are viewable and
updateable by anyone. There needs to be some sort of authorisation that
determines who can see and do what.

- i18n of the GUI, of the query system, and of error messages.

- some more administration things, e.g. viewing the number of process
instances for each version of a process definition.

- Chunking in the task/process listings (already implemented on the
back-end)

- Timers (needs starting of a thread, context setup and availability of
some repository user to perform operations) and timer management (remove
open timers, view failed timers).

- Front-end polishing: better input support for document links and
date-time fields.

- Re-assignment of tasks.

- Email notifications for tasks.

- And of course, checking if what's implemented now fullfills the
workflow needs of people.

The next weeks I'll probably work on other stuff, so finishing workflow
might be something for January, this leaves plenty of time for some
feedback on the current implementation.

Documentation is also todo, I'll give it a first short right now.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno at outerthought.org                          bruno at apache.org