So far, the wftk is a nice way to represent the "data landscape" of a process or set of processes, but that's only the backdrop for a workflow system. A workflow system is all about organizing actions on data, after all. So the next step on our road to workflow is to define actions and ways of representing them.

An action is an activity performed by an actor (which we'll ignore until the next chapter), which affects data. Of course, at a lower level every line of code, even every opcode in our CPU, is an action, but we're not interested in actions at that level. Instead, we are more interested in something closer to the notion of a function call. In the wftk, an action is defined as a record (a set of parameters) passed to an action handler. If we understand a list subclass to be a sort of "data handler", we can see that a subclass of the Workflow::wftk::Action class is an action handler.

Just as individual lists instantiate list subclasses, different specific action types are handled by a single action handler. And just as each individual list holds multiple specific records, an action type is used to carry out multiple specific actions. The record of those actions is what (potentially) gets stored in a record's enactment (see 02-i).

Action types are stored either in the repository itself, or in the repository's type. This provides a sort of hierarchical definition system allowing us to include applications and libraries into the repository.

The event is a notion similar to the action. Each specific action is, of course, an event (because it's logged in the enactment). However, the idea of an event is also used to cover data coming into a wftk system from actions taken outside the system. Events are organized into event lists, and an event list generally is assigned a handler to take action when an external event occurs.

The standard list of events is diverse: incoming email or other messages (faxes, SMS, etc.), Web form posts, commands issued from the command line, RPC or SOAP calls, GUI element actuation, and so on.

Finally, actions and events can also be scheduled by entries in a special list called, appropriately enough, a schedule. The wftk handles the conversion of changes to that list into specifications for the underlying scheduler provided by the operating system.

Here is an index to the information in this chapter:

(unresolved tag 03-index)