SWAMP Index Design
SWAMP
* Home
* Documentation
* License
* Demo Server
* Wiki
* Screenshots
* F A Q
* Downloads
* Contact
* Credits

SWAMP is supported by:
SourceForge.net Logo
and
Novell

Overview of the SWAMP architecture

The SWAMP workflow model

A workflow is quite similar to the world. There are a lot of villages, connected to each other by streets. Think of a craftsman on a walk. He was born in one village and on some day he starts on a walk to the world. Probably and hopefully he will find something to do in every village and after he finished the job he continues his way along one of the ways to the next village. The way he takes may depend on the result of the job he did in the last village or on other events.

Thats quite similar to how workflows are processed in SWAMP: In SWAMP the workflow's state engine acts as the craftsman, the villages are nodes. Roads that connect villages are edges in SWAMP that connect nodes. And finally, the jobs are similar to tasks in SWAMP.

A workflow is a compound object consisting of Nodes and Edges, which in turn are compound objects. The workflow definitions are read in from XML files, and a workflow template object is created for each workflow bundle. When a new workflow instance is requested , the template object is responsible for the creation of the workflow object. The workflow will run based on the template that it was created from. When a new version of a workflow-type was created, the running workflow instances are not affected. Only new workflow instances will be based on the new workflow definition. This mechanism assures that running workflows will not break on updates of the workflow definition.

A workflow has the following graph-like structure:

Each workflow has one or more datasets connected to it where it stores values that are needed for the workflow. These datasets can also be shared across workflow instances, to be able to create dependencies between different workflows.

Actions and Tasks

Whenever a node is entered, its included actions are triggered. Actions represent anything that has to be done, in any subsystem. Once an action is triggered, a task object is created that consists of:

  • a reference to the action

  • an (empty or pre-set) result set that fits the action

  • The user/group to whom this task is assigned to

An action is the template for a task, which means that a task is a concrete instance of an action with a person/group assigned to it. Another possibility are system-tasks that are automatically done by the system, such as sending notifications, changing values of the dataset, starting subworkflows and so on. When a Task is done, it sends out an event, and thus drives the workflow on into the path where there is a condition waiting for that event.

Events and Conditions

A node stays active until one or more of the edges leading out of it can be followed. Which means that the edge's condition must be met. Conditions are constructed out of the boolean operators AND, OR and NOT and the following atomic conditions: Either use only empty conditions to leave a node or only non-empty ones, mixing both doesn't make any sense at all. The empty conditions are used for modelling convenience.

  • EventCondition: waits until the workflow receives a specific event.

  • DataCondition: waits for a specific databit to be set to a certain value. Dataconditions can use regexps to evaluate the content of a databit, or just wait for the change of a databit-value.

  • SubsfinishedCondition: waits for attached subworkflows to be finished.

  • Empty: edges that should always be followed immediately are realized as an EventCondition with the special event "none".

If several different edges with compound conditions leave a node, they are followed (i.e. the node is left) according to these precedence rules:

  • Empty edges are followed immediately. If there are more than one, all of them are followed, so that the workflow can split its thread and afterwards has more than one active node at a time.

  • On entering a node, all Conditions are checked. If this leads to (simple or compound) conditions of one ore more edges to resolve to true, these edges are followed.

  • If the node is still active after 1. and 2., incoming events and data changes are processed in the order they occur. As soon as one or more simple or compound conditions resolve to true, the respective edge(s) are followed and the node is left and won't receive any further events.

When a node is left, but still has active tasks that were not yet done, these tasks get cancelled.

Data

Data is organized in datasets, which in turn can contain other datasets and databits. A databit is a single key-value item with a datatype assigned to it to be able to verify user input. Available datatypes so far are:

  • boolean (true/false, rendered by a checkbox in webSWAMP)

  • number (integer)

  • string (a text, rendered by a dynamically growing input field in webSWAMP)

  • text (a text, rendered by text field of static size)

  • person (comma-seperated list of loginnames and/or mail adresses)

  • date (a date string in the format: yyyy-mm-dd)

  • datetime (a date string in the format: yyyy-MM-dd, HH:mm)

  • bugzilla (a id referencing bug in a bugzilla installation)

  • enum (a list of possible values, rendered by a dropdown box in webSWAMP)

  • multienum (a list of more than one possible values, rendered by a multi-select box in webSWAMP)

  • comment (a comment field which will automatically create the possibility to post replies to it)

Users, Groups and Roles

The security concept of SWAMP is based on two role-systems. Roles can be stored in the database backend and roles can be defined in the workflow definition files. The workflow definition can also reference roles from the database. The systemwide "admin" role is defined as a group in the database. The admins are superusers of the SWAMP server and are allowed to do everything such as clearing the workflow cache, reloading workflow definitions and administrative tasks. This system is based on the database tables dbUsers, dbGroups, dbPermissions, dbUsers_Groups and dbGroups_Permissions which connect the permissions to certain groups and add users to groups.

The second system takes care of permissions inside workflows. That means who is allowed to do a special task, start or cancel workflows etc. These roles are initially defined in the workflow template, and may be overwritten in each single workflow instance. Standard roles are:

  • "user": is allowed to see a workflow and its content in the GUI

  • "owner": is the person who started this workflow-instance and has all rights for this instance.

  • "admin": is the admin of that workflow-template / -instance and has all rights for this instance. He is able to perform "admin"-action on that workflow, e.g. restarting, de-/activate certain nodes manually

  • "starter": is allowed to start workflows of that type

additional roles may be defined in each workflow template to be available in the workflow.


Valid CSS! Valid XHTML 1.0!