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

Mark Aufflick 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

pumptheory.com Mark Aufflick 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!

pumptheory.com Mark Aufflick 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

pumptheory.com Mark Aufflick 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

pumptheory.com Mark Aufflick Workflow Overview A workflow is a set of: –Roles –Actions –States –plus their relations A workflow is associated with an object type

pumptheory.com Mark Aufflick 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

pumptheory.com Mark Aufflick Roles From our publishing example, roles might be: –Author –Editor –Publisher Roles convey permission and responsibility Roles can be assigned by default and reassigned

pumptheory.com Mark Aufflick 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

pumptheory.com Mark Aufflick 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

pumptheory.com Mark Aufflick 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 { } }

pumptheory.com Mark Aufflick Defining a workflow: Roles roles { 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 }

pumptheory.com Mark Aufflick 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" }

pumptheory.com Mark Aufflick 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 }

pumptheory.com Mark Aufflick 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 } }

pumptheory.com Mark Aufflick 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

pumptheory.com Mark Aufflick 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

pumptheory.com Mark Aufflick 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

pumptheory.com Mark Aufflick 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.

pumptheory.com Mark Aufflick 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 )

pumptheory.com Mark Aufflick References All references, slides and materials will be posted on the internet at: OpenACS Workflow documentation