wftk tutorial - 06 Procedure definitions and roles

Where the last chapter talked about the machinery for organizing actual ongoing processes and the tasks needed to complete them, this chapter addresses the need to formalize processes by using procedures. A procedure definition or procdef is a standard, repeatable way of dealing with a given type of process -- a sort of workflow macro. The procdef can specify tasks to be completed, actions to be taken directly by the workflow system, decisions to be made using arbitrary logic, notifications to be sent, and so on. We'll cover the basic mechanism of organizing procdefs in this chapter, but we'll need the next two chapters to talk about some of the details.

In the meantime, we'll use the simplest form of procedure, the checklist, to illustrate the basic procedure mechanisms. A checklist simply creates a set of standard tasks when it is applied to a process. As tasks complete, the procdef can handle notifications or a progress indicator. It's simple and easy to understand, and is more than sufficient for understanding how procedures work in the wftk system.

Procedures use roles as placeholders for user and resource assignments. A role can be seen as a variable whose value is a user (or other resource). You can specify eligibility rules for role assignments. Of course, those rules can be overriden -- with approval. (See how workflow insinuates itself into everything?)

Procdefs are stored in a list as attachments. This list must be a version-controlled list (or at least it must tell the world that it is; if it lies, there's nothing I can do about it). When a procdef is attached to a procedure, the specific version applicable at the time is attached. If the procdef is then changed at a later date, this won't affect processes already launched (which would be a disaster).

It is possible (although potentially confusing) to attach any number of running procedures to a single process. Interactions may be complex and unpredictable, especially if they're state-based workflow. It is probably better practice to set up subprocesses as tasks within the main workflow, then use additional procedures to regulate the completion of the subprocesses. But just like anything else in Perl, the wftk allows you to shoot yourself in the foot if that's what you really think you want.

Here is an index to the information in this chapter:

(unresolved tag 06-index)

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.