Applying the wftk workflow toolkit

• 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 here.

Timeline of actual development of this section

• 19 Jan 2002 Started LARTmeister concept and wrote some use cases for the system.
• 25-29 Dec 2002 Wrote a bug tracker for Techspex.com and penned some general musings on CRM in general.
• 9 May 2003 Started a white paper on wftk support of Perl data processing systems.