Midgard CMS
Open Source Content Management System
Midgard Project > Development > Midgard RFCs > Workflow in Midgard

mRFC 0023: Workflow in Midgard

  1. Workflow
    1. Workflow is not for everybody
    2. Prototypes and implementations
      1. Object model
      2. Workflow phases
      3. Prototype management
  2. Task management
    1. Deliverables
      1. Deliverable Plugin Interface
    2. Task micro-workflow
    3. Getting Things Done
    4. Digital Business Ecosystem
    5. Synchronization
  3. Misc
  4. Glossary
  5. Related work

This proposal describes a workflow engine built for handling tasks, processes and workflows within MidCOM applications. This mRFC been submitted to the Midgard Community for discussion and approval under the Creative Commons Attribution-ShareAlike license.

Workflow

Wikipedia defines workflow as:

Workflow is the operational aspect of a work procedure: how tasks are structured, who performs them, what their relative order is, how they are synchronized, how information flows to support the tasks and how tasks are being tracked. As the dimension of time is considered in Workflow, Workflow considers "throughput" as a distinct measure. Workflow problems can be modeled and analyzed using Petri nets.

Workflow is not for everybody

In the Groupware bad paper, Jamie Zawinski comments that

"Groupware" is all about things like "workflow", which means, "the chairman of the committee has emailed me this checklist, and I'm done with item 3, so I want to check off item 3, so this document must be sent back to my supervisor to approve the fact that item 3 is changing from 'unchecked' to 'checked', and once he does that, it can be directed back to committee for review."

Nobody cares about that shit. Nobody you'd want to talk to, anyway.

While this is true for a lot of use cases, there are still heavily regulated industries and activities where well defined and coordinated workflows are a must. This mRFC is split into two pieces: Task management and Workflow management. While workflows are needed by only some, task management should be useful for almost all Midgard users.

Prototypes and implementations

TODO

Object model

Trail

  • Trails are the prototypes of processes
  • Trails have a title and description
  • Trails may have a field map used if the trail is instantiated by a Spawn step in another process for copying data from that process

Step

  • Steps have a title and description
  • Steps have a type telling which workflow phase it is
  • Steps have an up field telling after which step (predecessor) they begin
    • Join and Start steps don't have up field defined, they get their predecessors from deliverables
    • Only Decisions and Splits may have multiple successors
  • Steps are the prototypes of tasks and belong to a trail
  • Steps are assigned to roles (i.e. midgard_groups)
  • Steps have two time definitions: start and end (deadline)
    • The end definition is some offset from a selected earlier step end
    • The start definition is some offset from the step's end
    • Both offset selections provide an integer field and pulldown (hours, days, weeks, months) for user input

Process

  • Trail is the parent of the process
    • Process creation is a midgard:create privilege inherited from trail
  • Process has an owner person, and started and completed timestamps
  • Process has a start timestamp telling when the Start task has to be created
    • There is a daily check in cron service to start processes

Task

  • Mainly the existing org_openpsa_task implementation
  • Task has optional process and step link attributes
  • Tasks are assigned to persons (single or multiple) using member objects
  • Autocloseable
  • Skippable

Workflow phases

All workflow phases are modeled as steps, and handled during process

Start (circle)

  • Start is never instantiated as Task, and is simply used to lead to first actual step

Action (box)

  • Actions are regular tasks within the workflow
  • Actions always have a predecessor (up), and a successor (phase which has up pointing to this step)

Decision (diamond)

  • Decision editor asks for icon and text label of decision per each child step
    • The editor must be available both in the decision step, and in each child
    • Icons are presented as a selection list populated from component config array

Split (triangle pointing down)

  • Split is never instantiated as Task, and is simply used for pointing to succeeding steps

Join (triangle pointing up)

  • Join is a real Auto-closing task pointing to predecessors that must be completed via deliverables
  • Join is created only after all predecessor tasks exist
  • Joins don't have assignees in most cases -> rendered only in process view

End (two concentric circles, innermost filled)

  • End is never instantiated as a Task. Instead, the process is completed

Spawn (octagon)

  • Starts another process, passing some information to it
  • Spawn is a "dead end" step that that may not have successors, and does not complete the process

Prototype management

UI description/mock-up here

Task management

Task handling is centered into a Task Inbox where the user can see a list of her current open tasks. The tasks may come from active workflow processes, OpenPsa projects, support tickets, or be simply standalone tasks like "Remember to buy milk".

Deliverables

Deliverables are actual results of the task work. For example, if user is assigned to write a report about something, the deliverable could be a new OpenOffice.org document placed into a directory in the org.openpsa.documents repository, or it could be a wiki page.

As most workflows are related to highly regulated and paper-based processes, the most important deliverable will be "Create document from template", which will present user with a datamanager form and an office document template connected to that particular workflow, and will store the resulting document into a specified directory.

Deliverable Plugin Interface

Pseudocode/stubs from existing implementation.

<?php
/**
 * Deliverable object definition in PHP form (actually this is MgdSchema object)
 */
class org_openpsa_deliverable
{
    var $id"; //Local id of the deliverable
    var $plugin; //Name of the plugin used
    var $task; //Id of the task this deliverable is linked to
    var $target; /* Target of the plugin, the plugin interprets the target as it sees fit
                    but generally this is a GUID */

    /**
     * Instances the deliverable plugin interface for this deliverable object 
     * and checks for status via it.
     */
    function status()
    {
    }
}

/**
 * Wrapper class for deliverables operations
 *
 * This allows us to change the ways the plugins work and are loaded at a later
 * time (in case we wish to move them to the actual target components)
 */
class org_openpsa_projects_deliverables_interface
{
    var $_plugins = array(); //List of plugins available

    /**
     * Searches for plugins and fills $this->_plugins
     */
    function _find_plugins()
    {
    }

    /**
     * Returns an array of available plugins as objects
     */
    function list_plugins()
    {
    }

    /**
     * Checks all deliverables for task returns true if all return true otherwise false
     * @param integer $task_id Identifier of an OpenPsa Projects task
     * @return boolean Whether all deliverables of the task have been completed
     */
    function check_all_deliverables_status($task_id)
    {
    }

    /**
     * Takes plugin name and returns plugins classname for instancing
     */
    function _resolve_plugin($plugin)
    {
    }

    /**
     * Based on deliverable object id/guid returns correct plugin initialized
     */
    function get_deliverable_plugin($identifier)
    {
    }

    /**
     * Returns an empty (not initialized with deliverable object) plugin for plugin name
     */
    function get_plugin($name)
    {
    }
}

/**
 * Baseclass for deliverables plugins
 */
class org_openpsa_projects_deliverables_interface_plugin
{
    var $_deliverable; //A deliverable object
    var $name; //Name of the plugin
    var $description; //Description of the plugin

    /**
     * Returns true or false depending on whether the plugin considers the target
     * "delivered" or not.
     * @return boolean
     */
    function status()
    {
    }

    /**
     * In task view the select plugin(s) row for this
     */
    function render_select_plugin($task_id=NULL)
    {
    }

    /**
     * Creates the deliverable object (NOTE: not the target)
     */
    function handle_select_plugin($task_id)
    {
    }

    /**
     * Depending on deliverable status this will either render a way to
     * create the target or a link to the target
     *
     * There are two modes, 'task' and 'todo' for different renderings.
     */
    function render_deliverable($mode = 'task')
    {
    }

    /**
     * This will create the deliverable target
     *
     * At this time the mode selection has no effect.
     */
    function handle_deliverable($mode = 'task')
    {
    }
}

?>

Task micro-workflow

In addition to the regular workflows, all tasks within Midgard have a micro-workflow related to assigning it between people. This micro-workflow goes in the following way:

  • Project manager assigns tasks to resources
  • Resources can be local or remote (DBE) users
  • Resources can accept or decline task
    • Hours can be reported to task after acceptance
  • When task is finished resources can mark it as completed
    • Task's deliverables (document, SVN commit, ...) must be completed first
  • Project manager must approve the task before it is closed

When user assigns a task to herself the proposed phase is skipped and task is automatically accepted by the user, by same logic if user who is also manager of task marks it as completed the task is approved and closed automatically.

Getting Things Done

Getting Things Done is a popular task management methodology that focuses on storing all tasks, and making them easily filtrable based on the current working mode, or context. An important concept is elimination of "stuff":

Getting Things Done succeeds because it first addresses a critical barrier to completing the atomic tasks that we want to accomplish in a given day. That’s “stuff.” Amorphous, unactionable, flop-sweat-inducing stuff. David says:

Here’s how I define “stuff:” anything you have allowed into your psychological or physical world that doesn’t belong where it is, but for which you haven’t yet determined the desired outcome and the next action step. [pg. 17]

To follow the Getting Things Done model, the Midgard task manager must make addition and timing of new tasks easy. It also must enable marking tasks into specific contexts, and filtering them by those.

Digital Business Ecosystem

Midgard's task management is connected to the Digital Business Ecosystem. With DBE Midgard tasks can be replicated between business partners in a P2P network.

The DBE connection works transparently for the user of the Midgard task manager. she just assigns tasks to remote users (identified by a different icon in user listings), or receives tasks from them. The micro-workflow and handling of deliverables remains the same.

The actual DBE implementation is a Java ServENT (Server-Client) that monitors changes in tasks through Midgard-Java and pushes them to partners via the DBE network.

Synchronization

To support Getting Things Done, Midgard task management should try to reach beyond the web. Lots of the Contexts may be something that must be done away from the desktop, and these should be synchronizable to the smartphone, PDA or whatever.

The main synchronization protocol for mobile devices is SyncML. While a Horde SyncML implementation in PHP exists, it is lacking in client support. Midgard task manager, and other PIM applications should support SyncML through the Java-based Sync4J implementation instead.

In addition to SyncML, the task manager should seek to support subscribe-able vTODO output and possible related Microformats.

Note: According to Tantek from #microformats, the hCalendar microformat can be directly used for vTodo.

Misc

We need tasks that auto-close when all deliverables have been completed - Joins are tasks that have the steps to join as deliverables - Deliverable plugins call a task on_deliverable_completed() method

Idea: "skip step", which opens the next step but keeps current task open as well, steps need to be specifically marked as "skippable" in the workflow.

Idea: inserting user-written entries for process's activity log

Glossary

assignee
person that has been assigned to complete a task
deliverable
desired outcome of a task. e.g. a document written or decision made by assignee. Task may have multiple deliverables
process
an instance of a trail
role
abstraction of assignees based on business role. In Midgard terms, a midgard_group
step
one step in workflow, steps are prototypes of tasks, steps assignees are roles in stead of persons
task
any activity one needs to complete
trail
defines the workflow as a series of steps, trails are prototypes of processes

Related work

Back

Development

Copyright © 1999-2008 The Midgard Project. Open Content
Designed by Nemein, hosted by Anykey