Pumptheory.com Mark Aufflick OpenACS Workflow Mark Aufflick pumptheory.com.

pumptheory.comMark Aufflick

OpenACS Workflow

Mark Aufflick

pumptheory.com


This presentation

• Goal: Learn to use a workflow in a web application

• The OpenACS Workflow package

• Roles, Cases, Actions & States

• Defining a workflow

• Integrating a workflow with your app


A Brief History

• The original ACS Workflow package was designed using Petri Nets as the underlying formal model

• It’s design was very thorough, but the use of Petri Nets was overcomplicated and unnecessary in perhaps 95% of use cases

• In 2003 Lars Pind of Collaboraid didn’t use the existing workflow package because it was cumbersome and unfinished – even though he was the original author while working for ArsDigita!


The new Workflow

• An analysis of common use cases showed that all common business workflows can be modeled with a simple Finite State Machine

• The new workflow package is a modular development framework, and allows multiple workflow models to be used

• Initially only FSMs are supported


User Interface?

• Many workflow packages, including the original ACS Workflow, have funky UIs

• But – development is nearly always required

• So – the new workflow has been designed as a developer framework that allows the power of workflows to be easily incorporated into applications


Workflow Overview

• A workflow is a set of:– Roles– Actions– States– plus their relations

• A workflow is associated with an object type


Cases

• A workflow in action is a CASE

• A case revolves around a specific object

• A case holds information about:– Current state– Current assignments– Activity log


Roles

• From our publishing example, roles might be:– Author– Editor– Publisher

• Roles convey permission and responsibility

• Roles can be assigned by default and reassigned


Actions

• Which actions are available will depend on the current state

• Actions may change the state• Actions can have side effects• Allowed roles control who can perform what

actions• Assigned roles indicate who is responsible for

the action• A workflow has an initial action


States

• A workflow has a finite set of states

• From our bug tracker example:– Open– Resolved– Closed

• A case will always be in exactly one state

• States contain almost no information


Defining a workflow

• Start by drawing a diagram

• -> your states, actions and roles set spec { contract { pretty_name "Contract" package_key "finance-contracts" object_type “finance_contract“

roles { } states { } actions { } }

}


Defining a workflow: Rolesroles { submitter { pretty_name "Submitter" call_backs { workflow.Role_DefaultAssignees_CreationUser } } assignee { pretty_name “Assignee” callbacks { bug-tracker.ComponentMaintainer bug-tracker.ProjectMaintainer workflow.Role_PickList_CurrentAssignees workflow.Role_AssigneeSubquery_RegisteredUsers } }}


Defining a workflow: States submitted { pretty_name "Submitted“ hide_fields { date_approval date_settlement } } approved { pretty_name "Approved" hide_fields { date_settlement } }

declined { pretty_name "Declined" hide_fields { date_settlement } } settled { pretty_name "Settled" } discarded { pretty_name "Discarded" }


Defining a workflow: Actions (1)submit { pretty_name "Submit" pretty_past_tense "Submitted" new_state "submitted" initial_action_p t}comment { pretty_name "Comment" pretty_past_tense "Commented" allowed_roles { submitter } priviliges { read write } always_enabled_p t}


Defining a workflow: Actions (2)decline { pretty_name "Decline" pretty_past_tense "Declined" assigned_role "submitter" assigned_states { submitted } new_state "declined" privileges { write } edit_fields { date_approval }}approve { pretty_name "Approve" pretty_past_tense "Approved" assigned_role "submitter" assigned_states { submitted } new_state "approved" privileges { write } edit_fields { date_approval }}


Integrating With Your App's API

• Creating new objects– workflow::case::new

• Fetching data– workflow::case::get

• Editing objects– workflow::case::action::execute

• see packages/bug-tracker/tcl/bug-procs.tcl


Integrating with your App’s UI

• Bug Tracker demo…• Use ad_form to build the form fields• Workflow will give you:

– Action buttons (workflow::case::get_available_actions)

– Role assignment (workflow::case::role::add_assignee_widgets )

– Case log ( workflow::case::get_activity_html )

• See packages/bug-tracker/www/bug.tcl


Integrating with your app’s queries

• For complex view-only listings, stats etc.

• Join with:– workflow_cases– workflow_fsm_states – And others…

• See the bug-tracker index-postgresql.xql for an example


Service Contracts and Callback goodness

• What is a callback good for?– Notifications– Other side effects

• What is a service contract?– ACS Service contract allows packages to define and register

implementation of interfaces– ACS Service contract provides mean to dispatch method

calls on an interface implementation. – Interface Discovery is available programmatically– The Service Contract interface specification was inspired by

WDSL, the interface specfication for web services.


Package development details

• APM TCL callbacks:– after-install

(workflow::fsm::new_from_spec)– before-uninstall ( workflow::delete )– before-upgrade– after-instantiate ( workflow::fsm::clone )– before-uninstantiate( workflow::delete )


References

• All references, slides and materials will be posted on the internet at:

http://pumptheory.com/collaboration/open-acs/lectures/

• OpenACS Workflow documentation• http://www.collaboraid.biz/developer/workflow-spec

Pumptheory.com Mark Aufflick OpenACS Workflow Mark Aufflick pumptheory.com.

Documents