Framework to model and execute business processes within a collaborative environment Number:7,386,797 from the United States Patent and Trademark Office (PTO) owispatent A mechanism of specification of business process templates, to capture commonly performed business activities/workflows/projects within a business organization and encourage reuse of best practices. Long transaction workspaces based business process template execution mechanism are presented, which have several advantages over existing business process execution mechanisms in web collaboration frameworks. This execution approach provides support for an isolated environment for business process execution. This isolates the changes made on different resources while executing a business process from the external world until the business process completes. It enables the ability to concurrently manipulate same resources in different components of a business process, and later resolve conflicts if any and merge the different views of the same resource manipulated by different components of a business process. It also enables easy and effective mechanisms for error recovery and rollback during business process execution.<H collaborative, environment, Framework, to, mo, 7386797.html, Patent, pto, 7386797

Title: Framework to model and execute business processes within a collaborative environment

Abstract: A mechanism of specification of business process templates, to capture commonly performed business activities/workflows/projects within a business organization and encourage reuse of best practices. Long transaction workspaces based business process template execution mechanism are presented, which have several advantages over existing business process execution mechanisms in web collaboration frameworks. This execution approach provides support for an isolated environment for business process execution. This isolates the changes made on different resources while executing a business process from the external world until the business process completes. It enables the ability to concurrently manipulate same resources in different components of a business process, and later resolve conflicts if any and merge the different views of the same resource manipulated by different components of a business process. It also enables easy and effective mechanisms for error recovery and rollback during business process execution.

Patent Number: 7,386,797 Issued on 06/10/2008 to Chatterjee, et al.

Inventors: Chatterjee; Raja (Nashua, NH), Dhuleshia; Amit (North Andover, MA)
Assignee: Oracle Corporation (Redwood Shores, CA)

Appl. No.: 10/154,152

Filed: May 22, 2002

Current U.S. Class: 715/751 ; 705/1; 715/229; 715/759; 715/965

Field of Search: 700/100 707/10,100,103 705/2,8,1 715/500,751,864,229,759,965 718/102

References Cited [Referenced By]

U.S. Patent Documents


4875162	October 1989	Ferriter et al.
5193186	March 1993	Tamaki et al.
5301320	April 1994	McAtee et al.
5655118	August 1997	Heindel et al.
5671360	September 1997	Hambrick et al.
5671428	September 1997	Muranaga et al.
5737727	April 1998	Lehmann et al.
5819270	October 1998	Malone et al.
5890133	March 1999	Ernst
5923552	July 1999	Brown et al.
5966707	October 1999	Van Huben et al.
5974468	October 1999	Taylor et al.
6023702	February 2000	Leisten et al.
6026365	February 2000	Hayashi
6044354	March 2000	Asplen, Jr.
6058395	May 2000	Buzaglo et al.
6065011	May 2000	Bulusu et al.
6073108	June 2000	Peterson
6101481	August 2000	Miller
6212549	April 2001	Page et al.
6339838	January 2002	Weinman, Jr.
6349298	February 2002	Malone et al.
6449624	September 2002	Hammack et al.
6539404	March 2003	Ouchi
6571246	May 2003	Anderson et al.
6604124	August 2003	Archbold
6606740	August 2003	Lynn et al.
6609100	August 2003	Smith et al.
6678716	January 2004	Pronsati et al.
6714913	March 2004	Brandt et al.
6754677	June 2004	Cho et al.
6763353	July 2004	Li et al.
RE38633	October 2004	Srinivasan
6816902	November 2004	Bandat et al.
6817008	November 2004	Ledford et al.
6853974	February 2005	Akifuji et al.
6877153	April 2005	Konnersman
6895573	May 2005	Norgaard et al.
6920474	July 2005	Walsh et al.
6928447	August 2005	Kaler et al.
6938240	August 2005	Charisius et al.
6968343	November 2005	Charisius et al.
7096222	August 2006	Kern et al.
2001/0044738	November 2001	Elkin et al.
2002/0065701	May 2002	Kim et al.
2002/0077842	June 2002	Charisius et al.
2002/0078432	June 2002	Charisius et al.
2002/0184070	December 2002	Chen et al.
2002/0188597	December 2002	Kern et al.
2003/0004771	January 2003	Yaung
2003/0005406	January 2003	Lin et al.
2003/0036940	February 2003	Leymann et al.
2003/0050886	March 2003	Cohen et al.
2003/0126004	July 2003	Miller et al.
2003/0182172	September 2003	Claggett et al.
2003/0195785	October 2003	Thalangara et al.
2003/0236689	December 2003	Casati et al.
2003/0236693	December 2003	Chen et al.
2004/0054985	March 2004	Sewell
2004/0078777	April 2004	Bahrami
2004/0103393	May 2004	Reddy et al.
2004/0233056	November 2004	Pulfer
2005/0257136	November 2005	Charisius et al.
2005/0267795	December 2005	Tian et al.

Other References

Leymann F et al, "Workflow based applications", 1997 IBM Systems Journal vol. 36 No. 1 pp. 1-17. cited by examiner .
Rational Software et al. "Rational Clearcase: Managing Software Projects" Oct. 2001. cited by examiner .
Rational Software et al. "Rational Clearcase: MultiSite user manual" Aug. 2000. cited by examiner .
Documentum Inter-Enterprise Workflow Services Product Data Sheet, 2002 Documentum, Inc., taken from www.documentum.com (2 pages). cited by other .
Lotus Workflow, taken from www.lotus.com/products/domworkflow.nsf (2 pages), Oct. 28, 2002. cited by other .
Microsoft SharePoint Portal Server Product Overview, 2003 Microsoft Corporation, taken from www.microsoft.com/sharepoint/server/evaluation/overview (6 pages). cited by other .
SiteScape Workflow, SiteScape The Collaboration Company, taken from www.sitescape.com/next/p.PDF, Apr. 2001 (1 page). cited by other .
OnProject Enterprise Platform, 1999-2003 onProject, Inc., taken from www.onproject.com/con.sub.--Brands/onproject/cfm.sub.--HomePage/products/- enterprise.cfm (1 page). cited by other .
Mangomind and the Security of Your Data on the Internet; Mangosoft, Inc.; pp. 1-5, Copyright Oct. 2000, taken from www.mangosoft.com. cited by other .
Mangosoft: Secure File-Sharing Services over the Internet; Doug Chandler; pp. 1-11, Copyright 2001, taken from www.mangosoft.com. cited by other .
The Business Internet File Service.sup.SM; Doug Chandler; pp. 1-9 Copyright Oct. 2000, taken from www.mangosoft.com. cited by other .
Website: www.mangosoft.com. cited by other.

Primary Examiner: Lo; Weilun
Assistant Examiner: Theriault; Steven B.

Claims

What is claimed is:

1. A method of executing a project within a collaborative environment in a relational database system comprising: creating at least one task type, each task type modeling a task in a business process; creating at least one tasklist template, each tasklist template comprising an ordered set of task types connected to each other via task associations; detecting an occurrence of a tasklist trigger event of a child project; associating a task list template with each child project of the project template corresponding to a resource associated with the tasklist trigger event; automatically invoking execution of the tasklist template; creating a parent workspace in the system for executing the parent project and at least one child workspace in the system for each child project of the parent project as defined by the task list template, wherein each child workspace is isolated from the parent workspace and configured to operate on data content of the parent workspace concurrently with any other child workspace and independently of any other child workspace; executing each task type of each child project defined by the task list template in a respective child project task workspace each task type being executed in an isolated environment independent of any other task type; merging data content of each child project task workspace back to the child project workspace at any point during execution of a respective task; making the data content of each task workspace merged back to the child project workspace from which the task was created visible to all other child workspaces of the child project workspace at the time the data content is merged; and merging a content of each child workspace back to the parent workspace in the system.

2. The method of claim 1 further comprising after executing each child project task: executing, if any, each subsequent child project of each preceding child project in a respective subsequent child workspace, wherein activities of each subsequent child project continue concurrently in an isolated environment; executing remaining subsequent child projects in a similar fashion along a hierarchical chain of preceding projects and subsequent projects until all subprojects of the parent project are executed; and merging each subsequent child workspace in the hierarchical chain back to a respective preceding workspace, wherein changes in each subsequent child workspace are visible in the preceding project workspace, the step of merging continuing until each child workspace is merged into the parent workspace.

3. The method of claim 1 further comprising, after execution of each child project of the parent project, creating a save-point in each respective child workspace corresponding to an executed version of each child project, wherein a user can roll back to any save-point during execution of the project in order to bring project data to a consistent state.

4. The method of claim 1 further comprising creating a save-point during each project execution allowing a user to roll back to a previously created save-point to bring project data to a consistent state.

5. The method of claim 4 further comprising rolling back data and resources of the child workspace to a state of a save-point that was previously created.

6. The method of claim 1 wherein creating a parent workspace or child workspace further comprises granting read/write privileges on each created workspace and on data elements of each workspace to at least one user responsible for executing the project.

7. The method of claim 1 wherein executing each subsequent child project further comprises granting new workspace and data item privileges to users of the subsequent child project.

8. The method of claim 1 wherein creating a child workspace further comprises: defining a project type in order to create a instance of the project type; and beginning the project instance, including changing a status of the project to STARTED.

9. The method of claim 1 wherein creating a child project task workspace for each child project of the parent project further comprises; determining if any of each child project is a compound project, wherein each compound project includes sub-projects; and creating another workspace for each sub-project of each compound project, wherein a hierarchy of workspaces is created to execute a hierarchical compound project.

10. The method of claim 1 further comprising: determining, after merging, if the data content operated on in one child project task was also modified in a sibling child project task, wherein a conflict resolution is performed on a content of the child workspace; freezing the child workspace so no more work can be done in that project; and changing a status of the project to reflect that the project is ENDED.

11. The method of claim 1 wherein the project includes one or more tasklists, and wherein each tasklist can be adapted to be executed within the project.

12. A system comprising: at least one processor for modeling and executing tasklists within a collaborative environment in a database system a workspace manager in the at least one processor configured to support workspaces in the database system for performing tasks and create a child workspace for each child project; a tasklist template manager in the at least one processor configured to model at least one tasklist, wherein each tasklist comprises one or more tasks to be performed in workspaces, each workspace configured to be isolated and independent from any other workspace; and a tasklist manager in the at least one processor configured to detect an occurrence of a tasklist trigger event of a child project, associate a stored tasklist template with the child project, and automatically invoke execution of the stored tasklist template using a set of workspaces in the database system, wherein the tasklist manager is configured to create a task workspace in the workspace manager for each task in the tasklist as modeled by the tasklist template and wherein the tasklist manager provides an isolated environment for task execution by executing each task within a respective task workspace and publishing data content of each task to the child workspace from the respective task workspace at any point during execution of the task, where any other task created within the child workspace can view data content published to the child workspace.

13. The system of claim 12 wherein when the tasklist manager creates a task workspace, the tasklist manager is adapted to grant read/write privileges on the workspace and on data elements of the workspace to users responsible for executing the task.

14. The system of claim 12 wherein the workspace manager is adapted to support a creation of save-points that can be used to roll back to a previous consistent state in case of exceptions or errors encountered during execution of a task.

15. The system of claim 12 wherein a workspace provides an isolated environment for task execution so that task execution action does not affect an external environment until all tasks in the tasklist are completed successfully.

16. The system of claim 12 wherein the tasklist manager is adapted to create, merge and abort task workspaces automatically based on task operations.

17. The system of claim 12 wherein the tasklist manager is adapted to initialize and associate all task and tasklist attributes to task and tasklist instances, respectively.

18. The system of claim 12 wherein the collaborative environment comprises an Internet collaboration environment, wherein the modeling and execution of business process occurs by multiple people at different geographic locations communicating by collaborating with a web browser.

19. A computer program product stored in a memory comprising: a computer useable medium having computer readable code means embodied therein for causing a computer to execute a project within a collaborative environment in a database system, the computer readable code means in the computer program product comprising: computer readable program code means for causing a computer to create a parent workspace in the database system for a parent project and at least one child workspace in the database system for each child project of the parent project, wherein each child workspace is isolated from the parent workspace and configured to operate on data content of the parent workspace concurrently with any other child workspace and independently of any other child workspace; computer readable program code means for causing a computer to create at least one task type, each task type modelling a task in a business process, and at least one tasklist template comprising an ordered set of tasks connected to each other via task associations; computer readable program code means for causing a computer to detect an occurrence of a tasklist trigger event of a child project and associate a task list template with the child project; computer readable program code means for causing a computer to automatically invoke execution of the associated tasklist template for each task of each child project in a respective child project task workspace, each task being executed in an isolated environment independent of any other task; computer readable program code means for causing a computer to merge data content from each child project task workspace back to the child project workspace at any point in time during execution of a respective task; computer readable program code means for causing a computer to make the data content of each task merged to the child workspace visible to all other child workspaces at the time the data content is merged; and computer readable program code means for causing a computer to merge a content of each child workspace back to the parent workspace.

20. An article of manufacture comprising: a computer useable medium having computer readable code means embodied therein for causing a computer to execute a project within a collaborative environment in a database system, the computer readable code means in the computer program product comprising: computer readable program code means for causing a computer to create a parent workspace in the database system for a parent project and at least one child workspace in the database system for each child project of the parent project, wherein each child workspace is isolated from the parent workspace and configured to operate on data content of the parent workspace concurrently with any other child workspace and independently of any other child workspace; computer readable program code means for causing a computer to create at least one task type, each task type modelling a task in a business process, and at least one tasklist template comprising an ordered set of tasks connected to each other via task associations; computer readable program code means for causing a computer to detect an occurrence of a tasklist trigger event of a child project and associate a task list template with the child project; computer readable program code means for causing a computer to automatically invoke execution of the associated tasklist template for each task of each child project in a respective child project task workspace, each task being executed in an isolated environment independent of any other task; computer readable program code means for causing a computer to merge data content from each child project task workspace back to the child project workspace at any point in time during execution of a respective task; computer readable program code means for causing a computer to make the data content of each task merged to the child workspace visible to all other child workspaces at the time the data content is merged; and computer readable program code means for causing a computer to merge a content of each child workspace back to the parent workspace.

21. The method of claim 1 further comprising, when the child project begins, refreshing data related to the task from the parent project to the child project, the refreshed data including changes received by the parent workspace from each child workspace that has merged to the parent workspace.

22. The method of claim 1 further comprising merging each child workspace back to the parent workspace at any point in time during execution of the child project in the child workspace.

23. The method of claim 1 further comprising merging one child workspace back to the parent workspace independently of any other child workspace.

24. The method of claim 1 further comprising merging at least one child workspace back to the parent workspace and refreshing the at least one child workspace with data from the parent workspace when execution on the at least one child workspace resumes, the data from the parent workspace including changes received from other executing child workspaces that have merged back to the parent workspace.

25. The method of claim 1 further comprising: intermittently merging data content from the at least one child workspace back to the parent workspace during execution of the project in the at least one child workspace prior to completion of the respective child project; and refreshing data from the parent workspace to the at least one child workspace prior to resuming execution of the at least one child workspace, the refreshed data including at least partially completed results received from at least one other child workspace that has merged its data content back to the parent workspace.

26. The method of claim 1 further comprising executing each task by; determining a type of a current task to be executed; if the current task is not a compound task, executing a specified procedure for the current task in a current task workspace; and if the current task is a compound task, activate a first level child task by creating a sub-workspace for each first level child task where each first level child task will be executed, each sub-workspace configured to operate on common data elements of the data content in an independent and isolated environment.

27. The method of claim 26 further comprising: determining if a next task to be executed is a sequential task, and if so, creating a savepoint for the current task being ended in the current task workspace; and determining if the current task being ended is a parallel task, and if so, merging the ended current task in the sub-workspace back to the child project task workspace.

28. The method of claim 1 wherein the parent workspace is geographically dispersed from the child workspace, each child workspace is geographically dispersed from any other child workspace.

29. The method of claim 1 wherein the parent and child workspaces are accessible in an online environment.

30. The method of claim 1 wherein changes made to data content in each child-project task workspace are not visible to other users of the data content until the data content from a respective child project task workspace is published from the respective child project task workspace to the child workspace.

31. The method of claim 1 further comprising that each child workspace is configured to operate on data content from the parent workspace, wherein the data content being operated on in each child workspace is the same data content.

32. The method of claim 1 wherein the data content is relational database content.

33. The method of claim 1 further comprising refreshing content on demand or periodically from the parent project workspace to the child project workspace at anytime during a lifetime of the child project.

34. The method of claim 1 further comprising refreshing content on demand or periodically from the parent project workspace to the child task workspace at anytime during a lifetime of the child task.

35. The method of claim 1 further comprising: defining at least one project/task template; defining a triggering event to automatically invoke application of the at least one project/task template; and automatically executing the at least one project/task template in a respective workspace when the triggering event occurs.

36. The method of claim 35 further comprising automatically creating a project/task workspace corresponding to the at least one project/task template in response to the triggering event.

37. The system of claim 12 wherein the tasklist template further comprises a document type definition that is automatically invoked in response to a triggering event to automatically instantiate an instance of the tasklist.

38. The method of claim 1 wherein the task type comprises a task name, a task description and task data and resources which need to be operated on inside the task.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is generally related to business processes, and more particularly to the modeling and execution of a business process within a collaboration environment.

2. Brief Description of Related Developments

The advent of the Internet has eased the global presentation and distribution of information. The Internet has been used for collaboration purposes for several years now. There are many software vendors that provide a collaboration environment over the web. But there is a lack of a framework to model and execute real-world business processes in existing collaboration environments over the web.

Traditional workflow modeling and execution is designed to integrate business processes across heterogeneous systems, by modeling and executing control flow across systems. Traditional workflows do not address modeling of business organization structure and data sharing and merging within the hierarchy, which typically occurs during the execution of a complex business process.

Commercial Collaboration system like eRoom.TM. (ER), Sitescape.TM. (SI), on Project.TM. (OP), Microsoft SharePoint Portal Server.TM. (MSP), IBM's Quickplace.TM. (IBMQ) provide a comprehensive collaboration framework including sharing of content (file content and limited support for database content) and interaction between project members. These traditional frameworks do not have proper support for collaboration during long duration projects involving relational database content.

Collaboration frameworks mentioned above also do not have proper support for modeling hierarchical project structures. Hierarchical project structures have to provide support for merging both relational and file/folder content across a hierarchy. WEBDAV (WDAV) based collaboration systems do provide support for hierarchical project structures. However, WEBDAV does not natively address the type of content being shared. So, any system built using this specification has to address the problem of support for collaboration on relational content. The non-WEBDAV based collaboration systems do not contain a framework to model hierarchical projects. Also, none of the above mentioned collaboration systems support business processes based on long-transaction frameworks.

Existing web collaboration frameworks do not have a proper framework support for specifying and executing any arbitrary business process. Also, their business process execution frameworks do not provide proper support for isolated business process execution environment, so that the changes to the resources during the business process execution are not exposed to the external world until the business process is terminated properly. They also lack fine-grained access control support on the resources being manipulated during a business process execution. These frameworks also do not support for creating savepoints and rolling back to savepoints (markers to which data in a long transaction can be rolled back to).

The existing web collaboration frameworks does not provide proper support for concurrent updates of the same resource in parallel steps of a business process and then an ability to merge the different views of the same resource from different parallel steps at synchronization time with conflict resolution.

SUMMARY OF THE INVENTION

The present invention is directed to a method of executing a project within a collaborative environment. In one embodiment, the method comprises creating a parent workspace for a parent project and a child workspace for each child project of the parent project. Each child project of the parent project is executed in a respective child workspace, wherein activities of each child project of the parent project continue concurrently in an isolated environment. Each executed child workspace is merged back to the parent workspace so that changes in each child workspace are visible within the parent.

In another aspect, the present invention is directed to a method for collaborative execution of a tasklist. In one embodiment, the method comprises defining the tasklist, where the tasklist includes at least one task to be performed. A workspace for executing the tasklist is created. The tasklist is begun by changing its status to STARTED. If there are multiple start/first tasks within the tasklist, then a workspace is created for each first task. Each first task changes its status to be ACTIVE, so that these tasks can be now started by their respective users. In case the tasklist contain only one first task, then this task can be executed within the tasklist workspace. A tasklist is a set of inter-dependent tasks. Each task can be simple or compound and each compound task includes a number of tasks. A compound task can have one or more first tasks. A first task is executed in the tasklist and its status is changed from ACTIVE to STARTED. A save point corresponding to the completed first task is created in the respective sub-workspace. A next task is executed and a save point is created in the respective workspace. In case the next task is related to the current task via sequential/branch/loop association, then the next task is executed in the same workspace as the current task. If the next task is associated to the current task via parallel association then it is executed in a child workspace of the workspace where the current task is being executed. After the parallel task is over, then the content of the child workspace is merged into its parent task workspace.

When a task is compound, then if the compound task has one first task, that task is executed in the compound tasks workspace. In case the compound task has multiple first tasks, then a child workspace of the compound tasks workspace is created for each first task of the compound task. After all the tasks in the compound task are completed, then all the child workspaces created for the first tasks are merged to the compound tasks workspace, so that it can contain all the data changes made by all the tasks of the compound task.

The step of executing a next task in the tasklist in the dependent chain of tasks is repeated until all tasks in the dependent chain are completed. If the tasklist had multiple first tasks, then those task workspaces are merged into tasklist workspace, so that the tasklist workspace has all the data changes made by all the tasks in the tasklist. In case the tasklist had only one first task, then the tasklist workspace will already have all the data changes made by all the tasks in the tasklist. When the tasklist has ENDED, then the content of the tasklist workspace is merged into the workspace which started/instantiated the tasklist.

In a further aspect, the present invention is directed to a system for modeling and executing tasklists within a collaborative environment. In one embodiment the system comprises a workspace manager adapted to support workspaces for performing tasks. The system also includes a tasklist template adapted to model a tasklist, wherein a tasklist comprises one or more tasks to be performed in workspaces. A tasklist manager is also included that is adapted to execute a tasklist using a set of workspaces, wherein the tasklist manager is adapted to create a workspace in the workspace manager for each tasklist as modeled by the tasklist template. The tasklist manager provides an isolated environment for task execution by executing each task within a workspace.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and other features of the present invention are explained in the following description, taken in connection with the accompanying drawings, wherein:

FIG. 1 is a block diagram of one embodiment of a collaborative framework system incorporating features of the present invention.

FIGS. 2-5 are illustrations of different task associations that can be implemented and executed in a collaborative framework system incorporating features of the present invention.

FIG. 6 is an illustration of a project structure and a corresponding workspace structure that can be implemented and executed in a collaborative framework system incorporating features of the present invention.

FIG. 7 is an illustration of a hierarchical project structure that can be executed by a system incorporating features of the present invention.

FIG. 8 is an illustration of different states of a project in a collaborative framework system incorporating features of the present invention.

FIG. 9 is a flow chart of one embodiment of an application scenario for a collaborative environment in a geographical information system.

FIG. 10 is a block diagram of another project workspace hierarchy according to aspects of the present invention.

FIG. 11 is an example of one embodiment of an apparatus that can be used to practice the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(s)

Referring to FIG. 1, a block diagram of a system 10 incorporating features of the present invention is illustrated. Although the present invention will be described with reference to the embodiment(s) shown in the drawings, it should be understood that the present invention can be embodied in many alternate forms of embodiments. In addition, any suitable size, shape or type of elements or materials could be used.

As shown in FIG. 1, the system 10 generally comprises a collaborative framework including a workspace manager 110, a business process manager 114. The business process manager generally has two components, the tasklist manager 112 and the project manager 111. The tasklist manager 112 is generally responsible for interpreting tasklist template, and instantiating and managing the tasklist instances. The project manager 111 is generally responsible for interpreting project templates, and instantiating and managing project instances. In alternate embodiments, the system 10 can include such other suitable components for modeling and executing real-world business processes in collaboration environments. It is a feature of the present invention to be able to allow multiple users at various locations to communicate and collaborate within the collaboration environment with only a web browser.

In this invention, by business process, we generally refer to two concepts. The first is tasklist, which is a set of inter-dependent tasks performed to accomplish a business goal. One example of a tasklist is the approval of the routing of a business document. An approval routing tasklist could involve the following tasks, EDIT, FIRST ROUND REVIEW (FRR), SECOND ROUND REVIEW (SRR), and APPROVE. The above tasks are generally performed in the order they appear. Also, if the FRR is successful, then SRR starts, otherwise the EDIT task is executed again. If the SRR is successful, then APPROVE task is invoked, or else the EDIT task is executed again. Once the APPROVE task is performed the tasklist is completed.

The second concept referred to in the business process is a project, which is an undertaking in a business organization. A project can involve multiple independent tasklists spanning across different levels in a business organization hierarchy, generally performed by a group of users to achieve a business goal. One example of a project is "IT Rollout of status report". For example, IT Rollout of status report might involve the technology organization group of a company which has three sub-groups. First, the three sub-groups perform some tasklist (which may be different from one another) to generate their individual status report, which is then rolled up to the parent top-level group. The parent top-level group can invoke its own tasklist to integrate the three status reports into one, and sends it to the Chief officer of the technology organization group.

The collaborative framework of the present invention shown in FIG. 1 generally provides support for long transactions, hierarchical projects and tasklists. The collaborative framework of the present invention provides long-transaction-based workspaces 120, such as those shown in FIG. 1, which are the basic containers for collaboration in the collaboration framework. The present invention allows multiple users 116 to modify the same content concurrently in a transitionally consistent manner, and satisfying, for example, ACID properties (JG) across long duration projects. The present invention also provides support for conflict detection and resolution.

The collaboration framework executes business processes defined or specified in the business process manager using the hierarchical set of workspaces 120. This execution mechanism benefits from all the properties of long-transaction based workspaces such as isolation, fine-grained access control, rollback to save-points, and concurrent updates of the same content from parallel steps of a business process.

The present invention generally supports two types of templates, tasklist templates and project templates. The tasklist templates and project templates can be used to model business processes which contains a set of action(s)/task(s) which are performed on certain resources. A tasklist template/type will contain one or more dependent/independent task types/templates, task users(s) and task data, such as for example, the approval routing of business documents. A project template can contain one or more sub-project types, each of which can contain multiple tasklist templates, user(s) and data, such as for example, IT Rollout of status reports within a business organization.

A tasklist is an ordered set of tasks performed to achieve a business goal. The tasklist manager 112 generally provides or models the business process specifications. A task can be automatic (for example, execution of a user-defined procedure) or manual (for example, editing a file). A task can be simple or complex in nature, and may require multiple users 116 to complete it. It can operate on single/multiple resources. The business process manager 114 component of the collaborative framework shown in FIG. 1 supports tasklist template and project template specification, instantiation and execution. The tasklist manager 112 executes tasks using a set of workspaces 120. It should be noted that the workspaces 120 can comprise task workspaces or project workspaces. A different set of operations can be associated with task workspaces and project workspaces, respectively. The workspaces 120, whether task workspaces or project workspaces, generally comprise an environment where work can be done. The environment can comprise a computer medium. A project workspace can include one or more task workspaces. However, a task workspace cannot include a project workspace.

A task type models a task in a tasklist. A task type generally comprises a task name, task description, and task data/resources, which need to be operated on inside the task. A task is an operation performed inside a workspace 120. A task is part of a tasklist and can be manual or automatic. A task can be simple or compound in nature. A compound task generally comprises simple tasks associated with each other by control flow or workflow associations, such as for example Sequential, Parallel, Synchronization, Loop or Branch workflow associations. A task can also have before/after email, alert or callback actions. A task type can model a simple unit of work or a compound unit of work (i.e. an ordered set of task types connected to each other via task associations). Examples of task associations are illustrated in FIGS. 2-5.

Such tasklist can be instantiated directly on resource instances within any workspace 120.

Some examples of tasks in a tasklist related to a salary report are: EDIT REPORT REVIEW REPORT CALCULATE SALARY CHECK SPELLING/GRAMMAR

A tasklist can be triggered by either system/user defined events or explicit invocation.

Examples of events that can trigger a tasklist invocation can include: Uploading a file within a workspace; Updating a database row within a workspace; Explicit invocation within a workspace.

A tasklist can be attached to any resource entity within a workspace (file, folder, dbtable, dbrow, workspace, chart, poll).

Examples of tasklist include:

Analyzing a chart when it gets generated; Analyzing a poll when it is updated; Reviewing/Approving a file after it is uploaded; Reviewing/Approving a database row after it is updated; or

Referring to FIG. 1, a tasklist template corresponding to any one of these tasklists, among others can be defined by and made available within workspaces 120.

The workspace users 116 can attach tasklist to resources on certain system/user events or explicitly invoke tasklist on resource entities, or independently without any resource association.

One example of invoking a tasklist on a data entity within a workspace 120 is illustrated below. The tasklist in this case comprises approving a document.

In this example, the input resource is the document to be reviewed. The tasklist as modeled by the tasklist template of FIG. 1 is the approval process. After the approval process is complete, the output resource in the case will be the updated document after review or the original document and the comments or review data.

TABLE-US-00001 Input (Resource) - - - - - - .fwdarw. Task List - - - .fwdarw. Output (Document to be reviewed) (Approve) (Resource, updated or original + status and comments data)

A task type has a number of task users who can perform the task. Each task type can also include a number of user-defined attributes, which can better describe the task, and a system defined "status" attribute, which represents the current state of the task. The "status" attribute value can be INACTIVE, ACTIVE (this is the state when it is ready for getting started), STARTED, ENDED and ABORTED. Each task type can have before begin, and after end callbacks, which will be executed before the task is begun and after the task is ended respectively.

A tasklist type is an ordered set of task types connected to each other via task associations. A tasklist template/type, has a name, set of user-defined attributes and a system defined "status" attribute, which represents the current state of the tasklist (which can be either STARTED or ENDED). In one embodiment, the tasklist type definition can be defined as XML DTD, and users can specify their tasklist types in XML conforming to the DTD.

The workspace manager 110 generally provides an extensible business process modeling and execution framework. For example, the Workspace Manager 110, has support for workspaces 120. In one embodiment, the workspaces 120 comprise eWorkspaces. A workspace 120 can be a virtual container in the web (Internet) where people can aggregate resources, communicate with each other via, email, alerts, discussion list, polls and other collaborative components and share information. In alternate embodiments, a workspace 120 can comprise any suitable collaboration medium. The workspace 120 provides a collaborative environment that is extensible to allow incorporation of new collaborative resources to enhance collaboration within a workspace. Industries and lines of business define processes to increase productivity, and obtain predictable and successful outcomes. Tasklist templates, which define and encourage reuse of best practices are instantiated and executed by creating task workspaces automatically.

The tasklist manager 112 shown in FIG. 1 can be used to model a business process like Approval routing or HR Recruiting etc. The tasklist manager 112 is adapted to specify or model useful activity/set of activities (automatic/manual) that are performed within a workspace 120 set of workspaces to achieve a business goal. It can be simple or complex in nature, and may require multiple users/roles to complete it. The tasklist template 112 can operate on single/multiple resources.

The tasklist manager 112 of FIG. 1 provides an isolated environment for task execution by executing the task operations (which may be manual or automatic) within a workspace 120. Referring to FIGS. 2-5, initially, the tasklist manager 112 creates a workspace (w) for each tasklist (t1). In FIG. 2, the first task (ts1) in the tasklist is executed in a workspace (ws1, child of w). After task (ts1) is complete, then the next task (ts2) is executed in the same workspace (ws1) after creating a save-point (sp_ts1) corresponding to executed task (ts1). This ensures that task (ts2) can see the end results of task (ts1).

In FIG. 3, the first task (tp1) in the tasklist is executed in workspace (wp1, child of w). After tp1 is complete, a save-point sp-tp1 is created in wp1. Since the next tasks, tp2 and tp3, are parallel tasks, the tasklist manager 112 creates child workspaces (wp2 and wp3) of wp1 for each task tp2 and tp3. Then the process executes tasks tp1 and tp3 in parallel in wp2 and wp3 respectively. Both tp2 and tp3 can see the data changes made by tp1 (since wp2 and wp3 are child workspaces of wp1), and they can operate independently on the same data elements. After they are done, the workspaces wp2 and wp3 are merged to workspace wp1, and the corresponding save-points (sp-tp2 and sp-tp3) are created in wp1. Finally, the task (tp4) gets executed in wp1, so that task (tp4) can see the changes made by both the parallel branches of tasks tp2 and tp3.

In FIG. 4, the first task (tb) in the tasklist is executed in a workspace (wb, child of w). After first task tb is complete, a save-point sp-tb is created in wb. Then, the next task to be executed can be any one of tb1 to tb-n, depending on whether one of "Condition-1" to "Condition-n" evaluates to true. In the case where "Condition-1" evaluates to true, then tb1 is executed in the workspace wb, which contains the changes made by task tb1. In the case where the "Condition-2" evaluates to true, then the task tb2 is executed in workspace wb. As shown in FIG. 4, the tasklist can include any number of conditions, tb1 to tb-n. During execution, each branch condition can be analyzed and executed, if applicable.

In FIG. 5, the first task (t11) in the tasklist is executed in a workspace (w11, child of w). After t11 is complete, a save-point sp-t11 is created in workspace w11. Then, the next task (t12) is executed in workspace w11. Thereafter, if the "Loop-Condition" expression evaluates to true, t11 is again executed in workspace w11, followed by the execution of t12. This execution process continues until the "Loop-Condition" evaluates to false. Then, a save-point sp-t12 is created in workspace w11. Finally, the task t13 gets executed in workspace w11. It should be noted that although only a single loop is illustrated in FIG. 5, a tasklist could include any desired number of loops or loop-conditions.

When the tasklist (t1) ends, the content of the workspace (w) that was created for the tasklist is merged to the parent workspace where the tasklist was instantiated.

When the tasklist manager 112 of FIG. 1 creates a workspace 120 for executing a certain task, it grants read/write privileges on the workspace 120 and on the data elements of the workspace 120 to the users responsible for executing the task. When one task (t) terminates and another serial task (t') begins in the same workspace, all the workspace privileges and the data item privileges from users of task t are revoked, and all the appropriate workspace/data item privileges are granted to the users of t'. Because the tasklist manager 112 executes tasks in a workspace 120, it can take advantage of all the functionality provided by the workspace infrastructure.

Workspaces 120 support creation of save-points, which can be used to rollback to a previous consistent state in case of exceptions/errors encountered during the execution of a task. Workspaces 120 provide an isolated environment for task execution, so that external work is not affected by the task action consequences until the whole tasklist is completed successfully. In case of system exceptions/errors, the whole tasklist can be aborted, along with the workspace in which it was getting executed, so it can be restarted again later.

The tasklist manager 112 is generally responsible for creating, merging, and aborting the task workspaces 120 automatically based on the task operations. Tasklist manager 112 initializes and associates all of the task and tasklist attributes (if any) to the task and tasklist instances respectively.

Some of the various business operations a user can invoke, and the corresponding actions taken by the tasklist manager 112 are described below.

The user 116 can define a tasklist template/type. The tasklist manager 112 can parse and store the tasklist type specification in the system meta data, which will be later used to create instances of that type via the tasklist manager 112.

A user 116 can also drop a tasklist type. The tasklist manager 112 will drop the system meta data corresponding to that tasklist type. This step fails if there are running instances of the tasklist type.

A user can also begin the tasklist. The tasklist manager 112 will create a workspace 120 for executing the tasklist, and create a sub-workspace for each of the first-tasks in the tasklist. Generally, the tasklist instance is created with status STARTED and all of the task instances defined in the tasklist marked with the status INACTIVE. The tasklist attributes are defined and associated with the tasklist instance. The first task(s) of the tasklist that can be started is activated by changing its status to ACTIVE and execution of this task can begin.

In one embodiment, activating a task does the following:

Changes the task status from INACTIVE to ACTIVE; Creates a workspace 120, if necessary (depending on this task association as described previously in this section), for executing the task; If the task is automatic, then its Begin Task is called; The da