The ]po[ Workflow Introduction Frank Bergmann, 2006-11-15

1
The po Workflow Introduction Frank Bergmann,
2006-11-15
This guide contains po workflow overview
information for developers with experience with
PostgreSQL and the OpenACS toolkit.
Draft Draft
2
Scope, Audience Purpose

• These slides provide background material talk on
  project-open workflows.
• We assume that the reader is familiar with basic
  concepts and the database structure of po (no
  TCL knowledge necessary)
• For developer documentation please see
• http//www.project-open.org/product/modules/workfl
  ow/
• http//project-open.blogger.com/ Dynamic WF with
  po

3
Components of a Workflow

1. The Petri-NetMany people think this is the main
   component, but its not.
2. The ObjectEvery WF in po is associated with
   exactly one object.
3. Assignment LogicThis is usually a set of PL/SQL
   procedures that determine who should perform each
   action in the WF.
4. A number of ActionsThese are usually calls to
   im_object__set_status PL/SQL procedures that
   modify the objects status depending on the WF
   progress
5. GUI PanelsThese panels are TCL forms that allow
   a user to add information to an object and/or to
   take special actions implemented in TCL code.

4
Simple Approval Workflow
Workflow
Assignment
Actions
GUI Panels
enable statusrejected fire statusrequested
Assign to owner of the underlying object
Modify
NotOK
Assign to the supervisor of the objects owner

Confirm
OK
enable statusconfirmed
Automatic transitions, no assignment necessary
Confirmed
Rejected
5
Simple Approval Workflow

• The example in the previous page shows a simple
  approval workflow. This WF is used for example in
  po V3.4 for approval of vacation requests
  (Absences).

6
Object Type -gt Workflow Mapping

• When creating a new object, po allows you to
  define a workflow per object type.
• po looks up the workflow key in the object
  types category in the im_categories.aux_string1
  
• Currently, the following objects are WF-enabled
• im_project,
• im_user_absence,
• im_expense_bundle and
• im_timesheet_conf_obj
• The screenshot at the right show the SaaS
  project type, which is associated with a
  saas_project_workflow_wf.

7
Showing the WF-Status of a Project

• In po V3.4 there are two additional components
  associated with every WF-enabled object
• The Workflow Graph shows the current status of
  the WF and
• The Workflow Journal shows the history of all
  WF decisions.

8
Timed Transitions

• What is a Timed Transition?
• A Timed transitions automatically fired at its
  trigger_time.
• A Timed Transition is different from a hold
  timeout A timed transition fires, while the
  hold timeout cancels the transition
• How can I set the Trigger Time?
• Trigger_time is set by the result of the Time
  callback. This callback can be specified in the
  Time field of the WfActionPage
• The time callback is called when the transition
  is enabled.

9
Request For Change Example
10
"RFC" Example Case

• For the rest of this introduction we will assume
  the following a "Request for Change" (RFC)
  example.
• The IT-department of a large corporation wants to
  consolidate its help-desk operations
• All requests from the organization's users
  ("Requests for Change", RFC) are captured using a
  web based application
• Each RFC consists of a number of fields that
  together specify the customer's need
• The RFC is processed in a strucured way using a
  Workflow.
• It is likely that the workflow will change in the
  future to accomodate organizational and process
  changes. Changes should configurable.

11
RFC - Form Dynamic Fields

• An important number of form fields have been
  identified during the analysis phase
• Fields may or may not appear, depending on the
  type of RFC
• It is possible that the variables variables in
  the form will change during the course of the
  project. Changes should be easy to introduce,
  preferably configurable by the application
  administrators from the customer's side.

ScreenshotRFC-Form
12
RFC - Roles

• EmployeeAn employee beneficient of the RFC - the
  guy who needs something changed
• DistributorA member of the IT helpdesk to
  complete the RFC and to judge technical
  viablility
• ApproverThe Employee's boss or somebody with
  suitable budget responsability to confirm the
  employee's RFC.

13
How to Plan your Workflow
14
"Transitions" "Places"

• Transitions in general represent decisions or
  actions by a particular user group.
• You should normally use different transitions if
  different user groups are involved (i.e.
  Employee, IT-Department Employee's Boss).
  Otherwise only use a single transition.
• It's good practice to reduce the number of
  transitions to a minimum.
• Places are located before and after each
  transition. They are normally created
  automatically when creating a new transition.

15
"Arcs", "Guards", "Attributes" User Decisions

• "Arcs" connect Places with Transitions.
• "Guards" are boolean conditions on Arcs. An Arc
  only "becomes active" (passes on a token) if it's
  Guard is "true". Two or more Guards behave like
  an IF-THEN-ELSE.
• Web interface actions at the can not influence
  Guards, however.
• Instead, Web actions modifiy the values of WF
  variables ("Attributes"). The boolean Guard
  conditions can use these variables to determine
  their IF-THEN-ELSE behaviour.

16
"Arcs", "Guards", "Attributes" User Decisions

• Guards are not directly connected to the Web
  interface. A Guard
• A user action (pressing a button) can not
  influence a Guard directly.
• Instead, Web interface actions modify
  "Attributes" (the workflow's variables). These
  Attributes in turn can influence the behaviour of
  Guards.

17
Designing an IF-THEN-ELSE WF Decision/Branching/..
.

• Two type of standard Guards
• Guard that checks a variable for a particular
  value
• "ELSE"-Guard, that becomes true if the other
  guards haven't become true.
• - Plus User-Written Guards
• The SysAdmin can write his own guards as PlPg/SQL
  procedures.

18
Implementing a Two-Way Decision

• We usually implement a two-way (IF-ELSE) decision
  using a boolean Attribute
• One branch is followed if the attribute is
  "true". We select a wf_callback__guard_attribute_t
  rue" guard and specify the attribute name in the
  "Optional Argument" field.
• The ELSE condition of the other branch is
  implemented by choosing the "No other guards were
  satisfied" condition.
• It is important that exactly one Guard becomes
  true
• The token would disappear (gets "swallowed")

19
Implementing a Two-Way Decision

• Choose a reasonable Attribute name. For example
  "Cancel RFC". Take into account that this
  attribute is global to the entire WF, and that
  you may reuse the Attribute in other transitions
  for a similar purpose.

20
Avoiding Multiple Tokens and "Swallowed" Tokens

• Make sure that there is exactly one Guard active
  on the database Pl/SQL level
• You frequently make errors on the GUI level
• There errors are _extremely_ difficult to debug,
  because WF is difficult to debug
• Other parts of the GUI may depend on the
  assumption that there is only one Token in the
  WF. These GUI elements may crash under a
  duplicated Token condition. However, you won't
  understand (easily) that this was the condition
  of the crash.

21
WF User Decisions

• Transitions frequently involve decisions that
  lead to a kind of behaviour, controlling the flow
  in the Workflow
• In order to

22
Frank Bergmann frank.bergmann_at_project-open.com www
.project-open.com