Process Definition for Adaptable Workflow Management Systems
ABSTRACT
A conceptual framework of workflow is proposed, in which a workflow is considered interplay of policy, process and practice. This process adheres to certain policies and employs certain practices. The level of applicability of the policies and practices essentially determines the scope of the workflow. That is, a workflow may satisfy a given purpose for an office, several offices within an organization, the entire organization, or several collaborating organizations. A process can in turn consist of one or more subprocesses, each subprocess is assigned to a responsible actor who is at a certain location and has a certain authority. The location attribute raises the need for routing a work item, and the authority attribute assigns the responsible actor a role to the work item. In this context, a worker's role along with associated responsibility and authority is important, but not the worker's position in the organizational hierarchy. As appropriate, a subprocess can be delegated further to lower echelon. This characteristic of recursion is key to representing an organization hierarchy of any depth.
The framework also describes the generic processing rules for a subprocess. Each subprocess comprises a start date, a due date, a completion date and a State Event Transition Table. An external event, that may occur within a process or come from another process, causes a responsible actor to act on an object. The object implicitly or explicitly defines certain activities and has a measurable goal. The progress of an activity will generate one or more events. An event such as "work-completed" will cause the responsible actor to sign off and this event may cause another responsible actor within the same process to perform other activities. An event can also trigger an on-hold activity to resume processing.
Events are globally recognized by all subprocesses but states are only local to a subprocess. An activity is a piece of work that cannot be delegated or divided any further. It has one or more entry- and exit-conditions, and possibly some applications to be invoked automatically. At any moment an activity will have a status such as created, in process, suspended or finished, which should not be confused with a state. Not all activities are prescheduled, some activities may be created ad hoc as a worklist.
Based on the proposed framework and a basic process definition metamodel developed by WfMC, the author developed a tag set and the DTDs for generic workflow, State Event Transition Table, activity definition, and worklist.
For ease of update and collaboration among different software components, all workflow related documents, system control data and software tools are not hard-coded in the process definition but placed on a server and can be referenced with URLs.
For any particular business process the DTDs can be easily instantiated into a process definition instance with a DTD-directed editor. This affords the adaptability for a workflow management system to respond to organizational changes and to work with any type of business environment.
Table of Contents
A workflow management system (WFMS) is mainly used for business processes that can be effectively and efficiently specified in detail. As business process reengineering becomes a norm for competitiveness, any future WFMS must be able to respond to organizational changes on an ongoing basis. Also, it must work with any type of business environment. These abilities are called "adaptability." From the supervisor's point of view, workflow management must be able to easily coordinate various business functions, reschedule and reassign the worker's work contents, change the workflow of a business and use data and software from different sources. From the worker's point of view, workflow management must be able to schedule tasks to perform in a timely fashion.
The WfMC Workflow Reference Model (WfMC, 1995, January) illustrates a workflow architecture that identifies the major components and interfaces of a generic workflow application structure. The major components are workflow enactment service, process definition tools, workflow client applications, invoked applications, and administration and monitoring tools. As much as possible, the details of the individual interfaces (APIs and interchange formats) have been developed as a common core set using additional parameters as necessary to cope with individual requirements of particular interfaces. This enables products to interoperate at a variety of levels.
Hagenberg (1995) developed a prototype for the enactment of publishing processes using a client/server architecture, i.e. the administration part is a client of the workflow engine and the workflow engine alone is a process running on the server. Since the prototype was focused on a specific process, adaptability was not addressed.
Vivtek (2001) is working on a project, called wftk, that will provide an open-source alternative to the 40-odd proprietary workflow systems available on the commercial market. The eXtensible Markup Language (XML) is used for definition of process classes and for storage of process values for active processes. A Document Type Definition (DTD) for process classes is one of the early deliverables for the project. As far as the DTD and adaptability are concerned, in this author's opinion, there still is room for improvement.
1. A Conceptual Framework of Workflow
In this paper, a conceptual framework of workflow is proposed as in Figure 1, in which a workflow is considered interplay of policy, process and practice. Taking the insurance claim processing as an example, a workflow comes into being for that purpose and starts a process. The process adheres to certain policies (e.g. objectives, rules and regulations) and employs certain practices (e.g. calendar of events, standard operating procedures, forms, database, software tools). The level of applicability of the policies and practices essentially determines the scope of the workflow. That is, a workflow may satisfy a given purpose for an office, several offices within an organization, the entire organization, or several collaborating organizations.
A process can in turn consist of one or more subprocesses (e.g. a claim adjuster's field inspection). Each subprocess is assigned to a responsible actor (e.g. the claim adjuster) who is at a certain location (e.g. a computer terminal in the claim adjusters office) and has a certain authority (e.g. the claim adjuster can negotiate with an auto repair shop and approve a repair order within a certain dollar amount). The location attribute raises the need for routing a work item, and the authority attribute assigns the responsible actor a role (e.g. an authority-responsibility pair) to the work item. In this context, a worker's role along with associated responsibility and authority is important, but not the worker's position in the organizational hierarchy.
Figure 2 describes the generic processing rules for a subprocess. An external event (e.g. submission of a damage claim), that may occur within a process or come from another process, causes a responsible actor (e.g. a Claim Department clerk) to act on an object (e.g. the claim form). The object implicitly or explicitly defines certain activities (e.g. review the policy of the insured and inspect the damage) and has a measurable goal (e.g. the arrival of a claim form signals that a customer's request must be handled in a given period of time). The responsible actor then act on it, and the progress of the activity will generate one or more events (e.g. the claim processing is on hold for the claim adjuster's report). The measurable goal carries a status and certain status will trigger an event. An event such as "work-completed" will cause the responsible actor to sign off and this event may cause another responsible actor within the same process to perform other activities. An event (e.g. the field report has arrived) can also trigger an on-hold activity to resume processing.
2. Process Definition Metamodel
A process definition normally comprises a number of discrete activity steps, with associated computer operations and human rules governing the progression of the process. The process definition may be expressed in textual or graphical form or in a formal language notation. At definition time, the process-related roles for all activities of the process are defined. At execution time, each activity instance must be assigned to potential workflow participants. (Rupietta, 1997)
WfMC (1995, January 19) developed a basic process definition metamodel (see Figure 3) that identifies a basic set of object types and their relationships:
-
Workflow type definition such as process name, version number, process start and termination conditions, and security, audit or other control data
-
Activity such as activity name, activity type, pre- and post-activity conditions, and other scheduling constraints
-
Transition conditions such as flow or execution conditions
-
Workflow relevant data such as data name, data path and data types
-
Invoked application such as generic type or name, execution parameters and location or access path
3. The Tag Set and DTDs for Process Definition
Based on the conceptual framework of workflow and the process definition meta-model, this author developed a set of tags and DTDs for generic process definition. Each tag (see Table 1) is given a name and a description, thus providing a common ground for data exchange.
Table 1 Tags for Process Definition
activity
An activity is associated with an identifier that can be recognized by
the entire workflow management system. The identifier links to a
unique activity definition.
activityDef
An activity definition is associated with an activity through an
identifier. It specifies the entry conditions and exit conditions for
the activity. It also maintains the status of the ac-tivity (e.g.
created, inProcess, suspended or finished) that can be referenced by
the event handler. The procedures to be executed are stored on a
server that can be activated by the event handler with a unique URL.
External applications that may be invoked are also specified.
actor
A person who is responsible for a process or a subprocess. Each
actor is a (name, author-ity, responsibility)-entry that is stored
on a server on the Web with a unique URL. The entry is assigned in
advance and can changed ad hoc by his supervisor
completionDate
The completion date of a subprocess. The date is in YYYYMMDD format.
Each date is stored on a server on the Web with a unique URL and can
be referenced or updated by an application program.
currentState
The current state of a subprocess. Each state is associated with an
identifier that can be recognized by the subprocess.
dueDate
The due date of a subprocess. The date is in YYYYMMDD format. Each
date is stored on a server on the Web with a unique URL and can be
referenced or updated by an appli-cation program.
event
An event is associated with an identifier that can be recognized by
the entire workflow management system.
eventCalendar
The calendar of events is a document stored on a server. It can be
referenced by the workflow engine and other system software.
form
This is a directory for the standard forms stored on a server. It
can be referenced by the workers with its URL.
invokedApplication
An external application is declared as an external entity in XML.
The way to invoke it is declared in a NOTATION. This information is
stored on a server and can be referenced by the workflow engine with
a unique URL.
nextState
The next state of a subprocess. Each state is associated with an
identifier that can be rec-ognized by the subprocess.
objectives
This is a document stored on a server and can be browsed by the
workers with a unique URL.
policy
The policy consists of objectives as well as rules and regulations.
practice
The practice covers calendar of events, standard operating procedures,
standard forms, software tools and workflow relevant data.
process
A business process consists of an actor and at least one subprocess.
rulesAndRegulations
These are documents stored on a server and can be browsed by the
workers with a unique URL, respectively.
SETT
An instance of a State Event Transition Table that is stored on a
server on the Web with a unique URL and can be referenced or updated
by the event handler.
SoftwareTool
This is a directory for the software tools stored on a server. It can
be referenced by the workers with its URL.
SOP
This is a directory for the software tools stored on a server. It can
be referenced by the workers with its URL.
startDate
The start date of a subprocess. The date is in YYYYMMDD format. Each
date is stored on a server on the Web with a unique URL and can be
referenced or updated by an appli-cation program.
stateEventTransitionTable
A State Event Transition Table contains one or several (currentState,
event, activity, nextState)-entries. Each subprocess is associated
with a State Event Transition Table.
subprocess
A subprocess consists of an actor, a start date, a due date, a
completion date and a State Event Transition Table. It may in turn
delegate to one or more subprocesses instead of a State Event
Transition Table. In this case, all the delegated subprocesses must
observe the same start date, due date and completion date. The actor
has the ultimate responsibil-ity for all the subprocesses.
workflow
A workflow involves policy, practice and business process.
workflowRelevantData
The workflow relevant data are documents stored on a server. They can
be referenced by the workflow engine and other system software.
work_item
A work item consists of an activity identifier and a link to the
activity. These are stored on a server and can be referenced by the
worklist handler.
worklist
A worklist consists of one or more work items.
Table 2 shows a workflow DTD in which each line is assigned a line number to facilitate reference.
Table 2 Workflow DTD [1] <?xml version="1.0" ?> [2] <!-- workflow.dtd --> [3] [4] <!ELEMENT workflow (policy, practice, process)> [5] <ATTLIST xmls:xlink CDATA #FIXED "http://www.w3.org/1999/xlink"> [6] <!ELEMENT policy (objectives, rulesAndRegulations)> [7] [8] <!ELEMENT objectives EMPTY> [9] <!ATTLIST objectives [10] xlink:type (simple) #FIXED "simple" [11] xlink:href CDATA #REQUIRED [12] xlink:actuate (auto|user) "user" [13] xlink:title CDATA #IMPLIED> <!-- Quality Statement --> [14] [15] <!ELEMENT rulesAndRegulations EMPTY> [16] <!ATTLIST rulesAndRegulations [17] xlink:type (simple) #FIXED "simple" [18] xlink:href CDATA #REQUIRED [19] xlink:actuate (auto|user) "user" [20] xlink:title CDATA #IMPLIED> <!-- Rules & Regulations --> [21] [22] <!ELEMENT practice (eventCalendar,SOP,form,SoftwareTool, workflowRelevantData)> [23] [24] <!ELEMENT eventCalendar EMPTY> [25] <!ATTLIST eventCalendar [26] xlink:type (simple) #FIXED "simple" [27] xlink:href CDATA #REQUIRED [28] xlink:actuate (auto|user) "auto" [29] xlink:title CDATA #IMPLIED> <!-- Calendar of Events --> [30] [31] <!ELEMENT SOP EMPTY> [32] <!ATTLIST SOP [33] xlink:type (simple) #FIXED "simple" [34] xlink:href CDATA #REQUIRED [35] xlink:actuate (auto|user) "user" [36] xlink:title CDATA #IMPLIED> <!-- SOP Directory --> [37] [38] <!ELEMENT form EMPTY> [39] <!ATTLIST form [40] xlink:type (simple) #FIXED "simple" [41] xlink:href CDATA #REQUIRED [42] xlink:actuate (auto|user) "user" [43] xlink:title CDATA #IMPLIED> <!-- Forms Directory --> [44] [45] <!ELEMENT SoftwareTool EMPTY> [46] <!ATTLIST SoftwareTool [47] xlink:type (simple) #FIXED "simple" [48] xlink:href CDATA #REQUIRED [49] xlink:actuate (auto|user) "user" [50] xlink:title CDATA #IMPLIED> <!-- Software Tools Directory --> [51] [52] <!ELEMENT workflowRelevantData EMPTY> [53] <!ATTLIST workflowRelevantData [54] xlink:type (simple) #FIXED "simple" [55] xlink:href CDATA #REQUIRED [56] xlink:actuate (auto|user) "auto" [57] xlink:title CDATA #IMPLIED> <!-- Workflow Relevant Data --> [58] [59] <!ELEMENT process (actor, subprocess+)> [60] [61] <!ELEMENT actor (#PCDATA)> [62] <!ATTLIST actor [63] location CDATA #REQUIRED [64] xlink:type (simple) #FIXED "simple" [65] xlink:href CDATA #REQUIRED [66] xlink:actuate (auto|user) "user" [67] xlink:title CDATA #IMPLIED> <!-- Authority & Responsibility --> [68] [69] <!ELEMENT subprocess (actor,startDate,dueDate,completionDate, (SETT|subprocess+))> [70] [71] <!ELEMENT startDate EMPTY> [72] <!ATTLIST startDate [73] xlink:type (simple) #FIXED "simple" [74] xlink:href CDATA #REQUIRED [75] xlink:actuate (auto|user) "auto" [76] xlink:title CDATA #IMPLIED> <!-- Start date in YYYYMMDD --> [77] [78] <!ELEMENT dueDate EMPTY> [79] <!ATTLIST dueDate [80] xlink:type (simple) #FIXED "simple" [81] xlink:href CDATA #REQUIRED [82] xlink:actuate (auto|user) "auto" [83] xlink:title CDATA #IMPLIED> <!-- Due date in YYYYMMDD --> [84] [85] <!ELEMENT completionDate EMPTY> [86] <!ATTLIST completionDate [87] xlink:type (simple) #FIXED "simple" [88] xlink:href CDATA #REQUIRED [89] xlink:actuate (auto|user) "auto" [90] xlink:title CDATA #IMPLIED> <!-- Completion date in YYYYMMDD --> [91] [92] <!ELEMENT SETT EMPTY> [93] <!ATTLIST SETT [94] xlink:type (simple) #FIXED "simple" [95] xlink:href CDATA #REQUIRED [96] xlink:actuate (auto|user) "auto" [97] xlink:title CDATA #IMPLIED> <!-- State Event Transition Table --> [98] [99] <!-- End of workflow.dtd -->
The workflow DTD in Table 2 is explained in segments. At the top level, the workflow DTD states that a workflow comprises policy, practice and process (line 4).
The policy comprises the objectives as well as rules and regulations of the workflow (line 6-20). These are documents placed on a server and each can be referenced from anywhere on the network with a Uniform Resource Locator (URL). The URLs provide easy integration of document management because the workflow engine just needs to keep track of the URLs of the documents.
The practice comprises calendar of events, standard operating procedures, standard forms, software tools, and workflow relevant data (line 22-57). Again, these are either documents or catalogs placed on a server and each can be referenced with a URL.
The process comprises an actor and any number of subprocesses (line 59). The actor of a process is the head of the organization or an organization unit depending on the scope of the workflow (line 61-67). An actor is referred to by name and location (e.g. e-mail address), and is assigned authority and responsibility. The authority and responsibility are stated in a document that is placed on a server and can be referenced with a URL. Technically, authority is reflected by access rights while responsibility is reflected by subprocesses to be performed.
Each subprocess comprises an actor, a start date, a due date, a completion date and a State Event Transition Table (line 69-97). As appropriate, a subprocess can be delegated further to lower echelon. This characteristic of recursion is key to representing an organization hierarchy of any depth. For ease of update and collaboration among different software components, the start date, due date, completion date and State Event Transition Table are not hard-coded in the process definition but placed on a server and can be referenced with URLs.
A State Event Transition Table to a WFMS is like a roadmap to a driver, and is a key mechanism to make a data-centric WFMS. Using XML the structure of a State Event Transition Table is a DTD as shown in Table 3.
Table 3 State Event Transition Table DTD
<?xml version="1.0" ?>
<!-- State Event Transition Table SETT.dtd -->
<!ELEMENT stateEventTransitionTable (currentState,event,activity,
nextState)+>
<!ELEMENT currentState EMPTY>
<!ATTLIST currentState
id CDATA #REQUIRED>
<!ELEMENT event EMPTY>
<!ATTLIST event
id CDATA #REQUIRED>
<!ELEMENT activity EMPTY>
<!ATTLIST activity
id CDATA #REQUIRED>
<!ELEMENT nextState EMPTY>
<!ATTLIST nextState
id CDATA #REQUIRED>
<!-- End of State Event Transition Table -->
This DTD states that a State Event Transition Table consists of 4-tuple entries. Each entry comprises a current state, an event, an activity to be activated when the event occurred in the current state, and the next state to move on after the activity is completed. Note that the calendar of events mentioned before is a special kind of State Event Transition Table in which the current state of each entry is set to "Idle", the event is time-based, and the next state is again set to "Idle". Also note that events are globally recognized by all subprocesses but states are only local to a subprocess.
An activity is a piece of work that cannot be delegated or divided any further. It has one or more preconditions (i.e. entry conditions) and postconditions (i.e. exit conditions), and possibly some applications to be invoked with parameters automatically. At any moment an activity will have a status such as created, in process, suspended or finished, which should not be confused with a state. Using XML the structure of an activity is a DTD as shown in Table 4.
Table 4 Activity Definition DTD
<?xml version="1.0" ?>
<!-- Activity Definition ActivityDef.dtd -->
<!ELEMENT activityDef (id,pre_condition+,post_condition+,
invokedApplication*)>
<!ATTLIST activityDef
status (created | inProcess | suspended | finished) "created"
xmls:xlink CDATA #FIXED "http://www.w3.org/1999/xlink">
xlink:type (simple) #FIXED "simple"
xlink:href CDATA #REQUIRED
xlink:actuate (auto|user) "auto"
xlink:title CDATA #IMPLIED> <!-- Activity Description -->
<!ELEMENT id (#PCDATA)>
<!ELEMENT pre_condition (#PCDATA)>
<!ELEMENT post_condition (#PCDATA)>
<!ELEMENT invokedApplication EMPTY>
<!ATTLIST invokedApplication
xlink:type (simple) #FIXED "simple"
xlink:href CDATA #REQUIRED
xlink:actuate (auto|user) "auto"
xlink:title CDATA #IMPLIED > <!-- Application Name -->
<!-- End of Activity Definition -->
Not all activities are prescheduled, some activities may be created ad hoc. A worklist reflects the latter cases. Using XML the structure of a worklist is a DTD as shown in Table 5.
Table 5 Worklist DTD
<?xml version="1.0" ?>
<!-- Worklist Structure Worklist.dtd -->
<!ELEMENT worklist (work_item+)>
<!ELEMENT work_item EMPTY>
<!ATTLIST work_item
act_id CDATA #IMPLIED
xmls:xlink CDATA #FIXED "http://www.w3.org/1999/xlink">
xlink:type (simple) #FIXED "simple"
xlink:href CDATA #REQUIRED
xlink:actuate (auto|user) "auto"
xlink:title CDATA #IMPLIED> <!-- Activity Description -->
<!-- End of Worklist Structure -->
4. Instantiation of Process Defintion
For a particular workflow the DTD is then instantiated into a process definition DIDocument Instance (DI). Table 6 is a sample DI for Academic Affairs in a university and is explained below.
Table 6 A Sample DI for Academic Affairs
<?xml version="1.0" ?>
<!DOCTYPE workflow SYSTEM "workflow.dtd">
<workflow>
<policy>
<objectives xlink:href="URL-Obj" xlink:title="Quality Statement"/>
<rulesAndRegulations xlink:href="URL-RR"
xlink:title="Rules and Regulations"/>
</policy>
<practice>
<eventCalendar xlink:href="URL-EC"
xlink:title="Calendar of Events"/>
<SOP xlink:href="URL-SOP" xlink:title="SOP Directory"/>
<form xlink:href="URL-Form" xlink:title="Forms Directory"/>
<SoftwareTool xlink:href="URL-ST"
xlink:title="SoftwareTools Directory"/>
<workflowRelevantData xlink:href="URL-WRD"
xlink:title="Workflow Relevant Data"/>
</practice>
<process>
<actor location="smju@ccms.nkfust.edu" xlink:href="URL-DH"
xlink:title="Authority/Responsibility">
Dean of Academic Affairs</actor>
<subprocess>
<actor location="hong@ccms.nkfust.edu" xlink:href="URL-CA"
xlink:title="Authority/Responsibility">
Chief of Admission</actor>
<startDate xlink:href="URL-SD-adm" xlink:title="Start Date"/>
<dueDate xlink:href="URL-DD-adm" xlink:title="Due Date"/>
<completionDate xlink:href="URL-CD-adm"
xlink:title="Completion Date"/>
<SETT xlink:href="URL-SETT-adm" xlink:title="SETT-adm"/>
</subprocess>
<subprocess>
<actor location="yeng@ccms.nkfust.edu" xlink:href="URL-CR"
xlink:title="Authority/Responsibility">
Chief of Registration and Curriculum</actor>
<startDate xlink:href="URL-SD-CA" xlink:title="Start Date"/>
<dueDate xlink:href="URL-DD-CA" xlink:title="Due Date"/>
<completionDate xlink:href="URL-CD-CA"
xlink:title="Completion Date"/>
<subprocess>
<actor location="lu@ccms.nkfust.edu" xlink:href="URL-Clerk-1"
xlink:title="Authority/Responsibility">Clerk-1</actor>
<startDate xlink:href="URL-SD-reg" xlink:title="Start Date"/>
<dueDate xlink:href="URL-DD-reg" xlink:title="Due Date"/>
<completionDate xlink:href="URL-CD-reg"
xlink:title="Completion Date"/>
<SETT xlink:href="URL-SETT-reg" xlink:title="SETT-reg"/>
</subprocess>
<subprocess>
<actor location="chang@ccms.nkfust.edu"
xlink:href="URL-Clerk-2"
xlink:title="Authority/Responsibility">Clerk-2</actor>
<startDate xlink:href="URL-SD-cur" xlink:title="Start Date"/>
<dueDate xlink:href="URL-DD-cur" xlink:title="Due Date"/>
<completionDate xlink:href="URL-CD-cur"
xlink:title="Completion Date"/>
<SETT xlink:href="URL-SETT-cur" xlink:title="SETT-cur"/>
</subprocess>
</subprocess>
<subprocess>
<actor location="hsu@ccms.nkfust.edu" xlink:href="URL-CT"
xlink:title="Authority / Responsibility">
Chief of Teaching Support</actor>
<startDate xlink:href="URL-SD-CT" xlink:title="Start Date"/>
<dueDate xlink:href="URL-DD-CT" xlink:title="Due Date"/>
<completionDate xlink:href="URL-CD-CT"
xlink:title="Completion Date"/>
<SETT xlink:href="URL-SETT-teach" xlink:title="SETT-teach"/>
</subprocess>
</process>
</workflow>
<!-- End of Process Definition DI -->
The Academic Affairs DI states that the operation of the Academic Affairs is governed by the quality statement and the rules and regulations. Since these documents are only for the workers' reference, they can be described and retrieved with the same pattern of a DI as shown in Table 7.
Table 7 Objectives DI <?xml version="1.0" ?> <!-- Objectives.DI --> <!DOCTYPE document [ <!ELEMENT document EMPTY> <!ATTLIST document docTitle ENTITY #REQUIRED> <!ENTITY Objectives SYSTEM "Quality Statement.doc" NDATA Word> <!NOTATION Word SYSTEM "winword.exe" >]> <document docTitle="Objectives"/> <!-- End of Objectives.DI -->
The above DI stated that the document entitled "Objectives" is recorded on a file with a file name "Quality Statement.doc" in the local system. The file format is "doc" and is created with a software tool called "winword.exe". The same principle applies to the document "Rules and Regulations" as shown in Table 8.
Table 8 Rules-and-Regulations DI <?xml version="1.0" ?> <!-- RulesAndRegs.DI --> <!DOCTYPE document [ <!ELEMENT document EMPTY> <!ATTLIST document docTtitle ENTITY #REQUIRED> <!ENTITY RulesAndRegs SYSTEM "Rules and Regulations.doc" NDATA Word> <!NOTATION Word SYSTEM "winword.exe" >]> <document docTtitle="RulesAndRegs"/> <!-- End of RulesAndRegs.DI -->
The Academic Affairs DI has a Calendar of Events that specifies major activities to be performed by Academic Affairs during the school semester. Using XML a skeletal calendar of events is represented in Table 9.
Table 9 A Skeletal DI for Calendar of Events for Academic Affairs
<?xml version="1.0" ?>
<!-- Skeletal Calendar of Events for Academic Affairs AACOE.di -->
<!DOCTYPE stateEventTransitionTable SYSTEM "SETT.dtd">
<stateEventTransitionTable>
<currentState id="Idle"/>
<event id="19990801"/>
<activity id="act1"/>
<nextState id="Idle"/>
<currentState id="Idle"/>
<event id="19991015"/>
<activity id="act2"/>
<nextState id="Idle"/>
:
:
<currentState id="Activity-incomplete"/>
<event id="Due-date-arrived"/>
<activity id="Corrective"/>
<nextState id="Idle"/>
</stateEventTransitionTable>
<!-- End of Skeletal Calendar of Events for Academic Affairs -->
This DI stated that when the date is 1999 August 1, act1 will be performed, and after act1 is completed the state is back to "Idle". It is interesting to note that every State Event Transition Table has an entry that enforces a uniform treatment of exceptional situation, like this:
(Activity-incomplete state, Due-date-arrived event, Corrective activity, Idle state)
The Dean of Academic Affairs has three major responsibilities that are embodied by three subprocesses, and the things to do for each of the subprocess is precisely defined with a State Event Transition Table. The Dean delegates the three subprocesses to the three section chiefs: Chief of Admission, Chief of Registration and Curriculum, and Chief of Teaching Support. The Chief of Registration and Curriculum further delegates works to two clerks.
Figure 4 highlights the intricacy of process definition, process instance and worklist. A process definition consists of multiple subprocess definitions and each subprocess consists of structured activities. They are generic definitions and are instantiated for a particular workflow process. When an activity is activated it is associated with a work item. The relevant work items constitute a worklist. An example DI of a worklist represented is shown in Table 10.
Table 10 Sample Worklist DI
<?xml version="1.0" ?>
<!-- Sample Worklist Instance SampleWorklist.di -->
<!DOCTYPE worklist SYSTEM "Worklist.dtd">
<worklist>
<work_item act_id="act-A1D" xlink:href="URL-act-A1D"
xlink:title="Activity De-scription"/>
<work_item act_id="act-A2C" xlink:href="URL-act-A2C"
xlink:title="Activity Descrip-tion"/>
<work_item act_id="act-A3A" xlink:href="URL-act-A3A"
xlink:title="Activity De-scription"/>
<work_item act_id="act-B1B" xlink:href="URL-act-B1B"
xlink:title="Activity Descrip-tion"/>
</worklist>
<!-- End of Sample Worklist -->
5. Conclusion
Bogia (1995) proposed that an adaptable workflow system should be dynamic, controllable and extensible. By inference this author concluded that the approach for process definition would satisfy the criteria:
-
Dynamic. System data such as task descriptions are represented in XML and stored on a server. Authorized personnel can modify them as appropriate. A task can be added or deleted by adding or deleting an entry in the State Event Transition Table. The actual behavior of an activity can also be dictated by instantiating an activity DTD.
-
Controllable. This control is maintained by the policy and practice in the workflow DTD.
-
Extensible. All system data are represented by XML that by nature is extensible. All the process definition and system control data are stored on a server and can be updated by authorized personnel.
Furthermore, Project wftk (Vivtek, 2001) provided a long list of requirements for an adaptable workflow system. These requirements could be satisfied by collaborating the process definition mechanism described in this paper with a suitable workflow engine.
Acknowledgements
The author would like to thank Prof. John A. Scigliano for his guidance and encouragement.
Bibliography
| [Bogia, D.P. (1995).] | Supporting flexible, extensible task descriptions in and among tasks. (Doctoral dissertation, University of Illinois at Urbana-Champaign, 1995). pp. 435. |
| [Burger, F., Quirchmayr, G., Reich, S. & Tjoa, A. (1995).] | Using HyTime for modeling publishing workflows. SIGOIS Bulletin, 16(1), August 1995. |
| [Bussler, C. & Jablonski, S. (1994).] | An approach to integrate workflow modeling and organization modeling in an enterprise.Proc. 3rd Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, 81-95. |
| [Classen, I., Weber, H. & Han, Y. (1997).] | Towards evolutionary and adaptive workflow systems - infrastructure support based on higher-order object nets and CORBA.Proc. 1st International Enterprise Distributed Object Computing Workshop. 300-308. |
| [DeRose, S., Orchard, D. & Trafford, B. (Eds.) (1999, July 26).] | XML Linking Language (Xlink) Version 1.0, W3C Candidate Recommendation 3 July 2000. http://www.w3.org/TR/xlink/ Accessed November 22, 2000. |
| [Goldfarb, C. & Prescod, P. (1998).] | The XML handbook.Upper Saddle River, NJ: Prentice Hall. |
| [Hagenburg, FAW (1995, March).] | Enactment: A process support system for electronic publishing. http://www.faw.uni-linz.ac.at/projects/europub/workflowprototype.html/ Accessed May 4, 1995. |
| [Horn, S. & Jablonski, S. (1998, November 14).] | An approach to dynamic instance adaptation in workflow management applications. http://ccs.mit.edu/klein/cscw98/paper21/index.html/ Accessed December 6, 1999. |
| [Kwan, M.M. & Balasubramanian, P.R. (1998).] | Dynamic workflow management: a framework for modeling workflows. Proc. of the 31st Hawaii Int'l Conf. on System Sciences, Vol. 4, 367-376. |
| [Lawrence, P. (Ed.) (1997a).] | Workflow handbook 1997, New York: John Wiley & Sons. |
| [Rupietta, W. (1997).] | Organization and role models for workflow processes. In P. Lawrence (Ed.), Workflow handbook. (pp. 165-172). New York: John Wiley & Sons. |
| [Vivtek (2001).] | Wftk: Open-source workflow toolkit. http://www.vivtek.com/wftk/ Accessed March 4, 2001. |
| [WfMC (1995, January 19).] | The workflow reference model, Version 1.1,WfMC-TC-1003. http://www.aiim.org/wfmc/standards/docs.htm/ Accessed December 15, 1999. |
| [WfMC (1999, January 1).] | Process definition Q & A and examples,WfMC-TC-1016-X. http://www.aiim.org/wfmc/standards/docs.htm/ Accessed December 15, 1999. |
| [WfMC (1999, February).] | Terminology and glossary, Version 3.0,WfMC-TC-1011. http://www.aiim.org/wfmc/standards/docs.htm/ Accessed December 15, 1999. |
| [WfMC (1999, October 29).] | Process definition interchange, Version 1.1,WfMC-TC-1016-P. http://www.aiim.org/wfmc/standards/docs.htm/ Accessed December 15, 1999. |