Applying the wftk workflow toolkit
The most effective documentation of any system is descriptions of ways to build working systems with it.
With the addition of the repository manager, the wftk has finally reached the point where it is
practical to talk about real-life systems, and so I want to start sketching out (and wherever possible
actually building) some sample systems, so that you can get some idea of what you can actually do with
Here are a few basic functional areas that I see the wftk fitting into.
- Web-enabled submission
My chief example for this is the LARTmeister, which allows public submission
of Net abuse incidents and subsequent workflow-based tracking. This is far too complex, of course, but will
surely spin off a few much smaller example configurations before it goes too much further.
- Content-based website
Another track of development of wftk which has recently started bearing fruit is data and content
management. The content-based website is the whole idea here, starting from simple management of
articles posted at various times, to event calendars, weblogs, searchable archives, and the whole nine
yards. Everybody does this stuff by hand, but it gets out of control if you do that for too long.
A more advanced version of the content-based website is the searchable online database, and that model
also falls under this category. A good example of a non-free application which aims at this category
is Microsoft's Sharepoint.
- Simple document management
Although the content-based website can involve document management (for example, in managing images
used in the site), it makes sense to highlight some of the explicitly document-management-oriented features of
the new repository manager portion of the wftk. This isn't necessarily even an Internet-enabled
application; essentially you can imagine a drag-and-drop client which allows you to submit documents
to an EDMS (electronic document management system) from your desktop. Once the document is in the
repository, it can trigger whatever workflow processes are needed, and it can be version-controlled,
meaning that people can check it out, make changes, and check it back in, all tracked at each step.
- Customer relationship manager: also known as CRM, or issue tracker, or bug tracker, etc.
This is nearly the classic workflow application. Each trouble ticket is a case and may be attached
to a particular customer (if there is only one customer, i.e. the "userbase", then this is generally
called a bug tracker or project management system, but if you regard each issue as a project for any
of many customers, it's CRM.) As a case progresses
through various stages it must be brought to the attention of different people. Cases which have been
open too long need to trigger emergency handling. The customer needs to be notified of various actions
taken, or possibly needs to supply additional data.
- E-commerce server
The shopping cart/order server was one of the original prototype scenarios, and that hasn't changed.
From a repository standpoint (data management), you have a hierarchical set of SKUs in each merchant's
catalog, you have a list of customers, you have an arbitrary number of suppliers which may drop-ship
ordered items, and you have any number of arbitrary procedures to trigger when something happens. There
are a number of variations on all this, with the result that an implementation of a shopping cart that's
built on something less flexible than wftk is going to have surprising limitations just when you least
expect it. Trust me, this is the voice of painful experience speaking here.
- Session-based website
This will possibly be the most involved example, but the idea is to present a website in which the
navigational aids reflect the system's knowledge of who you are and what you are doing. This is based
on the new templating system built into the repository manager, and it is quite powerful technology.
- Status display for general data processing systems
A rather common model for complex data systems is to start with a few limited goals of things to manage,
write some quick Perl code to do things with it, maybe do some formatting code to make pretty lists of things
to indicate current status of things in the system, and then ... just keep tweaking and extending that for a
few years until nobody really remembers what is where and why. I do this a lot. So one of the goal areas for
a workflow toolkit would be to take such a system and make it manageable without requiring a great deal
of recoding (maybe none at all). My initial target for this mode of system development is the abuse tracking
and response systems of Despammed.com, with which I've been spending some
quality time lately. This documentation effort is starting on 9 May 2003 and the story starts
Timeline of actual development of this section
Copyright (c) 2003 Vivtek. Please see the licensing
terms for more information.