WO2001069431A2

WO2001069431A2 - System and method for automating business processes and performing data interchange operations in a distributed computing environment

Info

Publication number: WO2001069431A2
Application number: PCT/US2001/008611
Authority: WO
Inventors: Ilan Sehayek; Carlos Mendez; Orr Shakked; Doron Rotem; Per Henrik Nordberg; Shung-Yang Frank Chu
Original assignee: Commerceroute, Inc.
Priority date: 2000-03-14
Filing date: 2001-03-14
Publication date: 2001-09-20
Also published as: WO2001069431A8; AU2001247532A1

Abstract

A system and method for providing a communication centric service for automating business processes or workflows. A set of information is stored that defines a sequence of tasks for completing a workflow. Upon completion of a task, an incoming message associated with the task is routed to an incoming message queue. A workflow engine continuously monitors the incoming queue for incoming messages. Once the workflow engine receives the incoming message, the workflow engine reads the message and initiates one or more activities for completing one or more tasks associated with the incoming message. The system and method also includes a tool for creating and executing data interchange operations. Data interchange operations are operations by which a source object located at a source object location are transformed or mapped into target objects and saved at target object locations.

Description

SYSTEM AND METHOD FOR AUTOMATING BUSINESS PROCESSES

AND PERFORMING DATA INTERCHANGE OPERATIONS IN A

DISTRIBUTED COMPUTING ENVIRONMENT

Cross-Reference to Related Applications

This application is a continuation-in-part of U.S. Application No. 09/353,568 filed on July 15, 1999, and priority from the filing date of which is hereby claimed under 35 U.S.C. § 120.

Field of the Invention

The present invention relates to a method and system for automating business processes, and more specifically, to a method and system for an automated business process service and for performing data interchange operations.

Background of the Invention

Companies are constantly seeking ways to improve their business processes in order to decrease costs, improve efficiency and provide additional services to their customers. Typical business processes include purchase orders, weekly time sheets, claims processing, and employee performance reviews. These business processes are often referred to as business workflows or just workflows.

In the past, before computers were widely interconnected through networks, the workflows were performed as a manual process. In this manual process, each participant in the workflow reviewed and completed a portion of a form and then manually routed the form to the next participant. As one can imagine, this manual process had several disadvantages. One disadvantage was the physical delay in routing the form. Another disadvantage was the time-consuming method for checking the status of the workflow. The status was checked by asking each participant of the workflow whether they had seen the form. Once the form was located, the participant who was currently working on the form was asked for status. Even though checking the status was time consuming, it was necessary because, otherwise, the workflow may have been prematurely terminated due to a lost or improperly routed form.

With the growth of networked computers and e-mail, the automation of business workflows became more possible. Electronic forms replaced paper forms. Databases storing large amounts of information replaced file cabinets. E-mail replaced manual routing. However, the first attempts at providing an automated workflow system had several disadvantages. First, these prior art automated workflow systems used proprietary systems for creating, routing, and maintaining information necessary to process the workflow. These proprietary systems did not allow a company to use their existing computing infrastructure. Rather, the company was required to spend a large sum of money on additional hardware and software that was not compatible with existing computers and software in the company. Therefore, the company could not leverage their existing technology investments to provide automated workflow.

The next attempt at providing an automated workflow system allowed a company to leverage some of their existing hardware technology investments to provide automated workflow. However, these systems still required proprietary software, namely a proprietary e-mail system. The systems created forms that were saved in a proprietary, non-transactional database that was only accessible with the proprietary e-mail system that originally created the form. These prior art systems are referred to as "Ad Hoc workflow" systems because the systems do not directly interact with existing software. Therefore, companies that purchased these systems could not leverage all of their existing technology investments to provide automated workflow.

More recent attempts at eliminating proprietary hardware and software from automated workflow systems use existing Internet protocols such as Simple Mail Transport Protocol (SMTP) and HyperText Markup Language (HTML) to allow access to information residing on an existing company infrastructure through the use of a browser that opens electronic forms and accesses other information using a uniform resource locator (URL) embedded in the e-mail. However, these systems still have several disadvantages. A major disadvantage is that the systems own and control the data. Owning the data requires these systems to replicate information existing elsewhere on the company's computer infrastructure. This replication of information requires additional storage mechanisms, such as hard disk drives or optical drives. Therefore, users are forced to purchase considerable new hardware and software to realize an automated workflow system.

Given the shortcomings of these prior art systems there is a long-felt need for a system and method for automating business processes that uses the existing computing infrastructure. Moreover, there is an additional need for a method and system for automating business processes that may be provided as a service to subscribes, thereby removing the burden of providing a computing infrastructure from the subscribers.

Summary of the Invention

The present invention is a system and method that provides a communication centric service for automating business processes and operates on existing computing infrastructure. The present invention interacts with existing hardware and software by providing a communication path between software applications, objects, and other services.

According to an embodiment of the present invention, a system and method for providing a communication centric service for automating business processes or workflows is provided. A set of information is stored that defines a sequence of tasks for completing a workflow. Upon completion of a task, an incoming message associated with the task is routed to an incoming message queue. A workflow engine continuously monitors the incoming queue for incoming messages. Once the workflow engine receives the incoming message, the workflow engine reads the message and initiates one or more activities for completing one or more tasks associated with the incoming message.

The present invention also provides a modeling tool for defining the sequence of rules.

The present invention uses existing transports, forms, databases, objects and directories residing on existing computing infrastructure by using interfaces exposed by the existing components.

The present invention further provides caching and hashing of the incoming message and the set of information.

The prevent invention also provides a method and system for automating business processes in a distributed computing environment. The present invention further provides a method and system for executing data interchange operations in a distributed computing environment. As described in greater detail below, a data interchange operation generally comprises an operation for retrieving a source object at a source object location, performing a transformation/mapping operation on the source object to create a target object, and saving the target object at a target object location. The present invention further provides a graphical system for creating, editing, scheduling, and executing such data interchange operations in a distributed computing environment.

Brief Description of the Drawings

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:

FIGURE 1 is a block diagram of an illustrative network infrastructure providing a suitable environment for operation of the present invention;

FIGURE 2 is a block diagram illustrating the interaction of tasks in an illustrative requisition workflow;

FIGURE 3 is a process flow diagram illustrating the interaction of the various components of the present invention;

FIGURE 4 is an illustrative screen display of one embodiment of the present invention illustrating a modeling tool for defining tasks in a workflow;

FIGURE 5 A is an illustrative screen display of one embodiment of a general task window of the modeling tool illustrating the creation of a manager approval task;

FIGURE 5B is an illustrative screen display of a general task window illustrating the creation of a manager approval escalation task;

FIGURE 6 is an illustrative screen display of one embodiment of a role definition window of the modeling tool;

FIGURE 7 is an illustrative screen display of one embodiment of an escalation window of the modeling tool;

FIGURE 8 is an illustrative screen display of one embodiment of a document window of the modeling tool;

FIGURE 9A is an illustrative screen display of one embodiment of an action list window of the modeling tool illustrating the creation of an action list;

FIGURE 9B is an illustrative screen display of another action list window illustrating the creation of an action list for a purchase request task;

FIGURE 9C is an illustrative screen display of another action list window illustrating the creation of an action list for the manager escalation task;

FIGURE 10 is a flow diagram illustrating an overview of the process performed by the workflow engine for processing incoming messages; FIGURE 11 is a flow diagram illustrating a process of executing a task suitable for use in the process shown in FIGURE 10;

FIGURE 12 is a flow diagram illustrating a process of executing a route suitable for use in the process shown in FIGURE 11;

FIGURE 13 is a flow diagram illustrating a process of executing an object suitable for use in the process shown in FIGURE 11 ;

FIGURE 14 is a flow diagram illustrating a process of executing database calls suitable for use in the process shown in FIGURE 11 ;

FIGURE 15 is a flow diagram illustrating a process of executing expressions suitable for use in the process shown in FIGURE 11 ;

FIGURE 16 is a flow diagram illustrating a process of executing external logic suitable for use in the process shown in FIGURE 11 ;

FIGURE 17 is a flow diagram illustrating a process of executing internal drivers suitable for use in the process shown in FIGURE 11;

FIGURE 18 is a flow diagram illustrating a process performed by the workflow engine for processing outgoing messages;

FIGURE 19 is an illustrative screen display of one embodiment illustrating a drop-down menu suitable for use in the modeling tool;

FIGURE 20 is an illustrative screen display of one embodiment illustrating a COM Object Browser;

FIGURES 21A-21E are block diagrams illustrating various topologies for implementing the components of the present invention;

FIGURES 22A-22B are block diagrams illustrating an architecture for providing a service for automating business processes;

FIGURE 23 is a flow diagram illustrating a process for providing a service for automating business processes;

FIGURE 24 is a flow diagram illustrating a process for adding a new subscriber to the automated business processes service;

FIGURE 25A is a flow diagram illustrating a process for billing a subscriber of an automated business processes service;

FIGURE 25B is a block diagram illustrating a hardware architecture utilized for billing a subscriber of an automated business processes service;

FIGURE 26 is a block diagram illustrating an operation resolver for executing data interchange operations; FIGURE 27 is a block diagram of an illustrative network infrastructure providing a suitable environment for operation of an embodiment of the present invention;

FIGURE 28 is a block diagram illustrating a hardware architecture for a server computer utilized in an embodiment of the present invention;

FIGURE 29 is a block diagram illustrating a hardware architecture for a client computer utilized in an embodiment of the present invention;

FIGURE 30 is a flow diagram illustrating a process for defining a data interchange operation;

FIGURE 31 is a flow diagram illustrating a process for defining and editing accounts in an automated business processes service;

FIGURE 32 is an illustrative screen display showing a window for defining accounts in an automated business process service;

FIGURE 33 is a flow diagram illustrating a process for defining and editing projects in an automated business processes service;

FIGURE 34 is a is a flow diagram illustrating a process for defining and editing data interchange operations in an automated business processes service;

FIGURE 35 is an illustrative screen display showing a window for defining and editing projects;

FIGURE 36 is an illustrative screen display showing a window for defining and editing a data interchange operation;

FIGURE 37 is a flow diagram illustrating a process for defining and editing source objects;

FIGURE 38 is a flow diagram illustrating a process for defining and editing target objects;

FIGURE 39 is an illustrative screen display showing a window for defining and editing source objects;

FIGURE 40 is an illustrative screen display showing a window for defining and editing target objects;

FIGURE 41 is a flow diagram illustrating a process for defining and editing schedules for performing data interchange operations;

FIGURE 42 is an illustrative screen display showing a window for defining and editing schedules for performing data interchange operations;

FIGURE 43 is a flow diagram illustrating a process for defining aspects of a data interchange operation; FIGURE 44 is a flow diagram illustrating a process for defining and editing documents utilized by a data interchange operation;

FIGURE 45 is an illustrative screen display showing a window for defining and editing documents utilized by a data interchange operation;

FIGURE 46 is a flow diagram illustrating a process for defining and editing transformations utilized by a data interchange operation;

FIGURE 47 is a flow diagram illustrating a process for defining and editing target messages utilized by a data interchange operation;

FIGURES 48A-48E and 49 are illustrative screen displays showing windows for defining and editing transformations utilized by a data interchange operation;

FIGURE 50 is an illustrative screen display showing a window for defining and editing target messages utilized by a data interchange operation;

FIGURE 51 is a flow diagram illustrating a process for defining and editing process messages utilized by a data interchange operation;

FIGURE 52 is a flow diagram illustrating a process for performing administrative functions in an automated business processes service system;

FIGURE 53 is an illustrative screen display showing a window for defining and editing process messages utilized by a data interchange operation;

FIGURE 54 is an illustrative screen display showing a window for viewing a system log in an automated business processes service system;

FIGURE 55 is an illustrative screen display showing a window for viewing a queue of current data interchange operations in an automated business processes service system;

FIGURE 56 is an illustrative screen display showing a window for viewing a history of file transfers performed by data interchange operations in an automated business processes service system;

FIGURE 57 is a flow diagram illustrating a process utilized by an operation resolver for executing data interchange operations;

FIGURE 57A is a flow diagram illustrating a routine for performing a transformation/mapping operation.

FIGURE 58 is a flow diagram illustrating a process for scheduling the execution of data interchange operations;

FIGURE 59 is a flow diagram illustrating a process for administrating the operation of a workflow engine in an automated business processes service system;

FIGURE 60 is an illustrative screen display showing a window for viewing a system log in an automated business processes service system; FIGURE 61 is an illustrative screen display showing a window for viewing an error log in an automated business processes service system;

FIGURE 62 is an illustrative screen display showing a window for viewing the contents of an operations queue in an automated business processes service system;

FIGURES 63 and 64 are illustrative screen displays showing windows for viewing and editing system services in an automated business processes service system;

FIGURE 65 is an illustrative screen display showing a window for modifying permissions of users and groups in an automated business processes service system;

FIGURE 66 is a flow diagram illustrating an illustrative process for executing a data interchange operation on a workflow engine;

FIGURE 67 is an illustrative screen display showing a window for adding a data interchange operation to a workflow process;

FIGURE 68 is an illustrative screen display showing a window for selecting process versioning options; and

FIGURE 69 is an illustrative screen display showing a window for assigning workflow processes to specific workflow engines.

Detailed Description of the Preferred Embodiment

The present invention is a system and method for providing a communication centric service for automating business processes. The present invention interacts with existing hardware and software by providing a communication path between software applications, objects, and other services. Typically, one or more organizations in a company are interconnected through an intranet, a wide area network, or, perhaps, through the Internet. Each organization is responsible for maintaining the hardware and software for their individual organization. It is common that one organization may not use the same software as another organization. Recognizing this, the present invention provides a common service for interacting with existing software applications.

FIGURE 1 is a block diagram of an illustrative architecture suitable for providing an operating environment for operation of the present invention. The illustrative architecture 10 may include one or more organizations 12 interconnected through a network 14. The network 14, may be a wide area network, a local area network, or a TCP/IP connection. Each organization may include a plurality of host systems 16, sometimes referred to as legacy systems, such as System/38 manufactured by International Business Machines (IBM). The host systems 16 are coupled to an organization network 18, such as a Local Area Network (LAN), along with other client computers 20 and server computers 22. The client computers 20 include workstations, thin-clients, and desktops PCs. The client computers 20 and server computers 22, typically, are a personal computer of the type that includes an amount of volatile memory, and non-volatile memory. The non-volatile memory includes a hard disk or other data storage device. Computer-readable medium residing in the non-volatile memory is accessible by the computer. The computer-readable medium includes computer-executable components. In addition, each client computer 20 and server computer 22 includes a processor, a keyboard, a directional input device such as a mouse, and a monitor, such as a cathode ray tube (CRT) or a liquid crystal display (LCD). Programs executed by the client computer 20 and server computer 22 preferably use a graphical user interface that is displayed on the monitor. An example of a graphical user interface is the Windows®95 operating system produced by the Microsoft Corporation.

In the presently preferred embodiment of the invention, the network 14 connecting the various organizations 12 is the Internet. The Internet is a commonly used wide area network that comprises many networks linked together to form a global data link. The Internet, wide and local area networks, and TCP/IP communication mediums are well understood by those of ordinary skill in the art and need not be discussed in further detail here, except as they relate to the present invention.

Connection of the client computers 20 and server computers 22 to the Internet is provided in a conventional manner, such as by an Internet service provider. Using the Internet, the server computers 22 are able to communicate with the client computers 20 utilizing a protocol known as HyperText Transfer Protocol (HTTP). When operated in this manner, the server computers 22 are commonly referred to as World Wide Web servers, or simply Web servers. When the network 14 is a local area network, it is referred to as an "intranet."

Before describing in detail the processing involved in the present invention, a general overview of the terminology used in this discussion is provided. A business workflow may be any business process that may or may not involve human intervention. The present invention assigns each workflow process a unique process identification (PID). Each initiation of the same workflow is further identified by a process instance ID (PIID). For example, if a first workflow participant and a second workflow participant both initiate a purchase requisition, each purchase requisition will have the same process ID, but will have a different process instance ID. Each workflow process includes a number of tasks that are executed in an order determined by routing rules that are known within a company and captured using the present invention. The present invention assigns each task within the unique process ID a unique task ID (TID). In addition, because one task may be used several times within the workflow, each task is assigned a unique task instance ID (TIID). Therefore, each task within the process is identified by a combination of four attributes: PID; PIID; TID; TIID. This assignment occurs during run-time by a workflow engine 52 and is recorded in both an instance database 58 and a message database 54.

Each task may include the following actions: pre-role actions; manual actions; and post-role actions. The pre-role actions are performed by the workflow engine 52 shortly after the task is started. Examples of pre-role actions include calling component object model (COM) objects and performing database retrievals and updates. The manual actions are performed by a workflow participant 68 after being alerted of the task. Examples of manual actions include filling text fields in a Web-based form or selecting buttons on a display in a browser. The post-role actions are performed by the workflow engine 52 after the manual actions have been completed. Examples of post-role actions include data manipulation, database retrievals and updates and initiation of additional tasks in the business workflow.

The information that is processed during the business workflow is referred to as workflow data elements, or just simply, data elements. These data elements may be routed by the workflow engine 52 without additional processing, or may be routed after the workflow engine 52 has performed additional processing. The present invention provides a communication centric service for interacting with client software, server software, and host software. In general, the present invention allows business processes (business workflows) to be mapped to existing software applications residing on a company's existing computing infrastructure in order to allow access to databases, forms, documents, mailboxes and other software components without replicating the data.

The interaction provided by the system 50 of the present invention is best illustrated using a simple example workflow such as a purchase requisition workflow illustrated in FIGURE 2. In general, the purchase requisition workflow allows all requisitions initiated by a purchase requester (PR) less than or equal to $5000 to be automatically approved, represented by path 100. All requisitions greater than $5000 are sent to a manager of the purchase requester for approval, represented by a path 102. The manager then can either reject the request, represented by a path 104, or approve the request, represented by a path 106. The system 50 also provides a reminder or alert to the manager if the manager fails to perform the actions in the requested time, as represented by a pair of paths 108 and 109. As one skilled in the art will appreciate, more complicated business workflows that involve more workflow participants 68 and more complicated business logic than the above example can be easily handled after explaining the details of the present invention.

Referring to FIGURES 2, 3 and 10, the system 50 of the present invention is described in greater detail. The system 50 includes: a workflow engine 52, a message database 54, a process definition database 56 and an instance database 58. In addition, the system 50 may include a modeling tool 60 and an administration tool 64. In the purchase requisition example described above, a workflow participant 68 fills out entries on a web-based form 69, such as a purchase form, using browser capable software. For this example, the entries on the purchase form include information regarding a purchase item, a cost, and a requester name who is submitting the purchase form. Web-based forms 69 may be forms already in existence on the computing infrastructure of a company.

Once the workflow participant 68 submits the purchase form 69, computer readable code embedded in an incoming message 74 (not shown) associated with the purchase form 69 is routed to an incoming message queue (not shown) in the message database 54. This action by the workflow participant 68 has thus initiated the workflow for the purchase requisition workflow illustrated in FIGURE 2, and more specifically has performed actions in one of the tasks, designated as the "purchase request" (PR Task) 110 of the purchase requisition workflow. As will be described below in detail, some tasks only require manual actions, while others require manual actions in combination with additional processing.

The workflow engine 52 continuously monitors the incoming queue for incoming messages 74. In the above example, once the workflow engine 52 receives the incoming message 74 about the purchase form 69, the workflow engine begins processing. Based on the four attributes (PID, PIID, TID, and TIED) of the purchase form incoming message 74 (not shown) in the incoming queue, the workflow engine 52 retrieves a set of information 72 regarding the purchase form 69 from the process database 56. The set of information 72 includes pre-defined rules for the purchase request task 110 associated with the purchase form 69. Because the purchase request task 110 is the first task of the requisition workflow, the attributes appear as follows: "Purchasing Process .O.Task 1.0." "Purchasing Process" informs the workflow engine 52 of the name of the workflow associated with the incoming message. The first zero informs the workflow engine 52 that a new instance must be created for the process. The one informs the workflow engine 52 that the incoming message 74 is associated with the first task of the "Purchasing Process" workflow. The second zero informs the workflow engine that the task instance is the first instance of the task for this workflow. This protocol format is sent with each message in both the incoming queue and the outgoing queue. After receiving the incoming message 74, the workflow engine 52 creates a new process instance for the purchase requisition workflow. As described above, the workflow engine 52 will assign a process instance ID (PUD) for the process D (PLD) that corresponds to the purchase requisition workflow. This allows the workflow engine 52 to simultaneously process two or more purchase requisition workflows.

The set of information for the purchase request task 110 indicates that in the process database 56 the purchase request task 110 has post-role actions assigned for the workflow engine 52 to perform. For this example, the post-role action is testing whether the purchase amount is under a certain dollar amount. In the current example, the workflow engine 52 accesses the data element sent in the incoming message or a location for storing the dollar amount in the existing computer infrastructure to calculate whether the cost is equal or greater than $5,000. If so, the workflow engine 52 initiates the manager approval task 114 by creating a new task instance identifier (TIID) for the manager approval task 114. If the cost is less than $5,000, the workflow engine 52 initiates the approve task 112 by creating a new task instance identifier for the approve task 112. As mentioned above, the workflow engine 52 assigns each task in the workflow a unique task instance ID (TIED) for the unique task ID (TID). Assuming the purchase amount is over $5000, the workflow engine 52 initiates the manager approval task 114. The workflow engine 52 then records its actions in the instance database 58 with a timestamp. Information recorded in the instance database 58 include the from attributes and may include any of the relevant data elements.

Upon initiation of the manager approval task 114, the workflow engine 52 retrieves the pre-defined set of information in the process database 56 for the manager approval task 114 using the TID and PID. The workflow engine 52 also determines whether there are any pre-role actions. In the given example, the pre-role actions for the manager approval task 114 include retrieving information regarding an immediate manager for a requester name that is one of the data elements of the purchase request task 110. The requester name for the manager approval task 114 is obtained from the purchase requester task 110. The workflow engine uses the four attributes to retrieve the data elements for the purchase requester task 110. These data elements may be available in RAM or obtained from non-volatile memory. Using the requester name, the workflow engine 52 may query an external database 70 specified during creation of the manager approval task 114 using the modeling tool 60. This process will be described in detail in FIGURES 10-18. For this example, the "human resource database" is accessed and queried using the Structured Query Language (SQL) to retrieve the immediate manager and the corresponding e-mail address for the immediate manager. The next pre-role action defined in the process database 56 for the manager approval task 114 is to send an e- mail message to the immediate manager with a uniform resource locator (URL) pointing to an approval form. The URL and location of the approval form has been previously defined using the modeling tool 60 and will be described in detail below. The e-mail message to be sent to the immediate manager is sent via an out message queue (not shown) in the message database 54. The message includes the four attributes. This e-mail message is then recorded along with a timestamp in the message database 62. The workflow engine monitors the out message queue and replaces the data elements with desired values and then sends the out message to a next workflow participant. This processing is described in detail in FIGURE 18. It should be appreciated by those skilled in the art that the e-mail message may comprise other types of information than a URL. For instance, as described below, an MHTML encoded page may be transmitted containing a script. A reply to the message may then be transmitted to initiate processing at the workflow engine.

The immediate manager, now the next workflow participant for the purchase requisition workflow, receives the e-mail message with the URL pointing to the approve form. During this time, the workflow engine 52 continuously processes any other messages in the incoming message queue and outgoing message queue. Once the immediate manager has input the necessary information into the approve form and selected an Approve or Reject button on the form, the completed form is sent in the same manner as the purchase form (i.e., to the incoming queue of the message database 54). The workflow engine 52 retrieves the information entered in the approval form and starts processing in the manner described above. For this example, the workflow engine 52 obtains the pre-defined rules for the manager approval task 114 and determines whether the requisition was either approved or rejected. Depending on the determination, an approve task 112 is initiated or a rejected task 118 is initiated. Modeling Tool The modeling tool 60 of the present invention will now be described in detail. The modeling tool 60 includes computer-executable components that reside on the server computers 22 shown in FIGURE 1. The execution of the components representing the modeling tool 60 provide a user interface to the workflow administrator 66. In a preferred embodiment, the modeling tool 60 provides a graphical user interface to the workflow administrator 66. FIGURE 4 is an illustrative screen display of one embodiment of the modeling tool 60 that illustrates a modeler window 200 having a file menubar 202, a modeling toolbar 204, and modeling window 206. The requisition workflow example previously described is shown in the modeling window 206 and will be used to illustrate the modeling tool 60. The file menubar 202 includes standard menubar items, such as file, edit, and help, along with additional menubar items "modeler", "view", and "window". The programming necessary for implementing the file menubar 202 and the modeling toolbar 204 are well known in the art. Also, one skilled in the art will recognize that the file menubar 202 and the modeling toolbar 204 may be programmed in various manners and use various naming conventions without departing from the scope of the present invention.

The modeling tool 60 provides a convenient interface for describing business workflows and for mapping the tasks of the business workflows to other software applications or software components in order to achieve the communication centric service provided by the present invention. The modeling toolbar 204 includes the following items: a new item 210, an open item 212, a save item 214, an undo item 216, a redo item 218, a print item 220, a preview item 222 and a help item 224. The functionality and implementation of these items are well known in the art and need not be discussed in further detail here, except as they relate to the present invention. The modeling toolbar 204 also includes a process item 226, a task item 228, a route item 230, and a check item 232. The functionality of these items will be described in detail below.

The workflow administrator 66 using an input device selects the process item 226 that results in the execution of instructions that allows entry of a name for the business workflow ("named workflow"). The workflow administrator 66 then selects the task item 228 an appropriate number of times to create a visual representation of the tasks in the named workflow. In the example workflow shown in FIGURE 4, a purchase request task 110, an approve task 112, a manager approval task 114, a manager approval escalation task 116 and a reject task 118 were created in this manner. The route item 230 is then selected to visually link, and ultimately link the processing for, each of the created tasks. The creation of the tasks and the routes may be performed in various orders and each of the created tasks or routes may be easily deleted and moved by the modeling toolbar using well known programming methods.

Once the workflow administrator 66 has created a workflow diagram such as that shown in FIGURE 4, the workflow administrator 66 creates the business rules that underlie each task. The workflow administrator 66 positions the input device on any of the created tasks 110-118 and double clicks. After selection of the desired task, the present invention executes instructions to display a general task window. An illustrative screen display for a general task window is shown in FIGURE 5A illustrating the definitions for the manager approval task 114 shown in FIGURE 4. This general task window 250 allows the workflow administrator 66 to graphically define business rules and to graphically map the workflow tasks to existing computing resources.

The general task window 250 includes five tabs across the top of the window: a general tab 252; a define role tab 254, an escalation tab 256, a document tab 258, and an action tab 260. As is well know in the art, selecting any of the above tabs results in a corresponding window being displayed. Typically, the general task window 250 is the default window that appears when a particular task is selected. If the workflow administrator 66 has not previously entered any task information in the general task window 250 associated with the selected task, the text boxes and display windows of the general task window 250 do not contain any information. However, as one skilled in the art will recognize, default data may be specified and automatically entered into any edit box or display window. If the general task window 250 is not the window displayed, the workflow administrator 66 selects the general tab 252 using standard point and click operation or other selecting operation. Upon selection of the general tab, the present invention executes instructions that provide a display for entering task information. The general task window is used to define the pre-role actions for tasks.

The general task window 250 includes a task name edit box 262 and a task description edit box 264. Using the keypad, the workflow administrator 66 enters a task name ("named task"), such as "Manager Approval", in the task name edit box 262 and a description of the task in the task description edit box 264. Typically, the description of the task provided in the task description edit box 264 is an English translation of the business logic for the named task. In addition, the general task window 250 includes a task data edit box 266 and a data elements available window 268. The text entered in the task data edit box 266 may be written using a task scripting language. In one embodiment, the scripting language requires the word "Begin", shown at 270, to be entered on a first line to signal the start of the script and requires the word "End," shown at 271, to be entered on a last line to signal the end of the script. Each line of the task data edit box 266 lists one of the task data elements 272 necessary for performing the named task.

By right clicking on the "Begin" statement, the present invention provides a drop-down menu for easy entry of data in the task data edit box 266. FIGURE 18 illustrates an illustrative screen display for the drop-down menu suitable for use in the modeling tool. The drop-down menu 269 includes an "insert data element" option 242 and an "insert COM object" option 244 and many other menu selections. By selecting the "insert data element 242", the workflow administrator 66 may define a name for the data element 272 and then define a data type, such as integer, Boolean, or string, for the data element. For example, in the "Manager Approval" named task, the workflow administrator 66 defines the data element 272, "ItemCost", for supplying the cost of an item that is being purchased, the data element 272, "ItemName", for describing the item being purchased, the data element 272, "RequestorName", for indicating the person who initiated the purchase requisition. After the name is supplied for each of the data elements 272, the modeling tool 600 may automatically insert an equal sign "- '. After the "=", the workflow administrator 66 defines a location for that data element. The locations for the data elements may be from tasks that execute prior to the current named task, from remote databases, or any other accessible location. Because the present invention uses a combination of drop-down menus and other drag-and-drop features, the workflow administrator only needs to type very limited information. This allows for ease of definition and less chance of errors.

The data elements available window 268 provides a graphical representation of the availability of any data element 272 that has previously been defined for the named workflow. In one embodiment the window 268 uses a standard tree structure to represent the previously defined tasks. For example, the purchase request (PR) task 110 shown in FIGURE 4, is represented by PR shown at 290. The data elements 292 defined for the PR task 110 are indented and represented as a branch in a typical tree hierarchy. As one skilled in the art will recognize, the first task that is created for a named process will not have any available data elements 292 visible in the data elements available window 268. However, once one task has data elements 272 defined, these data elements 272 will be available to the workflow administrator 66, in the data elements available window 268 to aid in the specification of the location for the data elements 272 of the named task.

For example, the workflow administrator 66 may position the cursor over the PR:ItemCost(integer) item in the data elements available window 268 and drag and drop the PR:ItemCost(integer) item to the task data edit box 266 after the "ItemCost- ' entry. The modeling tool 60 then executes instructions that formats the location according to proper scripting rules. The workflow administrator 66 may also just type the necessary information after the "ItemCost- ' entry rather than using the drag-and-drop operation. Adding locations, such as shown generally at 278, for the task data element 272 may be entered by inserting a separator 276, "|", after any previously entered location, such as shown generally at 274, and adding text or use the drag-and-drop operation to input an additional location.

During processing of the business workflow, the separator 276 signals the workflow engine 52 that the data value for the current data element 272 may be derived from more than one location or source. The workflow engine 52 first attempts to derive a value from the location specified left of the separator 276 (first location), and if the data value is not available at that location, attempts to derive the data value from the location specified right of the separator 276 (second location). For example the workflow engine 52 may need to obtain the location for a data value from the second location when the task can be initiated by two different paths, see the approve task 112 of FIGURE 4. The approve task 112 can be initiated by the purchase request task 110 or the manager approval task 114. Because the workflow administrator 66 is unable to know which path will initiate the approve request 112 during run-time, the workflow administrator 66 defines both as possible locations. As one skilled in the art will recognize, the location for the data element 292 may also be from a third or subsequent location. When this occurs, the workflow engine 52 resolves the location in a left to right order with each location separated by the separator 276. Various scripting languages are well known in the art and the parsing of scripting languages in general are also well known in the art.

The workflow administrator 66 also designates the workflow participant 68, by using a special data element 272, named "role", in the task data edit box 266. Again, a separator 276 is used to separate two or more possible workflow participants 68 that may be assigned to the role 272. In the example illustrated in FIGURE 5A, during processing, the workflow engine 52 will recognize that the role may be assigned through location element "TASK:MAEscl.newEmail" or may have a fixed location such as an e-mail address at "frar_k(_ idtest.com". The location "TASK:MAEscl.newEmail" indicates to the workflow engine 52 that the task named MAEscl has a data element newEmail that has a location defined for it. The workflow engine 52 will then reference that location. Associated with the "role" is a reserved data element name "min" that is associated with an escalation value. The escalation value specifies a unit of time in which the "role" can perform the assigned actions, before an escalation task is initiated. The escalation value may also be obtained from one or more locations, hi the example, the "min" value may be assigned through the location "TASK:MAEsel.mins" or may be a hard-coded value. The definitions for the escalation task will be described in detail later with reference to FIGURE 5B and 7.

The task edit box 266 may also include a procedure call 284, such as "ReportDataElementsQ" that signals the workflow engine 52 to execute additional instructions for the named task. In the example, "ReportDataElements()" records the value of the data elements for the named task in a log file to aid in debugging. The data elements available window 268 may also include global variables , shown generally at 293. In one embodiment, global variables have a unique identifier, such as a "$" as the first character. These global variables are defined by the workflow administrator 66 similar to the definitions for task data elements 272.

After the necessary pre-role actions of the named task are completed, the workflow administrator 66 may select the define role tab 254 that causes the present invention to execute instructions for displaying a role definition window 300. An illustrative screen display for a role definition window 300 is shown in FIGURE 6. The role definition window 300 includes a role string edit box 302, a role data element window 304 and the following buttons: an absolute role button 306; a relative role button 308; and a resolved from common object mode ("COM") object button 310. The workflow administrator 66 may either enter data in the role string edit box 302 or leave the edit box 302 empty. If the role string edit box 302 is empty, the workflow engine 52 will begin processing the task as soon as the task is received, unless the named task is one of the following: a time-schedule task or an escalation task. If the named task is one of the above, the workflow engine 52 will wait until the specified time expires before beginning execution. This processing will be described later in FIGURE 17.

In general, the role may be a fixed role, a variable role, an absolute role, a relative role, or a resolved role. For a fixed role, the workflow administrator enters the e-mail address corresponding the workflow participant 68 assigned as the role 280 in the task data edit box 266 of FIGURE 5A (i.e., "frank@didtest.com"). The fixed role does not change throughout any workflow processing. For a variable role, the workflow administrator 66 enters the data element 272 associated with the role 280 in the role string edit box 302 of FIGURE 6. The workflow data element may then be changed by different tasks depending on the assigned role in a particular situation (see FIGURE 5A). The data elements 272 must have been previously defined during the creation of data elements described above in reference to the general task window 250.

The other role options are provided by selecting one of the buttons 306, 308, 310 that active a dialog box to enter the requested information. For an absolute role, a functional name for the role is provided, such as "head of marketing" that is saved in the process database. During runtime, the workflow engine 52 retrieves the current head of marketing from a specified database field. For a relative role, a relative association is specified in the dialog box, such as "requester's manager". The workflow engine then retrieves information about the requester to obtain the relative role. For a resolved role, the workflow administrator or other person may create a user-defined function, such as a COM object, that specifies the instructions necessary for determining the role. The role definition window 300 may also include a role data element window 304 that provides a graphical display of the data elements 292 previously defined for the named task.

After the role 280 has been defined, the workflow administrator 66 may select the escalation tab 256 that causes the present invention to execute instructions for displaying an escalation window 320. An illustrative screen display for an escalation window is shown in FIGURE 7. The escalation window 320 includes an escalation task edit box 322, a use button 324, a do not use button 326, a minute edit box 328, and a current task window 330. Again, the workflow administrator 66 enters the name of the escalation task in the escalation task edit box 322 that corresponds to the escalation task that was previously described graphically using the modeling tool shown in FIGURE 4. The present invention may also automatically name the escalation task using the information previously provided during the creation of the graphical workflow diagram of FIGURE 4.

The workflow administrator 66 then selects either the use data element button 324 or the do not use data element button 326. If the use data element button 324 is selected, the workflow administrator 66 enters the previously defined data element 272 that specifies the number of minutes before initiation of the named task. If the do not use button 326 is selected, the number of minutes is determined by a fixed value assigned during the definitions for the general task window 250 of FIGURE 5A (i.e., "3"). The data element 272 for the number of minutes is used by the workflow engine 52 during processing to determine whether a linked task has completed in the specified time, if not, the workflow engine 52 initiates the processing for the escalation task. This processing may involve sending a notification message to the workflow participant 68 assigned to the linked task. The current task window 330 provides a graphical display of the data elements 292 previously defined for the named task.

After the escalation task has been defined, the workflow administrator 66 may select the document tab 258 that causes the present invention to execute instructions for displaying a document window 330. An illustrative screen display for a document window is shown in FIGURE 8. The document window 330 includes an ASP (Active Server Page) button 332, an HTML (HyperText Markup Language) button 334, a MHTML (Meta-HyperText Markup Language) button 336, a path edit box 338, a URL edit box 340, a subject edit box 342, a browse button 344 and a reload button 346. The workflow administrator 66 selects the type of document that the named task uses by selecting one of the buttons 332, 334, 336.

In one embodiment, the document type may be an ASP, HTML, or MHTML document. However, one skilled in the art will appreciate that other document types may be added by adding an additional button and software instructions to handle the additional document type. The workflow administrator 66 enters a path, using a well-known path name convention, in the path edit box 338. The path specified in the path edit box 338 may by typed or located using the browse button 344 which uses the well-known browsing feature for locating a file on an intranet. The path specified in the path edit box 338 specifies a physical location for the document. The physical location is necessary so that the document may be parsed to identify any data elements that are then displayed in retrieved data element window 350. The present invention uses a built-in object browser to detect and use registered COM objects and to determine the workflow data elements in the specified document. FIGURE 20 illustrates an illustrative display of the built-in object browser 352. This allows the present invention to map to the existing computing infrastructure without replicating the data. The built-in object browser in combination with the Open Database Connectivity (ODBC) compatible applications allows all the properties, methods and events of external objects to be represented graphically in the retrieved data elements window 350.

The workflow administrator 66 also enters a standard URL in the URL edit box 340. The URL specified in the URL edit box 340 references the same document specified in the path edit box 338. The reload button 346 is used to update the document window 348 with the text of the document specified in the URL edit box 340. The document window 348 performs a browser type feature, such as displaying contents of the document specified in the URL edit box 340, to aid the workflow administrator 66 in determining whether the correct document was specified.

According to an embodiment of the present invention, the document window 330 may include an option for selecting a data interchange operation as the document type for the selected task. An illustrative window for making such a selection is shown in FIGURE 67. As described in more detail below, a data interchange operation comprises a move and/or transform operation capable of retrieving a source object from a source location, transforming the source object to create a target object, and saving the target object in a target location.

In order to define a data interchange operation as the document for the selected task, the workflow administrator 66 would select the document tab 258 as described above. In response, the document window 330 will be displayed, including a document type drop-down menu 259. From the drop-down menu 259, the workflow administrator 66 would select the "CommerceRoute Web Data Interchange Operation" menu selection in order to specify a data interchange operation. The workflow administrator 66 may also be prompted to provide a login name 261 and password 263 for the web data interchange (WDI) server that maintains the definition of the data interchange operation. A log-in user interface button 265 may also be provided to allow the workflow administrator 66 to log-in to the WDI server. Once the workflow administrator 66 has logged into the WDI server, accounts 267 and account details 269 may be displayed regarding the accounts to which the workflow administrator 66 has permissions. In this manner, the workflow administrator 66 can specify a data interchange operation to be performed as a task within a workflow process.

The workflow administrator 66 may then select the action tab 260 that causes the present invention to execute instructions for displaying an action window 360. An illustrative screen display for an action window is shown in FIGURE 9A. The action window 360 includes an action list window 362 and an action list data elements available window 364. The action list data elements available window 364 provides a hierarchical tree structure of the available data elements of the named task (shown generally at 290). The data element "$count" is shown as a branch from a route process entitled "Process_Data". This indicates that $count is a global data element that is available to all the tasks of the named process. The present embodiment includes a "ResolvedRole" data element for each task. The "ResolvedRole" data element contains the e-mail address of the responsible workflow participant for the named task. The "ResolvedRole" data element is determined during run-time by the workflow engine 52 when the task is instantiated. The "ResolvedRole" data element is determined by processing the locations defined for the "role" data element.

The present invention allows the workflow administrator 66 to enter actions using the scripting language as previously described. Variables entered in the scripting language are associated with buttons or fields on the named document. For example, the document, ManagerApproval.asp of FIGURE 8 has an approve button that is associated with the variable "Approve" shown in the action list window 362. This association will be described below. During processing, all messages are sent to the workflow engine 52 in a hub-and-spoke arrangement where the workflow engine 52 is the hub and the workflow participants 68 are the spokes. Messages are not sent directly between workflow participants 68. This allows the workflow engine 52 to process each message and determine necessary actions.

In one embodiment of the scripting language, the keyword "ROUTE" indicates to the workflow engine 52 that the workflow should be routed to the task listed after the keyword "ROUTE". For example, in FIGURE 9 A, if the data element associated with the approve field on the form is shown to indicate that the manager approved, the approve task 112 shown in FIGURE 4 is initiated. As one skilled in the art will recognize, the scripting language can provide various keywords that the workflow engine 52 interprets to signal a predefined action. Providing keywords and parsing scripting languages is well known in the art. The scripting language is interpreted by an interpreter and stored in the process database in a more compact format. Typically, the scripting language is interpreted when the workflow administrator selects the save item 214 on the modeling toolbar 204 shown in FIGURE 4.

FIGURES 5B and 9C illustrate the general task window 250 and action window 360, respectively, for the manager approval escalation task 116 shown in FIGURE 4 that is linked to the manager approval task 114. FIGURE 9B illustrates the action window 360 for the purchase request task 110 shown in FIGURE 4. The action window 360 and the general task window 250 are as described above.

Once all the tasks for the named workflow have been defined, the workflow administrator 66 saves the information to the process database 56. In a preferred embodiment, the process database 56 is Open Data Base Connectivity (ODBC) compliant. The information in the process database 56 includes task names, activities for each task, data elements, routing information and rules. The process ED and consecutive task ID number is stored in the process database 56 for later retrieval by the workflow engine 52 when determining the next action or task to be performed in the workflow process.

According to an embodiment of the present invention, the modeler may include a menu item or button for displaying versioning options. An illustrative versioning window 681 is shown in FIGURE 68. Using the versioning window 681, the workflow administrator 66 may specify how new versions of a workflow process should be handled by the modeler. In particular, the workflow administrator 66 may select one of the process versioning options 682 for adding the current version of the process as a new version. The workflow administrator 66 may also select one of the process versioning options 682 for replacing the last version of the workflow process with the version of the process currently being edited by the workflow administrator 66. Additionally, the workflow administrator 66 may select one of the process versioning options 682 for deleting all of the previous versions of the process and saving the current version of the process as a new version.

Utilizing the versioning window 681, the workflow administrator 66 may also select the version effective date 683. In particular, the workflow administrator 66 may select an option for making the current version of the process effective immediately. Alternatively, the workflow administrator 66 may select a future date on which the version of the process should become active. In this manner, the workflow administrator 66 may indicate that a new version of a process become effective immediately, or the next week, month, year, etc.

According to an embodiment of the present invention, the modeler may also include a pull down menu item or user interface button for displaying server mapping options. An illustrative server mapping window 691 is shown in FIGURE 69. Using the server mapping window 691, the workflow administrator 66 may change the deployment of the current workflow process from a current server 692 to a new server 693. In order to deploy the current process on a new server, the workflow administrator 66 need only specify the new server 693 and select the "apply" user interface button. Thereafter, the modeler will deploy the current process onto the new server 693 specified by the workflow administrator 66. Workflow Engine FIGURES 10-18 are flowcharts illustrating the processing performed by the workflow engine 52. The workflow engine includes computer-executable components that reside on one or more of the server computers 22 shown in FIGURE 1. In FIGURE 10, the workflow engine 52 checks an incoming message queue for messages at block 402. As described above, when the workflow participant 68 submits a form 69, the information on the form may be sent in an incoming message 74 to the incoming message queue. The incoming message queue and an outgoing message queue are included in the message database 54. The outgoing message queue is where the workflow engine 52 deposits messages for tasks and the incoming message queue is where the tasks deposit messages for the workflow engine 52 to retrieve and route. The messages use the four attributes (PID, PUD, TID, TIED) as described above. The message queue may be a standard transactional relational database or a vendor supplied message queue, such as Microsoft Message Queue or IBM MQ Series. If the incoming message queue is empty, at decision block 404, the workflow engine 52 waits for a pre-determined period of time at block 406. After expiration of the pre-determined period of time, the logic cycles back to block 402 and continues as described above.

If the queue is not empty (a message has been deposited from some task), the logic proceeds to block 408 where the workflow engine 52 begins processing the message. Based on the attributes in the incoming message 74, the workflow engine 52 determines whether the incoming message 74 is for a new process at decision block 410 by searching the process database 56 for the PID listed in the incoming message 74. If the PED is not found, the workflow engine 52 proceeds to block 412 where a new process instance is created, hi another embodiment, the four attributes indicate the process name, that there is not a process instance or task instance, and the number of the task. Based on the attributes, the workflow engine 52 directly proceeds to block 412 without accessing the process database 56. The workflow engine assigns a PIID for the new process instance. However, if the attributes indicate that the message was from an existing workflow, the logic proceeds to block 414 where a new task instance is initiated and the TIID is assigned. Using the PI D and TIID, the workflow engine 52 executes the task at block 416 and records the action in the instance database 58 by generating an outgoing message 76 at block 418. The format of the messages in the instance database 58 is similar in design to the process database 56. The data stored in the instance database 58 is used by the workflow engine 52 in determining whether a previous workflow task has completed before continuing with the current task. In one embodiment, the workflow engine 52 determines whether any subsequent tasks in the workflow require the message that is to be recorded in the instance database 58. If so, the message is cached in memory using a hashing algorithm that reduces the size and necessity for converting them for subsequent computations. After executing the task and generating the outgoing message 76, the logic cycles back to block 402 where the workflow engine checks for another incoming message 74 and proceeds as described above.

FIGURE 11 is a flow diagram illustrating the process of executing tasks suitable for use in block 416 of FIGURE 10. An execute task process is started at 420 and proceeds to block 422 where message data elements are defined for the message that was retrieved from the incoming message queue. In one embodiment, the information from the form may be inserted into the incoming message 74 using methods well known to those skilled in the art. The format for the information in the incoming message 74 may be as follows: <data elementl name> = <value>.<data element2 name> = <value>. The number of data elements 272 may be up to the number of data elements defined for the task. The workflow engine 52 parses the incoming message 74 during block 422 to define the data elements 272 using the values supplied in the incoming message 74. The workflow engine 52 may also validate the incoming message 74 by determining whether all the data elements 272 defined in the process database 56 were provided in the incoming message 74.

In another embodiment, it is not necessary to send data elements 272 in the incoming message 74. Rather, the location and manner for retrieving the value for the data element 272 is specified during the modeling phase and stored in the process database 56. This allows existing forms in the existing computing infrastructure to operate as they have done in the past without requiring the forms 69 to send data elements to the workflow engine 52. In the example, the workflow engine 52 may query a database to determine the dollar value of the requisition. In this embodiment, the existing forms must only receive the four attributes and pass the four attributes back in the incoming message 74. The workflow engine 52 will then perform the necessary activities to complete the workflow.

After the message data elements 272 are defined and space has been allocated for the data elements 272 at block 422, the workflow engine 52 proceeds to decision block 424 where the workflow engine 424 determines an activity driver to invoke. This determination is based on the information obtained from the process database 56 for the TED specified in the incoming message 74. At this time, the workflow engine 52 may execute a route shown at block 426, execute an object shown at 428, execute a database call shown at 430, execute an expression shown at 432, execute an internal logic shown at 434, or execute any internal driver shown at block 436. Each of these activities invoke native protocols. After one of these activity drivers is invoked and completed, the logic proceeds to decision block 438 where the workflow engine 52 determines whether the current task has any more activities defined. If yes, the logic cycles back to decision block 424 and proceeds as described above. If the workflow engine 52 determines that there are no more activities defined for the current task, the logic proceeds to block 440.

At block 440, the workflow engine 52 determines whether a role or a document is defined for the current task. The process for defining a role or document for an activity is described in detail above with reference to FIGURES 5A, 6 and 8. If a role or document is not defined for the current task, the logic proceeds to block 452 where the workflow engine 52 places an outgoing message 76 in the outgoing message queue. The processing for the outgoing message queue will be described in detail in FIGURE 18. hi general, the outgoing message queue is where the workflow engine 52 deposits messages to initiate other tasks. If a role or document is defined, the logic proceeds from decision block 440 to block 442 where the workflow engine 52 defines a role by parsing the "role" data element as previously described in FIGURE 5A and 6. The logic then proceeds to resolve the role at block 444.

As described earlier, the role may be assigned to more than one location or source. For example, in FIGURE 5A, the role is assigned through location "TASK:MAEscl.newEmail" or '"frank@didtest.com"'. If the manager approval task 114 (shown in FIGURE 4) is initiated by the purchase request task 110, the TASK:MAEscl.newEmail would not be available for the workflow engine 52 to resolve the role. In this situation, the second location would be used. After resolving the role, the logic proceeds to block 446 where a document template is created. The document template, such as Manager Approve.asp defined in FIGURE 8, does not have any data elements resolved at this time. The logic then proceeds to decision block 448 where the workflow engine 52 determines whether there is an escalation task defined for the current task (see FIGURE 7). If the current task has an escalation task defined, the logic proceeds to block 450 where the workflow engine 52 initializes the escalation task. During the initialization of the escalation task, the workflow engine allocates memory and assigns PIED and TIID to the escalation task. The logic then proceeds to block 452. If the current task does not have an escalation task defined, the logic proceeds from decision block 448 to block 452. At block 452, the workflow engine places an outgoing message 76 in the outgoing message queue.

FIGURE 12 is a process for executing a route suitable for use in block 426 of FIGURE 11. In general, the process for executing a route occurs when the workflow engine 52 encounters a ROUTE keyword as shown in the action list window 362 of the action window 360 of FIGURE 9 A. The workflow engine initializes the route and records the route in the instance database 58 so that the workflow engine 52 maintains a status for the workflow. The execute route process starts at 460 and proceeds to decision block 462 where the workflow engine 52 determines whether a route needs to be initialized. The route must be initialized the first time it is encountered. Subsequent encounters for the same route that depend on a different routing rules do not initialize the route again. The instance database 58 may include several tables for storing routing information. It will be apparent to one skilled in the art that the architecture for these tables may be done in several different ways. As will be described in detail below, the present invention performs hashing on these tables to improve performance and also may cache the tables during run-time operation to minimize the input/output access to the databases 54, 56 and 58.

The workflow engine 52 relies on the tables to include definitions for the four attributes and status for the processes and tasks. If the route needs to be initialized, the logic proceeds to block 464 where the workflow engine 52 initializes an instance for the task in a task table and records the route using PID, PIID, TID, TIID in the instance database 58. The logic then proceeds to block 466 as it would have done if the route had previously been initialized as determined at decision block 462. At block 466, the route link is recorded in the instance database 58. A source task and destination task are recorded in a route table associated with the instance for the task in the task table. The logic then proceeds to block 468 to get a routing rule. The routing rule is obtained from the stored set of information in the process database 56.

For example, as shown in FIGURE 4, the route links 100, 106 for the Approve Request task 112 are from the purchase request task 110 and the manager approval task 114. Because either task may initiate the approve request task 112, the workflow engine 52 performs an "or" operation to determine whether the routing rule is met. For other tasks (not shown), the workflow engine 52 may need to wait until two or more tasks are complete before routing to the next task. The logic then proceeds to decision block 470 where the workflow engine determines whether the routing rule is met. The workflow engine 52 accesses the instance database 58 during decision block 470 to determine whether the rule is satisfied. The instance database 58 contains the prior actions completed by the workflow engine 52 for various tasks and data elements 272 for various tasks. If the current task must wait until a different task has completed, the workflow engine 52 looks through the instance database 58 to determine whether the task relied upon is completed. If the routing rule is met, the logic proceeds to block 472 where the task is started. Block 472 performs processing previously described in blocks 414, 414 and 416 in FIGURE 10. After the task is started at block 472 or the routing rule is determined not to be met, the logic proceeds to decision block 474 where the workflow engine 52 determines whether there are any more rules to process before starting the next task. If there are, the logic cycles back to block 468 to get the next routing rule and proceeds as described above. If there are no more rules at decision block 474, the logic proceeds to the end block 476 and returns to decision block 438 in FIGURE 11.

FIGURE 13 is a flow diagram illustrating a process for executing an object suitable for use in block 428 of FIGURE 11. The executing object task process starts at 480 and proceeds to block 482 where the workflow engine 52 defines input data elements 272. During block 482, the workflow engine 52 formulates the input parameters for an object driver from the data elements and values that were sent in the incoming message or retrieved in some manner. The logic then proceeds to decision block 484 where the workflow engine 52 determines the type of object driver to invoke. The object driver corresponds to the object type specified during the modeling phase. The object drivers include COM objects shown at 486, Enterprise Java Bean shown at 488, CORBA objects shown at 490, DLL objects shown at 492, and plug-in objects shown at 494. These type of objects are well- known in the art and the instantiation of the objects shown in blocks 486-494 is also well-known in the art. In general, each object driver executes code that generates output data elements that are returned to the workflow engine 52 at block 496.

According to an embodiment of the present invention, the workflow engine may also cause a data interchange operation to be executed. At block 495, the data interchange operation is identified and executed. An illustrative routine for executing the data interchange operation is show in FIGURE 66. Referring now to FIGURE 66, the routine 660 for executing a data interchange operation will be described. Routine 660 begins at block 664, where the operation identification number associated with the data interchange operation is transmitted to an operation resolver. As will be described in more detail below with respect to FIGURE 57, the operation resolver performs the actual data interchange operation. From block 664, the routine 660 continues to block 666, where the workflow engine saves a message in the instance database indicating that the operation identification number has been transmitted to the operation resolver. From block 666, the routine 660 continues to block 668, where it returns to block 498, shown in FIGURE 13. Referring again to FIGURE 13, after the output data elements have been obtained, the logic ends at 498 and returns to decision block 438 in FIGURE 11.

FIGURE 14 is a flow diagram illustrating a process for executing a database call suitable for use in block 430 of FIGURE 11. The execute database call process 500 proceeds to block 502 where Standard Query Language (SQL) statements are created according to the set of information in the process database for the current task. The logic then proceeds to block 504 where the workflow engine 52 creates a connection string and to block 506 where the SQL is executed. Blocks 502, 504, and 506 are well-known in the art. The database call then returns the output data elements to the workflow engine 52 at block 508 and the logic ends at 510 and returns to decision block 438 in FIGURE 11. In one embodiment, database connection caching occurs once the database call to the external database occurs. Typically, this occurs during the execution of activities.

FIGURE 15 illustrates a process for executing an expression suitable for use in block 432 of FIGURE 11. The execute expression starts at 520 and proceeds to block 522 where the workflow engine 52 defines the data elements 272. The logic then proceeds to block 524 where the workflow engine 52 assigns each data element a source. For example, the workflow engine may access the instance database 58 to locate a value for a data element and add one of the defined data elements of block 522 to the retrieved data element to generate the output data element of block 526. After this is completed, the execute expression process is complete at 528 and the logic returns to decision block 438 in FIGURE 11.

FIGURE 16 is a flow diagram illustrating a process for executing internal logic suitable for use in block 434 in FIGURE 11. In general, the process for executing internal logic evaluates expressions to test whether an expression is true or false. For example, in FIGURE 9B, the internal logic executed for the purchase requisition task 110 is to evaluate whether the item cost is greater or equal to $5,000. At decision block 534, the workflow engine 52 determines whether an expression is true, and if so, the workflow engine 52 proceeds to block 538 to perform the true activity, such as routing to the manager approval task 114 as shown in FIGURE 9B. If the expression is not true, the logic proceeds to block 536 and performs a false activity, such as routing to the reject request task 118 shown in FIGURE 9B. After performing either the true activity or the false activity, the logic proceeds to the end 540 and returns to decision block 438 in FIGURE 11.

If the task is the final task for workflow, the workflow engine 52 marks the workflow as complete. This allows the memory storing this complete process instance to be later deallocated or garbage collected so that the memory is available for the creation of new instances of new workflows.

FIGURE 17 is a flow diagram illustrating the processing for executing internal functions suitable for use in block 436 of FIGURE 11. In general, in one embodiment, there are the following internal functions: block escalation, scheduled event, task termination, and task suspension. The execute internal drivers process starts at 550 and proceeds to decision block 552 where the workflow engine 52 determines which internal function to perform. If the internal function is a block escalation, the logic proceeds to block 554. Block escalation occurs when a task is overdue and must be repeated. Because the workflow participant currently defined in the role has not performed the task, the workflow engine assigns the role to another workflow participant based on the set of information in the process database for the escalation task associated with the current task. In block 554, the workflow engine initiates block escalation by eliminating the original task in the instance database at block 556 and defining data elements for a next action at block 558. The logic then proceeds to the end denoted by 576.

If the internal function is to schedule an event, the logic proceeds from decision block 552 to block 560. The workflow engine initializes the scheduled task in the instance database at block 562 and generates a scheduled message at block 564. The scheduled message is input into the incoming message queue so that the workflow engine may later retrieve the scheduled message and proceed as described in FIGURE 10. The logic then proceeds to block 566 to define data elements for the scheduled task and then proceeds to the end 576.

Returning to decision block 552, if the internal function is to initiate task termination, the logic proceeds to block 568 and then to block 570 where the workflow engine alters a status bit in the instance database that indicates to the workflow engine that the task with the altered status bit has been terminated. The logic then proceeds to the end at 576. Returning to decision block 552, if the internal function is to initiate task suspension, the logic proceeds to block 572 and then to block 574 where an altered status bit in the instance database is set to suspend the task. The altered status bit for termination of the task and suspension of the task alter the status bit in a different manner. After the status bit has been altered at block 574, the logic proceeds to the end at 576 and then returns to decision block 438 in FIGURE 11.

FIGURE 18 is a flow diagram illustrating a process performed by the workflow engine 52 for processing outgoing messages 76. Processing outgoing messages 76 begins at 580 and proceeds to a block 582 where the workflow engine 52 checks the outgoing message queue for any outgoing messages 76. The logic then proceeds to decision block 584 where the workflow engine 52 determines whether the outgoing message queue is empty. If it is, the logic proceeds to block 586 where the workflow engine 52 waits for a predetermined time period and then cycles back to block 582 and proceeds as described above. Returning to decision block 584, if the queue is not empty, the logic proceeds to decision block 588 where the workflow engine 52 checks for the type of message protocol.

Typical message protocols include SMTP, FTP, HTTP, and any other plug-in driver as shown respectively at blocks 590, 590', 590", 590'". The workflow engine 52 is designed to handle existing query drivers as well as plug in query drivers that emerge in the future. Examples of query drivers would include: database query drivers, directory query drivers, interface definition language (DDL) drivers, e-mail protocols, and security protocols.

Database query drivers provide the workflow engine with direct access to external database for data selection, manipulation and definition. For example, database query drivers include Open Database Connectivity (ODBC), Object Linking and Embedding Database (OLE-DB), Java Database Connectivity (JDBC), Oracle Call Interface (OCI), and Database Libraries (DB-LIB). Directory query drivers provide the workflow engine with direct access to external directories for identifying users, user groups, organization hierarchies, network devices and other components on a network. For example, directory drivers include Lightweight Directory Access Protocol (LDAP), x.500, Messaging Application Programmable Interface (MAPI), Active Directory Service Interface (ADSI) and Novell Directory Services (NDS). The IDL drivers provide the workflow engine with direct access to objects that expose their interfaces using methods associated with the drivers. For example, DDL drivers include Distributed Common Object Model (DCOM), Java Remote Method Indication (RMI), and Interoperable Internet Object Protocol (HOP). The e-mail protocols enable the workflow engine to send mail over the Internet. For example, e- mail protocols include Post Office Protocol (POP3), Internet Messaging Access Protocol (EVIAP4), and Messaging Application Programmable Interface (MAPI). The security protocols provide the workflow engine an ability to authenticate and encrypt incoming and outgoing process requests. Example security protocols include x.509, New Technology Lan Manager (NTL) and Kerberos. It will be apparent to those skilled in the art the manner for invoking the message protocols and will not be described in further detail.

After invoking the message protocol, the logic proceeds to block 592 where the workflow engine 52 generates the document by replacing the data elements 272 of the document template that was created in block 446 in FIGURE 11 with derived (resolved) values as defined in the process database for the document. The logic then proceeds to block 594 where the workflow engine 52 sets the driver settings for a target destination and applies any necessary communication protocols. The target destination may be any computer on the network illustrated in FIGURE 1. The logic then proceeds to block 596 where the workflow engine 52 activates the driver and sends the information to the target destination. The logic then proceeds to decision block 598 where the workflow engine 52 determines whether there is an error. If there is no error, the logic cycles back to block 582 and proceeds as described above. If there is an error, the logic proceeds to block 600 and executes an error task corresponding to the type of error received. For example, an error may occur if an external component has a problem, such as a database element that is not found or the URL cannot be resolved. These external problems are also reported in the instance database 58. The logic then cycles back to block 582 and the workflow engine 52 continues checking for additional outgoing messages 76 and proceeds as described above.

In another embodiment, the workflow engine further includes a messenger component. In this embodiment, the messenger component interacts with an existing mail service so that if the mail service is modified, only the messenger component of the workflow engine needs to be revised. The messenger component is responsible for placing incoming messages in the incoming message queue and for retrieving outgoing messages from the outgoing message queue as previously described for the workflow engine.

In one embodiment, the workflow engine 52 runs as a native Windows™ NT service. The workflow engine uses the NT Eventlog, Performance Monitor NTLM for integrated log on security. The workflow engine also supports other security mechanisms, such as X.509B3 for cross organization authentication and encryption. The workflow engine may be deployed across multiple servers so that each computer-executable component is employed on one of the servers shown in FIGURE 1. FIGURES 21A-21E illustrate various topologies for employing the components on one or several servers. FIGURE 21 A illustrates a simple topology in which all the components reside on one server. Therefore, processing is limited to the processing power of one machine, the server. FIGURE 21B illustrates a single datasource multi-engine topology in which the databases may reside on one, two or three servers and the workflow engine resides on one or more servers. FIGURE 21C illustrates a multi-message queue, multi-engine, single process database instance database topology in which there is one instance of the process database and instance database (may reside on one or two servers) and the workflow engine and multi- message queues reside on one or more servers. FIGURE 21D illustrates a multi- message queue, multi-engine, multi-instance database, single process database topology in which there is one instance of the process database. FIGURE 2 IE illustrates a multi-component topology in which all components may reside on one or more servers. Other topologies not illustrated in FIGURES 21A-21E are envisioned such as a split engine - database topology in which the process database and instance database reside on one or more servers other than the server with the workflow engine. The message queue, process database and instance database may reside on one or more separate servers running on the same or different type of database server.

Using these topologies, each topology was reviewed regarding scalability considerations and fault tolerance aspects. When a component resided on two or more servers, the fault tolerance aspects were typically more ideal. In addition, by having the one or more of the databases reside on a different server than the one with the workflow engine, the present invention allowed greater scalability. These factors then were used during the design of the components. The algorithms used to achieve greater throughput for multi-configuration topologies are described in detail below.

The computer-executable components include an incoming message detector, on outgoing message processor, and a message router. The incoming message detector component detects incoming messages that are sent to the incoming message queue from any of the networked devices, such as the clients and servers shown in FIGURE 1. The outgoing message processor component processes outgoing messages that were sent by a message router to the outgoing message queue when the message router completed an activity. The message router component reads incoming messages, initiates the activities based on the stored set of information that defines the sequence of tasks for completing the work flow, routes the activities to a software application running on one of the network devices and sends the outgoing message to the outgoing message queue upon completion of the activity. Hashing Algorithms and Caching

Another feature of the present invention is the use of hashing algorithms and caching to improve efficiency of the workflow system. The present invention recognizes that when the workflow system is implemented in various topologies as described in FIGURES 21A-21E, it is advantageous for it to be implemented so that the workflow engine processes efficiently and effectively in any topology.

To a achieve this, the workflow system of the present invention provides round robin message processing in which the workflow engine is configured to fetch one message from the incoming message queue at a time. In another embodiment, each message in the incoming and outgoing message queues is weighted. The weight applied to each message is determined during the modeling phase by considering the number of activity calls and external calls that each workflow message may require from the workflow engine. Weighting each message provides a more effective and precise load balancing. This allows dynamic weight-based fetching from the message queues. During run-time, the workflow engine dynamically determines a number of messages to fetch from the incoming message queue per fetch. By fetching several incoming messages per fetch, the input/output to the message database is reduced. In addition, the weight of the incoming and outgoing messages may be used to distribute message processing when the present invention is in multi- engine topologies, such as FIGURE 21B-21E.

The present invention also provides caching of the process database 56. In one embodiment, the complete process database 56 is cached in memory before the workflow engine 52 begins processing. This allows the workflow engine 52 to minimize the number of accesses to the process database 56 and thereby, increase performance. In a further embodiment, the present invention performs static hashing on the cached process database to provide fast searches. The hashing of the process database will be described in detail below. Typically, the route is used as a unique key for hashing. The data elements corresponding to that key are then located.

The present invention also provides auto-caching and releases memory after completing a process or task instance. The workflow engine determines whether subsequent process steps need information regarding the incoming message being process, if so, the incoming message is cached. If not, the workflow engine releases the memory associated with the incoming message. Caching messages that will be used later, saves several disk input/output operations when processing messages. The instance database may also be cached. The workflow engine caches active data (i.e. data of uncompleted workflows). This allows the workflow engine to use this cached active data later for evaluating rules, such as AND/OR rules, when determining whether a task may be started.

As explained above, the process database 56 includes several tables that store the set of information used in processing the workflows. Because the size of the process database (the tables) is known at the time of caching, static hashing techniques are used. The tables are hashed and once the task is found, the workflow engine uses the pointers to find the data elements corresponding to the found task.

In general, hashing is well understood by those of ordinary skill in the art and need not be discussed in further detail here, except as hashing relates to the present invention. In one embodiment, a hashing technique called Linear Probing is used.

Linear Probing allows a hash table to be approximately 20% larger than a task table in the process database. This balances memory usage and performance for the system.

The linear probing used in the present invention is provided below: C^" = Average number of probes for successful search — Average number of probes for unsuccessful search

M — Size of hash table N = Number of records

a = — (Load factor[0..1]) The exact value for average probes for successful searches is:

Where:

From which it follows that:

When the table is 80% full, the Linear Probe algorithm provides fetching of the required data in less than three table lookups in most cases. The incoming messages from the incoming message queue may also be hashed. However, because the message size is unpredictable, dynamic hashing techniques were used for the message cache. The instance database may also be hashed. Again, the instance database is dynamic because the size of the hash tables are not known in advance because new data is added and deleted from the instance database as a process proceed from one task to the next task. Therefore, dynamic hashing techniques are used in the present invention for caching the instance database. These techniques allow the hash tables to expand and shrink. One embodiment, the present invention utilizes Linear Hashing that typically guarantees at most two access for finding a required record. The necessary storage is as follows:

For a file with k records the number of table entries L(k) is

This formula can be approximated as:

E(/c) « /c/ln2

Based on the above algorithm, the storage utilization is L(k)/k= ln2=0.69%. The message cache may use the dynamic hashing algorithm similar to the one described above for hashing the instance database.

While the linear probe algorithm and linear hashing algorithm are described above, other hashing techniques for hashing incoming messages associated with workflows or for hashing the process and instance database would not depart from the claimed invention. As mentioned earlier, the present invention solves the problem of requiring additional storage or other proprietary hardware and software to provide a workflow system. By providing caching and hashing capabilities as described above, the present invention further allows the use of existing computing infrastructure.

In addition, the workflow engine handles multiple requests simultaneously. The workflow engine allocates multiple threads and ensures that the workflow rules are not broken during processing of simultaneous workflow requests. Embodiment of an Administration Tool

One embodiment of the system, includes the administration tool 64 that provides the workflow administrator 66 a convenient graphical tool for setting efficient parameters for the garbage collection process in the process database 56, instance database 58, and message database 54. The administration tool 60 includes a database connection manager 550, an archive manager 552. The database connection manager 552 is used by the workflow administrator 66 to identify the ODBC data source names for entry in the instance database 58 and the message database 54. The workflow administrator 66 uses the administration tools 66 to supply information, such as SMTP server and other directory information, that is recorded in the process database 56 along with information created through the modeling tool 60.

The archive manager 550 performs garbage collection on the instance database 58 and the message database 54 during run-time processing of the workflow engine 52. As mentioned earlier, when a business workflow has completed all the business rules associated with it, the workflow instance that was created by the workflow engine 52 is marked as completed. The archive manager 550 uses this information to determine which workflow instances and task instances may be garbage collected. The archive manager 550 also allows workflow administrators 66 to delete or archive messages in the instance database 58 and message database 54 based on the time stamp associated with the data. For example, because the workflow engine 52 records a timestamp along with each message, a workflow administrator using the administration tool 64 could delete all information about processes that is past a certain period of time. The archive manager 550 also provides statistics about the number of processes and tasks that are currently recorded in the instance database and the number of messages in the message database. Automated Business Process Service

According to an embodiment of the present invention, an automated business process service is provided. As shown in FIGURE 22A, a commerceroute server 700 is provided that is connected to the Internet 704 or other distributed computing network. Using a standard WWW browser, subscribers 702-702N can access the commerceroute server 700 and automate business processes 706. As will be described in more detail below, subscribers 702A-702N may utilize commerceroute server 700 to automate business processes 706 between each other, and to automate business processes that execute independently of other subscribers. As shown in FIGURE 22B, many subscribers 702A-702N may access commerceroute server 700 and automate business processes between each other. As described in additional detail below, commerceroute server 700 may maintain subscription information for each subscribers 702A-702N, and bill subscribers 702A-702N for use of the commerceroute server 700.

Subscribers 702A-702N may utilize a standard WWW browser to visit a WWW site provided by commerceroute server 700. Referring now to FIGURE 23, an illustrative WWW site for providing the automated business processes service will be described. Routine 708 begins at block 710, where a subscriber is connected to the commerceroute WWW site. At block 712, the subscriber provides their login name and password. At block 714, a determination is made as to whether the subscriber is a new subscriber or has previously been registered with the commerceroute server. If it is determined at block 714 that the subscriber is new, routine 708 branches to block 716 where the new subscriber is enrolled in the system. An illustrative routine for enrolling a new subscriber is described below with respect to FIGURE 24.

If, at block 714, it is determined that the subscriber is not a new subscriber, the subscriber is logged into the commerceroute WWW site at block 718. The subscriber is then provided a main menu including several menu items from which to choose. At block 720, user input is received from the user selecting one of the menu items. At block 722, the menu item selected by the subscriber is identified, and routine 708 branches to the appropriate block for handling the selected menu item.

If the subscriber has selected a menu item for creating a data interchange operation, routine 708 branches to block 704. As will be described in more detail below, a data interchange operation is a move and/or transform operation that can retrieve a source object at a source object location, perform a transformation on the source object to create a target object, and save the target object at a target object location. An illustrative routine for performing a data interchange operation is described below with respect to FIGURE 30.

If, at block 722, it is determined that the subscriber has selected a menu item for billing, routine 708 branches to block 728. An illustrative routine for billing a subscriber and providing the subscriber with billing information is described below with reference to FIGURES 25A and 25B.

If, at block 722, it is determined that the subscriber has selected a menu item for modeling a business process, routine 708 branches to block 734. At block 734, the subscriber is permitted to use the modeler application program to model business processes, as described above and below with respect to FIGURES 2-10. Additionally, the subscriber may select menu items for performing account administration functions, site administration functions and for receiving technical support. Upon the selection of these menu items, routine 708 branches to blocks 726, 730 and 732, respectively. Moreover, the subscriber may select a menu item for logging out of the commerceroute WWW site. If such a selection is made by the subscriber, routine 708 will branch from block 722 to block 736 where the subscriber is logged out of the commerceroute WWW site. Routine 708 continues from block 736 to block 738, where it ends.

Referring now to FIGURE 24, an illustrative routine 740 for registering a new subscriber will be described. Routine 740 begins at block 746, where new subscriber information is received. New subscriber information may include the subscriber's company name, contact name, business address, billing address, telephone number, email address, and other information necessary to bill the subscriber for use of the automated business process service.

From block 746, routine 740 continues to block 748, where a new subscriber identification ("ID") number is created for the subscriber. As will be described in more detail below, the subscriber ED number is utilized by the commerceroute server 700 to keep a record of all operations performed on behalf of the subscriber and to create accounting information necessary to bill the subscriber for executing workflows and data interchange operations. From block 748, routine 740 continues to block 750, where a login and password is assigned to the subscriber. The login and password are utilized by the subscriber to gain access to the commerceroute WWW site. From block 750, routine 740 continues to block 752 where the subscriber information, subscriber ID number, subscriber login, and subscriber password are saved in a subscriber database. At block 764, routine 740 returns to block 718, shown in FIGURE 23.

Referring now to FIGURE 25 A, an illustrative routine for billing a subscriber for use of the automated business process service will be described. Routine 760 begins at block 764, where a system log maintained by the commerceroute WWW site is queried for operations matching a particular subscriber ED number. As described above, each operation performed by the workflow engine is logged to a database which includes the subscriber ED number corresponding to the subscriber for which the operation was performed. In this manner, a complete log is maintained of all operations on a subscriber-by-subscriber basis.

Once all of the operations matching a particular subscriber ED have been identified, routine 760 branches to block 766, where the matching operations are priced according to billing rules assigned to the subscriber. Billing rules identify the type of billing arrangement each subscriber has with the commerceroute WWW site. For instance, a subscriber may be billed on a per-operation basis, a monthly flat-fee basis, or some other billing basis negotiated between the subscriber and the operator of the commerceroute WWW site. Once the operations have been priced based on the billing rules, routine 760 continues to block 768 where the subscriber's bill is prepared and provided to the subscriber. According to an embodiment of the invention, the subscriber may be provided with a traditional paper invoice, or may be permitted to view their bill online at the commerceroute WWW site. From block 768, routine 760 continues to block 780 where it returns to block 720, shown in FIGURE 23.

Referring now to FIGURE 25B, an illustrative software architecture for providing billing in an automated business process service will be described. As discussed above, a system log 782 is maintained which contains a complete record of operations performed on behalf of each subscriber. The system log is sorted based upon a subscriber identification number to identify each operation performed on behalf of any particular subscriber. The billing engine 784 performs this function to provide an invoice to the subscriber. In particular, an invoice generator 788 may search the system log for operations matching a particular subscriber ED, price the matching operations based on the billing rules assigned to the subscriber, and prepare the invoice 790 for the subscriber. The invoice generator may be designed to execute these operations once per month in order to provide the subscriber with a monthly invoice. In a similar fashion, an accumulator 786 may be designed to execute those operations as requested to provide access to the subscriber's bill in a real time fashion. Data Interchange Operations

As described above with reference to FIGURE 23, a subscriber may select a menu item for creating or editing a data interchange operation. Generally described, a data interchange operation is an automated process for retrieving a source object at a source object location using a protocol, performing a transformation/mapping operation on the source object, and saving the resulting target object in a target object location. As shown in FIGURE 26, according to an embodiment of the invention, the data interchange operation is performed by an application program called an operation resolver 792. hi general, the operation resolver 792 utilizes a data interchange operation definition provided by a subscriber to locate a source object 794 at a source object location 796. The operation resolver 792 may retrieve the source object 794 using a variety of protocols 798. Moreover, the operation resolver may perform decryption 800 on the source object prior to modifying the source object. Additionally, the operation resolver 792 may perform a transformation and/or mapping operation 802 on the source object. The transformation/mapping operation 802 may include transforming the source object in a variety of ways described below to create a target object, or may include mapping fields of the source object into fields of the target object.

Once the operation resolver 792 has performed the transformation operation 802, the operation resolver 792 may perform encryption 806 on the target object as known to those skilled in the art. The operation resolver 792 may also utilize a protocol 808 to save the target object 812 to a target object location 810. Operation of the operation resolver 792 is described in more detail below with respect to FIGURE 57.

Referring now to FIGURE 27, an illustrative system for performing data interchange operations will be described. In order to enable the use of data interchange operations within an automated business process system, a Web data interchange ("WDI") server 814 is provided. As will be described in more detail below, the WDI server 814 comprises a general purpose computer connected to a network such as the Internet, and capable of providing WWW pages to a user of a client computer 816. Utilizing a client computer 816, a user may access the WDI server 814, and define, edit, schedule, and save data interchange operations.

Once a user has created a data interchange operation, a data interchange operation definition may be saved in the WDI database 818. The WDI database may be accessed by the WDI server 814 to permit editing of the data interchange operation definition at a future time, may be utilized by the scheduler 820 to schedule data interchange operations, and may be utilized by the operation resolver 792 to execute data interchange operations.

Through the WDI server 814, the user may access the scheduler 820 for scheduling data interchange operations. As will be described in more detail below with reference to FIGURE 41, once a schedule has been defined, the scheduler 820 can utilize the schedule to trigger the execution of data interchange operations. Generally speaking, the scheduler determines whether a particular data interchange operation should be executed and, if so, retrieves the data interchange operation definition from the WDI database 818. The scheduler then transmits a message to the message database 54, which as described above is monitored by the workflow engine 52. The workflow engine 52 then retrieves the message and determines that the message contains a request for execution of a data interchange operation. In response, the workflow engine 52 transmits a request to the operation resolver 792 to perform the data interchange operation. The operation resolver 792 retrieves the data interchange operation definition from the WDI database 818, and performs the data interchange operation.

As generally described above, the operation resolver utilizes a set of protocol objects 824 to retrieve a source object 794 at a source location. Using the data interchange operation definition, the operation resolver then performs a specified transformation/mapping operation on the source object to create a target object 812. Again, using the protocol objects 824, the operation resolver 792 saves the target object 812 at a target object location. The operation resolver 792 then transmits a message to the workflow engine 52 indicating whether or not the data interchange operation was successfully completed.

According to an embodiment of the invention, a task within a workflow process defined in the modeler may be defined as a data interchange operation. In this manner, the workflow engine may trigger the execution of data interchange operations on the operation resolver 792 as part of its normal processing of workflow processes as described above. Furthermore, a user of the client computer 816 utilizing WDI server 814 may also cause a data interchange operation to be executed utilizing a command available at the WDI server 814. Additionally, a user of the client computer 816 may utilize an option available at the WDI server 814 to communicate with engine controller 822 to control the operation of workflow engine 52. These and other aspects of the WDI server 814 are described below with reference to FIGURES 28-66.

FIGURE 28 depicts several of the key components of the WDI server 814. Those of ordinary skill in the art will appreciate that the WDI server 841 includes many more components then those shown in FIGURE 28. However, it is not necessary that all of these generally conventional components be shown in order to disclose an illustrative embodiment for practicing the present invention. As shown in FIGURE 28, the WDI server 814 is connected to the Internet 704, or other communications network, via a network interface unit 860. Those of ordinary skill in the art will appreciate that the network interface unit 860 includes the necessary circuitry for connecting the WDI server 814 to the Internet 704, and is constructed for use with the TCP/IP protocol.

The WDI server 814 also includes a processing unit 826, a video display adapter 856, and a mass memory, all connected via bus 828. The mass memory generally comprises a RAM 832, ROM 829, and a permanent mass storage device, such as a hard disk drive 858, tape drive, optical drive, floppy disk drive, or combination thereof. The RAM 832 stores an operating system 834 for controlling the operation of the WDI server 814. It will be appreciated that this component may comprise a general purpose server operating system as is known to those of ordinary skill in the art, such as UNIX, LINUX™, or Microsoft WINDOWS NT®. A binary input/output system ("BIOS") 830 is also provided for controlling the low-level operation of WDI server 814.

The mass memory also stores the program code and data for providing a WWW site for defining and utilizing data interchange operations. More specifically, the RAM 832 stores a WWW server application program 836 as known to those skilled in the art. The WWW server application program 836 comprises computer executable instructions which, when executed by the WDI server computer 814, generate the WWW browser displays described below, including performing the logic necessary to generate the screen displays. The WDI server 814 may include a JAVA virtual machine 838, a SMTP handler application 840 for transmitting and receiving e-mail, a HTTP handler application 840 for receiving and handing HTTP requests, JAVA servlets 844 for execution on the WDI server 814, Active Server Pages ("ASP") for generating the WWW browser screen displays described below, and an HTTPS handler application 848 for handling secure connections. The HTTPS handler application 848 may initiate communication with an external security application 850, or a credit card processing application for communicating with remote financial institutions in a secure fashion. WDI server 814 also comprises an input/output interface 854 for communicating with external devices, such as a mouse, keyboard, scanner, or other input devices not shown in FIGURE 28. Likewise, WDI server 814 may further comprise additional mass storage facilities such as CD- ROM/DVD-ROM drive 852 and hard disk drive 858. The operation of the WDI server 814 is described below in additional detail.

FIGURE 29 depicts several of the key components of the client computer 816. Those of ordinary skill in the art will appreciate that the client computer 816 includes many more components then those shown in FIGURE 29. However, it is not necessary that all of these generally conventional components be shown in order to disclose an illustrative embodiment for practicing the present invention. As shown in FIGURE 29, the client computer 816 includes a network interface unit 884 for connecting to a LAN or WAN, or for connecting remotely to a LAN or WAN. Those of ordinary skill in the art will appreciate that the network interface unit 884 includes the necessary circuitry for such a connection, and is also constructed for use with the TCP/IP protocol, the particular network configuration of the LAN or WAN it is connecting to, and a particular type of coupling medium. The client computer 816 may also be equipped with a network interface unit 884 or modem capable of connecting to the Internet through a point to point protocol ("PPP") connection or a SLIP connection as known to those skilled in the art.

The client computer 816 also includes a ROM BIOS 866, central processing unit 862, a video display adapter 880, and a memory. The memory generally comprises a random access memory 868 ("RAM"), a read-only memory 865 ("ROM") and a permanent mass storage device, such as a disk drive. The RAM 868 stores an operating system 869 for controlling the operation of the client computer 816. The memory also includes a WWW browser 870, such as Netscape's NAVIGATOR® or Microsoft's INTERNET EXPLORER® browsers, for accessing the WWW. It will be appreciated that these components may be stored on a computer-readable medium and loaded into the memory of the client computer 816 using a drive mechanism associated with the computer-readable medium, such as a floppy drive (not shown), CD-ROM/DVD-ROM drive 882, or hard drive 876. An input/output interface 878 may also be provided for receiving input from a mouse, keyboard, or other input device. The memory, network interface unit 884, video display adapter 880, and input/output interface 878 are all connected to the central processing unit 862 via bus 864. Other peripherals may also be connected to the central processing unit 862 in a similar manner. ^'

As is known to those skilled in the art, WWW browser 870 may execute instructions for displaying WWW pages generated by WDI server 814. Moreover, WWW browser 870 may utilize a JAVA virtual machine to execute JAVA "applets" 874 served by WDI server 814 as known to those skilled in the art. Operation of the WDI server 814 and client computer 816 is described in more detail below.

Referring now to FIGURE 30, an illustrative routine 900 for creating, editing and scheduling a data interchange operation will be described. Routine 900 begins at block 902 and responds to the selection of the data interchange menu item shown in FIGURE 23. In response to the selection of the data interchange menu item, a data interchange menu is displayed to the user. The data interchange menu includes menu selections for creating and modifying accounts, projects, sources, operations, targets, schedules, definitions, and for monitoring the status of the workflow engine. At block 904, a selection of one of the foregoing menu items is received from the user. At block 906, the menu item selected by the user is identified, and routine 900 branches to the appropriate block based upon the user's selection. If, at block 906, it is determined that the user has selected a menu item for creating and editing accounts, routine 900 branches to block 908. An illustrative routine for creating and editing accounts is described below with reference to FIGURE 31.

If, at block 906, it is determined that the user has selected a menu item for creating and editing projects, routine 900 branches from block 906 to block 910. An illustrative routine for creating and editing projects is described below with reference to FIGURE 33.

If, at block 906, it is determined that the user has selected a menu item for creating and editing source objects, routine 900 branches from block 906 to block 912. An illustrative routine for creating and editing source objects is described below with reference to FIGURE 37.

If, at block 906, it is determined that the user has selected a menu item for creating and editing data interchange operations, routine 900 branches from block 906 to block 914. An illustrative routine for creating and editing data interchange operations is described below with reference to FIGURE 34.

If, at block 906, it is determined that the user has selected a menu item for creating and editing target objects, routine 900 branches from block 906 to block 916. An illustrative routine for creating and editing target objects is described below with reference to FIGURE 38.

If, at block 906, it is determined that the user has selected a menu item for creating and editing schedules, routine 900 branches from block 906 to block 918. An illustrative routine for creating and editing schedules is described below with reference to FIGURE 41.

If, at block 906, it is determined that the user has selected a menu item for creating and editing definitions, routine 900 branches from block 906 to block 920. An illustrative routine for editing definitions is described below with reference to FIGURE 43.

If, at block 906, it is determined that the user has selected a menu item for status, routine 900 branches from block 906 to block 922. An illustrative routine for viewing the status of the workflow engine is described below with reference to FIGURE 52.

If, at block 906, it is determined that the user has selected a menu item for logging out of the WDI server routine 900 branches from block 906 to block 924 where the user is logged out. Routine 900 then continues to block 926, where it ends. Referring now to FIGURE 31, an illustrative routine 950 for creating and editing accounts will be described. Routine 950 begins at block 954, where a process tree is displayed. The process tree illustrates a hierarchy of accounts, projects, and operations, in a tree format. Accounts are the top-level folders in the account management hierarchy. Accounts hold projects which, in turn, hold collections of related operations. The process tree contains all accounts, projects, and data interchange operations accessible to the current user. If no accounts, projects or data interchange operations have been created by the user, the process tree will be empty. Likewise, if the user has not been granted access rights to view, edit, or delete accounts, the process tree will be empty. Routine 950 continues from block 954 to block 956, where user input is received selecting a portion of the process tree. At block 958, a determination is made as to whether the user has selected an existing account in the process tree. If the user has selected an existing account in the process tree, routine 950 branches to block 960.

At block 960, the account details associated with the selected account are displayed and the user is permitted to edit the account details if the user has edit privileges. The account details are described below. From block 960, routine 950 continues to block 962 where the updated account details may be saved in the WDI database. From block 962, routine 950 continues to block 972, where it returns.

If, at block 958, it is determined that the user did not select an existing account, routine 950 continues to block 964, where a detennination is made as to whether the user has selected a menu item for creating a new account. If the user has selected a menu item for creating a new account, routine 950 branches to block 966. At block 966, the user is permitted to utilize the new operation "wizard". The new operation "wizard" steps the user through the creation of a new account, project, and operation, and prompts the user for account details necessary to create the new account. Regardless of whether the user chooses to use the new operation "wizard", new account details are received from the user at block 968. New account details may include such information as account name, account description, account number, a street address to be associated with the account, and a contact name. From block 968, routine 950 continues to block 970, where the new account details are saved in the WDI database. The process tree is also updated to reflect the new account. From block 970, routine 950 continues to step to block 972, where it returns.

Referring now to FIGURE 32, an illustrative screen display for creating and editing accounts will be described. As discussed above, a WWW browser 870 is used to browse a WWW site provided by WDI server 814. The screen display shown in FIGURE 32 is created at the WDI server 814, transmitted to the client computer 816, and displayed by the WWW browser 870. As described above with reference to FIGURE 31, the screen display shows a process tree 980 which includes a listing of the accounts, projects and data interchange operations available to the currently logged-in user. The accounts, projects and data interchange operations are shown in the process tree 980 with the accounts at the highest level, the projects nested one level, and the data interchange operations nested one level below.

When the user selects an account such as "CR demo," the account details regarding the selected account are shown. The account details include an account name 982, an account description 984, an account number 986, an account address 988, and an account contact 990. Utilizing an input device, the user may be able to edit any of the account details and save them. Likewise, the user may be able to select a user interface button for creating a new account and provide the account details. Furthermore, the user may select the operation wizard button for utilizing a step-by-step procedure for creating a new account. Once the user has created a new account, the new account will be reflected in the process tree 980.

Referring now to FIGURES 33 and 35, an illustrative routine 1000 for creating an editing projects will be described. Projects are groups of related data interchange operations. Routine 1000 begins at block 1004, where the process tree 980 illustrating accounts, projects and data interchange operations is displayed. At block 1006, user input is received. From block 1006, routine 1000 continues to block 1008, where a determination is made as to whether an existing project has been selected. If an existing project has been selected such as "Demo Project", shown in FIGURE 35, routine 1000 branches to block 1010. At block 1010, project details are displayed and user input is received for editing the project details. Project details may include such items as a project name 1080, project description 1082, project type 1084, and a project contact 1086. From block 1010, routine 1100 continues to block 1012, where the updated project details are saved in the WDI database 818. Routine 1000 continues to block 1020, where it returns.

If, at block 1008, it is determined that an existing project was not selected, routine 1000 continues to block 1014, where a determination is made as to whether a user interface item for creating a new project was selected by the user. If such an item was selected, routine 1000 branches to block 1016, where new project details are received. Alternatively, the user may choose to use the project wizard to create a new project. From block 1016, routine 1000 continues to block 1018, where the new project details are saved in the WDI database 818. The process tree 980 is also updated to reflect the new project. From block 1018, routine 1000 continues to block 1020, where it returns.

Referring now to FIGURES 34 and 36, an illustrative routine 1050 for creating and editing data interchange operations will be described. As described generally above, a data interchange operation is an operation by which a source object located at a source location may be transformed and saved as a target object at a target location. By utilizing the illustrative routine 1050, a user may provide all of the information necessary to create a data interchange operation definition.

Routine 1050 begins at block 1054, where the process tree 980 is displayed. From block 1054, routine 1050 continues to block 1056 where user input is received. At block 1058, a determination is made as to whether user input was received selecting an existing data interchange operation shown in the process tree 980. If an existing data interchange operation was selected by the user, routine 1050 branches to block 1060 where the operation details and definitions for the selected data interchange operation are displayed.

As shown in FIGURE 36, operation details include an operation name 1088, an operation description 1090, and an operation type 1092. Operation definitions may include a source object 1096, a target object 1106, and a transformation 1108 to be performed on the source object. Additionally, the data interchange operation definitions may include a schedule 1098 describing when the data interchange operation should be performed. Moreover, a success message 1100 and a failure message 1110 may be defined for transmitting a message in the event of success or failure of the data interchange operation, respectively. Likewise, a success operation 1102 and a failure operation 1112 may be specified for perfoiming another data interchange operation in the event of success or failure of the selected data interchange operation, respectively. Similarly, a success workflow 1104 and a failure workflow 1114 may be defined for performing an entire workflow in the event of success or failure of the selected data interchange operation, respectively. In this manner, a data interchange operation may be utilized to trigger another data interchange operation or an entire workflow in the event of its success or failure.

It should be appreciated that the user may only select from source objects, target objects, transformations, schedules, and success/failure operations and workflows that have been previously created, or create new objects, etc. Illustrative routines for creating these objects are described below. Referring again to FIGURE 34, at block 1060 the user may be permitted to edit the data interchange operation definitions. At block 1062, the updated data interchange operation definition is saved in the WDI database 818. From block 1062, the routine 1050 continues to block 1076 where it ends.

If, at block 1058, it was determined that the user did not select an existing data interchange operation, routine 1050 continues to block 1064, where a determination is made as to whether the user has selected an option for creating a new data interchange operation. If such a selection was made by the user, routine 1050 branches to block 1066 where operation details for the data interchange operation are received from the user. As described above, operation details may include an operation name 1088, an operation description 1090, and an operation type 1092. From block 1066, the routine continues to block 1068 where the operation definitions are received from the user. At block 1070, the operation details and definitions are saved in the WDI database 818 as a data interchange operation definition. From block 1070, routine 1050 continues to 1076, where it returns. It should be noted that the user may utilize a new data interchange operation wizard 1094 to create a new operation in an easy-to-use fashion similar to that described above with respect to the creation of accounts and projects.

If, at block 1064, it is determined that the user has not selected an option for creating a new data interchange operation, routine 1050 continues to block 1072. At block 1072, a determination is made as to whether the user has selected a user interface button 1116 for performing the selected operation immediately. If the user has made such a selection, routine 1050 branches to block 1074, where the currently selected data interchange operation is transmitted to the message database for immediate execution. The user may also be provided with feedback as to whether the operation was successfully or unsuccessfully executed. Routine 1050 continues from block 1074 to block 1076, where it returns.

Referring now to FIGURES 37 and 39, an illustrative routine 1154 for defining source object locations will be described. The source object location defines where a site is currently stored (e.g., on an FTP server, in a file share directory, in a database, etc.). Routine 1150 begins at block 1154 where the available source object locations are displayed to the user. According to an embodiment of the invention, the source object locations are displayed in a source list 1250, shown in FIGURE 39. The source list 1250 contains all those source object locations which have been previously defined and which are accessible to the user. At block 1156, user input is received. At block 1158, a determination is made as to whether the user has selected an existing source object location from the source list 1250. If the user has made such a selection, routine 1150 branches to block 1160, where details for the selected source object location are displayed, and edits to the source object location details are received from the user. As shown in FIGURE 39, source object location details may include the source name 1252 and a source type 1254. Depending upon the source type 1254, additional details may also be specified. For instance, if the source type 1254 is selected as a "file share", the additional source object location details may include a path 1256 and a directory file filter 1258. The directory file filter 1258 is used to select files within the path 1256. Other types of source object location details may be required for other types of sources. Those skilled in the art should appreciate that the present invention may utilize source types such as FTP, ODBC, HTTP, UNC, and other protocols known to those skilled in the art. From block 1160, routine 1150 continues to block 1162 where the updated source object location details are saved in the WDI database. From block 1162, routine 1150 continues to block 1184, where it returns.

If, at block 1158, it is determined that the user has not selected an existing source object location from the source list 1250, routine 1150 continues to block 1164, where a determination is made as to whether the user has selected an option for creating a new source object location. If the user has made such a selection, routine 1150 branches to block 1166, where the source object location name 1252 is received from the user. At block 1168, the source type 1254 is received from the user. At block 1170, the source definition is received from the user. As described above, the source definition includes details for connecting to the source object location, such as a path 1256 and a directory file filter 1258. At block 1172, the new source name type and source definition are saved in the WDI database 818 as a new source object location. From block 1172, routine 1150 continues to block 1184, where it returns.

If, at block 1164, it is determined that the user has not selected an option for creating a new source object location, routine 1150 continues to block 1174 where a determination is made as to whether the user has selected an option for connecting to the selected source object location. If such a selection has been made, routine 1150 branches to block 1176, where an attempt is made to connect to the source object location. For instance, if the selected source object location is identified as a "file share" object, an attempt will be made to connect to the path 1256 specified by the user. At block 1178, a determination is made as to whether a successful connection was made to the source object location. If a successful connection was made to the source object location, routine 1150 continues to block 1180 where connection details are displayed for the source object location. If the connection attempt was unsuccessful, routine 1150 branches to block 1182, where an error message is displayed. In this manner, a user may determine whether a connection may be successfully made to the source object location. From blocks 1180 and 1182, routine 1150 continues to block 1184 where it returns.

Referring now to FIGURES 38 and 40, an illustrative routine 1200 for defining target object locations will be described. A target object defines where transformed data will be sent (e.g., to a different FTP location, in a file share directory, in a database, etc.) According to an embodiment of the invention, a user may select a menu item for defining and editing target object locations. When such a selection is made by the user, the available target object locations are displayed at block 1204. According to an embodiment of the present invention, a target list 1260 is displayed to the user showing all defined target object locations that are available to the user. At block 1206, user input is received. At block 1208, a determination is made as to whether the user has selected an existing target object location from the targets list 1260. If such a selection has been made, routine 1200 branches to block 1210 where details for the selected target object location are displayed and edits to the details may be received from the user.

As shown in FIGURE 40, target details may include a target name 1262 and a target type 1264. Depending on the target type 1264, additional target details may also be provided. For instance, as shown in FIGURE 40, when a file transfer protocol ("FTP") target type 1264 is selected, additional target object location details may include an FTP host 1266, an FTP host path 1268, a file name 1270, a login 1272, and a password 1274. This information specifies an FTP host and path where the target object should be saved. Additionally, the user may indicate whether encryption 806 should be performed on the target object prior to saving at the target object location. Methods for electronically encrypting data in this manner are well known to those skilled in the art. Additionally, target object locations may comprise locations accessible via FTP, ODBC, HTTP, or UNC protocols, or other protocols known to those skilled in the art. Moreover, a target object location may also comprise an SMTP server. By utilizing an SMTP server as a target object location, e-mail messages may be sent as a part of the data interchange operation, as compared to simply saving a file at a target object location. At block 1212, the updated target details are saved in the WDI database 818. From block 1212, routine 1200 continues to block 1234 where it returns. If, at block 1208, it is determined that the user did not select an existing target object location from the targets list 1260, routine 1200 continues to block 1214, where a determination is made as to whether the user has selected an option for creating a new target object. If the user has made such a selection, routine 1200 branches to block 1216, where the target object name is received from the user. At block 1218, the target object type is received from the user. At block 1220, the target object definition is received from the user. As described above, the contents of the target object definition will depend on the target type, and will include information necessary to connect to the target location and save the target object. At block 1222, the new target object name, target object type, and target object definition are saved in the WDI database 818. From block 1222, the routine 1200 continues to block 1234, where it returns.

If, at block 1214, it is determined that the user has not selected an option for creating a new target object, the routine 1200 continues to block 1224. At block 1224, a determination is made as to whether the user has selected an option for connecting to the target object location. If such a selection is made by the user, routine 1200 branches to block 1226 where an attempt is made to connect to the target object location. At block 1228, a determination is made as to whether a successful connection was made to the target object location. If a successful connection was made, the routine 1200 continues to block 1230 where connection details are displayed to the user. If a successful connection was not made, routine 1200 branches from block 1228 to block 1232 where an error message is displayed. From blocks 1230 and 1232, routine 1200 continues to block 1234, where it returns.

Referring now to FIGURES 41 and 42, an illustrative routine 1300 for creating and editing data interchange operation schedules will be described. According to an embodiment of the present invention, a user may select a menu item

modify these items to customize the schedule for their particular needs. For instance, the user may modify the occurrence pattern 1354 to specify that the data interchange operation occur daily, weekly, monthly or every number of days specified by the user. Likewise, the user may modify the occurrence frequency 1356 to specify that the data interchange operation occurs once at a specified time or that it occurs every number of hours, minutes, etc., specified by the user. Furthermore, the user may modify the duration 1358 to specify that the data interchange operation start on a given date and end on a given date, or continue without duration. Once the user has modified these items to customize the schedule to their preferences, the updated schedule is saved in the WDI database 818 at block 1312. From block 1312, the routine 1300 continues to block 1326, wherein it returns.

If, at block 1308, it is determined that the user has not selected an existing schedule, the routine 1300 continues to block 1314. At block 1314, a determination is made as to whether the user has selected an option for creating a new schedule. If such input is received from the user, routine 1300 branches to block 1316, where the new schedule name 1352 is received from the user. At block 1318, the occurrence pattern 1354 for the new schedule is also received from the user. At block 1320, the occurrence frequency 1356 is received from the user. At block 1322, the duration 1358 is received from the user. At block 1324, the new schedule name, occurrence pattern, occurrence frequency, and duration are saved in the WDI database. At block 1326, routine 1300 returns.

Referring now to FIGURE 43, an illustrative routine 1400 for defining documents, transformations, process messages and target messages in connection with a data interchange operation will be described. Routine 1400 begins at block 1404 where the definitions menu 1474 is displayed in response to the user's selection of the definitions menu item. The definitions menu 1474 includes tabs for defining documents, transformations, process messages, and target messages. At block 1406, user input selecting one of the menu items from the definitions menu 1474 is received. At block 1408, the menu item selected by the user is identified. In response to the identification of the correct menu item, the routine 1400 branches to the appropriate block. In particular, if the user selected the documents tab from the definitions menu 1474, routine 1400 branches to block 1410. An illustrative routine for defining documents is described below with reference to FIGURE 44.

If, at block 1408, it is determined that the user has selected the target messages menu item, routine 1400 branches to block 1412. An illustrative routine for defining target messages is described below with reference to FIGURE 47. Likewise, if at block 1408 it is determined that the user has selected the define process messages menu item, routine 1400 branches to block 1416. An illustrative routine for defining process messages is described below with reference to FIGURE 51. If, at block 1408, it is determined that the user has selected a menu item for defining transformations, routine 1400 branches from block 1408 to block 1418. An illustrative routine for defining transformations is described below with reference to FIGURE 46. From blocks 1410, 1412, 1416, and 1418, routine 1400 continues to block 1420, where it returns.

Referring now to FIGURES 44 and 45, an illustrative routine 1450 for defining documents will be described. Documents define the files that are stored at the source object location that are to be transferred. As described above, routine 1450 is executed in response to the selection of the documents tab from the definitions menu 1474. In response to the selection of the documents tab, the previously defined documents that are available to the user are displayed at block 1454. According to embodiment of the invention, a documents list 1476 is displayed identifying these documents. At block 1456, user input is received. At block 1458, a determination is made as to whether the user has selected an existing document from the documents list 1476. If such a selection has been made, the routine 1450 branches to block 1460 where a document definition for the selected document is displayed to the user and the user is permitted to edit the document definition. The document definition may include a document name 1478 and a document type 1480. Depending on the document type 1480 selected by the user, additional information may be provided as a document type definition 1482.

For instance, if the user chose a delimited document type 1480, a delimiter 1484 may be required to indicate the character that separates the fields of the document. Moreover, additional information may need to be provided as part of the document type definition 1482 to further define the document. In this example, a field name, sequence, and type may be defined to specify the fields of the document and their types. By selecting an add records user interface button, additional fields may be added until the document is accurately described. Additional information may be necessary for other document types as is known to those skilled in the art.

Once the user has edited the document type definition 1482 at block 1460, the routine 1450 continues to block 1462 where the modified document definition is saved in the WDI database. From block 1462, the routine 1450 continues to block 1474, where it returns. If, at block 1458, a determination is made that the user has not selected an existing document from the documents list 1476, the routine 1450 continues to block 1464. At block 1464, a determination is made as to whether the user has selected an option for creating a new document definition. If the user has selected such an option, the routine 1450 branches to block 1466 where the document name 1478 is received from the user. From block 1466, the routine continues to block 1468, where the document type 1480 is also received from the user. At block 1470, the document type definition is received from the user. As described above, the type of information required to define the document type definition will be dependent on the document type 1480 specified by the user. At block 1472, the new document definition is saved in the WDI database and reflected in the documents list 1476. At block 1474, the routine 1450 returns.

Returning now to FIGURES 46, 48, and 49, an illustrative routine 1500 for defining transformations will be described. As described above, the routine 1500 is executed in response to selection of the transformations tab from the definitions menu 1474. The routine 1500 provides the user the ability to create and edit transformations that will be applied to documents located at source object locations during data interchange operations.

Routine 1500 begins at block 1504, where the previously defined and available transformations are identified in the transformations list 1530. At block 1506, user input is received. At block 1508, a determination is made as to whether an existing transformation identified in the transformations list 1530 has been selected by the user. If the user has made such a selection, the routine 1500 branches to block 1510, where the transformation definition is displayed for the selected transformation and the user is permitted to edit the transformation definition. As shown in FIGURE 48, the transformation definition includes a mapped fields window 1542, which shows the transformation of fields of the documents located at the source object location to fields of the document to be saved at the target object location. Selection of these fields is made by the user by selecting entries from the available source fields window 1532 and the available target fields window 1534. When a user makes a selection from the available source fields 1532, the selected source field appears in the selected source field window 1536. Likewise, when a user selects one of the available target fields 1534, the selected field appears in the selected target field window 1538.

In order to map the selected source field 1536 to the selected target field 1538, the user selects a "map" user interface button 1540. In response to the selection of the "map" user interface button 1540, the selected source field 1536 is mapped to the selected target field 1538 and added to the mapped fields window 1542. hi this manner, different documents' fields may be mapped to each other, and documents can be transformed from one format to another. The user then may customize the transformation of the data contained in the selected source field 1536 to the selected target field 1538 by selecting the formula user interface button 1544. hi response to the selection of the formula user interface button 1544, the transformation definition window 1546 shown in FIGURE 49 is displayed.

The transformation definition window 1546 allows the user to customize the operation applied to the source field. According to an embodiment of the invention, the transformation definition window 1546 is implemented as a JAVA applet. The user may select from a number of arithmetic and logical operators 1547, functions 1548, and source elements 1549. Using the operators, functions, and source elements, the user can define virtually any type of operation to be applied to the selected source field 1536. For instance, functions performing arithmetic conversion, database operations, date and time conversions, logical conversions, math operations, and string operations may be utilized. Moreover, the user may utilize the transformation definition window 1546 to gain access to COM objects and to utilize these objects in the transformation. Once the user has customized the operation to be applied to the selected source field 1536, the user selects the "OK" interface button. Once the user has edited the transformation definition to their satisfaction, the modified transformation definition is saved in the WDI database 818 at block 1512. From block 1512, the routine 1500 continues to block 1526, where it returns.

If, at block 1508, it is determined that the user has not selected an existing transformation from the transformations list 1530, the routine 1500 continues to block 1514. At block 1514, a determination is made as to whether the user has selected an option for creating a new transformation. If the user has selected such an option, the routine 1500 branches to block 1516, where the transformation name is received from the user. At block 1518, the identity of the source and target objects is received from the user. At block 1520, the mapping of the fields in the source object to fields in the target object is received from the user as described above. At block 1522, the transformation formulas for mapping selected source field 1536 to the selected target field 1538 is received from the user as described above with respect to FIGURE 49. At block 1524, the new transformation is saved in the WDI database 818 and reflected in the transformations list 1530. At block 1526, the routine 1500 returns. Those skilled in the art may appreciate that the creation of a new transformation may be simplified for the user by utilizing a "wizard" that prompts the user for the appropriate input.

According to an embodiment of the invention, such a "wizard" may be utilized to define transformations that include source and target objects having parent and child relationships. Referring now to FIGURES 48A and 48B, a "wizard" for creating source transformations will be described. When a transformation wizard is used to create source objects having parent/child relationships, a list of available files 1900 is first presented to the user. The list of available files 1900 includes all of the documents previously defined and available to the user. Utilizing an "add file" user interface button 1904, the user may select files from the list of available files list 1900. The selected files are then added to the list of . selected files 1902. Utilizing a "remove file" user interface button 1906, the user may similarly remove files from the list of selected files 1902. When the user has completed selecting the files for use in the definition, the user may select a "next" user interface button.

Following the user's selection of the "next" user interface button, the screen display as shown in FIGURE 48B is presented to the user. Utilizing a parent file window 1908 and a child file window 1910, the user can specify a parent file and a child file for use in the transformation. In response to the selection of a parent file, the available file fields of the selected parent file are shown in the parent file fields window 1914. Likewise, in response to the selection of an available child file, the available child file fields are displayed in the child file fields window 1916. A defined files relationship is shown in the defined files relationship window 1912. Utilizing the parent file fields window 1914, the user may select fields of the selected parent file. Likewise, utilizing the child file fields window 1916, the user may select available fields from the selected child file. When a field of the parent file and a field of the child file have been selected, the user may utilize the "map" user interface button 1918 to map the selected parent file field to the selected child file field. By mapping a field of the parent file to a field of the child file, the user is specifying that a field of the parent file should be obtained by searching the specified field of the child. The mapped parent/child relationships are displayed in the parent/child relationship window 1920 in response to the selection of the "map" user interface button 1918. When the user has completed the mapping of the fields of the parent file to the fields of the child file, the user may select a "next" user interface button to continue to the next screen of the "wizard." FIGURES 48C and 48D illustrate performing this mapping process for target objects in a like fashion. Once the user has mapped parent and child fields of the source object and of the target object, the user is returned to the transformation screen display shown in FIGURE 48E. The available source fields window 1532 reflects the mapping of the child fields into the source object, as described above. Likewise, the available target fields window 1534 reflects the mapping of the child fields into the target object as also described above. Utilizing the mapping and transformation functions described above, the user may then utilize the defined source and target objects, including the child fields, in mapping and transformation operations as described above. In this manner, many-to-one and one-to-many operations may be defined.

Referring now to FIGURE 47, an illustrative routine 1550 for creating target messages will be described. Routine 1550 is executed in response to selection of the target messages tab from the definitions menu 1474. Routine 1550 begins at block 1554, where the available target messages are displayed. According to an embodiment of the invention, the previously defined target messages that are available to the user are displayed in the target messages list 1578. Target messages are messages that can be sent that are associated with a specific target object.

Routine 1550 continues from block 1554 to 1556, where user input is received. At block 1558, a determination is made as to whether the user has selected an existing target message from the target messages list 1578. If the user has selected a target message from the target messages list 1578, routine 1550 branches to block 1560. At block 1560, the selected target message is displayed and the user is permitted to edit the target message. According to an embodiment of the invention, the user may be able to edit the message name 1580, the SMTP mail server 1582 from which the message will be sent, and the traditional message fields, such as the to field 1584, the subject field 1588, and the message text 1590. It is important to note that the user may specify that data contained in the source object be used to complete the fields of the target message by specifying a variable. For instance, in the to field 1584, the user has specified by using the "trans" variable that the "email_to" field from the source object be used as the email address. Such variables can similarly be used in any of the other fields of the target message.

Once the user has completed editing the target message at block 1560, the routine 1550 continues to block 1562. At block 1562, the user's edits are saved as a modified target message in the WDI database 818. The routine 1550 then continues to block 1576 where it returns.

If, at block 1558, it is determined that the user has not selected an existing target message from the target messages list 1578, the routine 1550 continues to block 1564. At block 1564, a determination is made as to whether the user has selected an option for creating a new target message. If the user has made such a selection, the routine 1550 branches to block 1566, where the message name 1580 is received from the user. Routine 1550 then continues to block 1568, where the identity of the SMTP mail server 1582 is received from the user. At block 1570, destination information such as the to field 1584 and the subject field 1588 are received from the user. Additionally, the user may specify carbon copy recipients and a reply to address. At block 1572, the user provides message text 1590. From block 1572, the routine 1550 continues to block 1574, where the new target message is saved and added to the target messages list 1578. At block 1576, the routine 1550 returns.

Referring now to FIGURES 51 and 53, an illustrative routine 1600 for creating and editing process messages will be described. Process messages are messages that may be sent in response to the success or failure of a data interchange operation, such as the success messages and failure messages described above with reference to FIGURE 36. Routine 1600 is executed in response to the selection of the process messages tab from the definitions menu 1474. Routine 1600 begins at block 1604 where the previously created process messages that are available to the user are displayed as a process messages list 1676. Routine 1600 continues from block 1604 to block 1606, where user input is received.

At block 1608, a determination is made as to whether the user has selected an existing process message from the process messages list 1676. If the user has made such a selection, routine 1600 branches to block 1610, where the selected process message is displayed and user edits are received. The process message may include a message name 1678, an SMTP mail server 1680 from which the message should be sent, and other information necessary to send the process message. For instance, the message may include a to field 1682, a subject field 1684, and a text message 1686. Additional fields may include carbon copy fields and "reply to" fields. Moreover, the message name 1678 may include a success or failure identifier so that the message may be identified as a success message or a failure message. Once the user has completed editing the selected process message, the routine 1600 continues to step 1612, where the edits are saved in the WDI database 818. Routine 1600 then continues to step 1626, where it returns.

If, at step 1608, it is determined that the user has not selected an existing process message from the process messages list 1676, the routine 1600 continues to block 1614. At block 1614, a determination is made as to whether the user has selected an option for creating a new process message. If the user has selected such an option, the routine 1600 branches to block 1616, where a success or failure identifier is received from the user. As described above, the success or failure identifier may be included in the message name 1678 to identify the process message as a success message or a failure message. Routine 1600 then continues to block 1618, where the message name 1678 and the SMTP mail server 1680 are identified by the user. Routine 1600 then continues to block 1620, where the to field 1682, carbon copy recipients, and subject field 1684 are received from the user. Additionally, a "reply to" field may be specified by the user to indicate where a reply message to the process message should be transmitted. Routine 1600 then continues to block 1622 where the message text 1686 is received from the user. At block 1624, the new process message is saved in the WDI database 818 and reflected in the process messages list 1676. Routine 1600 then continues to block 1626, where it returns.

Referring now to FIGURES 52, 54, 55, and 56, an illustrative routine 1650 for providing status information will be described. Routine 1650 is executed in response to the selection of the status menu item described above with respect to FIGURE 30. In response to the selection of the status menu item, the status menu 1687 is displayed at block 1654. As will be described in more detail below, the status menu 1687 includes tabs for viewing a system log, viewing pending processes, and viewing an operation history.

From block 1654, routine 1650 continues to block 1656 where user input is received. At block 1658, a determination is made as to whether the user has selected the system log tab from the status menu 1687. If the user has made such a selection, routine 1650 branches to block 1660. At block 1660, the system log 1688 is displayed for the account, project, or operation currently selected by the user in the process tree 980. If an account is selected, the system log 1688 will include all of the projects and operations for the selected account. Similarly, if a project is selected from the process tree 980, the system log 1688 will include all of the operations for the selected project.

If, at block 1658, it is determined that the user has not selected the system log tab from the status menu 1687, the routine 1650 continues to block 1662. At block 1662, a determination is made as to whether the user has selected the pending processes tab from the status menu 1687. If the user has made such a selection, routine 1650 branches to block 1664 where the list of current operations 1690 is displayed to the user. As described above, the list of current operations 1690 will be detennined based upon the selected account, process, or operation selected from the process tree 980.

If, at block 1662, it is determined that the user has not selected the pending processes tab from the status menu 1687, routine 1650 continues to block 1668. At block 1668, a determination is made as to whether the user has selected the history tab from the status menu 1687. If the user has made such a selection, a transfer history 1692 is displayed. As described above, the transfer history will include all of the transfers performed for the selected account, project, or operation. From block 1670, routine 1650 continues to block 1672, where it returns. Operation Resolver

Referring now to FIGURE 57, an illustrative routine 1700 for the operation of the operation resolver 792 (shown in FIGURE 27) will be described. As described above, the operation resolver is responsible for performing the data interchange operations described in interchange operation definitions stored in the WDI database 818. The operation resolver performs the data interchange operations in response to messages received from the workflow engine 52. Accordingly, the routine 1700 begins at 1704, where the operation resolver receives an operation ED number from the workflow engine. The operation ID number comprises a request from the workflow engine 52 that the operation resolver perform the data interchange operation associated with the operation ID number.

Routine 1700 continues from block 1704 to block 1706, where a determination is made as to whether an operation status flag is set. An operation status flag may be associated with an operation ED number to indicate that a particular data interchange operation should not be performed. This functionality may be useful, for instance, where a subscriber to the automated business process system has not paid a bill. If, at step 1706, it is determined that the operation status flag is set, the routine 1700 branches to block 1708, where the current operation is skipped. Additionally, the workflow engine 52 may be notified that the operation was not performed. Routine 1700 then continues from block 1708 to block 1704 where another operation identification number is received from the workflow engine.

If, at block 1706, it is determined that the operation status flag is not set, routine 1700 continues to block 1710 where the data interchange operation definition is retrieved from the WDI database according to the operation ED number passed to the operation resolver by the workflow engine. As described above with respect to FIGURE 36, the data interchange operation definition contains all of the information necessary for the operation resolver to perform the requested data interchange operation.

From block 1710, routine 1700 continues to block 1712, where the source object is retrieved from the source location as defined in the data interchange operation definition. Routine 1700 then continues to block 1714, where the source object may be decrypted, if necessary. Methods and systems for decrypting data are well known to those skilled in the art.

From block 1714, routine 1700 continues to block 1716, where the specified transformation is performed on the source object to create the target object. As described above with reference to FIGURES 46-49, the transformation may result in the conversion of a source object to a different format, change the mapping of the fields in the source object, or other data transformation as known to those skilled in the art. An illustrative routine for performing the specified transformation is described below with respect to FIGURE 57A.

From block 1716, routine 1700 continues to block 1718 where the target object is encrypted if required. At block 1720, the target object is saved at the target location as specified in the data interchange operation definition. From block 1720, the routine 1700 continues to block 1722 where a determination is made as to whether the data interchange operation was successful.

If, at block 1722, it is determined that the data interchange operation was successful, the routine 1700 branches to block 1724 where a success operation is performed as defined in the data interchange operation definition. A successful operation may comprise the same or another data interchange operation, and may be triggered by transmitting an appropriate message to the message database 54. Likewise, at block 1726, a success workflow may be performed if specified in the data interchange operation definition. In this manner, an entire workflow may be executed in response to the success of the data interchange operation. A workflow may be triggered by transmitting an appropriate message to the message database 54, as described above. Additionally, at block 1728, a success message may be transmitted if specified in the data interchange operation definition. From block 1728, the routine 1700 returns to 1704 to continue processing requests from the workflow engine to perform data interchange operations.

If, at block 1722, it is determined that the data interchange operation was not successful, routine 1700 branches to block 1730. At block 1730, a failure operation is performed if specified in the data interchange operation definition. Likewise, at block 1732, a failure workflow may be performed if specified in the data interchange operation definition. Moreover, at block 1734, a failure message may be transmitted if specified in the data interchange operation definition. The operation resolver may also log the status of the workflow operation in the instance database 58. From block 1734, the routine 1700 returns to block 1704 where additional requests from the workflow engine to perform data interchange operations are received.

As described above, a data interchange operation may utilize source and target documents in XML format, flat file format, flat database format, hierarchy file or hierarchy database format, EDI format, or other similar datafile formats. In order to effect the mapping and transformations of files in these formats, data is first classified into two groups, namely, XML or non-XML data. By classifying the data into these two groups, data transformations may be performed using only four methods: XML to XML, XML to non-XML, non-XML to XML, and non-XML to non-XML. In order to effect the mapping and transformation functions, each format must have its own read and write functions. For XML files, a standard XML parser such as the Microsoft® XML Parser may be utilized to read and write the file. For the remainder of the file formats, an object model, called the Commerce Route Object Model ("CROM") is utilized to handle the data transformation.

The CROM includes two kinds of objects, the base object and the container object. The base object is used to store data element information such as a node, a value, or an attribute. Additionally, the base object contains the position information in the data tree, and a flag field to indicate whether the attribute is a primary key or a foreign key, and to show whether the node is a multiple instance node. The container object contains the collection of the root nodes of the tree. The container object also defines methods for parsing the structure file, creating structure trees for mapping, reading data files, and other functions such as searching a data element in the tree.

As described above, before a data mapping or transformation operation may take place, a user must define the relationship between a source object and target object. In general, the structure of the data elements is hierarchical. In order to show the structure, CROM creates a browser tree (such as the available source fields 1532) from the structure file, such as an industry standard Document Type Definition ("DTD") for XML, or a proprietary .SCM file for non-XML formats. The .SCM file contains not only the table and CROM information for the data, but also defines the parent/child relationships between tables. Once the user has created the mapping and/or transformation to be applied to the source object at the source location, the specified transformation may be performed. An illustrative routine 1950 for performing the specified transformation is shown in FIGURE 57A. Referring now to FIGURE 57A, the illustrative routine 1950 for performing the specified transformation will be described. It should be appreciated by the reader that for each file format, CROM provides a reading function and a writing function. The CROM first reads the source data and transforms the source data into a common data structure to which the writing application may be applied. By utilizing a common data structure for all file formats, the transformation and mapping process is greatly simplified. The CROM object is used to represent the definition of a mapping and transformation operation, and is called a "STRUCT tree object." A DATA tree object is used to represent the data when a transformation takes place. As will be described in more detail below, the object may comprise a node, the value of the node, or an attribute of a node. The node object may also contain a flag to indicate whether the node object is a single node or a multi-instance node.

The routine 1950 begins at block 1954, where the source document at the source location is read. Depending on the source data type, CROM calls a reader to generate a source data tree object. At block 1956, the DTD or SCM file is read. The file is then parsed to create the target STRUCT tree object. At block 1958, the target STRUCT tree object is "walked" to visit each node in the tree. Walking a tree in this manner is well know to those skilled in the art. At block 1960, each node in the tree is identified, and for each node blocks 1962-1968 and blocks 1974-1982 are performed. Blocks 1962-1968 are performed if the node comprises a multi-instance tree object. Blocks 1974-1982 are performed if the node is a single instance node.

If a determination is made that the node comprises a multi-instance STRUCT tree object, the routine 1950 branches to block 1964 where the mapping definitions for the node are collected and analyzed. At block 1966, the deepest descendant child node of the tree object is identified. At block 1968, blocks 1978, 1980, and 1982 are performed for each descendant child node to create a data node object. Once these blocks have been performed for each node, the routine 1950 continues to block 1970 where the target object is written at the target location.

If a node is determined to be a single instance node, the routine 1950 branches from block 1960 to block 1976, where a target data node object is created. At block 1978, all mapping definitions of the node value and its attributes are defined. At block 1980, all source data elements appearing in the mapping definitions are identified and the source data elements are defined from the source data tree object. At block 1982, the specified transformation is called to define the target value and its attribute in the target object. At block 1970, the target object is written to the target location. At block 1972, routine 1950 returns.

Referring now to FIGURE 58, an illustrative routine 1750 for the operation of the scheduler 820 (shown in FIGURE 27) will be described. As described above with respect to FIGURES 41 and 42, the user may define schedules for the execution of data interchange operations. The scheduler 820 is operative to receive the schedules defined by the user and to perform the data interchange operations at the time periods specified in the schedule. Routine 1750 performs this functionality.

Routine 1750 begins at block 1754, where the schedule retrieves the current time. At block 1756, the schedule retrieves the occurrence schedule from the WDI database 818. As described above with respect to FIGURES 41 and 42, the occunence schedule defines the times at which the data interchange operation should be executed.

Routine 1750 continues from block 1756 to block 1758 where a determination is made as to whether any scheduled operations are to be performed at the current time. If no scheduled operations are to be performed at the current time, routine 1750 branches to block 1754. If scheduled operations are to be performed, routine 1750 continues from block 1758 to block 1760.

At block 1760, a determination is made as to whether an operation status flag is set associated with a scheduled operation. As described above, if an operation status flag is set for a data interchange operation, that operation should not be performed. Therefore, if an operation status flag is set, the routine 1750 branches to block 1762, where the scheduled operation may be skipped. If an operation status flag is not set for the scheduled data interchange operation, the routine 1750 continues to block 1764 where the scheduled data interchange operations are executed. As described above, data interchange operations may be executed by the schedule by transmitting an appropriate message to the message database 54 which causes the workflow engine to execute the scheduled data interchange operation. Server Administration

In order to monitor and administer the operation of the workflow engine 52, a menu option for server administration may be provided to users of the automated business process system. Referring now to FIGURE 59, an illustrative routine 1800 for administrating the operation of the workflow engine 52 will be described. Routine 1800 begins at block 1804 where a login is received from a registered subscriber of the automated business process system. Once a valid login has been received, routine 1800 continues from block 1804 to block 1806, where a selection is received from the server administration menu. As shown in FIGURE 60, a server administration menu may include options for viewing a system log, viewing an error log, viewing an operations queue, defining users and groups of the system, and controlling the operation of the workflow engine 52. Accordingly, at block 1808, determination is made as to which server administration item has been selected by the user.

If, at block 1808, it is determined that the user has selected the menu item for viewing the system log 1810, a system log will be provided to the user. An illustrative system log 1824 is displayed in FIGURE 60, and includes a list of all operations performed by the system. The system log 1824 may also include the data and time the operations were performed, the source object, error codes, and other status messages associated with each operation. According to an embodiment of the present invention, this information is stored in the instance database 58, as described above.

If, at block 1808, it is determined that the user has selected the menu item for viewing the error log, the routine 1800 branches to block 1812. At block 1812, an error log 1826 is displayed to the user. An illustrative error log 1826 is shown in FIGURE 61 and includes lists of all errors encountered by the server during the execution of data interchange operations..

If, at block 1808, it is determined that the user has selected a menu item for viewing an operations queue, the routine 1800 branches to block 1814, where an operations queue 1828 is displayed to the user. An illustrative operations queue 1828 is shown in FIGURE 62. Because no operations are currently pending in the queue, the operations queue 1828 shown in FIGURE 62 is empty. However, if operations were currently pending in the message queue database 54 awaiting retrieval by the workflow engine, the operations queue 1828 would include the identity of the operations, the time that the operations were received, and any other messages associated with the pending operations. Moreover, the user may be permitted to delete pending operations from the queue.

If, at block 1808, it is determined that the user has selected a menu item for performing workflow server services, the routine 1800 branches to block 1816. At block 1816, a services window is displayed to the user as shown in FIGURE 63. The services window 1875 may include information regarding the operation of each workflow engine 52. As described above, multiple workflow engines 52 may be used simultaneously. Accordingly, status information for each server may be displayed, including an indication of whether the server is running or is stopped. Additionally, a user interface button may be provided to the user for starting or stopping each workflow engine. According to an embodiment of the invention, the workflow engine 52 is implemented as a distributed COM object and may be remotely started and stopped from the automated business processes service web site. The services window 1875 may also include status information on the scheduler 820, including an indication of whether the scheduler is running or stopped. Moreover, the scheduler may be started and stopped in a manner similar to that described above with respect to the workflow engine 52. In this manner, multiple servers may be administered from a central location.

The services window 1875 may also include options for configuring the workflow engine 52. As shown in FIGURE 64, the services window 1875 may include an option for changing the proxy server 1877 used by workflow engine 52. Additionally, the services window 1875 may allow the user to modify database connection information 1879. Database connection information 1879 may include information necessary for the workflow engines to connect to the process database 56, the instance database 58, and the message database 54. Moreover, the services window 1875 may allow the user to change the SMTP server 1881 utilized by workflow engine 52.

If, at block 1808, it is determined that the user has selected a menu item for configuring users or groups, routine 1800 branches from block 1808 to block 1818. At block 1818, the user is provided with the user configuration screen 1890 shown in FIGURE 65. The user configuration screen 1890 includes options for configuring the permissions of users and groups of users to access the automated business processes system. Users and groups of users may be permitted access on a operation basis, a project basis, or an account basis. Moreover, users may be given high-level access providing permissions to the entire system.

If, at block 1808, it is determined that the user has selected a menu item for logging out of the server administration system, the routine 1800 branches to block 1820. At block 1820, the user is logged out, and the routine 1800 continues to block 1822 where it ends.

It should be appreciated by the reader that the present invention provides a method and system for automating business processes. According to an embodiment of the invention an Internet web site is provided at which a user may define business processes, including data interchange operations. Data interchange operations comprise operations for retrieving source objects at a source location, transforming the source objects to create target objects, and saving the target objects at a target location. Data interchange operations may be performed in response to a user command, in response to a user defined schedule, or as part of a workflow process. Additionally, data interchange operations may trigger other data interchange operations, workflow processes, or messages, in response to their success or failure.

While the 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.

Claims

The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:

1. A method for performing a data interchange operation, comprising: receiving a request to perform said data interchange operation comprising the identity of a source object, a source location, a target location, and a transformation; and in response to receiving said request, executing said data interchange operation by: retrieving said source object at said source location, performing said transformation on said source object to create a target object, and saving said target object at said target location.

2. The method of Claim 1, further comprising: determining whether said data interchange operation was successfully executed; and executing a success data interchange operation in response to determining that said data interchange operation was successfully executed.

3. The method of Claim 1 , further comprising: determining whether said data interchange operation was successfully executed; and executing a success workflow in response to determining that said data interchange operation was successfully executed.

4. The method of Claim 1 , further comprising: determining whether said data interchange operation was successfully executed; and executing a failure data interchange operation in response to determining that said data interchange operation was not successfully executed.

/

5. The method of Claim 1, further comprising: determining whether said data interchange operation was successfully executed; and executing a failure workflow in response to determining that said data interchange operation was not successfully executed.

6. The method of Claim 1, further comprising: determining whether said data interchange operation was successfully executed; and transmitting a success message in response to determining that said data interchange operation was successfully executed.

7. The method of Claim 1, further comprising: determining whether said data interchange operation was successfully executed; and transmitting a failure message in response to determining that said data interchange operation was not successfully executed.

8. The method of Claim 1 , further comprising: determining whether said source object is encrypted; and in response to determining said source object is encrypted, decrypting said source object prior to performing said transformation on said source object.

9. The method of Claim 1, further comprising: determining whether said request includes a request that said target object be encrypted; and in response to determining that said target object should be encrypted, encrypting said target object prior to saving said target object at said target location.

10. The method of Claim 1, wherein said request is transmitted according to a pre-defined schedule.

11. The method of Claim 1, wherein said request is transmitted in response to a user command.

12. The method of Claim 1, wherein said request is transmitted in response to determining that said workflow operation comprises a task in a workflow process.

13. A networked computer system for automating business workflows, the system comprising: a stored set of information defining a sequence of tasks for completing a workflow process; an operation resolver for executing data interchange operations; a workflow engine residing on one or more computers in the networked computer system for: monitoring an incoming queue for incoming messages associated with said workflow process; reading an incoming message from said queue; determimng whether said message comprises a request to perform a data interchange operation; and in response to determining that said message comprises a request to perform a data interchange operation, transmitting a request to said operation resolver identifying said data interchange operation.

14. The system of Claim 13, wherein said operation resolver is further operative to receive said request to perform said data interchange operation from said workflow engine and to perform said data interchange operation.

15. The system of Claim 14, wherein executing said data interchange operation comprises: retrieving the identity of a source object, a source location, a target location, and a transformation associated with said workflow operation; retrieving said source object at said source location; performing said transformation on said source object to create a target object; and saving said target object at said target location.

16. The system of Claim 15, wherein said operation resolver is further operative to: determine whether said data interchange operation was successfully completed; and to transmit a message to said queue identifying a success data interchange operation in response to determining that said data interchange operation was successfully completed.

17. The system of Claim 16, wherein said operation resolver is further operative to: determine whether said data interchange operation was successfully completed; and to transmit a message to said queue identifying a failure data interchange operation in response to determining that said data interchange operation was not successfully completed.

18. The system of Claim 17, wherein said operation resolver is further operative to transmit a success message in response to determining that said data interchange operation was successfully completed.

19. The system of Claim 15, wherein said operation resolver is further operative to: determine whether said data interchange operation was successfully completed; and to transmit a message to said queue identifying a success workflow process in response to determining that said data interchange operation was successfully completed.

20. The system of Claim 19, wherein said operation resolver is further operative to: determine whether said data interchange operation was successfully completed; and to transmit a message to said queue identifying a failure workflow process in response to determining that said data interchange operation was not successfully completed.

21. The system of Claim 20, wherein said operation resolver is further operative to transmit a failure message in response to determining that said data interchange operation was not successfully completed.

22. The system of Claim 13, further comprising: a scheduler for transmitting a request to perform a data interchange operation to said queue according to a pre-defined schedule.

23. The system of Claim 13, further comprising: a web data interchange server for receiving a data interchange operation definition from a client computer, and for making said data interchange operation definition available to said operation resolver.

24. The system of Claim 23, wherein said data interchange operation definition comprises the identity of a source object, a source location, a target location, and a transformation associated with said workflow operation.

25. The system of Claim 24, wherein said operation resolver is further operative to receive said request to perform said data interchange operation and to identify said data interchange operation definition based upon said request.

26. The system of Claim 25, wherein said operation resolver is further operative to: retrieve said source object at said source location; performing said transformation on said source object to create a target object; and save said target object at said target location.

27. A networked computer system for automating business workflows, the system comprising: a stored set of information defining a sequence of tasks for completing a workflow; a modeling tool for generating the stored set of information comprising a graphical user interface to define the tasks and routes between the tasks, said modeling tool operative to define one of said tasks as a data interchange operation; and a workflow engine residing on one or more computers in the networked computer system for: monitoring an incoming queue for incoming messages associated with the workflow; reading the incoming messages; and initiating one or more activities for completing one or more tasks associated with the incoming message.

28. The system of Claim 27, wherein said modeling tool is further operative to identify a previous version of said stored set of information and to add said stored set of information as a new version.

29. The system of Claim 28, wherein said modeling tool is further operative to make said new version active as of a specified date.

30. The system of Claim 27, wherein said modeling tool is further operative to identify a previous version of said stored set of information and to replace said previous version with said stored set of information.

31. The system of Claim 30, wherein said modeling tool is further operative to make said stored set of information active as of a specified date.

32. The system of Claim 27, wherein said modeling tool is further operative to identify a plurality of previous versions of said stored set of information and to delete said plurality of previous versions of said stored set of information prior to saving said stored set of information.

33. The system of Claim 32, wherein said modeling tool is further operative to make said stored set of information active as of a specified date.

34. The system of Claim 27, wherein said modeling tool is further operative to make said stored set of information available to a specified workflow engine.