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:

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.

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

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:

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:

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