The present invention relates to computer software, and more particularly, to the reuse of workflows.
The need to manage the execution of project tasks has existed as long as people have worked collaboratively. A simple but exemplary task management process is shown in
The linear task management process shown in
The next stage of development in the history of task management was enabled by computing devices and computer software. Many of the planning, listing, diagramming, charting, and communication chores were sped up and made easier through the brute force application of computer software tools. However, these chores were still executed with little coordination among the chores or the participants. Most attempts at coordinating these chores involved nontrivial computer programming which required the time, effort, and cost of highly trained computer programmers. Using computer software tools to automate at least some parts of a business process made it easier to think about the flow of work through a business process. Thus, computer software tool development shifted from focusing on a given business process to focusing on the “workflow” that runs through a business process.
Note that a workflow is not a business process. A workflow is an abstraction of how work flows through a business process. For example, given a business process for approving documents, a workflow may be developed to track a particular document through the approval process as each participant in the approval process receives and approves the document. This abstract notion of a “workflow” has been modeled in computer programs and computer software for supporting workflow through a business process has become known as a “workflow.” Hereinafter, the term “workflow” refers to such a software model, i.e., a software program that supports how work flows through a business process.
A workflow allows the flow of work between individuals and/or departments to be defined and tracked. While it is true that a workflow enables the automation of many task management chores, the overwhelming value of a workflow is in the coordination the workflow provides among the many chores inherent in task management. More practically, a workflow helps automate business tasks and electronically route the right information to the right people at the right time. Participants are automatically notified of pending work. Managers are able to route approvals through the system quickly. A workflow may also provide graphical representations of the flow of work in a project, including dependencies and the sequence of decisions and activities.
There is no question that workflows significantly improve task management; however, workflow development requires the costly labor of highly trained computer programmers and workflow deployment requires significant labor and cost. Even though workflows are often similar to each other, workflow development and deployment tools in the prior art make it difficult or impossible to take a workflow developed for one project and apply it to another project. What is needed is a way to amortize the labor and cost required to develop one workflow over many workflows by reusing a workflow for more than one project. The present invention is directed to reusing workflows by providing a method and apparatus for associating the structure and metadata of a workflow developed for one project with other projects.
In accordance with aspects of the present invention, a method and apparatus, including computer-readable medium, for creating workflows using workflow templates is provided. The use of workflow templates allows the method and apparatus to associate the structure and metadata of a workflow developed for one project with other projects. A workflow is associated with a schedule by assigning values to parameters, inserting new parameters, disabling existing parameters, enabling existing features, disabling existing features, and/or inserting computer-implemented forms. Associating a workflow with a schedule is controlled through graphical user interfaces that display computer-implemented forms.
In accordance with one aspect of the invention, a workflow is developed using a workflow template. The template preferably allows preprogrammed workflow components to be inserted and/or removed, values to be assigned to parameters in workflow components, new parameters to be inserted into workflow components, and parameters already existing in a workflow component to be disabled. A developed workflow is packaged for installation preferably by assigning values to parameters, inserting new parameters, and/or disabling existing parameters, and storing the workflow and related data in a persistent store. Preferably, a workflow may be installed, deployed, and/or enabled. A workflow may be instantiated and/or terminated.
In accordance with yet another aspect of the invention, a workflow that has been instantiated and reached a state of acquiescence may be disabled, and parameter values describing the internal state of the workflow may be persistently stored for an arbitrarily long length of time and restored and re-enabled using said persistently stored parameter values.
In accordance with other aspects of the invention, the structure and metadata of existing workflows are reused by developing workflow templates and using workflow templates and/or preprogrammed workflow components. A workflow is modeled as a plurality of human-to-human and/or human-to-computer interaction points. Interaction points may occur in arbitrary order. A workflow may be comprised of a plurality of tasks. A task may be completed by a single user with or without input data. A plurality of tasks may be completed by a single manager with or without input data. Tasks may be assigned to one or more users, delegated to one or more users, and/or forwarded to one or more users. Tasks in the workflow may be defined using computer-implemented forms developed by a third party. Developing a workflow, packaging a workflow, installing a workflow, deploying a workflow, enabling a workflow, associating a workflow with a schedule, instantiating a workflow, and terminating a workflow are controlled through graphical user interfaces that display computer-implemented forms.
As will be readily appreciated from the foregoing description, the present invention provides a method and apparatus for reusing the structure and metadata of existing workflows by associating the structure and metadata of a workflow developed for one project with other projects.
The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:
Embodiments of the invention provide a computer-implemented method and apparatus (tool), including computer-readable medium, for associating the structure and metadata of a workflow developed for one project with other projects and for developing and using workflows and workflow templates. A workflow may be created directly or by using a workflow template. The first part of the description is directed to defining workflows and explaining how they are directly created. Workflow templates and using workflow templates to create workflows are described later.
A workflow includes information about a business process such as: (a) the procedural steps of the business process; (b) the persons involved at each step of the business process; (c) the input information and output information required at each step of the business process; and (d) the tools needed at each step of the business process. As those skilled in the art will readily appreciate, a workflow may include other types of information in addition to the aforementioned exemplary types of information.
In an exemplary embodiment of the invention, the model upon which a workflow is based closely models a human workflow, i.e., the events and items normally associated with human interaction points in the lifecycle of a workflow. Such workflow modeling provides for difficult to predict events during human/workflow interaction, e.g., vacations, illness, forgetting steps in the process, and the like. For ease of discussion, the humans which interact with a workflow are referred to by their roles in relation to the workflow: (a) owner, the person who creates and controls a workflow; (b) developer, a person who designs and implements all or parts of a workflow and/or workflow components; and (c) participant, a person who participates in one or more activities controlled by the workflow. Activities include, but are not limited to, review, revision, and approval. Obviously, the “roles” may overlap. For example, the owner may also be a developer and/or a participant. An entity that responds to input from a workflow is an “actor.” An actor may be a participant or a computing device. Preferably, human actors interact with an embodiment of the invention by using graphical user interface forms (GUI forms). A GUI form may be a window in an application, a Web page, or like graphical user interface component that enables human actors to enter view, select, and/or enter information.
By way of example, and not limitation, exemplary embodiments of the invention, i.e., methods and apparatus for developing and using workflows, may be supported within a collaborative computer application such as Microsoft® SharePoint™ Portal Server (SharePoint). SharePoint is a scalable portal server that integrates information from various networked computing devices and networked computing systems into one software entity to provide convenient portal deployment and administration. Those skilled in the art will appreciate that a portal is a site, such as a Web site, that serves as a gateway to a network, such as the Internet. A Web site portal is a collection of links, content, and services designed to guide users to information they are likely to find interesting—news, weather, entertainment, commerce sites, chat rooms, and so on. Yahoo!, Excite, MSN.com, and Netscape NetCenter are examples of portals. The services provided by SharePoint are collectively referred to as Windows SharePoint™ Services (WSS). The GUI forms used to interact with WSS are referred to as WSS forms.
An exemplary embodiment of the invention operates as a SharePoint service. A SharePoint service provides collaboration and information sharing and may also provide integration with other software applications.
The WSS Workflow OM 158 is the interface through which passes workflow state information 162 to the workflow engine 170. The workflow engine 170 runs a workflow and provides a workflow with support for scheduling, messaging, data persistence, role definition, and task tracking. The workflow may cause instructions 166 to be generated. The workflow engine 170 passes the workflow instructions 166 through the WSS Workflow OM 158 to the applications. Note that the applications 156 interact with the WSS Workflow OM 158 to access SharePoint services. Since a workflow is a SharePoint service, a workflow is accessed through the WSS Workflow OM 158. Thus, applications 156 are able to access the workflow through the WSS Workflow OM 158. Also note that a workflow does not interact directly with the WSS Workflow OM 158. The workflow engine 170 interacts with the WSS Workflow OM 158 providing workflows with an interface to the WSS Workflow OM 158.
A workflow interacts with the workflow engine and the workflow engine interacts with the WSS Workflow OM 158. For example, a participant may perform an action in an application 156 that is intended to change the state of a workflow. The application 156 passes a message to the WSS Workflow OM 158. The message contains information that identifies the workflow and specifies a workflow state change. The WSS Workflow OM 158 converts the message from the application to workflow state information 162 and passes the workflow state information 162 to the workflow engine 170. The workflow engine 170 selects the intended workflow from among the workflows the workflow engine 170 is running and passes the workflow state information 162 to the workflow specified in the message from the application 156.
The workflow engine 170 runs a workflow by advancing the workflow through a workflow schedule. A workflow schedule is a data structure containing tasks, workflow logic, and various metadata. In an exemplary embodiment of the invention, a WSS workflow schedule, suitable for running in Windows Workflow Services and associated with a WSS workflow, is an XML structure that contains workflow tasks and logic. Such a WSS workflow schedule may be stored as an XML file in a workflow package installed in a suitable site, such as a Web site.
While advancing through a workflow schedule, a workflow often operates on documents and lists. In the context of SharePoint, a document is any self-contained piece of work created with an application, and, if stored persistently, is given a unique filename by which it can be retrieved. In the context of SharePoint, a list is an abstraction for a relational schema of well-defined field types. A list may contain one or more documents. As with relational schema, lists have certain unique characteristics that differentiate one list from another list. A specific group of lists may be selected from a plurality of lists by using a “profile.” A profile is a filter comprising the characteristics of the desired lists. A function applied to a list may also be applied to the lists that result from the application of a profile to a plurality of lists. A more specific kind of list, called a document library, may not only contain documents, but may also organize the documents in a way that makes it easy to search and filter data about the documents and data contained in the documents. For example, a workflow document requires that the document be approved by one or more participants. Versions of the document may be created, canceled, modified, etc. in the course of a workflow lifecycle. A workflow associated with such a document manages and tracks such activities.
A workflow normally begins as a workflow definition. A workflow definition is an installable package of software containing a Windows Workflow Services workflow schedule and the supporting code files and forms required to fully specify a workflow. A specific workflow is created when a workflow definition goes through the processes of workflow association and workflow parameterization. Workflow association is the process of making a workflow available on a list or profile. Workflow parameterization is the process of collecting and submitting to the workflow a set of parameters, such as participants, due date, routing order, and so on. Some parameterization happens when the workflow is associated with a list or a profile. Some parameterization happens when the workflow is initiated. The workflow designer, i.e., the workflow developer or workflow owner, decides what parameters to include and when to ask for their values.
A workflow may run from start to finish without needing input from an actor; however, it is more likely that a workflow will require some external input from an actor to proceed. Actors, i.e., participants and computing devices, may provide external input to a workflow running on a workflow engine, i.e., Windows Workflow Services, at certain discrete, well defined points in the workflow. Such a point is referred to as a “task.” Conceptually, a task may be considered a unit of work having a beginning, an end, and associated metadata, such as status information. Each workflow contains a set of task lists. Each workflow stores its task in a task list.
A workflow can be associated with a list (where a document library is a type of list) or a content type. Workflow association settings are stored as properties of a list. These settings are preserved if the list is copied. These settings are preserved if the library is copied.
In a WSS embodiment of the invention, a task may be defined by using an application such as Microsoft Office InfoPath™ or Microsoft Visual Studio™, or tasks may be defined using custom data collection forms, i.e., GUI forms or WSS forms, developed by an Independent Software Vendor (ISV). Tasks are completed by participants. For example, a participant may click a link for a task to view a form for the task. The participant enters data into the form and somehow indicates that the form is complete, by selecting a checkbox indicating that the form's “Status” is “Complete,” for example. An application 156 providing the form passes the status information to the WSS Workflow OM 158, which passes the status information as workflow state information 162 to the workflow engine 170. The workflow engine 170 receives this information and passes back a workflow instruction 166 to notify the workflow's owner that the task is complete. In a similar process, a workflow owner, i.e., a project manager, may complete multiple tasks by selecting a set of tasks with similar requirements and marking them as complete or approved.
An exemplary embodiment of the invention uses a particular kind of WSS task called a “ToDo.” A ToDo is a task to be accomplished by an actor. A ToDo may be completed, canceled, or delegated. A ToDo is synchronized with other ToDos to execute the appropriate actions that, in turn, cause the appropriate message or messages to be sent to the workflow engine 170. A workflow begins the process of requesting external input by creating a ToDo and directing it to a set of actors. Since a ToDo is a type of WSS task, a ToDo can be inserted into a WSS task list and be assigned to actors. A ToDo is extensible in that it can have an arbitrary schema representing the data needed by the workflow at a particular point in the schedule running within the workflow engine. A ToDo can be delegated or forwarded to other actors. In the absence of requiring input data, ToDos can be completed outright. If data from a participant is required to complete a ToDo, the data is collected by presenting the participant with a form. After the data is entered into a form, the data is submitted to the WSS Workflow OM 158 which then submits workflow state information 162 to the workflow engine 170.
Information is passed from the WSS Workflow OM 158 to the workflow engine 170 as messages. In an exemplary embodiment, the types of messages comprise activation, send, and receive. The messages are generated by “Save” events in WSS. For example, as part of a workflow state transition within a workflow engine, a workflow schedule may create a workflow task and specify the subscriptions of the “Save” event, i.e., specify which software objects will be notified of a “Save” event. The creation of the workflow task by the workflow schedule within the workflow engine is translated into the action of creating a ToDo in WSS and registering the appropriate ToDo events. In an exemplary embodiment of the invention, when a participant submits a form to complete the ToDo, the ToDo executes a “Save” event in the supporting database by submitting a request that causes the following actions to execute:
1. A round trip to the database is made to fetch metadata about the ToDo using untyped events.
2. Pre-event handlers are executed and an Access Control List (ACL) check is performed.
3. The payload of the request is saved and an event queue payload is constructed. The database server calculates the changes the “Save” operation will cause in the database. Based on filtering done in the middle tier, the database server reduces the set of untyped events to the specific set of appropriate typed events.
4. Another round trip to the database is made to execute the “Save” transaction. The following actions are executed within the “Save” transaction:
a. The “Save” is committed in the database.
b. Typed events for the operation are generated and enqueued in the event queue.
c. The workflow schedule is locked.
d. The workflow schedule is serialized, and the serialized workflow schedule is returned as the result of the transaction.
5. If the workflow schedule is successfully obtained, a “Post-Save” event is delivered asynchronously in the middle tier.
At item 4.c., if the locking of the workflow schedule fails, which may occur because some other process on some other machine may have locked the workflow schedule, the workflow schedule is serialized and returned to complete the transaction, but the “Post-Save” event is not delivered. Based on an adaptive timing scheme, the “Post-Save” event is delivered when the workflow schedule is able to be locked. Upon the completion of a ToDo, the ToDo may be deleted using a process similar to the one described above. Such a ToDo deletion causes the WSS Workflow OM to delete the ToDo, as well as the appropriate subscriptions on the ToDo.
When a workflow creates a ToDo, one or more links are established between the ToDo and the schedule running in the workflow engine 170 and associated with the workflow. The ToDo registers for one or more of the events that are generated by the form used to submit data to the ToDo. When a participant enters data into one or more fields of the form, an event is generated. The ToDo detects the event, processes the submitted data, and passes the processed data to the workflow-enabled or non-workflow-enabled application 150, 154. The workflow may respond with a workflow instruction 166. A typical instruction is to update the ToDo. When a ToDo is updated, a plurality of consistency checks are performed. If all checks are successful, an asynchronous event is enqueued for delivery to the schedule which initiated the ToDo. Consistency checks include, but are not limited to, checks for synchronization, security, and data validity. In order to maintain database consistency, the enqueuing of the asynchronous event occurs in the same transaction as the update to the ToDo. Once an event is enqueued for delivery to the workflow schedule, the participant submitting the update is notified that the update has been successfully delivered.
Events may be delivered to a workflow asynchronously for a number of reasons. One reason is that an embodiment may allow only one instance of a schedule and the instance of the schedule may only be allowed to run on a single, arbitrary, middle-tier machine. Though it is possible to route a new event arriving on one middle-tier machine to a running schedule's instance on another middle-tier machine, such a mechanism adds unnecessary complexity to the overall design. So, in the case where the schedule is in an active running state, and assuming no routing mechanism exists to deliver new events to a running schedule, workflow events must be enqueued for consumption at a later time. Once there are pending events in a queue waiting to be consumed by their respective workflow schedule, a mechanism must be designed to dequeue the events. As it is inefficient to synchronously poll to see if a schedule is able to consume events, the dequeuing process is handled asynchronously. Relying upon an asynchronous dequeuing mechanism for event delivery also means that a single code path can be used in both the nominal code execution path, as well as the exceptional code path, i.e., where event delivery and consumption failed to complete and must be retried at a later time. Note that, if desired, the event queue may be a table in a database and not maintained in memory. This adds robustness to the design, guarding against catastrophic system failure.
Preferably, an event is dequeued directly by the workflow that owns the event once the workflow has been bootstrapped into a running state. Once running, the workflow consumes the events designated for the workflow by taking the events from the event queue in FIFO order. Events on the event stack designated for a workflow ultimately advance the workflow through the schedule causing the schedule to eventually complete.
In the herein described exemplary embodiment, WSS hosts the workflow engine, i.e., Windows Workflow Services, and provides persistent storage for the state of workflows. During the time that a workflow runs to completion, there are points at which the state of the workflow may be persistently stored. The state of a workflow may be captured and persistently stored at points explicitly defined in the schedule by the workflow developer or at points of acquiescence. A point of acquiescence is a point at which the workflow enters a state of acquiescence, i.e., a period of time in which no useful work or interaction happens. In essence, the workflow is waiting for a long and indeterminate amount of time for something to happen. When such a condition is detected, the workflow sets a transaction point. At a transaction point, a workflow collects data describing the internal state of the workflow and persistently stores the internal state data with the corresponding schedule in a database. Along with this transaction, other schema management may also occur. The workflow state of a schedule is stored in its serialized form in either binary or XML. At a transaction point, a workflow may be put into a state of “hibernation.” Workflow hibernation is a state in which a workflow schedule consumes no computing resources other than the static storage persisted in the database. For example, if all workflow threads are blocked on ToDo task completions and there are no pending events to be delivered to the workflow, the workflow's exclusive lock is released and the workflow is allowed to go into hibernation. Preferably, an active process continually monitors the event queue looking for events that need to have the workflows that own them woken up. Once such a workflow has been identified, a suitable middle-tier machine is designated as a host for the workflow. The binary code and state information for the workflow are loaded from persistent storage onto the host machine. The workflow is bootstrapped into a running state.
Supported by the aforementioned description of workflows, is a foregoing explanation of how a project manager, i.e., workflow owner, uses an embodiment of the invention running in a collaborative application such as SharePoint to create a workflow to manage a project. First, a workflow developer develops a workflow definition. The developer packages the workflow definition and installs the workflow definition on a server to enable the workflow owner to access the workflow definition. Then, the owner deploys the workflow definition, i.e., copies the workflow definition to use for a particular project. The owner enables, i.e., activates, the deployed workflow definition, associates the deployed workflow definition with the set of documents for the project, and instantiates the deployed workflow definition, i.e., creates the workflow for the project. Finally, the owner starts the workflow for the project. Thereafter and until the workflow is terminated, participants interact with the workflow by using GUI forms to complete tasks for the project and the owner uses GUI forms to check the progress and the like. The aforementioned process is referred to as the “workflow lifecycle” and is illustrated by the flow diagram in
As shown in
An example of a workflow is used to aid in understanding the detailed explanation of each stage. The exemplary workflow is used by a group of participants working on a project involving the development of video editing tool.
During the Development stage 200, the parts that comprise the workflow or workflow template are developed and/or gathered by a workflow developer or a workflow owner. Since the workflow developer plays the primary role in the development stage, only the workflow developer is referred to during the Development stage 200. The developed and/or gathered parts include, but are not limited to: (a) a workflow schedule; (b) views of data used by or related to the workflow; (c) computer-implemented forms supporting the workflow; and (d) metadata about the workflow. The developed and/or gathered parts may be created using computer applications like Microsoft Visual Studio© or Microsoft FrontPage©. During the Development stage 200, for each part in a workflow definition, an interaction may set up between the part and SharePoint and/or an application like Microsoft Office© running on client computing devices.
Although the developed and/or gathered parts may be created directly as described above, it is more advantageous to use a workflow template to create a workflow. A workflow is created from a workflow template by copying the workflow template and modifying the workflow template copy to change the workflow template copy into the desired new workflow. The workflow template allows the structure and metadata of a workflow developed for one project to be associated with other projects. Note that a workflow template is not a GUI form but, instead, is a set of workflow components which are then modified using GUI forms.
During the Development stage 200, forms are provided to enable a workflow developer to accomplish the aforementioned steps.
In the exemplary workflow “Send for Approval” step shown in
Note that certain terms in the conditions and actions illustrated in
Additional conditional branches may be created by selecting “Add Conditional Branch” 249. Selecting “Add Conditional Branch” 249 causes a new block of conditions and actions 247 to be inserted after the existing conditional branches. The type of each component within a block of conditions and actions may be selected using drop down menus. For example, on the left side of the block of conditions and actions 247, “Set Conditions” and “Actions” are selected from drop down menus. On the right side of the block of conditions and actions 247, the condition “when Amount is less than or equal to $1000” is selected from a drop down menu as is the condition “else when Amount is greater than $1000.”
Another activity supported during the Development stage 200 is associating a workflow with a document library.
In the exemplary embodiment of the invention described here, after a workflow is created during the Development stage 200, the workflow may be customized. An example of a GUI form 253 for customizing a workflow is shown in
In the example shown in
As shown in
Returning to
After being packaged, the workflow enters the Installation stage 208 (
After a workflow is installed, the workflow enters the Deployment stage 212 (
A document library may be involved in more than one project and, thus, may be associated with more than one workflow.
After a workflow is deployed, the workflow enters the Enablement stage 216 (
After a workflow is enabled, the workflow enters the Association stage 220 (
A content type is a collection of settings that can be applied to other content types or to lists (where a document library is a type of list). For example, a content type for a Specification might define columns of metadata on a document library list for inputting the Specification Writer, Specification Implementer, and Specification Area of a Specification document. The Specification content type might include a default document template to use when creating new documents of this content type. When the Specification content type is added to a document library, its setting are copied to the document library and users of the document library can save items or documents of that content type to the document library. Note that multiple content types can be added to the same list or document library, and that content types can also be added to other content types. A workflow association is a type of setting that can be added to content types. For example, one might add a Specification Approval workflow association to the Specification content type, and that workflow association will get copied to lists that Specification content type is added to. Subsequent changes to the workflow association on the Specification content type can be pushed down to document libraries that inherit from that content type, enabling site administrators to configure workflow settings in one place and broadcast them to a number of other places.
Workflow association also may be accomplished by using a specific kind of GUI form, the workflow association form. Such a form is used to collect workflow parameters and restrictions from a list or from a profile manager. A workflow association form is defined in the workflow package that installed on the server and enabled on the site or site collection.
After a workflow is associated, the workflow enters the Instantiation stage 224 (
Starting a workflow activates the schedule that is associated with the workflow and runs in the workflow engine 170 (
A workflow owner may generate a variety of reports about a workflow using the exemplary GUI form 622 shown in
In the exemplary workflow lifecycle shown in
Regardless of how the workflow was deleted, SharePoint waits a user-configurable number of days, e.g., 90 days, to allow the owner of a workflow to delete the workflow or restart it 712. If a workflow is not restarted after ninety days, the workflow tasks are deleted from SharePoint and no longer tracked 716.
Embodiments of the invention may provide status information about a workflow such as real-time status for specific workflows and aggregated information about a set of workflows. For example, an embodiment of the invention may provide a collection of approval comments for an item in a workflow, a collection of approvers who have signed off on certain items, a set of workflows that are currently active and in use, or metrics for various aspects of a business process.
While the present preferred embodiment of the invention has been illustrated and described, it will be appreciated that various changes can be made therein without departing from the spirit and scope of the invention. For example, within the context of SharePoint, a workflow may be associated with, or operate with, many kinds of forms including, but not limited to, a standard Microsoft Outlook message form. Also within the context of SharePoint, an embodiment of the invention may operate with a custom user interface comprising custom fields and other controls. While the embodiments of the invention described above are used for business processes having to do with the development and maintenance of Web sites in the context of SharePoint, it will be appreciated that the invention may be applied to other types of business processes in other contexts. In this regard it should be understood that the invention can be implemented other than in connection with SharePoint. Thus, it is to be understood that within the scope of the appended claims this invention can be practiced otherwise then as specifically described herein.
Pursuant to 35 U.S.C. § 119, this application claims the benefit of the filing date of Provisional Patent Application No. 60/614,096, filed Sep. 29, 2004, titled WORKFLOW IN A COLLABORATIVE APPLICATION, the subject matter of which is also incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
60614096 | Sep 2004 | US |