Programmer's Guide to the wftk -- core workflow API

[ wftk documentation home ]


The wftk core API is the set of C-language routines you can call from your code, assuming you're working in some language that can deal with calling C-language routines. Under Windows, these are contained in the wftk or wftk_rt DLLs (depending on which runtime library you link against). Under Unix you generally static-link to the wftk.

If you're using the repository manager (and if you're not, you're in wild and unexplored territory) then there's an excellent chance you are in the wrong place in looking at the wftk core API, and you might just want to let the repository manager take care of workflow for you. But if you're pretty sure you want to talk to the core API yourself, that's what you'll find here.

This API is roughly object-oriented, making it relatively easy to embed in an object-oriented language. Notes on the class structure planned for the wftk are here. These classes are more or less language-agnostic, in that they will be substantially identical whether you're writing Python, Java, or C++.

In the wftk core, a process is represented by a datasheet. Internally, the datasheet is an XML document, which you manipulate using the XMLAPI library, a DOM-like set of functions which build and modify heap-based data structures based on XML (and which can be written to and read from actual XML files on disk or elsewhere.) I say, "internally," because you could easily write an adaptor which would talk to some other non-XML-based system to load a datasheet; that adaptor would build an XMLAPI structure which would be equivalent to the standard XML file used in the stock adaptor.

The datasheet contains values (hence its name), it maintains a queue of tasks and bookmarks into active workflows, it contains an enactment history of the process, and it will probably end up doing more as time goes on. In a very real sense, then, even though the users' activities focus on tasks more than on processes, your programming will focus on processes.

Data structures

All data structures for the wftk are built as internal XML objects using the XMLAPI. These are the various things you will encounter while working with the wftk: Obviously, a major shortcoming of the current documentation is the absence of definitions for any of these. I need to comb through the code to reconstruct them, so it'll be a few days yet. Caveat: "a few days" in my personal universe means it may or may not be this year. Bear with me. I never actually stop working on the wftk, I just get distracted sometimes.

Areas of functionality

The functions in the wftk core API fall into the following categories: Granted, some of those categories are pretty peripheral, but that's the API as it stands right now.


For now, you can look at the code in the command-line utility, but at some point I want to snip some working bits of code out as examples. Most importantly, there are a couple of ways to use wftk that you probably aren't thinking of -- for instance, you can use it as a permission system for arbitrary actions using the wftk_action function. (You can grant or revoke full permission or cause the action to start an approval process; after approval, wftk will automatically complete the action.) WFTK -- it's not just for breakfast anymore.

Copyright (c) 2001 Vivtek. Please see the licensing terms for more information.