Workflow Scenario: Trouble Ticketkswenson.workcast.org/1998/98-03-10-TroubleTicket_Nortel.pdf ·...

Supporting Document

Workflow Scenario: Trouble Ticket

Nortel

Supported by:

University of Newcastle upon Tyne

OMG Document Number bom/98-03-10

Workflow Scenario: Trouble Ticket bom/98-03-10

2 Workflow Scenario: Trouble Ticket

Copyright 1998 by Northern TelecomCopyright 1998 by University of Newcastle upon TyneAll rights reserved.

The companies and organizations listed above hereby grant a royalty-free license to the ObjectManagement Group, Inc. (OMG) for worldwide distribution of this document or any derivative worksthereof, so long as the OMG reproduces the copyright notices and the below paragraphs on alldistributed copies.

The material in this document is submitted to the OMG for evaluation. Submission of this documentdoes not represent a commitment to implement any portion of this specification in the products of thesubmitters.

WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, THECOMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND WITH REGARD TO THISMATERIAL INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OFMERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The companies listedabove shall not be liable for errors contained herein or for incidental or consequential damages inconnection with the furnishing, performance or use of this material. The information contained in thisdocument is subject to change without notice.

This document contains information which is protected by copyright. All Rights Reserved. Except asotherwise provided herein, no part of this work may be reproduced or used in any form or by any means-graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage andretrieval systems-without the permission of one of the copyright owners. All copies of this documentmust include the copyright and other information contained on this page.

The copyright owners grant member companies of the OMG permission to make a limited number ofcopies of this document (up to 50 copies) for their internal use as part of the OMG evaluation process.The copyright owners also grant OMG permission to reproduce the document and to use the interfacescontained herein.

RESTRICTED RIGHTS LEGEND. Use, duplication, or disclosure by government is subject torestrictions as set forth in subdivision (c) (1) (ii) of the Right in Technical Data and Computer SoftwareClause at DFARS 252.227.7013.

TrademarksAll trademarks acknowledged.

bom/98-03-10 Workflow Scenario: Trouble Ticket

Table of Content 3

Table of Contents

0. Supporting Document Information ................................................................. 4

0.1 Copyright Waiver .................................................................................. 4

0.2 Supporting Document Contact Points ................................................... 4

1. Introduction ....................................................................................................... 5

2. Workflow Scenario: Trouble Ticket................................................................ 6

2.1 Setting.................................................................................................... 6

2.2 The Process ........................................................................................... 6

2.3 The Data ................................................................................................ 8

2.4 Interaction Scenario............................................................................... 9

3. Scenario Realization........................................................................................ 12

3.1 Task Structure ..................................................................................... 12

3.1.1 Course Grained Structure ..................................................... 123.1.2 Medium Grained Structure................................................... 133.1.3 Fine Grained Structure ......................................................... 16

3.2 Class Structure..................................................................................... 18

3.3 Interaction Structure ............................................................................ 19

4. References ........................................................................................................ 22


4 Supporting Document Information

0. Supporting Document Information

0.1 Copyright Waiver

See inside front cover.

0.2 Supporting Document Contact Points

John WarneNortelLondon RoadHarlowESSEXCM17 9NAUK

Stuart WheaterDepartment of Computing ScienceUniversity of Newcastle upon TyneClaremont TowerNewcastle upon TyneTyne and WearNE1 7RUUK

tel: +44 1279 403752fax: +44 1279 439636e-mail: [email protected]

tel: +44 191 222 8066fax: +44 191 222 8232e-mail: [email protected]


Introduction 5

1. Introduction

The purpose of this document is to illustrate how the Workflow ManagementFacility proposed by Nortel and the University of Newcastle upon Tyne [1] can beused to realized the workflow scenario (version 2) provided by Keith D. Swenson,Netscape Communications Corporation [2].

A secondary purpose of this document is to form a tangible example of theslightly abstract facilities specified in the submission.

The scenario comprises a description of: the process and the data, whichconstitutes a trouble ticket workflow application, and an interaction scenario withthe workflow application.

The document is structure as follows, in section 2 the trouble ticket workflowscenario is described, and in section 3 how the scenario could be realized usingthe proposed workflow management facility is described.



2. Workflow Scenario: Trouble Ticket

Copyright 1998 Netscape. This document is provided by Netscape CommunicationsCorporation to the members of the OMG for the purpose of evaluating workflow.Permission is hereby granted for copying and redistribution of this document aslong as this copyright notice remains in place.

2.1 Setting

The trouble ticket scenario covers quality assurance teams or customer supportteams. A "bug" or "problem" is identified; it must be recorded; the record must bechecked for accuracy; from a single instance of a problem, the underlying cause isidentified; a resolution is identified, which must be communicated back to theoriginal party with the problem.

The scenario has been modified in version 2 to provide for a subprocessinvocation in order to be able to discuss the interoperability of two workflowsystems.

2.2 The Process

First we will present a process centric view of what happens to a given troubleticket

Step 1: Recording the Problem

The problem may be found by an internal or external person. There are two waysthat a problem can come from the external person: by phone or by email.

For the internal person, there must be a screen that can be called up without delaythat presents a form for entering the details of the problem. Submitting this formwill cause the creation of the workflow process, and at the same time generate aunique ID for the trouble ticket.

A phone call from an external person will be handled by an internal person, whouses essentially the same form mentioned above, but needs to be able to search forregistered customers a couple of different ways. Again, submission of the formwill create the process and assign an id. The ID of the trouble ticket must beproduced by the system and be immediately available (within 10 seconds) in orderto let the external person know the trouble ticket ID. The ID is used as a way tocall up the trouble ticket when that person calls in again to check on progress.

Finally, email may be sent to a particular address. This email is automaticallypicked up, and a trouble ticket started, which includes the body of the email aspart of the data. No attempt is made to automatically analyze the body of themessage, but the sender's email address is retrieved from the header. The first stepof the process is for some internal person to read the message, and to fill in someof the other fields on the form with real values, and then submit it. The system


Workflow Scenario: Trouble Ticket 7

should be able to look up the registered user from the email address. When thetrouble ticket is submitted, a email confirmation is sent to the external person, andthe process goes to step 2.

Step 2: Reproduce the Problem

This step is designed to check the trouble ticket report, and to see if it describesaccurately a reproducible problem. This activity is simply to follow the instructionon the report, and to see if the described behavior occurs. If the trouble ticketcomes from an internal person, then this activity must be assigned to someone elseso that the recording and reproducing of the problem are not done by the sameperson. If it comes from an external person, this activity may be done by the sameperson who enters the report. If the behavior can not be reproduced, then thisprocess goes to step3, otherwise it goes to step 4.

The problem may be identified at this stage. If there is a known solution to theproblem it should be entered or referred to at this stage, and then communicatedback to the originator by going to Step 6. If the problem is recognized as aduplicate of another problem, it should be able to be recorded as such, and go tostep 5.

Step 3: Correcting the Report

This step is reached only if the problem can not be reproduced. This step isassigned to the originator if internal. If external, this must be assigned to a personwho can contact the originator and get more clarification on the problem. Thereare two results of this step, either back to Step 2, or to give up on the process andgo to step 6.

Step 4: Identifying the Problem and Resolution

This is where the specialist is called in. The problem details should narrow downthe area of the problem. If the expert determines that the area is wrong, it shouldbe able to be reassigned, and the person assigned to the activity should change.The problem stays in this state until a resolution is determined. Either the problemis identified and it will be fixed, or it be fixed later due to schedule constraints, orit is determined to be a misunderstanding and is actually the correct behavior. Inall cases the resolution must be communicated to the originator, either via email,or else through a phone call. It goes to step 5.

For this organization, accomplishing this activity require invoking a subprocess.The development team has its own workflow process that handles this in a mannerthat fits the way they work. The exact route of this sub process is not the subjectof this scenario, only that it is started, it is given data, and at some time later itreports that it is complete and returns a set of data.

The subprocess for the development team was implemented before the troubleticket scenario, so it already has a set of field with meaning appropriate to that



task. This means that the trouble ticket process must translate the fields into thefield used by the sub process. The details of this is defined below.

Step 5: Verifying the Resolution

When the problem is resolved, then it waits for the resolution to become available.When it is available, the resolution is verified. If the resolution was "fixed," andthe problem is not actually solved, then the process can be sent back to step 4.Otherwise the process goes to step 6.

Step 6: Communicate Results

The results of the process are communicated back to the originator here. This stepcontains a rule that the result must be communicated within 3 days of beingknown. If not, an email message is sent to the support manager.

Step 7: Audit and Record

This step may happen before or after Step 6, but must happen before the end ofthe process. It involves someone looking at the process and determine whether thequestion/answer should be included in a monthly newsletter to the usercommunity. This step is started in parallel with Step 6 since it does not dependupon it, and might happen before it.

2.3 The Data

This first set of data is the set of filed used within the Trouble Ticket processitself.

• Originator UID - a unique id if one exists

• Originator Name

• Originator Address

• Originator phone

• Originator email address

• Submitter - the person who took the call. If internal, same as originator.

• Synopsis - a one line description

• Description - a full in depth description

• Source Email - holds the email that started the process, if there is one.

• Severity

• Priority

• Product

• Area



• Date Received (Submitted)

• Date Resolved

• Date Verified

• Date Closed

• Attached data files (URLs to files checked into a server)

• Expert - the person who is the expert for the current product area.

• Resolution

• Resolution Description

• Status (presumably part of the workflow...)

• Date of last originator contact

• Duplicate Ticket number.

This second set is the data needed by the subprocess invoked under step numberfour.

• ShortDescription - a one line description of the problem (like Synopsisabove)

• QAPriority - the priority assigned by QA (like Priority above)

• Priority - the priority within the development team (not present in theparent process)

• Description - the full description of the problem (like Description above)

• Attached files (like above)

• Submitter - (like above)

• SubmittedDate - the date submitted to the development team.

• A number more data fields internal to this process.

• Resolution - this is a result that is passed back to the parent process.

2.4 Interaction Scenario

Day 1

(a) An important customer calls up with a problem. Person A takes the call, andbrings up the form, enters the information, submits it, and sees that it is currentlyassigned to Person B. Later person B sees it on the worklist, but does not call itup.



Day 2

(b) Person A checks on the status of the trouble ticket (where was this listed, sinceit is not on his worklist?), and sees that Person B has not taken any action. PersonA composes an email message to Person B, with the processes status pageattached.

(c) Person B receives the email, clicks on the link to call up the process in thebrowser. Person B reproduces the problem, makes sure it is correctly assigned toProduct X, Area 1, and then completes the activity. It disappears from B'sworklist.

(d) Step 4 becomes active, and it looks up in the directory to find the workflowprocess definition that is responsible for Product X, Area 1. It does not matter thatthe definition is in a different workflow engine, an instance of it is created. Thedata is passed to it. The subprocess determines that for Product X Area 1 the firstactivity on the subprocess should be assigned to user C. It appears on C's worklist,and C has specified to receive notification by email, so it sends him an emailmessage.

Day 3

(e) Person C gets the email, and clicks on the link to bring up the sub processinstance, looks at it for 5 minutes, and determines that it should be in Area 2. Hechanges the Area field to 2. The system finds out that person D is assigned to Area2, so it disappears from C's worklist, appears on D's worklist, and D also receivesan email notification.

(f) Person A checks on the progress of the case and sees that step 5 is currentlyactive. He sees that it has a subprocess. He can navigate to the subprocess and seewhat step it is in there and that it is currently assigned to person D. He can readthe output data from the subprocess which includes the resolution of the problem,which at this time is still empty.

Day 4

(g) Person D gets the message, retrieves the process instance, but does not havethe time to get to it. Instead he determines that Person E should be able to handlethe task, so he delegates the activity to Person E.

(h) The important customer calls up again but this time to the Vice President ofthe division, who talks to Person A, who checks on the status. Person A rasies thepriority data field in the process in response.

(i) Person E sees it immediately, and gets to work. A short time later a solution isfound; he enters the resolution, and marks it fixed, completing the subprocess,passing the data back to the main process, and finally ending up at step 5. This isassigned to Person B since B was the one who reproduced the problem. B verifiesthe fix, and the process goes to step 6. This is assigned to Person F.



Day 5 & 6

(j) Nothing happens to Step 6

(k) The newsletter editor picks up and completed Step 7, removing it from hisworklist.

Day 8

(l) Still nothing has happened. There is a rule that the result must becommunicated back within 3 days of the fix, so a trigger goes off, causing anemail message to be sent to Person A, and to Person G who is the manager ofPerson F.

(m) Person G knows that Person F is on vacation, and forgot to set up automaticforwarding of responsibility. Since this activity needs to be attended to, reassignsthe task to person H (how did he claim authority to do so?) who gets an emailnotification, and takes case of the activity completing the process.

Day 9

(n) Person A checks back in on the process. The process is finished, but A is stillable to access the history and final state of the process.


12 Scenario Realization

3. Scenario Realization

The description of the realization of the trouble ticket scenario will involvedescribing three aspects: the task structure, the class structure and the interactionstructure.

3.1 Task Structure

3.1.1 Course Grained Structure

The following figures describes the course grained structure of the “TroubleTicket” workflow application. It shows that the “Trouble Ticket” task has beendecomposed into five sub-tasks (small solid boxes represent simple tasks (or ifdesired compound tasks) and small dotted boxes represent genesis tasks),“Recording the Problem”, “Reproduce Problem and Correct Report”, “Identifyand Verify Resolution”, “Three Day Timeout” and “Communicate Results”, andalso shows their inter-relationships (solid arrows represent data-dependencies anddotted arrows represent temporal-dependencies).

Trouble Ticket

Recordingthe Problem

CommunicateResults

ReproduceProblem and

CorrectReport

Identify andVerify

Resolution

Three DayTimeout

Figure 1 Trouble ticket

The “Reproduce Problem and Correct Report” and “Identify and VerifyResolution” tasks, are specified to be genesis tasks which means that the sub-taskstructure associated those tasks will only be instantiated when the task is started.This means that the instantiation of the trouble ticket task can be performeddynamically when needed.

The following figures describes the structure of the “Reproduce Problem andCorrect Report” task. It shows that the “Reproduce the Problem” task has beendecomposed into three sub-task, “Recording the Problem”, “Correcting theReport”, and “Reproduce Problem and Correct Report”, and also shows theirinter-relationships.


Scenario Realization 13

Reproduce Problem and Correct Report

Reproducethe Problem

Correctingthe Report

ReproduceProblem and

CorrectReport

Figure 2 Reproduce problem and correct report

The “Reproduce Problem and Correct Report” sub-task within the “ReproduceProblem and Correct Report” task is specified to be genesis task with the sametask structure as the its enclosing task. This means that the task structure isrecursive. Recursion is used here to perform the iteration between step 2 and step3.

The following figures describes the structure of the “Identify Problem and VerifyResolution” task. It shows that the “Identify Problem and Verify Resolution” taskhas been decomposed into three sub-task, “Identifying the Problem andResolution”, “Verifying the Resolution” and “Identify Problem and VerifyResolution”.

Identify Problem and Verify Resolution

Identifying theProblem andResolution

Verifying theResolution

IdentifyProblem and

VerifyResolution

Figure 3 Identify problem and verify resolution

Once again recursion is used for iterating between steps 4 to 6.

3.1.2 Medium Grained Structure

The following figures describes the medium grained structure of the “TroubleTicket” workflow application, by describe the input and output sets of the“Trouble Ticket” task and it’s sub-tasks, and the relationships between input andoutput sets.



The figure below shows that the “Trouble Ticket” task has two input sets (labeledis1; which corresponds to starting the task with a “problem from an internalperson” and labeled is2; which corresponds to starting the task with a “problemfrom an external person”) and a single output set (labeled os1; which correspondsto the “outcome” of the task).

Trouble Ticket

Recordingthe

Problem

CommunicateResults

VerifyProblem

andCorrectReport

Identifyand

VerifyResolution

is1

is2

os1

is1

is1

os3

os1

os1

is2

os1

os2

is1

is2ThreeDay

Timeoutos1is1

os1

is1

is2

Figure 4 Trouble ticket

The purpose of the input and output sets are described below:

“Recording the Problem” task:

• Input set is1: Problem from internal person.

• Input set is2: Problem from external person.

• Output set os1: Produce report.

“Verify Problem and Correct Report” task:

• Input set is1: Obtain Report.

• Output set os1: Unknown resolution.

• Output set os2: Probable known resolution.

• Output set os3: Known resolution.

“Identify and Verify Resolution” task:

• Input set is1: Unknown resolution.

• Input set is2: Probable known resolution.

• Output set os1: Produce resolution.

“Three Day Timeout” task:

• Input set is1: Start timer.

• Output set os1: Timer expired.

“Communicate Results” task:

• Input set is1: Resolution.



• Input set is2: No Resolution.

• Output set os1: Outcome.

This figure below describe the relationships between the input and output sets ofthe “Verify Problem and Correct Report” task and it’s sub-tasks.

Verify Problem and Correct Report

Reproducethe

Problem

Correctthe

Report

VerifyProblem

andCorrectReport

os1

os1 os2

os2

is1 os2

is1

os3

is1

os4

os3

os3

os1

is1

os2

os1

Figure 5 Verify problem and correct report


“Reproduce the Problem” task:


• Output set os1: Not reproducible.

• Output set os2: Reproducible, unknown resolution.

• Output set os3: Reproducible, probable known resolution.

• Output set os4: Reproducible, known resolution.

“Correct the Report” task:


• Output set os1: Report corrected.

• Output set os2: Report not corrected.

“Verify Problem and Correct Report” task: the input and output sets of this taskare specified above.

The figure below describes the relationships between the input and output sets ofthe “Identify and Verify Resolution” task and it’s sub-tasks.



Identify Problem and Verify Resolution

Identifythe

Problemand

Resolution

Verifythe

Resolution

IdentifyProblem

andVerify

Resolution

os1

is1

is1

is2

os2

is2

os1

is1

os1

is1

os1

Figure 6 Identify problem and verify resolution


“Identify the Problem and Resolution” task:

• Input set is1: Obtain report.


“Verify the Resolution” task:

• Input set is1: Obtain report and resolution.

• Output set os1: Resolution don’t solves problem.

• Output set os2: Resolution solves problem.

“Identify Problem and Verify Resolution” task: the input and output sets of thistask are specified above.

3.1.3 Fine Grained Structure

This section will describe the structure of the “Trouble Ticket” workflowapplication in terms of the object references which are passed between tasks.Because of the large number of interaction between tasks the interaction betweenonly three tasks will be described, the “Verify Problem and Correct Report”,“Identify and Verify Resolution” and the “Communicate Results” tasks.



VerifyProblem

andCorrectReport

CommunicateResults

Identifyand

VerifyResolution

is1

os1

os1

is1

os3

is1os2

o1

o4

o3

o2

i3

i2

i1

i1

o1

Figure 6 Fine grained structure of application

The purpose of the input and output objects are described below (see section 3.2class definitions):

“Verify Problem and Correct Report” task:

• Output set os1: Unknown resolution.

• Object o1: problem (Problem class)

• Output set os2: Probable known resolution.

• Object o2: problem (Problem class)

• Object o3: probable_resolution (Resolution class)

• Output set os3: Known resolution.

• Object o4: resolution (Resolution class)

“Identify and Verify Resolution” task:

• Input set is1: Unknown resolution.

• Object i1: problem (Problem class)

• Input set is2: Probable known resolution.

• Object i2: problem (Problem class)

• Object i3: probable_resolution (Resolution class)


• Object o1: resolution (Resolution class)

“Communicate Results” task:

• Input set is1: Resolution.

• Object i1: resolution (Resolution class)

• Input set is2: No Resolution (not shown).



The input set is1 of the “Communicate Results” task will be triggered if either theoutput set os4 of the “Verify Problem and Correct Report” task or the os1 of the“Identify and Verify Resolution” task are produced.

3.2 Class Structure

This section will describe one possible class structure of the data specified in thetrouble ticket scenario, and how existing class structures can be incorporated in tothe application.

The class structure is obtained by grouping information to form classes. Objectreferences to instances for such classes are passed between tasks.

The figure below shows a medium grained class structure for the trouble ticketscenario which contains five classes; Resource, Originator, Report, Problem andResolution. Resource is the base class (base interface) of the object referenceswhich can be passed between tasks. The remaining four classes contain the troubleticket workflow application specific information.

Originator UID name address phone email_address

Report submitter source_email priority date_received date_verified date_closed date_last_contact

0..10..*

CfWorkflow::Resource id

Problem synopsis description severity product area attached_data expert

1..* 0..1

Resolution resolution description date_resolved date_verified

0..1 0..1

Figure 7 UML class diagram of class structure

A more fine grained structure is possible which contain more classes, as is acourser grained structure which contains fewer classes. The granularity of theclass structure is left to the workflow application designed.

The figure below describes the incorporated into the trouble ticket application of aclass called TroubleTicket which was been implemented separating for theworkflow application.



CfWorkflow::Resource id

TroubleTicket short_description q_a_priority priority description attached_files submitter submitted_date resolution

TroubleTicketResource

Figure 8 UML class diagram of class structure

As the TroubleTicketResource class is a combination of the Problem andResolution classes a task can be constructed which take as input a Problem objectreference and Resolution object reference and produce as output an objectreference to TroubleTicketResource. Naturally a task can also be constructedwhich does the reverse. The appropriate addition of such tasks into the troubleticket application would allow the interoperability of task constructed using thedifferent class structures.

3.3 Interaction Structure

The following interaction scenarios illustrate how the features of the workflowmanagement facility can be used to achieve specific goals. Naturally all thefollowing interactions would be performed by support tools, which provide theuser with a higher level of abstraction.

It is assumed that WorkList and E-Mail support is provided. Worklist objectscould be transactional ad primitive tasks could be constructed which transfer workbetween worklists (atomically), and send e-mail. This will ensure that a workitemwill ‘disapear from a workflow and reappear at another worklist’ in a reliablemanner.

Interaction (a):

Person A finds the appropriate workflow specification in the workflow repository,an object reference to a TaskDef interface.

Person A instantiates and starts a workflow instance, based on the workflowspecification. The start operation is passed the initial inputs needed by theworkflow instance. The object reference to the created task controller will beretained by person A, to allow monitoring of the workflow.

In the first task (“Record the Problem”, performed by person A), originator,report and problem objects are created, object references to these objects will bepassed between subsequent tasks.



It is possible to traverse the task structure (using the get_requested_notification ofthe TaskControl interface) to discover that the “Reproduce the Problem” task hasbeen assigned to person B and is currently active (using the get_status operationof the Task interface).

Interaction (b):

Person A checks the status of the workflow instance using the retained objectreference to the created task controller, in the same manner as before and findsthat the “Reproduce the Problem” task is still active. The object reference to thetask controller or task (as a “stringified” object reference or name server entry,using the id attribute of the Task or TaskControl interface), if it was to be e-mailed) could be passed to person B to indicate that this task requires attention.

Interaction (c):

Person B completes the “Reproduce the Problem” task, causing the “task object”to invoke the notification operation of it’s task controller (with appropriate outputset), this in turn causes it’s task controller to invoke notification operations ofinterested task controllers. At this point the task and task controller are both inStatusCompleted states. The task entering completed state would remove the taskform person B’s active worklist (possible adding it to a completed list, so theperson B can monitor it further progress, until the task is destroyed; using thedestroy operation).

Interaction (d):

Section 3.2 describes how task based on different class structures can interoperate.

Interaction (e):

The “Identify and Verify Resolution” task needs to be changed; this may requiredreassigning the locations and implementations of the task (dynamicallyreconfigured). To achieve this the set_status_to_setup should be invoked on thetask controller to set its status to StatusSetup. In this status the set_task operationcan be invoked to change the task associated with the task controller. Theset_status_to_waiting should then be invoked on the task controller to set back tostatus to StatusWaiting. To ensure that this, and other, changes are makeconsistently such changes could be performed within a transaction.

Interaction (f):

Person A checks the status of the workflow instance using the retained objectreference to the created task controller, in the same manner as before (Interaction(a)) and finds that the currently active task is assigned to person D. Theget_selected_input_set operation of the task controller can be used to determine



the input set that started the task, and the get_input_alternative can be used to findwhich tasks supplied the selected input objects.

Interaction (g):

This can be achieved using dynamic reconfiguration (see interaction (e)).

Interaction (h):

Person A can obtain an object reference to the report and set its priority field.

Interaction (i):

Section 3.1 describes how task can be coordinated.

Interaction (j):

Nothing happens.

Interaction (k):

The newsletter editor can request a notification of specific outcomes by invokingthe request_notification operation of task controller which is controlling the taskwhich is to be monitored.

Interaction (l):

Section 3.1 describes how a time task can trigger a task.

Interaction (m):

This can be achieved using dynamic reconfiguration (see interaction (e)).

Interaction (n):

Even after the all tasks have completed the task controllers will still respond toquery operation such as get_selected_input_set, get_selected_output_set,get_input_alternative and get_task, until the destory operation is called on thetask controllers.


22 References

4. References

[1] Nortel and University of Newcastle upon Tyne, Revised Submission forWorkflow Management Facility Specification, OMG Document bom/98-03-01.

[2] Keith D. Swenson, Netscape Communications Corporation, Trouble TicketWorkflow Scenario (Version 2), OMG Document bom/98-02-09.

Workflow Scenario: Trouble Ticketkswenson.workcast.org/1998/98-03-10-TroubleTicket_Nortel.pdf ·...

Documents

Transcript of Workflow Scenario: Trouble Ticketkswenson.workcast.org/1998/98-03-10-TroubleTicket_Nortel.pdf ·...