Health & Fitness

Applications of Web-Based Workflow

Description
A web-based workflow system was developed at the Jet Propulsion Laboratory and several pilot applications were developed. We give an overview of the architecture and functionality of the workflow system, describe three pilot workflows that have been
Published
of 9
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  Applications of Web-Based Workflow Chuck Ames, Scott Burleigh, Steve Mitchell, Tom HuynhJet Propulsion Laboratory, California Institute of Technology {chuck,scott,steve,tom}@tel.jpl.nasa.gov  Abstract A web-based workflow system was developed atthe Jet Propulsion Laboratory and several pilotapplications were developed. We give an overview of the architecture and functionality of the workflowsystem, describe three pilot workflows that have beenor are being deployed, and relate lessons learned. 1. Introduction Workflow Management is becoming anincreasingly important part of organizationalinformation systems. A Web-based workflowmanagement system called WWWorkflow wasdeveloped at the Jet Propulsion Laboratory (JPL) [1].WWWorkflow was designed to provide a general-purpose process mediation service as an integral partof an organizational “Intranet”. WWWorkflow’s userinterface consists of dynamically generated Webpages, email messages, and pager notifications, so nounique desktop applications are required in order forusers to interact with the system.A key design principle embodied in theWWWorkflow system is the careful separation of process mediation from product data management.This has been shown to be a useful distinction inother contexts [2]. Instead of building datamanagement functions (e.g. forms processing, datavaulting, etc.) into WWWorkflow, we defineinterfaces to external systems that provide thesefunctions. Thus WWWorkflow can be used to addworkflow functionality to pre-existing datamanagement systems.WWWorkflow has been used to implement anddeploy several workflow management applications atJPL and at the NASA Johnson Space Center (JSC).These applications vary in procedural complexity,size and distribution of user community, and volumeof transactions. We learned much about processengineering and workflow implementation in general,and about the validity of the design of WWWorkflowin particular.This paper is organized as follows: an overview of the architecture and design of the WWWorkflowsystem is given. Next, three case studies of specificapplications of the WWWorkflow system arepresented. We conclude with a discussion of lessonslearned from these three applications. 2. WWWorkflow System Overview The purpose of Workflow Management systems isto coordinate activities of people. Many existingWorkflow Management systems provide very goodsupport for process engineering but limited supportfor process execution, often requiring additionalproprietary desktop applications which may havelimited platform availability. Unfortunately, processengineering cannot be effective unless the results areaccessible to the people who must carry out theprocesses. WWWorkflow provides a processmediation service using tools that most users alreadyhave and know how to use. Users interact with thesystem using their Web browser to check their"TODO" list and read Task Descriptions aboutassignments. In its "nag daemon" role, WWWorkflowuses email and pagers to notify people when theyneed to do something. 2.1 System Architecture The WWWorkflow system architecture containsthree main parts:1.A Common Gateway Interface (CGI) [3] front endwhich allows users to interact with the system viaa browser.2.A workflow "engine" which sends and receivesmessages into and out of the workflow system.3.A database which contains predefined workflowprocedures, status information for proceduresunderway, and complete histories of previouslyexecuted procedures. 1060-3425/98 $10.00 (C) 1998 IEEE  The user interface to the system is the user's webbrowser software. The web browser uses the HyperText Transfer Protocol (HTTP) [4] to send requestsand receive documents from an HTTP daemonprocess. The HTTP daemon helps the user interactwith the workflow system by calling the CGIprogram responsible for WWWorkflow activities. TheCGI program communicates both with the workflowengine and with the workflow database to retrieveinstructions for the user and to notify the workflowengine of activities the user has performed. engine CGI httpdrdbmsshellwfdbauthservice browser  HTMLHTML task descriptions TCP SocketI/O httpdwww_cr crdbDBMS CR System TCP SocketTCP SocketI/OCGIHTTPHTTP Figure 1: WWWorkflow systemarchitecture Figure 1 shows the system architecture as deployedin the Process Change Request system described insection 3.3. The system drives a document changerequest process used to approve changes to SpaceStation documentation. Shown in the diagram areboth the workflow system and the document changerequest (CR) system. While WWWorkflow is used toembody and execute change request procedures, thesystem is carefully separated from the product datawithin the CR system itself. Also shown is theoptional communication with existing enterpriseauthentication services. The architecture of WWWorkflow is consistent with therecommendations of the Workflow ManagementCoalition Reference Model [5]. 2.2 Workflow Language 2.0 Workflow Language (WFL) is the low-levellanguage in which commands are written to controlthe operation of the Workflow Daemon (server). Inthis respect the relationship between WFL and theworkflow server is functionally analogous to therelationship between SQL and a relational databasemanagement server. That is, a procedure definition isnot written in WFL, exactly; what is written in WFLis a set of instructions to the workflow server thatenable it to record the procedure definition in theworkflow database. Other WFL commands are usedto instantiate procedure definitions, to note thecompletion of procedure steps (and thereby triggeractivation of contingent procedure steps), and to editexisting procedures and procedure definitions.Every procedure definition comprises one or more steps . Each step has an associated  precondition , somestatement that must be true before the step can begin(in any procedure instantiated from this definition);the precondition of a step is usually expressed interms of the completion statuses of other steps. Eachprocedure may also have any number of arbitrarilydeclared operands  whose values constitute the“memory” of the procedure, similar in function to thelocal variables of a computer program.When a procedure definition is instantiated, i.e., aspecific initiative  governed by that definition isbegun, the initiative is essentially a replica of theprocedure definition; it has all the same steps andoperands. Those steps of the initiative whoseprecondition is the predefined value START,  or someBoolean expression that is True when START   is true,are automatically begun as soon as the initiative hasbeen recorded in the workflow database.Steps may be either simple or compound in nature.A simple step is one whose initiation is expressed asa single task   assigned to a single person or a singleautomated task (e.g., the execution of a script); acompound step is one whose initiation is expressed asmultiple tasks, such as the assignment of the samework item to each member of a team. When a task iscompleted, the assignee uses WFL (usually bytriggering a CGI script from a Web page) to notifythe workflow daemon of the task’s completion status.The daemon uses this information to update theworkflow database and automatically initiate all stepswhose precondition is true now that the affected stephas been completed in the status indicated. Thecompletion of a task may in fact re-initiate a step thatwas previously completed; that is, the daemon maytrigger multiple iterations  of the same step if requiredby the procedure definition.WFL is a dialect of Tcl, the Tool ControlLanguage [6] devised by John K. Ousterhout at theUniversity of California at Berkeley. The WFLextension to Tcl comprises just six commands: new,edit, delete, start, stop, and  get . Subsets of these commands can be applied to six general types of  1060-3425/98 $10.00 (C) 1998 IEEE  workflow database objects: procedures (which areactually procedure definitions), initiatives (procedures instantiated from those definitions), operands , steps , tasks , and statuses .Associated with each type of object are dataattributes, such things as name, value (in the case of an operand), assignee and task description (in the caseof a step), etc. The values of several of the attributesof a step may be “late bound”, that is, they mayexplicitly be Tcl scripts but implicitly be the valuesreturned by evaluating those scripts at the time thestep is begun. The value of the “assignee” attributeof a step may be explicitly or implicitly a list of assignee names, making the step compound ratherthan simple. Built-in Tcl variables whose values areupdated automatically in context-sensitive fashion areprovided to simplify the writing of WFL scripts.The start  command is used only to start a newinstance of a procedure definition. The stop command is used principally to note the completionstatus of a task. The get  command simply returnsthe current value of an operand (which, like any otherattribute, can be set by means of the edit  command).Step preconditions can be arbitrarily complex Booleanexpressions concerning the completion statuses of other steps.Here is an example of a small WFL script thatcreates a simple procedure definition: new procedure add_userdo {new operand $Pr $In loginId}do {new operand $Pr $In userName}do {new step $Pr $In add_acctassignee Marlacondition START}do {new step $Pr $In tell_userassignee Darrylcondition {status .add_acct Done}} A complete discussion of WFL syntax andfunctionality is available in [7]. 2.3 WWWorkflow User Interface The critical component necessary to putWWWorkflow to work is the Web Gateway to theworkflow engine and database. WWWorkflow usesCommon Gateway Interface (CGI) technology toprovide an interface to the users. The modules arewritten in Perl. It has been shown that CGIprograms can provide effective user interfaces tocomplex systems. [8].To interact with the system, the user directs a webbrowser to access the Uniform Resource Locator(URL) of the CGI program that will act as the user’sinterface to the organization’s workflow. The CGIprogram interrogates the user for authentication andidentification information. A main menu is presentedto the user that contains options to interact with theuser’s current “todo” list, start previously definedprocedures, and view the status or historicalinformation of procedures. Todo lists have beenshow to be an effective way of communicatingassignments to distributed workgroups [9]. Figure 2: TODO list display The user’s todo (figure 2) list is the result of aquery to the workflow database. The query finds allactive instances of steps within active procedures forwhich the user is currently responsible. Figure 3: task description display 1060-3425/98 $10.00 (C) 1998 IEEE  Once a user selects a task from the todo list, theuser is presented with a task description of the step(figure 3). The task description is defined anddocumented with HTML files. These use hypertextlinks to help users begin working on a certain task. Files in the collection of task descriptions for aprocess may also serve as documentation or on-lineprocedure manuals.At the bottom of each task description the user isshown one button for each of the prescribedcompletion statuses for the task at hand. The userselects one of these completion statuses when he hascompleted the task. The selection of a completionstatus button will cause the CGI to send a completioncommand to the workflow system for that particulartask. This is one of the ways the workflow system isnotified of user participation, and helps drive theworkflow. 3. Case Studies This section describes three cases whereWWWorkflow has been successfully applied. Allthree cases required that WWWorkflow be integratedwith other pre-existing data management systems.For each case, we describe the problem domain, theworkflow procedure that was designed, and theresulting system architecture with reference toexternal data management systems that wereintegrated. 3.1 Case 1: Process Action Item Small teams often operate by establishing an actionitem list. Action items are assigned by the teamleader, carried out by team members, then closed bynegotiation between team member and team leader. DoActionConcurReviseSTOPACK  Close Reject Complete Accept Renig Cancel Disagree Update  (actionor) Figure 4: The “process action item”procedure A WWWorkflow-based system was designed toestablish team action item lists and track progress of individual action items [10]. WWWorkflow wasintegrated with an external action item database whichprovides forms for creating and editing action items,as well as generating summary reports. When a newaction item is created, a new initiative of the ProcessAction Item (PAI) workflow procedure (figure 4) isstarted within WWWorkflow. WWWorkflow theninitiates work and tracks progress according to thisinitiative. The initiative is complete when theAction Item is either closed or canceled by the ActionItem list owner.The PAI procedure is relatively simple, composedof 4 possible steps, with 8 possible paths. Eachinitiative is short lived, lasting from a few days to afew weeks. The Process Action Item applicationinvolved a small user community of 12-15 usersdistributed over a single site. 3.2 Case 2: Develop Command Sequence JPL builds and operates unmanned planetaryspacecraft. Part of the operations process is designand preparation of command sequences to be sent tospacecraft in flight. The application of the followingcommand sequence workflow involved a medium-sized user community of 30-150 users distributed overmultiple sites. The procedure is complex, involving73 possible steps, with a high degree of parallelism.Each initiative is long lived—roughly 56 days.The process of developing a sequence of commandsto send to an unmanned planetary spacecraft hasalways been time-consuming and labor-intensive.Historically, most or all of the responsibility forensuring that command errors don’t damage thespacecraft or jeopardize its mission has rested with themission operations teams rather than with the on-board software charged with executing the commands,due to severely constrained on-board computingcapacity. The spacecraft are complex and expensive;they respond to hundreds of different commands thatconfigure many different subsystems, managed bydifferent organizations, often with conflictingoperational goals; and recovering from some types of error may be difficult or physically impossible.Consequently command sequencing has alwaysinvolved many stages of conference, negotiation,analysis, modeling, review, and approval.Sequence planning for the Cassini mission toSaturn is a particularly demanding, yet critical,process because Cassini is the largest and mostcomplex unmanned spacecraft ever built.WWWorkflow was used to characterize the Cassini 1060-3425/98 $10.00 (C) 1998 IEEE  sequence planning process with an eye towardminimizing the delay between the completion of anystep and initiation of the contingent steps, to give allparticipants as much productive time as possiblewithin the 56-day window allotted to the planning of each sequence.The procedure can be divided into three chainedsubprocedures: activity planning, sub-sequencegeneration, and sequence integration and validation.Each subprocedure requires that the work done bymission operations team members be smoothlyintegrated with automated work, such as the executionof automatic conflict detection and resolution toolsand the archiving of team decisions in a missiondatabase. WWWorkflow’s built-in notion of paritybetween “automated” steps and steps assigned topeople minimized the difficulty of this integration.The activity planning subprocedure is relativelystraightforward, with two provisos. First,determination of the availability of files needed tosupport the automated steps can proceed in parallelwith the review of the Phase Update Package (PUP).Second, both review steps must be performed by allmembers of the Sequence Virtual Team, i.e., they arecompound steps.The sub-sequence generation sub-procedure isconceptually very simple, but implementing it usingan earlier version of WFL was tedious. Support forcompound steps in WFL 2.0 greatly simplifies thesub-procedure by collapsing many nearly identicalsub-steps into a single compound step with assignee-specific variations (see Figure 6 for an illustration of this general model). The compound step reduces sub-sequence generation to only five steps, one of whichis assigned with variations to each of the subsystemteams.Sequence integration and validation is the mostcomplex and time-consuming of the sub-procedures,but it too is simplified by applying a new feature inWFL 2.0: built-in support for iteration enables us toinclude the steps entailed in uplink package approval just once in the workflow but let them be executedtwice, or even more often if time permits. Figure 5illustrates this kind of simplification. 3.3 Case 3: Process Change Request The Johnson Space Center (JSC) is leadingdevelopment of the International Space Station, andStation Operations will be conducted from JSC.Development of Operations Procedures and otherOperations-oriented documentation has begun withcontributions from the entire Space Stationdevelopment community. These contributions andproposed changes flow through a change requestprocess.The change request srcinates when contributionsor modifications to documents are identified byauthors and document reviewers using the documentlibrary system. The change request workflow isstarted through the document library with a CGI forminterface. This interface appears seamless to the userof the document library—they see it as a part of thelibrary system. The CGI interface is passed theappropriate document identification information fromthe library system, along with the changes requestedor new contributions to be added. The CGI thenstarts a new change request workflow. Given thedocument identification, the newly initiated workflowcan retrieve documents from the document library oraid users in retrieving documents.The document change requests are routed throughseveral review steps, each with potential outcomessuch as “approve with modifications” and“disapprove.” The workflow potentially iterates overreview steps several times as modifications are madeand re-reviewed.In addition to several review/approve cycles, theworkflow must coordinate the roles of reviewers andcomposition of teams constructed to review changes.For example, depending on the type of document tobe changed, the teams constructed to review thedocument may differ from change request to changerequest. Additionally, several roles in the changerequest procedure (such as review board chair, orreview manager) may need to be determined from theresults of ad hoc database queries or input from users.This application involves a large user communityof more than 1,000 users distributed around the globe.The procedure is complex, involving approximately60 steps. Each initiative lasts from one week to onemonth. This application involves interfaces to 3external data management systems, including arelational database, a document vault, and anorganizational model. 4. Observations and Lessons Learned In this section, we relate specific insights achievedand solutions to problems found while implementingthe applications described in the case studies insection 3. As a result of these experiences, severalimprovements were made to the workflow language,the workflow server, and the user interface. Also, 1060-3425/98 $10.00 (C) 1998 IEEE
Search
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks