INFS4201 Distributed Enterprise Computing Module 1: Workflow Systems - PowerPoint PPT Presentation

1 / 60
About This Presentation
Title:

INFS4201 Distributed Enterprise Computing Module 1: Workflow Systems

Description:

School of Information Technology and Electrical Engineering ... Forte Conductor. HP Changeengine. MQSeries Workflow. InConcert. ADEPT. METUFlow. METEOR ... – PowerPoint PPT presentation

Number of Views:50
Avg rating:3.0/5.0
Slides: 61
Provided by: ITEE
Category:

less

Transcript and Presenter's Notes

Title: INFS4201 Distributed Enterprise Computing Module 1: Workflow Systems


1
INFS4201Distributed Enterprise ComputingModule
1 Workflow Systems
  • Semester 2, 2002
  • School of Information Technology and Electrical
    Engineering

2
Module 1 Lectures
  • Overview of Workflow Systems
  • Workflow Modeling
  • Workflow Process Change
  • Workflow Management
  • Standards, Trends, Products

3
Scenario
  • Organization with functionally complex processes
    consisting of several distributed and
    heterogeneous information systems
  • Good candidate for deployment of workflows?
  • Impact of change on a successful setup?

ADEPT
Action Workflow System
METUFlow
MQSeries Workflow
CMI
WIDE
HP Changeengine
TRAMs
Exotica
Forte Conductor
METEOR
InConcert
4
Process Change
  • Business process change can arise due to three
    main reasons
  • Process Improvement, which involves performing
    the same business process with increased
    efficiency.
  • Process Innovation, which involves performing the
    business process in a radically different way
    Davenport 93. Business process reengineering
    would fall in this class of changes, since it is
    "a new conceptualization of the business process"
    Hammer 90.
  • Process Adaptation, which involves adapting the
    process to unforeseen change.

5
Reasons for Process Change
Improvement Innovation Adaptation
Level of change Incremental Radical Unknown
Starting Point Existing process Clean slate Existing process
Frequency of change One-time/ Continuous One-time One-time
Time required Short Long Short
Participation Bottom up Top down Varied
Scope Narrow, Within functions Broad, Cross-functional (Generally) Narrow
Risk Moderate High Moderate
Type of change Cultural Structural Unknown
Planned Planned Planned Not planned, Unforeseen
Effect of change Permanent Permanent Temporary/ Permanent
6
Scope of the Problem
  • Business process change will have to be
    propagated to underlying (workflow)
    implementations

Failure
System
Phase
Application
Semantic
ProposeDistributeRefine ...
Static
Enact
Dynamic
Production
Ad-hocCollaborative
Process
7
Dimensions of Change
  • Change characteristics of workflows
  • Dynamism
  • Adaptability
  • Flexibility

8
Dimensions of Change
  • Dynamism
  • ability of the workflow process to change when
    the business process evolves
  • Adaptability
  • Flexibility

Process Reengineering
Evolving Workflows
Dynamic Schema Change
Dealing with Active Instances
9
Dimensions of Change
  • Dynamism
  • Adaptability
  • ability of the workflow processes to react to
    exceptional circumstances
  • Flexibility

Exception Handling
Capturing Useful Exceptions
Dealing with Unknown Exceptions
10
Dimensions of Change
  • Dynamism
  • Adaptability
  • Flexibility
  • ability of the workflow process to execute on the
    basis of a loosely, or partially specified model,
    where the full specification of the model is made
    at runtime, and may be unique to each instance

Dynamic Instance Modification
Constraint Specification
Modeling the Flexible Workflow
11
Dynamic Workflows
  • ability of the workflow process to change when
    the business process evolves
  • How to define the model?
  • How to verify that the changes do not introduce
    any structural or semantic errors?
  • How to propagate the change to active workflow
    instances?

12
Methodology
  • Defining
  • Changes to the Process Model
  • Changes to the Workflow Model
  • Verification of the new model
  • Conforming
  • Instance Grouping
  • Compliance Graphs
  • Enacting
  • Architectural Implications
  • Temporal Implications
  • Organizational Implications

13
Immigration Process
14
Immigration Process Instance
Application
lt75
Review
Points
Rejected
for Points
Skill
gt75
Police
Verification
Receive
Receive
Class
Results
Application
Eligible
Medical
Family
Examination
Approve
Request
Clear
Passport
Receive
Review by
Sponsors
Review
Family Affairs
Disapprove
Application
Stamp
Rejected
Ineligible
Visa
Application
Rejected
Return
Passport
15
Defining the Change
  • Changes to the Process Model
  • Must be known
  • Must be verified (for semantic correctness)
  • Changes to the Workflow Model
  • Add new tasks
  • Delete existing tasks
  • Modify order of execution
  • Modify task properties
  • Verification of new Workflow Model

16
Modified Workflow
Application
lt75
Review
Points
Rejected
for Points
gt75
Police
English
Verification
Skill
Test
Receive
Result
Results
Receive
Class
Application
Fail
Pass
Medical
Examination
Approve
Request
Interview
Clear
Passport
Satisfied
Family
Application
Eligible
Reject
Disapprove
Stamp
Assess
Rejected
Visa
Ineligible
Application
Review by
Receive
Sponsors
Return
Rejected
Family Affairs
Review
Passport
17
Conforming to the change
  • Instance Grouping
  • Type
  • Compliance
  • Stage
  • Compliance graph generation
  • Compensation Tasks
  • Plug Point

18
Affected Instance
19
Compliance Graph
English
Review
Test
Points
Police
Plug Point
for Points
Verification
gt75
Skill
Receive
Result
Results
Receive
Class
Medical
Fail
Application
Pass
Examination
Request
Approve
Clear
Passport
Interview
Police
Medical
Verification
Examination
Instance initiated in old model
Not Redone
Disapprove
Satisfied
Stamp
Application
Receive
Visa
Assess
Rejected
Results
Reject
Clear
Return
Passport
Application
Rejected
Approve
Return Passport
with Letter of
Compensation Task
Request
Explanation
Passport
20
Enacting the change
  • Handling workflow execution during the transition
    period
  • Instances may follow old model
  • New instances will follow new model
  • Affected instances will follow compliance graphs

21
Challenges
  • Compliance criteria
  • Suspension of affected instances
  • Dealing with semantic objects
  • Suitability of the business process

22
Compliance Criteria
  • Containment Method
  • Structural containment of an instance sub graph
    in the new model
  • Equivalence Method
  • compliance can be found, even when strict
    structural containment cannot be established due
    to certain classes of equivalent structures

23
Equivalence Classes
  • Decomposition
  • Redundancy
  • Ordering
  • Deletion
  • Transformation
  • Property

24
Decomposition Class
25
Redundancy Class
26
Ordering Class
27
Deletion Class
28
Transformation Class
29
Property Class
30
Exercise 4
  • Design modifications for any (all) of the models
    you designed in exercise 2, and determine
    compliance graphs for at least two non-compliant
    instances

31
Adaptive Workflows
  • ability of the workflow processes to react to
    exceptional circumstances
  • Can exceptions be defined?
  • How to model exceptions?
  • How to detect, diagnose and resolve an exception?

32
Classes of Exceptions
  • Information Systems
  • random-event, error, political, system, total
    quality management, and human computer system
    perspective SM95
  • Workflow Systems
  • basic failures (system level), application
    failures, expected exceptions and unexpected
    exceptions EL95
  • Process level, Resource level, Infrastructure
    level HS98
  • Synchronous, Asynchronous CP99

33
Classes based on predictability
  • Embedded
  • Exceptions which are embedded within the process
    model become part of the core process and
    generally are not even considered as exceptions.
  • Separated
  • Exceptions which are implemented through
    exception rules and/or exception workflows
    constitute the set of useful exceptions for the
    process.
  • Unanticipated
  • The business process can not be completely
    captured through its core and exception processes
    because of the existence of unanticipated (or
    true) exceptions.

34
Example
  • Conference Management
  • Several participants conference organizers, the
    program committee, authors, publishers and
    sponsors
  • Block object represents complex activity

35
Embedded Exceptions
  • Possible Exceptions in Publication Block
  • Authors are unable to view the author kit
    attachments
  • The author sends the paper but does not fully
    comply with the formatting guidelines
  • The author does not send the paper at all, or
    after the deadline

Iteration omitted for simplicity
36
Embedded Exceptions
  • Exception Handling (business) Rules
  • Authors unable to view author kit attachments can
    download the documents from the publisher's web
    site.
  • Papers received by the publishers which fail to
    comply with prescribe formatting standards will
    be charged to the authors at a given rate
  • Papers not received within the deadline will not
    be published

37
Separated Exceptions
  • Exception Workflow
  • The instantiation of the exception workflow will
    (temporarily) suspend the corresponding workflow
    of the exception raising instance, the execution
    of which may, or may not resume later.
  • Creating an instance of this workflow would cause
    the conference workflow instance for that paper
    to be terminated.

The exception workflow of paper withdrawal in the
conference workflow.
38
Unanticipated Exceptions
  • Unanticipated exceptions are True exceptions
  • Similar to dynamic modification, except that all
    active instances will not be affected
  • Change will affect one or a few instances
  • Nature of exception will dictate if exception
    raising instance is to be modified or handled
    outside the system

39
Exception Handling Phases
  • Detection (Event)
  • Failure Conditions
  • Task level
  • Process level
  • Diagnosis (Condition)
  • Exception Rules
  • Control Flow
  • External
  • Resolution (Action)
  • Exception Workflow

Mechanism is required to manage the signalling
between the triggering objects and the WFMS The
workflow management system then has to search for
the given failure condition and find the
corresponding exception handling process The
invocation of exception handling process takes
place, which may require transfer of control to
the exception workflow, where required, changing
the node states of the triggering tasks in the
exception raising instance And finally resuming
the execution of the exception raising instance
40
Resuming Execution
Case nodestate (n, i) Active nodestate (n, i) Scheduled
A n is aborted and control never returns to i Control never returns to i
B Control returns to i and n is (re)activated Control returns to i and n is (re)scheduled
C Control returns to i, but execution is resumed at a different point Control returns to i, but execution is resumed at a different point
D Control is not diverted from n, and n executes in parallel with e Control is not diverted from n, and n executes in parallel with e
41
Exercise 5 (Hard)
  • Can you make the workflow processes for the
    various cases of resuming execution after
    exception handling?

Hint Triggering task (t) can be in
concurrent/sequential execution in the exception
raising instance
42
Flexible Workflows
  • ability of the workflow process to execute on the
    basis of a loosely specified model
  • How to define a flexible model?
  • What degree will keep a balance between
    flexibility and control?

43
Flexible Workflows
  • Motivation
  • It may not be desirable or even possible to
    define the entire process before execution
  • There are flexible business processes where a
    prescriptive model will compromise the process
    goals
  • Applications
  • Healthcare
  • Tertiary Education
  • Customer Relationship Management (CRM)

44
Achieving Flexibility
  • Traditional workflow technology applicable only
    on well structured and well defined processes
  • Achieving flexibility using traditional WF
    technology
  • Flexibility by definition
  • Flexibility by granularity
  • Approaches for extending traditional workflow
    functionality
  • Extended modelling structures
  • Flexible workflows

45
Pockets of Flexibility
  • Simple process modelling language as a foundation
  • Loosely specified models
  • Complex functional requirements through pockets
    of flexibility structures
  • Build and execute flexible pockets of workflows
    at runtime
  • Making the process of change part of the workflow
    process

46
Modelling the Pocket
  • A defined core process containing
  • Identifiable (pre-defined) workflow activities
    and control dependencies
  • Pockets of flexibility within the process,
    represented as a special workflow activity called
    the build activity, and consisting of
  • Set of workflow fragments, where a workflow
    fragment may consist of a single activity, or a
    sub-process
  • Set of rules or build constraints for
    concretizing the pocket with a valid composition
    of workflow fragments.

47
Example in Healthcare


Create

File



Examine

Receive
Merge


Choice

Patient
Begin
Patient

Retrieve

File



Receive

Make
End
BUILD


Payment
Diagnosis

Mammogram


Second
Ultra


Opinion
Sound
48
Example in Healthcare


Create
Build Activity

File



Examine

Recieve
Merge


Choice
Flexible Workflow Model

Patient
Begin
Patient

Retrieve

File



Recieve

Make
End


BUILD
Payment
Diagnosis
Pocket of Flexibility

Mamogram


Second
Ultra


Fragments
Opinion
Sound
Retrieve
File
1.
Receive
Examine
Begin
Merge
Choice
Patient
Patient
Create
File
Make
Receive
Ultra
End
Diagnosis
Payment
Sound
Retrieve
Instance Templates
File
2.
Receive
Examine
Merge
Choice
Begin
Patient
Patient
Create
File
Mammogram
Ultra
Sound
Receive
Make
Second
End
Payment
Diagnosis
Opinion
49
Instance Template
  • An instance template is an instance specific copy
    of the process model
  • Typically in systems that have little change
    support, the instance template would be an exact
    replica of the original process model
  • The pockets framework attempts to make the
    instance template a dynamic object which may be
    changed several times during the life of an
    instance
  • The definition of the instance template must be
    controlled

50
Challenges
  • How to model pockets of flexibility?
  • Defining constraints for allowable runtime
    building?
  • Engine capabilities for handling dynamic
    modifications of instances (templates) at
    runtime?
  • End user change modelling graphical or
    interactive?

51
Constraint Specification
  • Building may be constrained by several factors
    including
  • the data relating to that instance,
  • the stage of execution of the instance,
  • temporal constraints,
  • fragments available for building,
  • and the business rules of the particular
    application for which the template is being
    defined
  • These constraints are distinct from strong
    constraints.
  • Where as strong constraints will map to one and
    only one valid construct in the workflow model,
  • these weak or flexible constraints may map to
    several constructs
  • The manifestation of flexibility through build
    constraints is the key to providing configurable
    process models.

52
Constraint Types
  • Containment Constraints
  • The constraints belonging to the containment
    class identify conditions under which fragments
    can and cannot be contained in the resulting
    templates
  • For example, a fragment A cannot be included when
    a fragment B is included
  • Structural Constraints
  • The constraints belonging to the structural class
    impose restriction on how fragments can be
    composed in the templates
  • Fragment A and B must always be done in sequence

53
Exercise 6 (Hard)
  • Can you think of other containment and
    structural constraints

54
Unified Framework
  • Can we provide a framework that can support the
    combined methods for dynamism, adaptation and
    flexibility?
  • Concept of templates may hold the answer
  • Current research at UQ/DSTC targeted at above
  • Many open and interesting questions still
  • Interested honours students welcome to contact

55
Change Policies
  • Three dimensions of change (Dynamism,
    Adaptability and Flexibility) differentiated
    through Change Policies
  • Flush Instances are allowed to complete
  • Abort Instances are terminated before completion
  • Migrate Instances are switched to new model
  • Adapt Instances have to divert from the model
  • Build Instance execution defines the model

56
Scope of the Policies
  • Policy Model Affected Compliant
  • Changed? Instances Instances
  • Flush Y None -
  • Abort Y/N Some None
  • Migrate Y All Some
  • Adapt N Some Some
  • Build Y/N Some All

57
Unified Framework
Dimension Policy Description Mechanism
Dynamism Migrate (Flush, Abort) Represents a permanent change in the process, affecting many or all active instances May affect executed part and hence cause loss of work Compliance graphs
Adaptability Adapt Represents a deviation of one or more instances from the process model May affect executed part and hence cause loss of work Exception processes
Flexibility Build Represents a customization of an instance to specific requirements Does not affect executed part Build Constraints
58
Proposed Architecture
Process Changes
Definition Tool
Verification Engine
Activate
WFA
Process Definition
Version Tracker
Administration Monitoring Tools
Modification Analyser
Workflow Engine(s)
Archive
Version Store
Change Handler
Schedules
Events
Work list Handler and User Interface
Templates
Policy, Logs, Definitions
Workflow History
Done, Cannot Do
To Do Lists
Invoke
Tools and Applications
Workflow Clients
Workflow Repository
59
Suggested Reading
  • Shazia Sadiq (2000) Handling Dynamic Schema
    Change in Process Models. Proceedings of the 11th
    Australian Database Conference, Canberra,
    Australia. Jan 27 - Feb 02, 2000. IEEE Computer
    Society, 2000.
  • Shazia Sadiq, Wasim Sadiq, and Maria E. Orlowska.
    Pockets of Flexibility in Workflow Specification.
    20th International Conference on Conceptual
    Modelling (ER2001). Yokohama, Japan, 27-30
    November 2001.
  • INFS4201 Handout 2

60
Module 1
  • Workflow Change Management
  • Next Workflow Management Systems
Write a Comment
User Comments (0)
About PowerShow.com