Workflow Scenario: Trouble Ticket

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 Copyright 1998 by Northern Telecom Copyright 1998 by University of Newcastle upon Tyne All rights reserved. The companies and organizations listed above hereby grant a royalty-free license to the Object Management Group, Inc. (OMG) for worldwide distribution of this document or any derivative works thereof, so long as the OMG reproduces the copyright notices and the below paragraphs on all distributed copies. The material in this document is submitted to the OMG for evaluation. Submission of this document does not represent a commitment to implement any portion of this specification in the products of the submitters. WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, THE COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The companies listed above shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance or use of this material. The information contained in this document is subject to change without notice. This document contains information which is protected by copyright. All Rights Reserved. Except as otherwise provided herein, no part of this work may be reproduced or used in any form or by any meansgraphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems-without the permission of one of the copyright owners. All copies of this document must 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 of copies 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 interfaces contained herein. RESTRICTED RIGHTS LEGEND. Use, duplication, or disclosure by government is subject to restrictions as set forth in subdivision (c) (1) (ii) of the Right in Technical Data and Computer Software Clause at DFARS 252.227.7013. Trademarks All trademarks acknowledged. 2 Workflow Scenario: Trouble Ticket

bom/98-03-10 Workflow Scenario: Trouble Ticket 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... 12 3.1.2 Medium Grained Structure... 13 3.1.3 Fine Grained Structure... 16 3.2 Class Structure... 18 3.3 Interaction Structure... 19 4. References... 22 Table of Content 3

Workflow Scenario: Trouble Ticket bom/98-03-10 0. Supporting Document Information 0.1 Copyright Waiver See inside front cover. 0.2 Supporting Document Contact Points John Warne Nortel London Road Harlow ESSEX CM17 9NA UK tel: +44 1279 403752 fax: +44 1279 439636 e-mail: J.P.Warne@nortel.co.uk Stuart Wheater Department of Computing Science University of Newcastle upon Tyne Claremont Tower Newcastle upon Tyne Tyne and Wear NE1 7RU UK tel: +44 191 222 8066 fax: +44 191 222 8232 e-mail: Stuart.Wheater@newcastle.ac.uk 4 Supporting Document Information

bom/98-03-10 Workflow Scenario: Trouble Ticket 1. Introduction The purpose of this document is to illustrate how the Workflow Management Facility proposed by Nortel and the University of Newcastle upon Tyne [1] can be used 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 the slightly abstract facilities specified in the submission. The scenario comprises a description of: the process and the data, which constitutes a trouble ticket workflow application, and an interaction scenario with the workflow application. The document is structure as follows, in section 2 the trouble ticket workflow scenario is described, and in section 3 how the scenario could be realized using the proposed workflow management facility is described. Introduction 5

Workflow Scenario: Trouble Ticket bom/98-03-10 2. Workflow Scenario: Trouble Ticket Copyright 1998 Netscape. This document is provided by Netscape Communications Corporation to the members of the OMG for the purpose of evaluating workflow. Permission is hereby granted for copying and redistribution of this document as long as this copyright notice remains in place. 2.1 Setting 2.2 The Process The trouble ticket scenario covers quality assurance teams or customer support teams. A "bug" or "problem" is identified; it must be recorded; the record must be checked for accuracy; from a single instance of a problem, the underlying cause is identified; a resolution is identified, which must be communicated back to the original party with the problem. The scenario has been modified in version 2 to provide for a subprocess invocation in order to be able to discuss the interoperability of two workflow systems. First we will present a process centric view of what happens to a given trouble ticket Step 1: Recording the Problem The problem may be found by an internal or external person. There are two ways that 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 delay that presents a form for entering the details of the problem. Submitting this form will cause the creation of the workflow process, and at the same time generate a unique ID for the trouble ticket. A phone call from an external person will be handled by an internal person, who uses essentially the same form mentioned above, but needs to be able to search for registered customers a couple of different ways. Again, submission of the form will create the process and assign an id. The ID of the trouble ticket must be produced by the system and be immediately available (within 10 seconds) in order to let the external person know the trouble ticket ID. The ID is used as a way to call 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 automatically picked up, and a trouble ticket started, which includes the body of the email as part of the data. No attempt is made to automatically analyze the body of the message, but the sender's email address is retrieved from the header. The first step of the process is for some internal person to read the message, and to fill in some of the other fields on the form with real values, and then submit it. The system 6 Workflow Scenario: Trouble Ticket

bom/98-03-10 Workflow Scenario: Trouble Ticket should be able to look up the registered user from the email address. When the trouble ticket is submitted, a email confirmation is sent to the external person, and the 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 describes accurately a reproducible problem. This activity is simply to follow the instruction on the report, and to see if the described behavior occurs. If the trouble ticket comes from an internal person, then this activity must be assigned to someone else so that the recording and reproducing of the problem are not done by the same person. If it comes from an external person, this activity may be done by the same person who enters the report. If the behavior can not be reproduced, then this process goes to step3, otherwise it goes to step 4. The problem may be identified at this stage. If there is a known solution to the problem it should be entered or referred to at this stage, and then communicated back to the originator by going to Step 6. If the problem is recognized as a duplicate of another problem, it should be able to be recorded as such, and go to step 5. Step 3: Correcting the Report This step is reached only if the problem can not be reproduced. This step is assigned to the originator if internal. If external, this must be assigned to a person who can contact the originator and get more clarification on the problem. There are two results of this step, either back to Step 2, or to give up on the process and go to step 6. Step 4: Identifying the Problem and Resolution This is where the specialist is called in. The problem details should narrow down the area of the problem. If the expert determines that the area is wrong, it should be 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 problem is identified and it will be fixed, or it be fixed later due to schedule constraints, or it is determined to be a misunderstanding and is actually the correct behavior. In all 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 manner that fits the way they work. The exact route of this sub process is not the subject of this scenario, only that it is started, it is given data, and at some time later it reports that it is complete and returns a set of data. The subprocess for the development team was implemented before the trouble ticket scenario, so it already has a set of field with meaning appropriate to that Workflow Scenario: Trouble Ticket 7

Workflow Scenario: Trouble Ticket bom/98-03-10 2.3 The Data task. This means that the trouble ticket process must translate the fields into the field 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," and the 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 step contains a rule that the result must be communicated within 3 days of being known. 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 of the process. It involves someone looking at the process and determine whether the question/answer should be included in a monthly newsletter to the user community. This step is started in parallel with Step 6 since it does not depend upon it, and might happen before it. This first set of data is the set of filed used within the Trouble Ticket process itself. 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 8 Workflow Scenario: Trouble Ticket

bom/98-03-10 Workflow Scenario: Trouble Ticket 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 number four. 2.4 Interaction Scenario Day 1 ShortDescription - a one line description of the problem (like Synopsis above) QAPriority - the priority assigned by QA (like Priority above) Priority - the priority within the development team (not present in the parent 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. (a) An important customer calls up with a problem. Person A takes the call, and brings up the form, enters the information, submits it, and sees that it is currently assigned to Person B. Later person B sees it on the worklist, but does not call it up. Workflow Scenario: Trouble Ticket 9

Workflow Scenario: Trouble Ticket bom/98-03-10 Day 2 (b) Person A checks on the status of the trouble ticket (where was this listed, since it is not on his worklist?), and sees that Person B has not taken any action. Person A composes an email message to Person B, with the processes status page attached. (c) Person B receives the email, clicks on the link to call up the process in the browser. Person B reproduces the problem, makes sure it is correctly assigned to Product X, Area 1, and then completes the activity. It disappears from B's worklist. (d) Step 4 becomes active, and it looks up in the directory to find the workflow process definition that is responsible for Product X, Area 1. It does not matter that the definition is in a different workflow engine, an instance of it is created. The data is passed to it. The subprocess determines that for Product X Area 1 the first activity 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 email message. Day 3 (e) Person C gets the email, and clicks on the link to bring up the sub process instance, looks at it for 5 minutes, and determines that it should be in Area 2. He changes the Area field to 2. The system finds out that person D is assigned to Area 2, so it disappears from C's worklist, appears on D's worklist, and D also receives an email notification. (f) Person A checks on the progress of the case and sees that step 5 is currently active. He sees that it has a subprocess. He can navigate to the subprocess and see what step it is in there and that it is currently assigned to person D. He can read the 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 have the time to get to it. Instead he determines that Person E should be able to handle the task, so he delegates the activity to Person E. (h) The important customer calls up again but this time to the Vice President of the division, who talks to Person A, who checks on the status. Person A rasies the priority data field in the process in response. (i) Person E sees it immediately, and gets to work. A short time later a solution is found; 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 is assigned to Person B since B was the one who reproduced the problem. B verifies the fix, and the process goes to step 6. This is assigned to Person F. 10 Workflow Scenario: Trouble Ticket

bom/98-03-10 Workflow Scenario: Trouble Ticket Day 5 & 6 (j) Nothing happens to Step 6 (k) The newsletter editor picks up and completed Step 7, removing it from his worklist. Day 8 (l) Still nothing has happened. There is a rule that the result must be communicated back within 3 days of the fix, so a trigger goes off, causing an email message to be sent to Person A, and to Person G who is the manager of Person F. (m) Person G knows that Person F is on vacation, and forgot to set up automatic forwarding of responsibility. Since this activity needs to be attended to, reassigns the task to person H (how did he claim authority to do so?) who gets an email notification, 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 still able to access the history and final state of the process. Workflow Scenario: Trouble Ticket 11

Workflow Scenario: Trouble Ticket bom/98-03-10 3. Scenario Realization 3.1 Task Structure The description of the realization of the trouble ticket scenario will involve describing three aspects: the task structure, the class structure and the interaction structure. 3.1.1 Course Grained Structure The following figures describes the course grained structure of the Trouble Ticket workflow application. It shows that the Trouble Ticket task has been decomposed into five sub-tasks (small solid boxes represent simple tasks (or if desired compound tasks) and small dotted boxes represent genesis tasks), Recording the Problem, Reproduce Problem and Correct Report, Identify and Verify Resolution, Three Day Timeout and Communicate Results, and also shows their inter-relationships (solid arrows represent data-dependencies and dotted arrows represent temporal-dependencies). Trouble Ticket Identify and Verify Resolution Reproduce Problem and Correct Report Communicate Results Recording the Problem Three Day Timeout Figure 1 Trouble ticket The Reproduce Problem and Correct Report and Identify and Verify Resolution tasks, are specified to be genesis tasks which means that the sub-task structure associated those tasks will only be instantiated when the task is started. This means that the instantiation of the trouble ticket task can be performed dynamically when needed. The following figures describes the structure of the Reproduce Problem and Correct Report task. It shows that the Reproduce the Problem task has been decomposed into three sub-task, Recording the Problem, Correcting the Report, and Reproduce Problem and Correct Report, and also shows their inter-relationships. 12 Scenario Realization

bom/98-03-10 Workflow Scenario: Trouble Ticket Reproduce Problem and Correct Report Correcting the Report Reproduce Problem and Correct Report Reproduce the Problem Figure 2 Reproduce problem and correct report The Reproduce Problem and Correct Report sub-task within the Reproduce Problem and Correct Report task is specified to be genesis task with the same task structure as the its enclosing task. This means that the task structure is recursive. Recursion is used here to perform the iteration between step 2 and step 3. The following figures describes the structure of the Identify Problem and Verify Resolution task. It shows that the Identify Problem and Verify Resolution task has been decomposed into three sub-task, Identifying the Problem and Resolution, Verifying the Resolution and Identify Problem and Verify Resolution. Identify Problem and Verify Resolution Identify Problem and Verify Resolution Verifying the Resolution Identifying the Problem and Resolution 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 Trouble Ticket workflow application, by describe the input and output sets of the Trouble Ticket task and it s sub-tasks, and the relationships between input and output sets. Scenario Realization 13

Workflow Scenario: Trouble Ticket bom/98-03-10 The figure below shows that the Trouble Ticket task has two input sets (labeled ; which corresponds to starting the task with a problem from an internal person and labeled is2; which corresponds to starting the task with a problem from an external person ) and a single output set (labeled ; which corresponds to the outcome of the task). Trouble Ticket Verify Problem and Correct Report os2 Identify and Verify Resolution is2 is2 is2 Recording the Problem os3 Three Day Timeout Communicate Results is2 Figure 4 Trouble ticket The purpose of the input and output sets are described below: Recording the Problem task: Input set : Problem from internal person. Input set is2: Problem from external person. Output set : Produce report. Verify Problem and Correct Report task: Input set : Obtain Report. Output set : Unknown resolution. Output set os2: Probable known resolution. Output set os3: Known resolution. Identify and Verify Resolution task: Input set : Unknown resolution. Input set is2: Probable known resolution. Output set : Produce resolution. Three Day Timeout task: Input set : Start timer. Output set : Timer expired. Communicate Results task: Input set : Resolution. 14 Scenario Realization

bom/98-03-10 Workflow Scenario: Trouble Ticket Input set is2: No Resolution. Output set : Outcome. This figure below describe the relationships between the input and output sets of the Verify Problem and Correct Report task and it s sub-tasks. Verify Problem and Correct Report Verify Problem and Correct Report os2 Correct the Report os3 os2 Reproduce the Problem os2 os2 os3 os3 os4 Figure 5 Verify problem and correct report The purpose of the input and output sets are described below: Reproduce the Problem task: Input set : Obtain Report. Output set : 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: Input set : Obtain Report. Output set : Report corrected. Output set os2: Report not corrected. Verify Problem and Correct Report task: the input and output sets of this task are specified above. The figure below describes the relationships between the input and output sets of the Identify and Verify Resolution task and it s sub-tasks. Scenario Realization 15

Workflow Scenario: Trouble Ticket bom/98-03-10 is2 Identify the Problem and Resolution Identify Problem and Verify Resolution Identify Problem and Verify Verify Resolution the is2 Resolution os2 Figure 6 Identify problem and verify resolution The purpose of the input and output sets are described below: Identify the Problem and Resolution task: Input set : Obtain report. Output set : Produce resolution. Verify the Resolution task: Input set : Obtain report and resolution. Output set : Resolution don t solves problem. Output set os2: Resolution solves problem. Identify Problem and Verify Resolution task: the input and output sets of this task are specified above. 3.1.3 Fine Grained Structure This section will describe the structure of the Trouble Ticket workflow application in terms of the object references which are passed between tasks. Because of the large number of interaction between tasks the interaction between only three tasks will be described, the Verify Problem and Correct Report, Identify and Verify Resolution and the Communicate Results tasks. 16 Scenario Realization

bom/98-03-10 Workflow Scenario: Trouble Ticket Verify Problem and Correct Report o1 os2 o2 i1 i2 Identify and Verify Resolution o1 o3 i3 os3 o4 i1 Communicate Results Figure 6 Fine grained structure of application The purpose of the input and output objects are described below (see section 3.2 class definitions): Verify Problem and Correct Report task: Output set : 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 : Unknown resolution. Object i1: problem (Problem class) Input set is2: Probable known resolution. Object i2: problem (Problem class) Object i3: probable_resolution (Resolution class) Output set : Produce resolution. Object o1: resolution (Resolution class) Communicate Results task: Input set : Resolution. Object i1: resolution (Resolution class) Input set is2: No Resolution (not shown). Scenario Realization 17

Workflow Scenario: Trouble Ticket bom/98-03-10 3.2 Class Structure The input set of the Communicate Results task will be triggered if either the output set os4 of the Verify Problem and Correct Report task or the of the Identify and Verify Resolution task are produced. This section will describe one possible class structure of the data specified in the trouble ticket scenario, and how existing class structures can be incorporated in to the application. The class structure is obtained by grouping information to form classes. Object references to instances for such classes are passed between tasks. The figure below shows a medium grained class structure for the trouble ticket scenario which contains five classes; Resource, Originator, Report, Problem and Resolution. Resource is the base class (base interface) of the object references which can be passed between tasks. The remaining four classes contain the trouble ticket workflow application specific information. CfWorkflow::Resource id Originator UID name address phone email_address Report submitter source_email 0..* 0..1 priority date_received date_verified date_closed date_last_contact Problem synopsis description 1..* 0..1 severity product area attached_data expert Resolution resolution description 0..1 0..1 date_resolved date_verified Figure 7 UML class diagram of class structure A more fine grained structure is possible which contain more classes, as is a courser grained structure which contains fewer classes. The granularity of the class structure is left to the workflow application designed. The figure below describes the incorporated into the trouble ticket application of a class called TroubleTicket which was been implemented separating for the workflow application. 18 Scenario Realization

bom/98-03-10 Workflow Scenario: Trouble Ticket TroubleTicket short_description q_a_priority priority description attached_files submitter submitted_date resolution CfWorkflow::Resource id TroubleTicketResource Figure 8 UML class diagram of class structure As the TroubleTicketResource class is a combination of the Problem and Resolution classes a task can be constructed which take as input a Problem object reference and Resolution object reference and produce as output an object reference to TroubleTicketResource. Naturally a task can also be constructed which does the reverse. The appropriate addition of such tasks into the trouble ticket application would allow the interoperability of task constructed using the different class structures. 3.3 Interaction Structure The following interaction scenarios illustrate how the features of the workflow management facility can be used to achieve specific goals. Naturally all the following interactions would be performed by support tools, which provide the user with a higher level of abstraction. It is assumed that WorkList and E-Mail support is provided. Worklist objects could be transactional ad primitive tasks could be constructed which transfer work between worklists (atomically), and send e-mail. This will ensure that a workitem will disapear from a workflow and reappear at another worklist in a reliable manner. 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 workflow specification. The start operation is passed the initial inputs needed by the workflow instance. The object reference to the created task controller will be retained 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 be passed between subsequent tasks. Scenario Realization 19

Workflow Scenario: Trouble Ticket bom/98-03-10 It is possible to traverse the task structure (using the get_requested_notification of the TaskControl interface) to discover that the Reproduce the Problem task has been assigned to person B and is currently active (using the get_status operation of the Task interface). Interaction (b): Person A checks the status of the workflow instance using the retained object reference to the created task controller, in the same manner as before and finds that the Reproduce the Problem task is still active. The object reference to the task 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 output set), this in turn causes it s task controller to invoke notification operations of interested task controllers. At this point the task and task controller are both in StatusCompleted states. The task entering completed state would remove the task form person B s active worklist (possible adding it to a completed list, so the person B can monitor it further progress, until the task is destroyed; using the destroy 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 required reassigning the locations and implementations of the task (dynamically reconfigured). To achieve this the set_status_to_setup should be invoked on the task controller to set its status to StatusSetup. In this status the set_task operation can be invoked to change the task associated with the task controller. The set_status_to_waiting should then be invoked on the task controller to set back to status to StatusWaiting. To ensure that this, and other, changes are make consistently such changes could be performed within a transaction. Interaction (f): Person A checks the status of the workflow instance using the retained object reference 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. The get_selected_input_set operation of the task controller can be used to determine 20 Scenario Realization

bom/98-03-10 Workflow Scenario: Trouble Ticket the input set that started the task, and the get_input_alternative can be used to find which 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 invoking the request_notification operation of task controller which is controlling the task which 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 to query operation such as get_selected_input_set, get_selected_output_set, get_input_alternative and get_task, until the destory operation is called on the task controllers. Scenario Realization 21

Workflow Scenario: Trouble Ticket bom/98-03-10 4. References [1] Nortel and University of Newcastle upon Tyne, Revised Submission for Workflow Management Facility Specification, OMG Document bom/98-03-01. [2] Keith D. Swenson, Netscape Communications Corporation, Trouble Ticket Workflow Scenario (Version 2), OMG Document bom/98-02-09. 22 References