HK1145218B

HK1145218B - A system, method and graphical user interface for workflow generation, deployment and/or execution

Info

Publication number: HK1145218B
Application number: HK10111727.5A
Authority: HK
Inventors: 让-巴普蒂斯特‧莱昂内利; 特里萨拉‧钱达里亚
Original assignee: 西安姆贝拉有限公司
Priority date: 2007-09-11
Filing date: 2008-09-10
Publication date: 2014-07-04

Description

Systems, methods, and graphical user interfaces for workflow generation, scheduling, and/or execution

Technical Field

This document relates to graphical user interfaces. More particularly, the present document relates to graphical user interfaces and related systems for generating, scheduling, and/or executing one or more workflows.

Background

Companies may use one or more business processes and other workflows to perform their core and ancillary businesses. These workflows can include, for example, workflows that facilitate processing information as it moves between or within any business rules, including purchasing, manufacturing, marketing, selling, billing, recruitment, information technology support, etc. of a company and/or its customers, vendors, suppliers, etc.

To facilitate information processing, the workflow defines two or more tasks that are organized and connected in a specific and desirably efficient manner. Each task may be any automatable activity for business rules in which information entered into the task ("input information") may be manipulated and/or output. Examples of such tasks include downloading information from a remote server, converting file formats, processing updates, communicating with a customer or order management system, sending email messages, automatically backing up changes, and so forth.

Typically, the input information for each task resides or must be input (e.g., from a physical file) into one or more data files of multiple computer systems of the company and/or its customers, vendors, suppliers, etc. While some of these computer systems use compatible platforms and protocols ("compatible systems"), some of the computer systems often use disparate platforms and/or protocols ("incompatible systems"). Unfortunately, such incompatible systems make it very difficult to at least access and transfer input information between computer systems.

Conventional solutions for automatically accessing and/or communicating input information between compatible and incompatible systems include (i) manual solutions and (ii) automatic solutions. The manual solution utilizes personnel to communicate with the incompatible system, whereby the personnel can manually communicate input information to and from the incompatible computer. Automated solutions, on the other hand, use custom software and/or hardware specifically adapted to interface with incompatible systems ("custom interfaces").

While conventional solutions may meet the particular needs set forth in a certain set of circumstances, such conventional solutions may be time, capital, and resource consuming for a company. For example, a company requires an initial cost of time, funds, and resources to build, test, implement, and provide support for an initial version of a customization interface. However, when the input information resides on an incompatible system that was not considered or ignored when establishing the initial version of the custom interface, the company requires additional costs in time, money, and resources for establishing, testing, executing, and supporting additional versions of the custom interface. Moreover, a company may also encounter other additional costs in time, money, and resources for developing new or rebuilt implementations when the custom interface no longer functions properly due to updates, upgrades, or other modifications to the computer system, if possible.

Accordingly, there is a need for a system and method that facilitates generating, scheduling, and/or executing workflows, wherein accessing and communicating input information between computer systems having both compatible and disparate platforms and/or protocols does not require a customized interface. That is, a system and method that facilitates generating, scheduling, and/or executing workflows that facilitates interoperability between computer systems having both compatible and disparate platforms and/or protocols. There is also a need for a system and method that facilitates generating, scheduling, and/or executing workflows in which access to and communication of input information can be provided regardless of updates, upgrades, or other changes made to computer systems having and/or added computer systems.

Drawings

In order that the manner in which the above-recited features are achieved can be understood in more detail, a more particular description is provided below with reference to the figures illustrated in the appended drawings.

It should be noted that, like the detailed description, the figures in the accompanying drawings are exemplary only. Accordingly, the drawings and detailed description are not to be taken in a limiting sense and other equally effective examples are possible and contemplated. Furthermore, like reference numerals in the figures denote like elements, wherein:

FIG. 1 is a block diagram illustrating an example of a user device that facilitates generating, scheduling, and/or executing a workflow;

FIG. 2 is a flow diagram illustrating a flow that facilitates generating, scheduling, and/or executing a workflow;

FIG. 3 is a block diagram illustrating a system for generating, scheduling, and/or executing workflows;

FIG. 4 is a flow diagram illustrating a flow for facilitating the generation, scheduling, and/or execution of a workflow;

FIG. 5 is a block diagram illustrating another system for generating, scheduling, and/or executing a workflow; and

FIG. 6 illustrates a diagram of an example of a display screen of a graphical user interface for facilitating the generation, scheduling, and/or execution of a workflow.

Detailed Description

In the following detailed description, numerous specific details are set forth to provide a thorough understanding of example embodiments or other examples described herein. It is understood, however, that the embodiments and examples may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the description below. Furthermore, the disclosed embodiments are for exemplary purposes only and other embodiments may be used in place of, or in combination with, the disclosed embodiments.

Architecture example

FIG. 1 is a block diagram illustrating an example of a user device 100 that facilitates generating, scheduling, and/or executing workflows. As described above, the workflow includes a plurality of tasks; each task defines a respective automatable behavior ("task function") for operating on and/or outputting information input thereto.

The user device 100 may be, for example, any one or any combination of a personal computer, portable computer, handheld computer, mobile telephone, digital assistant, personal digital assistant, cellular telephone, smart phone, pager, digital tablet, laptop computer, internet appliance, and the like. In general, user device 100 comprises a processor-based platform operating on any suitable operating system, such asLinux and/or Symbian, and capable of executing software.

However, the user equipment 100 may comprise a large number of elements, some of which are not shown in fig. 1 for simplicity. Details of an example structure of a user device that may represent the user device 100 are described with reference to fig. 3. As shown in FIG. 1, user device 100 includes a processing platform 102 operable to control, operate or interact with a monitor or other display device (collectively, "monitor") 104 and/or an input/output ("I/O") device 106 through respective couplings.

The monitor 104 may be any suitable device that displays visual images generated by the processing platform 102. For example, monitor 104 may be any one or any combination of a liquid crystal display-based monitor, a cathode ray tube monitor, a plasma display monitor, a surface-conduction electron emitter display monitor, an organic light emitting diode display monitor, or any other monitor that may display a visual image using a television and/or computer protocol such as super video graphics array, digital visual interface, phase inversion by line, SECAM, NTSC, and the like.

The I/O devices 106 may be any devices that receive input from a user (human or machine) to control, operate or interact with the operation of the processing platform 102. Examples of I/O devices 106 include any one or any combination of pointing devices such as mice, joysticks, trackballs, touch pads, pointer sticks, light pens, head pointers, soap mice, eye tracking devices, digitizing tablets and styluses, data gloves that translate user motion into computer gestures; such as a keyboard or touchpad. Although illustrated as one device, the I/O device 106 may be divided into two or more devices that may each have reduced, increased, or equivalent functionality as compared to the I/O device 106.

The processing platform 102 includes a memory 108 capable of storing (i) software, such as graphical user interface ("GUI") software 110; and (ii) one or more records or other data structures (collectively, "records") 112, which may be stored as or in a single file or multiple files, respectively. The records 112 may be structured as text, tables, databases, distributed hash tables, distributed concurrent target storage, documents formed using tags such as extensible markup language ("XML"), extensible markup language-remote procedure call protocol ("XML/RPC"), or similar markup languages; or documents formed according to a given protocol, such as hypertext transfer protocol ("HTTP"), simple object access protocol ("SOAP"), etc.

The records 112 may include workflow records 114, workflow operation records 116₁-116_nAnd workflow sort record 118₁-118_m. For example, the workflow record 114 may be stored as an XML document in one or more files. Workflow operations may be recorded 116₁-116_nStored in one or more files, the workflow order record 118 may be sorted₁-118_mStored in one or more files.

As described in more detail below, each workflow-operation record 116₁-116_nCorresponding to a workflow task.Each of these tasks may be configured as a sequence of logical operations for completing this task, as well as preliminary setup operations and/or subsequent validation operations for achieving proper execution of the task. The logic, setup, and/or verification operations of a task may take the form of an excerpt (abstraction) of a function associated with one or more complex processes for obtaining, converting, and outputting information, rather than information for performing a single low-level programming construct that handles a small portion of such functions, such as calling a given function or assigning a given value to a variable, etc. To facilitate this, workflow-operation records 116₁-116_nOne or more parameters for each respective task may be included. The parameters for each task ("task parameters") may include a representation of the task's functionality; one or more references to task input information for generating, scheduling, and/or executing the task, and/or one or more references to services, settings, rules, variables, expressions, templates, features, directives, commands, fields, and the like.

Each workflow order record 118₁-118_mCorresponding to the ordering of one task to another. To facilitate this, each workflow order record 118₁-118_mOne or more parameters ("sequence parameters") associated with the ordering may be included. The sequence parameter may include a task indication for ordering; a task execution order for generating, scheduling, and/or executing the ordering, a set of conditions and/or services that control the task execution order, a set of settings, rules, variables, expressions, templates, features, directives, commands, and the like.

The workflow record 114 may include task parameters for all or a subset of the tasks and sequence parameters for all or a subset of the sequences within the workflow. Alternatively, the workflow record 114 may include task parameters for all or a subset of the tasks and be arranged in an order according to the ordering. Workflow record 114, workflow operation record 116₁-116_nAnd workflow sequencingRecord 118₁-118_mBut may take other forms and include other information.

In addition to the memory 108, the processing platform 102 includes one or more processors (collectively "processors") 120 that perform (e.g., launch, generate, run, maintain, etc.) and operate on a suitable operating system. The processor 120 may support execution of the GUI software 110, store the records 112 in the memory 108, send the workflow records 114 to facilitate generation, scheduling, and/or execution of the workflow, issue a trigger signal, and/or issue one or more commands and/or instructions to generate, schedule, and/or execute the workflow. Examples of processor 108 may include conventional processors, microprocessors, multi-core processors, and/or microcontrollers.

When executed by the processor 120, the GUI software 110 may execute a GUI and present at least one display screen 122 of the GUI on the monitor 104. The display screen 122 includes a window 124. The window 124, in turn, includes a control pane 126, a control toolbar 128, and a workflow pane 130.

The control pane 126 includes task controls 132₁-132_n. Task control 132₁-132_nTasks that can be selected into the workflow are graphically represented. By controlling the task 132₁-132_nExamples of (b) include into a workflow graphic representation ("graphic workflow") 134 listed on the workflow pane 130 to perform such selection. Task control 132₁-132_nAnd any instances thereof, may be represented by the GUI software 110 as icons, etc.

The control toolbar 128 includes sequencing controls 136, examples of which may also be used to form the graphical workflow 134 and, in turn, the workflow. The sequencing control 136 graphically represents the coupling that can be used to couple together and sequence the tasks. The sequencing control 136 and any instances thereof may be represented by the GUI software 110 as a connector line, or the like.

The workflow pane 130 includes a graphical workflow 134. The graphical workflow 134 may include and sort control instances 140₁-140_mAre ordered togetherTask control instance 138₁-138_n. Each task control instance 140₁-140_nMay be any task pane 132₁-132_nEach sort pane instance 138₁-138_mMay be an instance of the sort pane 136.

Task pane instance 138₁-138_nCan be separately associated with the workflow-operation record 116₁-116_nAssociation, workflow operation records 116₁-116_nMay include passing task control instances 138₁-138_nTask parameters of the represented task. Similarly, sort pane instance 140₁-140_mRecords 118 may be separately ordered with workflow₁-118_mAssociated, workflow sort record 118₁-118_nMay include through the sort pane instance 140₁-140_nSequence parameters of the represented sequence.

Notwithstanding the above, workflow operation records 138₁-138_nWorkflow sort record 140₁-140_mAnd workflow record 114 are depicted as three separate entities, but the partitioning and use of these three entities may be omitted. For example, the workflow record 114 (or any other record 112) may include a task pane instance 138₁-138_nTask parameters of the represented task and the ordered pane instance 140₁-140_nSequence parameters of the represented sequence.

Alternatively, the workflow record 114 (or any other record 112) may include a task pane instance 138₁-138_nTask parameters of the represented task and in accordance with the ordered pane instances 140₁-140_nIs arranged in the order of the ordering represented by the common sequence. To facilitate this, task pane instance 138 is provided₁-138_nAnd sort pane instance 140₁-140_mMay be directly associated with the workflow record 114. Workflow record 114, workflow operation record 116₁-116_nAnd workflow sort record 118₁-118_mBut may also take other forms and be arranged in other ways.

Moreover, although the window 124 includes only two panes and one toolbar, as shown, the window 124 may include more or fewer panes and more or fewer toolbars. Moreover, window 124 may also include tabs, drop down menus, command menus, and the like. The control pane 126 may include more or fewer task type panes than shown, and the pane toolbar 128 may include more sort type panes than shown.

Alternatively, the control pane 126 and the control toolbar 128 may be combined into a single pane or toolbar that includes both task-type and sequencing-type controls. As another alternative, one or both of the control pane 126 and the control toolbar 128 may include both task-type and sort-type controls.

As yet another alternative, one or more of the sequencing-type controls 136 may be associated with the task control 132₁-132_nCombined, integrated, or integrally constructed together to form a unified control. The unified control avoids having a separate sort type control for each task type control. Such a uniform control may be represented by the GUI software 110 as an icon or the like with a connector element. Instances of unified controls on the workflow pane 130 may be associated with the workflow-operation record 116₁-116_nAnd workflow sort record 118₁-118_nBoth are associated. Alternatively, the instance of the unified control can be directly associated with the workflow record 114.

Example of operation

Referring now to FIG. 2, a flow diagram of a process 200 for facilitating generating, scheduling, and/or executing a workflow is illustrated. For convenience, the flow 200 is described with reference to the user equipment 100 of fig. 1. However, other structures may be used to perform the process 200.

Flow 200 begins at start block 202 where processor 120 executes GUI software 110 to form a GUI and present display screen 124. After a start block 202, the flow 200 proceeds to a process block 204.

As illustrated in processing block 204, the GUI software 110 may form the graphical workflow 134. The GUI software 110 may operate as such in response to one or more operations of the GUI by the user via the I/O device 106. For example, the GUI slave task control 132 is operated in response to the I/O device 106 operating₁-132_nTo select and place (e.g., by drag-and-drop) such instances on the workflow pane 130, the GUI software 110 can render task control instances 138 on the workflow pane 130₁-138_n。

Moreover, the GUI is operated in response to the I/O device 106 to (I) select such an instance from the widget toolbar 128, (ii) place the instance on the workflow pane 130, and (iii) place the task control instance 138₁-138_nAnd sort control instance 140₁-140_mCoupled, the GUI software 110 can present a sequencing control instance 140 on the workflow pane 130₁-140_m。

Through GUI operations of the I/O device 106, the GUI software 110 may obtain information for populating the records 114, 116₁-116_nAnd 118₁-118_mTask parameters and sequence parameters. For example, per task control instance 138₁-138_nAs a function of the presence in the graphical workflow 132, the GUI software 110 may obtain task parameters that define the functionality of the task. For example, task control instance 138₁A task for starting a workflow ("start task") may be represented. The start task parameter may include information for starting a task function, which, as indicated, marks the start of the workflow. Task control instance 138₁Presence within the graphical workflow 134 enables the launch task parameters to be populated into the records 114 and/or 116₁-116_nIn (1).

Alternatively and/or additionally, the GUI may be entered by a user using a keyboard or other I/O device into one or more fields of one or more display screens (not shown) of the GUISoftware 110 may supplement boot and/or other task parameters. Entering information in this manner may also be used to select a task control instance 138₁-138_nAnd place (e.g., drag and drop) it on the workflow pane 130. For example, a user may enter a character or character string into the control for each task instance 138₁-138_nIn one or more fields of the GUI display screen. The GUI software 110 may then interpret this input and, in response, present the task control instance 138 on the GUI₁-138_n。

Similar to the task parameters, the GUI software 110 can obtain information that can be used to generate task control instances 140 as a function of the existence and layout of the graphical workflow 132₁-140_nThe execution order of (2) sequence parameter. For example, the task control instance 138 can be considered₁-138_nThe output of one is connected to another task control instance 138₁-138_nBy each link of the input (e.g., by ordering control instances 140 a-140)_mShown) to obtain the sequence parameters. Alternatively and/or additionally, the GUI software 110 may obtain the sequence parameters by entering a character or string of characters into one or more fields of one or more display screens (not shown) of the GUI. Entering parameters in this manner may also provide for selecting an instance of a sequencing control 140a-140_mAnd place it on the alternative way of the workflow pane 130. As described above, the GUI software 110 may then interpret the input and, in response, display an instance 138 of a task control for establishing a connection₁-138_nOf the link of (2) the sequencing control instances 140a-140_m。

After processing block 204, the flow may proceed to processing block 206. As illustrated in processing block 206, the GUI software 110 may generate or compose a workflow record 114 from the graphical workflow 134. The GUI software 110 may, for example, populate the workflow record 114 with the task and sequence parameters it obtained in processing block 204.

As an alternative to directly populating the workflow record 114, the GUI software 110 may first populateCharging workflow operation record 116₁-116_nAnd workflow sort record 118₁-118_m. For example, the GUI software 110 may use the task instance 138 obtained at processing block 204₁-138_nPopulating workflow operation records 116 with associated task parameters₁-116_n. Moreover, the GUI software 110 may associate the sequencing control instance 140 obtained in processing block 204 with the sequence control instance₁-140_mPopulating the workflow ordering record 118 with associated sequence parameters₁-118_m. Sorting records 116 in filling workflow operations and workflows₁-116_n、118₁-118_mThereafter, the GUI software 110 may record 116 the workflow operation according to the ranking₁-116_nInserted into the workflow record 114.

Moreover, the GUI software 110 may arrange the records 114, 116 in a particular manner₁-116_nAnd 118₁-118_m. For example, the records 114, 116 may be arranged in an object-oriented programming manner as respective instances of objects of one or more given classes₁-116_nAnd 118₁-118_mTask parameters and sequence parameters. For example, task control instance 138₁-138_nA start task and a task for stopping the workflow ("stop task") may be defined separately. Workflow operation record 116₁、116₂Task parameters are defined for scheduling the start and stop instances of the start and stop objects of the start and stop classes, respectively. Workflow sort record 118 may be arranged in a similar manner₁-118_mAnd a workflow record 114.

The GUI software 110 may also prepare a workflow record 114 for transmission to the target device to facilitate generating, scheduling, and/or executing the workflow. For example, the GUI software 110 may format the workflow record 114 according to one or more suitable information exchange mechanisms. Examples of such switching mechanisms include: american Standard code for information interchange ("ASCII"), XML/RPC, HTTP, SOAP, shared memory, sockets, local or remote procedure calls, and the like. In addition to facilitating sharing and replication of the workflow record 114, the switch mechanism advantageously facilitates interoperability between the processing platform 102 and a target device, such as the host device 306 (FIG. 3) to which the workflow record 114 may be sent.

After processing block 206, the flow 200 proceeds to processing block 208. As shown in process block 208, the GUI software 110 may send the workflow record 114 to facilitate generating, scheduling, and/or executing the workflow. To accomplish this, the GUI software 110 may cause the processing platform 102 to transmit the workflow record 114 from the user device 100 to the target device. This transmission may occur in response to a trigger initiated by the GUI software 110 (e.g., in response to a GUI operation by a user) or in response to a query from the target device.

Alternatively, the GUI software 110 may cause the processing platform 102 to periodically send the workflow record 114 using, for example, routines for synchronizing and/or replicating the workflow record 114 on the target device. After processing block 208, the flow 200 proceeds to processing block 210.

As shown in process block 210, the GUI software 110 may cause the processing platform 102 to send commands issued from the GUI to execute the workflow. The execution command may be, for example, a trigger signal issued from the GUI. The trigger signal may be initiated in response to a user operation of the GUI.

The GUI software 110 may cause the processing platform 102 to issue the execution command at any time after the workflow record 114 is sent, either simultaneously, or substantially simultaneously. As described in more detail below, in response to the execution command, the target device may directly interpret the workflow record 114 to execute the workflow.

As an alternative to interpreting the workflow record 114 directly, the target device may generate computer-executable instructions (or simply "code") for executing the workflow ("workflow-executable code") as a function of the workflow record 114. The target device may generate the workflow-executable code prior to the execution time, or at the same, or substantially the same, time as the execution time. To facilitate the former, prior to the execution command, the GUI software 110 and/or the processing platform 102 may issue another command to cause the target device to generate the workflow-executable code. The target device may also generate one or more tests for testing the workflow-executable code.

After the process block 210, the process 200 proceeds to an end block 212, at which point the process 200 ends. Alternatively, the process 200 may be repeated periodically, in a continuous manner, or when triggered as a result of a condition, such as adding, deleting, or modifying one or more tasks of a workflow. As another alternative, process block 210 may be repeated periodically, in a continuous manner, or when triggered as a result of a condition, to enable additional scheduling of the workflow.

System architecture example

FIG. 3 is a block diagram of a system 300 that facilitates generating, scheduling, and/or executing workflows. The system 300 includes a user device 302 and a host device ("host" 306). The user device 302 and the host 304 may be communicatively connected together through a network 304. In this way, the user device 302 and the host 304 can exchange input and/or scheduling information, as well as other information associated with workflow scheduling, through one or more communications carried over the network 304.

Network 304 may be a partial deployment or a full deployment of most any communication or computer network, including any combination of public or private, terrestrial wireless or satellite, or wired networks. Thus, the network 302 may include network elements from the public switched telephone network ("PSTN"), the internet, core and private public networks, wireless voice and packet data networks such as 1G, 2G, 2.5G, and 3G telecommunications networks, wireless office telephone systems ("WOTS"), and/or wireless local area networks ("WLANs") including bluetooth and/or IEEE 802.11 WLANs, wireless personal area networks ("WPANs"), wireless urban area networks ("WMANs"), and so forth.

The network elements may include circuit-switched as well as packet data elements to provide for the transmission of workflow records 114, triggers, execution commands and other information (collectively "workflow content") for generating, scheduling and/or executing workflows, and may be configured to communicate this workflow content using any number of protocols and in any manner consistent with providing this information to user device 302 and host 304. These protocols may include standardized, proprietary, open source, and toll free communication protocols for communicating content in circuit switched and/or packet data networks and the like.

The user equipment 302 is similar to the user equipment 100 of fig. 1, except as described below. The user device 302 may be any computing device, system, etc., and may be formed within a single device and centralized on a single server, client, peer or other type of node. Alternatively, the user device 302 may be comprised of one or more discrete devices and thus may be distributed among multiple servers, clients, peers, or other types of nodes. Moreover, the user device 302 may also be extensible (i.e., may use an upward and/or outward expansion approach).

As shown, user device 302 may include a processing platform 308 operable to control, operate, or interact with monitor 104 and/or I/O device 106 through respective connections. Processing platform 308 includes one or more processing units (collectively, "processors") 310, memory 312, support circuits 314, and a bus 316. Processor 310 may be one or more conventional processors, microprocessors, multi-core processors, and/or microcontrollers. The support circuits 314 facilitate operation of the processor 310 and may include well-known circuits including, for example, I/O interfaces, one or more network interface units ("NIUs"), cache, clock circuits, power supplies, and the like.

The processor 310 may exchange workflow content with the host 306 over the network 304 using the NIU. Thus, the NIU may be adapted to communicate via any terrestrial wireless, satellite, and/or wired media.

The memory 312 may store (and receive requests from the processor 310 to retrieve) software 318, records 112, 114, 116₁-116_nAnd 118₁-118_mAnd various other stored software packages, such as an operating system 320. The memory 312 may be or use random access memory, read only memory, optical memory, magnetic memory, removable memory, erasable programmable read only memory and variations thereof, content addressable memory and variations thereof, flash memory, disk drive memory, removable memory, any combination thereof, and the like. Moreover, the memory 312 may store (and receive requests from the processor 310 to obtain) operands, operators, spatial values, configurations, and other data used by the operating systems 320 and 318 to control the operation of the user device 302 and/or to facilitate performing its functions.

Bus 320 is used to transfer digital information between processor 310, memory 312, support circuits 314, and other portions (shown and not shown) of user device 302. The I/O interface is adapted to control the transfer of digital information between components (shown and not shown) of the user equipment 302. Further, the I/O interface is adapted to control the transfer of digital information between I/O devices disposed within, associated with, or connected to user device 302. Examples of I/O devices include I/O device 106, monitor 104, and any one or any combination of the following: (i) storage devices including, but not limited to, tape drives, floppy drives, hard disk drives, or compact disk drives; (ii) a receiver; (ii) a transmitter; (iii) a speaker; (iv) a display; (v) a speech synthesizer; (vi) output ports and (vii), and so on.

The operating system 320 may include code for operating the user device 302 and for providing a platform on which the software 318 may execute. The software 318 may include GUI software 110 and other user device software 322 that may perform exchange of workflow content using communication and security protocols compatible with the user and host devices 302, 306.

The GUI software 110 and the user device software 322 may be any of stand-alone, client/server, peer-to-peer, and other forms. The GUI software 110 may include code for accessing one or more services provided by the host 306. Using the code and information obtained from the user, the GUI software 110 is operable to validate its identity and then receive authorization to access (e.g., view, configure and/or execute) services provided by the host 306.

The host 306 may include one or more servers, including a host application server 324. The host application server 324 may be deployed on one or more general-purpose or special-purpose computers, personal computers, mainframes, minicomputers, server-type computers, and/or on a computer system such asAnd/or any processor-based platform operating on any suitable operating system, such as Linux, and capable of executing software.

Similar to the user device 302, the host-application server 324 may include a number of elements, some of which are not shown in fig. 3 for simplicity of illustration. The elements of host-application server 324 may be formed in a single device and centralized on a single server, client, peer or other type of node. Alternatively, the elements of host-application server 324 may be formed from two or more separate devices, and thus may be distributed among multiple servers, clients, peers, or other types of nodes.

As shown, host application server 324 includes one or more processing units (collectively, "processors") 326, memory 328, support circuits 330, and a bus 332. Processor 326 may be one or more conventional processors, microprocessors, multi-core processors, microcontrollers, or the like.

The bus 332 is used to transfer digital information between the processor 326, the memory 328, the support circuits 330, and other portions (not shown) of the host application server 324. The support circuits 330 facilitate operation of the processor 326 and may include one or more well-known circuits including, for example, one or more input/output I/O interfaces, one or more NIUs, cache, clock circuits, power supplies, and the like.

The I/O interface provides an interface to control the transfer of digital information between components (shown and not shown) of the host application server 324. The I/O interface also provides an interface for controlling the transfer of digital information between I/O devices (not shown) associated with or connected to the host application server 324. The I/O devices (not shown) may be implemented in any one or any combination of the following: (i) storage devices including, but not limited to, tape drives, floppy drives, hard disk drives, or compact disk drives; (ii) a receiver; (ii) a transmitter; (iii) a speaker; (iv) a display; (v) a speech synthesizer; (vi) (vii) output ports and (vii) pointing devices, such as mice, joysticks, trackballs, touch pads, pointer sticks, light pens, head pointers, soap mice, eye tracking devices, digitizing tablets and styluses, data gloves to convert user motion into computer gestures, and typing devices such as keyboards or touch pads; (vii) and so on.

The NIU facilitates the exchange (e.g., transmission and/or reception) of workflow content. Accordingly, the NIU may be adapted to communicate via terrestrial wireless, satellite, and/or wired media.

Memory 328 may store, and may be queried by processor 326 for, various software packages, such as operating system 334, application server software 336, and workflow application software 338. The memory 328 may be or use random access memory, read only memory, optical memory, magnetic memory, removable memory, erasable programmable read only memory and variations thereof, content addressable memory and variations thereof, flash memory, disk drive memory, removable memory, any combination thereof, and the like.

In addition, the memory 328 may also store the workflow record 114 and one or more libraries 340 for generating workflow executable code. The library 340, which may be written in C + +, may include, for example, routines for generating workflow executable code associated with each task ("task routines"). Additionally, the library 340 may also include routines for ordering the task routines according to the sequence parameters listed in the workflow record 114 ("sequence routines").

The memory 328 may also store operands, operators, spatial values, configurations, and other data that may be used by the application server software 336 and the operating system 334 to control the operation of the host application server 324 and/or facilitate performing its functions.

The host-application server 324 can be deployed according to an scale-up and/or scale-out approach. By using the upward scaling approach, the host-application server 324 may increase its processing power, storage, and number of network connections by using a symmetric, multi-processor architecture, thereby providing additional capacity. An advantage of the scale-up approach over the scale-out approach is that it provides simplified configuration and management. By using the scale-out approach, the host-application server 324 may balance workloads among multiple processors, multiple servers, dedicated processors, and/or servers for performing specialized tasks by increasing and/or decreasing capacity as needed, using physical or logical servers (e.g., a multi-node cluster approach), etc., to increase its processing power, storage, and number of network connections.

The operating system 334 may include and/or be embodied as various software and/or executable instructions or code for operating the host-application server 324. When executed by processor 326, operating system 334 provides a platform on which application server software 336 and workflow application software 338 may execute.

When executed by processor 326, workflow-application software 334 is operable to generate, schedule, and/or execute workflows. To facilitate this, the workflow-application software 122 may include an interpreter for interpreting the workflow record 114. The interpreter may include, for example, code for directly interpreting the workflow record 114 upon execution to execute the workflow in response to an execution command.

Alternatively, the workflow-application software 122 may include, for example, a workflow-builder module and a workflow-scheduling module. When executed by the processor 326, the workflow builder module is operable to obtain the workflow record 114 and generate workflow executable code as a function of the workflow record. To generate the workflow-executable code, the workflow-builder module 124 may include an analyzer and a code generator.

The analyzer includes code for analyzing the task parameters and/or sequence parameters ("analysis information") from the workflow record 114. The analyzer may also include functionality for verifying that the workflow record 114 is well-formed and valid.

The code generator includes code for examining the parsed information to determine which libraries 340 correspond to the task, and for combining the parsed information with one or more of the libraries 340 to form a code-group ("parsed-code-group"). To facilitate this, the code generator may further comprise code for ordering the analysis information according to an ordering reflected in the analysis information. The code generator may also include code for arranging or rearranging the analysis information dynamically and/or through user interaction to derive from the ordering reflected within the analysis information and provide another order of execution of the workflow tasks. This may be performed for efficiency (e.g., by analyzing the analysis information and determining the most efficient execution order), processing branches, processing errors, etc.

The code generator may also include code for combining the parsed-code sets with one or more of the libraries 340 to bind the parsed-code sets together ("binding libraries"). The code may use a binding library to facilitate the transmission of appropriate portions of task parameters and/or sequence parameters between adjacent sets of parsed code.

Optionally, the workflow builder module may include a compiler (not shown). The compiler includes code for compiling workflow executable code for execution by the workflow scheduling module 126. Alternatively, the workflow builder module 124 may not compile the workflow executable code until runtime, or may not compile the workflow executable code depending entirely on which programming language is used to generate the workflow executable code.

When executed by processor 326, the workflow-scheduling module is operable to execute workflow-executable code. In response to receiving or retrieving the execution command over the network 304, the workflow-scheduling module may execute the workflow-executable code. To execute the workflow executable code, the workflow scheduling module may be configured to provide the workflow application software 338 and other modules of the application server software 340 (as described in more detail below).

To simplify the illustration, the workflow builder and workflow scheduling module are described herein as separate entities. However, the workflow builder and workflow schedule module or their functionality may also be mixed or combined within the workflow application 324, or not present at all. Alternatively, the workflow-application software 324 may include the same or substantially the same functionality as the workflow-builder and workflow-scheduling module. As another alternative, each of the workflow constructor and workflow schedule module may be separate and distinct entities (e.g., separate software packages) from each other and/or from the workflow application software 324.

Workflow scheduling operations

Referring now to FIG. 4, a flow diagram of a process 400 for facilitating the generation, scheduling, and/or execution of a workflow is illustrated. For convenience, the flow 400 is described with reference to the system 300 of fig. 3. However, other architectures may be used to implement the flow 400.

The flow 400 begins at a start block 402 where the user device 302 executes the GUI software 110 to form a GUI and render the display screen 124. After a start block 402, the flow 400 proceeds to a process block 404.

As shown in process block 404, the user device 302 prepares the workflow record 114 for transmission via the GUI software 110. The GUI software 110 may perform this operation according to the processing blocks 204, 206 of fig. 2. The GUI software 110 may also prepare the workflow record 114 for transmission in other ways. After processing block 404, the flow 400 proceeds to processing block 406.

As shown in process block 406, the workflow-application software 338 retrieves the workflow record 114 from the GUI software 110. To accomplish this, the workflow-application software 338 may receive the workflow record 114 over the network 304 in response to a transmission resulting from a GUI operation, or alternatively, from a synchronization and/or replication routine. The GUI software 110 and the workflow-application software 338 may perform the sending and receiving of the workflow record 114 using any suitable information exchange mechanism. After process block 406, the flow 400 may proceed to optional process block 408 or process block 410.

As illustrated at optional process block 408, the workflow-application software 338 may generate workflow-executable code as a function of the workflow record 114. The workflow-application software 338 may perform this operation as follows.

The workflow-application software 338 may communicate the workflow record 114 to the workflow-builder module. The workflow builder module may then communicate the workflow record 114 to the analyzer. The analyzer may analyze the analysis information from the workflow record 114. The analysis information includes task parameters and/or sequence information from the workflow record 114. The analyzer may then communicate the analysis information to the code generator.

The code generator may examine the analysis information to determine which libraries 340 match the analysis information. This may include, for example, the code generator examining task parameters listed within the analysis information to determine the tasks contained within the workflow (e.g., by examining task function indications within each task parameter).

In addition to determining the tasks contained within the workflow, the code generator may also order the tasks according to the ordering reflected within the analysis information. To perform this operation, the code generator may first gather sequence parameters from the analysis information to obtain the ordering. The code generator may then order the analysis code-sets according to the ordering so that the tasks are performed in an order defined by the workflow (as represented by the graphical workflow 134). Alternatively, the code generator may arrange or rearrange the tasks in a different order than the sequence defined by the ordering, dynamically and/or through user interaction. As noted above, the code generator may perform this operation to obtain the most efficient execution sequence and/or processing branches, processing errors, and so forth.

In addition, the code generator may search the entire library 340 to determine a library ("matching library") that matches (e.g., has a consistent, the same, and/or substantially the same pattern) the task parameters and/or the sequence parameters. After locating the matching library, the code generator may combine the parsed information with the matching library to form a parsed code set. The code generator may form each parsed code set, for example, by applying a task parameter to a matching library corresponding to the task. This operation may include, for example, incorporating criteria specified in the task and/or sequence parameters into the code of the matching library. In addition, the code generator may also configure the parsed-code sets, or include a binding library to link the parsed-code sets together, to transfer appropriate portions of the task and/or sequence parameters between adjacent parsed-code sets. Once linked, the parsed-code sets constitute workflow-executable code.

Alternatively, the code generator may pass the workflow executable code to a compiler. The compiler may then compile the workflow executable code to make it ready for execution by the workflow scheduling module 126. Alternatively, the workflow builder module 124 may not compile the workflow executable code until runtime, or not compile at all.

After processing block 408, flow 400 proceeds to processing block 410. As illustrated at processing block 410, the workflow-application software 338 obtains the execution command from the GUI software 110 via the network 304. The GUI software 110 and the workflow-application software 338 may use any suitable information exchange mechanism to perform the sending and receiving of the execution command. As noted above, the execution command may be received at some time after the workflow record 114 is received, or alternatively, at the same or substantially the same time as the workflow record 114. After processing block 410, flow 400 proceeds to processing block 412.

As shown in process block 412, the workflow scheduling module executes the workflow. In response to the execution command, the workflow-application software 338 may interpret the workflow record 114 directly to execute the workflow.

If not directly interpreted, the workflow-application software 338 may indicate to the workflow-scheduling module that it received the execution command. Alternatively, the workflow-application software 338 may communicate an execution command to the workflow-scheduling module to cause the workflow-scheduling module to execute the workflow. The workflow scheduling module may perform the operation in response to the execution command.

When the execution command is received at the workflow-application software 338 prior to generating the workflow-executable code, the workflow-application software 338 and/or the workflow-scheduling module awaits completion of the generation of the workflow-executable code. Thereafter, the workflow-application software 338 may instruct the workflow-scheduling module to execute the workflow-executable code. The workflow scheduling module may execute the workflow executable code at any time after the workflow executable code is generated and the executable command is received.

The workflow-application software 338 may execute the workflow in either a test mode or a production mode (by directly interpreting or workflow-executable code). In the test mode, the workflow-application software 338 may initiate one or more tests to test the workflow, and execute the workflow for evaluation against the tests. When the workflow is executed for testing, the input information may mimic the input information for the production mode. In the production mode, the workflow-application software 338 may execute the workflow using the input information for generating the pattern.

To facilitate execution of the workflow (either through direct interpretation or workflow executable code), the workflow-application software 338 may provide the host-application server 324 (e.g., by providing one or more modules of the workflow-application software 338 and/or application-server software 340 for the task) to receive the service. The workflow-application software 338 may provide the host-application server 324 as a function of the functionality and criteria of each task. Examples of tasks and related functions and criteria are described in more detail with reference to fig. 5 and 6.

After the process block 412, the flow 400 proceeds to an end block 414, at which point the flow 400 ends. Alternatively, flow 400 may be repeated periodically, in a continuous manner, or when triggered as a result of a condition such as a command or trigger signal. As another alternative, process block 410 may be repeated periodically, in a continuous manner, or when triggered as a result of a condition such as an additional execution of a command, to thereby execute the workflow. As yet another alternative, the process block 412 may be repeated periodically (e.g., on a given schedule, etc.) to execute the workflow, either in a continuous manner, or when triggered as a result of a condition.

Alternate system architecture examples

FIG. 5 is a block diagram illustrating a system 500 for generating, scheduling, and/or executing workflows. The system 500 is similar to the system 300 of fig. 3, except as described herein. The system 500 includes a user device 302, a host device ("host") 502, a first endpoint device 504, a second endpoint device 506, a service database server 508, a service FTP server 510, a remote message store 512, a service HTTP server 514, a web server 516, and a service email server 517, each of which may be communicatively connected to another device via the network 304.

Each of the first endpoint device 504, the second endpoint device 506, the service database server 508, the service FTP server 510, the remote message store 512, the service HTTP server 514, the web server 516, and the service email server 517 (collectively "remote devices") may be, for exampleAny processor-based platform operating on any suitable operating system, such as Linux and/or Symbian, and capable of executing software. Each remote device 504 and 517 may include a number of elements, most of which are not shown in fig. 5 for simplicity of illustration.

The elements of each remote device 504-517 may be formed in a single device and centralized on a single server, client, peer or other type of node. Alternatively, remote device 504 and 517 may be comprised of two or more separate devices and thus may be distributed among multiple servers, clients, peers, or other types of nodes.

Similar to the host application server 324, each of the remote devices 504 and 517 may be configured as a server, although these devices may perform different services than the host application server 324. However, the remote device 504 and 517 need not be configured as a server, but rather have the capability to serve the host-application server 324.

The first endpoint device 504 may be configured as an application server and may include a memory ("first endpoint memory") 556. The first endpoint memory 556 may store source records obtained from the host application server 324 using file transfer protocol ("FTP").

The second endpoint device 506 may be configured using a messaging application. The messaging application may service requests and/or messages sent from the host application server 324.

The service database server 508 may be configured as a database server that may service requests from the host-application server 324. The service database server 508 may include a memory 558 for storing source database records transmitted from the host-application server 324 and target database records for transmission to the host-application server 324.

The service FTP server 510 may be configured as an FTP server, which may service requests from the host application servers 324. The service FTP server 510 may include a memory 560 for storing a target FTP file 562 to be transmitted to the host application server 324.

Remote message store 512 may be configured to hold (temporarily, permanently, or for some other period of time) one or more messages. These messages may be extracted and/or stored therein by one or more workflow tasks, another process (e.g., manual or automatic input by a remote server, client, etc.), and/or another workflow.

Further, messages in remote message store 512 may include or be populated with one or more target messages and/or one or more source messages. The targeted messages are messages that may be exchanged between the remote message store 512 and the content records 526 (by executing the workflow). The source message is a message that may be exchanged between the remote message store 512 and the content record 526 and/or messaging software 570 (as described in more detail below).

The service HTTP server 514 may be configured as an HTTP server and may service HTTP requests sent from the host application server 324. The web server 516 may be configured to provide web services to the host-application server 324. Service email server 517 may be configured as an email server and may service email requests sent from host-application server 324.

In order not to obscure the above and below description with details and/or features of the elements of system 300 described above, some of these details and/or features will not be repeated in the below description or the illustration of fig. 5. Additional details and/or features not described or shown in fig. 3 will be provided.

Host 502 is similar to host 306 of fig. 3. Like host 306, host 502 includes host application server 324. Host 502 also includes host http server 564. Under the control of the workflow-application software 324 (e.g., under the control of a workflow-scheduling module executing workflow-executable code), the host-application server 324 can connect to and interact with the host HTTP 564.

The host http server 564 may be included, for example, inAny processor-based platform operating on any suitable operating system, such as Linux and/or Symbian, and capable of executing software. Similar to the host-application server 324, the host-http server 564 may include a number of elements, most of which are not shown in FIG. 5 for simplicity of illustration.

The elements of the host http server 564 may be formed in a single device and centralized on a single server, client, peer or other type of node. Alternatively, the elements of the host http server 564 may be formed from two or more separate devices and may thus be distributed among multiple servers, clients, peers, or other types of nodes.

Although not shown, the host HTTP server 564 may include one or more processing units, memory, support circuits, buses, and other elements similar to those of the host application server 324. The memory of the host HTTP server 564 includes an operating system that may include and/or be embodied as various software and/or executable instructions or code for operating the host HTTP server 564. When executed by the processor of the operating system, the operating system provides a platform on which the host HTTP server 564 may execute software applications that service HTTP requests issued from and/or sent to the host application server 324.

The host http server 564 may be configured as a server that may assist the host-application server 324 in executing the workflow (as described in more detail below). However, the host http server 564 need not be configured as a server, but may take any form operable to execute the services of the host application server 324.

The memory 328 may also include various other software, such as messaging software 570, email software 572, FTP software 574, database software 574, and the like, which may be configured to facilitate requests by the host-application server 324. Each of the messaging software 570, email software 572, FTP software 574, and database software 574 can operate as clients, peers, and/or servers.

The messaging software 570, when executed by the host application server 324, provides an engine ("host messaging engine") for exchanging one or more messages between the workflow application software 338 and one or more remote devices, such as the remote message store 512. The messaging engine may exchange messages using any messaging protocol, such as Java messaging service ("JMS"), session initiation protocol ("SIP"), session initiation protocol ("SIMPLE") with extensions to instant messaging and presence services, application exchange ("APEX"), presence and instant messaging protocol ("PRIM"), extensible messaging and presence protocol ("XMPP"), instant messaging and presence service ("IMPS"), internet message access protocol ("IMAP"), and so forth.

When executed by host-application server 324, email software 572 provides the engine ("host email engine") to host-application server 324 for exchanging one or more email messages (with or without attachments) with serving email server 517, and for transferring those email messages to and from storage 328. The email engine is capable of interacting with the service email server 518 according to any version of the simple mail transfer protocol ("SMTP"), post office protocol ("POP"), internet message access protocol ("IMAP"), and other email service types.

The FTP software 574, when executed by the host application server 324, provides the engine ("host FTP engine") to the host application server 324. In accordance with FTP, the FTP engine may perform one or more file transfers between one or more remote devices, such as service FTP server 510 and storage 328.

When executed by the host application server 324, the database software 576 provides an interface ("host database interface") to the host application server 324 for exchanging one or more database records from one or more remote devices, such as the service database server 508, and for transferring such database records to and from the memory 328. The database software 576 may be, for example, a client interface such as a Java database connectivity ("JDBC") API, a root database connectivity ("RDBC") API, or the like. The client interface may be operable with Oracle, DB2, Microsoft Access, Microsoft SQL Server, MySQL, 4^thDimension, FileMaker, etc. database applications. In any case, the database software 576 can interface with any number of databases including using Oracle, DB2, Microsoft Access, Microsoft SQL Server, MySQL, 4^thDimension, FileMaker, etc. database applications.

In addition to the above, memory 328 may include a plurality of records or other data structures (collectively, "records"). These records may be used by and/or retrieved for use by one or more tasks during workflow execution. Examples of records include message records 518, template records 520, service definition records 522, content records 526, and recorded workflow records 556.

Message record 518 may include a repository ("message repository") that may be configured to hold one or more messages to be extracted by one or more tasks of the workflow. The message repository may include, for example, one or more messages for transmission or extraction from the host-application server 324 ("source messages"), and/or one or more messages for transmission to the host-application server 324 or extraction by the host-application server 324 ("target messages").

The template record 520 may include one or more transformation templates, schema templates, verification templates, and/or message templates. As described in more detail below, the conversion template may be used by the task to convert an input message from an original format to another format. To facilitate this, the transformation template may include one or more transformation filters. Examples of such conversion filters include("XLS") to XML filter, separator field format to XML filter, fixed length field format to XML filter, XML to XLS filter, XML to separator field format filter, XML to fixed length field filter, and the like.

A scenario template may be used by one or more tasks of a workflow to identify, evaluate, and/or verify that certain input information or results output from such tasks conform to one or more scenarios and/or one or more semantic protocols. Examples of schema and/or semantic protocols may include: XML, the financial information exchange ("FIX") protocol, a customized version of the FIX protocol, the standards issued by the global banking, financial, telecommunications, association, SCRL ("SWIFT"), the financial product markup language ("FpML") protocol, the simple object access protocol, or the service-oriented architecture protocol (collectively "SOAP"), etc.

In addition, the verification template (as described in more detail below) may include one or more expressions and/or one or more mappings that may be used by one or more tasks to evaluate the correctness and/or appropriateness of content input to those tasks. The expressions and/or mappings may be used to establish a series of rules that constitute a function for determining whether the content input to the task is valid (e.g., whether the content meets expected criteria).

The message template may be configured as a template-type template (e.g., a mail merge template) that may be used by one or more tasks to analyze the input information. The message template may include one or more entries into which the input information may be parsed. The entries may also be populated with expressions, which may be evaluated using input information (e.g., formulas). The message template may be used by one or more tasks to programmatically generate any number of records. For example, message templates may be used by tasks to generate web pages, corporate business communications, and the like.

The content record 526 may include: content input to a task, results generated by the execution of the task, one or more expressions (e.g., formulas, programs, rules, etc.) assigned by one or more tasks, task parameters, one or more variables for use with the expressions and/or task parameters, email records, and other information used, processed, and/or stored by the task.

Each email record may include: (i) a first field that may be populated with an email address assigned to or associated with a sender of an email message; (ii) a second field that may be populated with an email address assigned to or associated with the recipient of the email message; (iii) a third field that may be populated with a subject matter of the email message; (iv) a fourth field that may be populated with the body of the email message; and/or (v) information for extracting or retrieving any attachments, if any, to the email message.

The record workflow file 556 may include one or more records ("recorded workflow records") for executing a previously recorded workflow ("recorded workflow"). These recorded workflow records may include information for accessing the content records 526 to (i) obtain input information for executing the recorded workflow; and/or (ii) store any results from the execution of the recorded workflow in the content record 526.

GUI display Screen example

Fig. 6 illustrates an example of a display screen 600 of a graphical user interface. Display screen 600 is similar to display screen 124 of FIG. 5, except as described herein. For simplicity, display screen 600 is described with reference to system 500 of FIG. 5. However, other structures may be used to present the display screen 600.

The display screen 600 includes a control pane 126, a control toolbar 128, and a workflow pane 130. The controls pane 126 includes launch controls 132₁Stop control 132₂Display control 132₃Conditional statement control 132₄Analysis template control 132₅Expression control 132₆Send e-mail control 132₇Get ftp control 132₈Sending ftp control 132₉Get dB control 132₁₀Send dB control 132₁₁Http monitor control 132₁₂Http send control 132₁₃Http response control 132₁₄Get MQ control 132₁₅Sending MQ control 132₁₆Web services control 132₁₇Transformation control 132₁₈Switching control 132₁₉Semantic protocol controls 132₂₀Delete control 132₂₁Verification control 132₂₂Tcp listening control 132₂₃Tcp get control 132₂₄Tcp send control 132₂₅Wait control 132₂₆Get email control 132₂₇Copy control 132₂₈Repetitive control 132₂₉And launch workflow control 132₃₀。

These controls 132₁-132₃₀Corresponding to start, stop, display, conditional statement, parse template, expression, send email, get ftp, send ftp, get dB, send dB, http listen, http send, http respond, get MQ, send MQ, web service, transform, semantic agreement, delete, validate, tcp listen, tcp get, tcp send, wait, get email, copy, repeat, and start workflow tasks (collectively "tasks"), and with workflow operation records 116, respectively₁-116₃₀And (6) associating. Workflow operation record 116₁-116₃₀And also the corresponding task parameters.

As described above, for control 132 in graphical workflow 134₁-132₃₀The GUI software 110 may obtain the corresponding task parameters by operating the GUI with the I/O device 106 (e.g., via keyboard entry). WorkflowThe application software 338 may obtain the parameters for these tasks from the workflow record 114 sent by the GUI software 110 and may execute the workflow using these task parameters. For each control 132₁-132₃₀The following describes (i) the tasks that the workflow-application software 338 may perform if such tasks were to be included within the workflow (and the graphical workflow 134); and (ii) instances of task parameters associated with executing the workflow and providing the host 502 to execute the workflow.

Initiating instances of tasks

Such as with the launch control 132₁Shown, the start-up task serves as a starting point for executing the workflow and causes the host-application server 324 to begin executing the workflow task. Typically, a workflow includes only one starting point.

Some of the startup task parameters may be shared with other tasks and/or the entire workflow. The common startup task parameters may include a workflow name entry, a workflow description entry, a workflow author entry, a workflow version entry, and a log level entry.

The workflow name entry may include a name provided to the workflow to identify the workflow. Workflow description entries may be populated with workflow given descriptions describing a workflow such as a workflow purpose. The workflow-author entry may be populated with the name of the author that authored the workflow. The workflow version entry may be populated with an identifier (e.g., a number) that represents the version assigned to the workflow. Each of the workflow name, workflow description, workflow author, and work version entry may be represented as a character or string of characters.

The log level entries may be populated with indicators representing levels (e.g., error, alarm, or debug levels) for triggering event logging during execution of the workflow. The log level entry may be represented as one of the given set numbers.

For each of the tasks described below, the task parameters may include a corresponding name entry and description entry. In addition to that described herein, each name entry may include a name assigned to the corresponding task to identify its particular instance, and the name entry may be represented as a character, string, variable, expression, or the like.

Further, each description entry may include a description assigned to the corresponding task to describe a specific instance of the corresponding task. These description entries may be represented as characters, character strings, variables, expressions, and the like. The parameters of the other tasks are described in more detail below.

Stopping task instances

As represented by the stop control 132, the stop task serves as a termination point or end point for the workflow, causing the host-application server 324 to end the workflow. The definition of the stop task may include an end parameter. The end parameters may include a setting to indicate a normal or abnormal end of the workflow ("end setting"), and a flag to indicate whether any input information processed by the workflow is to be considered as having been fully processed by the workflow.

For example, when a workflow includes more than one alternative execution path, or task "branch" ("workflow branch"), the workflow may include more than one stop task. For example, a workflow branch may include a first and second branch. The first branch may end with a first stop task and the second branch may end with a second stop task. In this case, the GUI software 110 may configure the parameters of the first and second stop tasks by setting both the end settings of the first and second stop tasks to normal end, so that the workflow ends only the corresponding workflow branch. When so configured, the GUI software 110 may set a flag to indicate that the input information processed by the first and second branched tasks is deemed to have been fully processed.

Alternatively, the GUI software 110 may configure either or both of the first and second stop task parameters by setting the end setting to abnormal end, thereby causing the workflow to end when either the first or second stop task is executed. When so configured, the GUI software 110 may set a flag to indicate that the input information processed by the workflow is not considered to have been fully processed.

Displaying task instances

Such as with display control 132₃The display task, as shown, causes the host-application server 324 to send a message to the message record 518 for searching, and/or to the second endpoint device 506, via the host messaging engine. Messages within message record 518 may be extracted by other tasks, another workflow, user device 302, host 306, and/or second endpoint device 506, etc.

Examples of display task parameters may include message queue entries and message entries. The message queue entry may include information for accessing and/or communicating with the message record 518 and/or the second endpoint device 506 to deliver the message. This information may be, for example, a name or address assigned to message record 518 and/or second endpoint device 506 association. Alternatively, the information may be a reference, pointer, uniform resource identifier ("URI"), or other indicator for the location of the message record 518 within the memory 328, and/or for the name or address of the second endpoint device 506.

The message entry may include: (i) a first field that can be populated with message subject ("message subject") and (ii) a second field that can be populated with message body or content ("message body"). The message queue and message entries may be represented as characters, strings, expressions, templates, variables, and/or the like. In addition, the message body may also be specified using the messaging template described above.

Conditional statement task instances

Such as with conditional statement control 132₄Illustratively, the conditional statement task serves as a decision point for the host-application server 324 to execute one or more of the workflow branches as a function of the conditional statement. The parameters of the conditional statement task may include conditional expression entries.

Conditional expression entries may be populated using conditional statements. Conditional statements may be represented as logical expressions, such as if-then statements and/or boolean expressions, and one or more of the workflow branches may be specified for execution upon evaluation of the conditional statement (e.g., determination of true or false).

Analyzing template task instances

Such as with analysis template control 132₅The analyze template task, as shown, causes the host-application server 324 to select a template ("selected template") from the message templates, and to use the selected template to analyze at least a portion of its input information. To analyze the input information, the host-application server 324 may (i) populate variables within the selected template with the input information corresponding thereto; (ii) evaluating the expression specified in the selected template to form a result; and (iii) output and/or store the results in the content record 526.

The parameters of the analyze template task may include template entries. Template entries may be represented as characters, strings, expressions, templates, variables, and/or the like.

The template entries may include information for extracting or retrieving a selected template for analyzing the input information. This information may be, for example, a name assigned to or associated with the selected template. Alternatively, the information may be a reference, pointer, URI or other indicator to the location on memory 328 of the selected template stored in template record 520.

Expression task instances

As with expression control 132₆As shown, the expression tasks may cause the host-application server 324 to perform valuation of one or more expressions specified within the expression task parameters and store one or more results of the valuations within the content records 526 for subsequent extraction and/or analysis. When the expression entry includes more than one expression, the expression tasks may cause the host-application server 324 applications to execute in sequence. The order of execution may be based on entry time, entry order, mathematical hierarchy, scoreAnalytic hierarchy, arithmetic hierarchy, statistical analysis, and the like.

Examples of expression task parameters may include an expression entry and a result location entry. The expression entries may include one or more expressions (e.g., formulas). The result location entry may include information for extracting or retrieving previously stored results from the content record 526, and storing current results back to the content record 526. This information may be, for example, a name assigned to or associated with the current result within the content record 526 and/or a previously stored result stored within the content record 526. Alternatively, the information for the result location entry may be a reference, pointer, URI or other indicator to the location of: (i) content record 526, (ii) a previously stored result stored within content record 526, and/or (iii) for storing a current result within content record 526. The result location entries may be expressed as characters, strings, expressions, templates, variables, and/or the like.

Sending email task instances

Such as by sending an email control 132₇As shown, the send email task may cause the host application server 324 to create an email message (with or without an attachment) and send it to at least one recipient, such as the second endpoint device 506, via the email software 572 and/or the service email server 517. Examples of send email task parameters may include email service definition entries and email entries.

The email service definition entry may include a reference to a previously configured service definition ("email service definition") that identifies an email service that may be used to perform the send email task. The email service definition may include a plurality of parameters ("email service parameters") that may be stored on the memory 338 in the form of a service definition record 522. The email service parameters may include information for configuring the email software 572 and/or the service email server 517 to perform the task of sending emails. This information may include, for example, the URI and/or other address of the e-mail software 572 and/or the service e-mail server 517, the protocol to be used to perform the e-mail service, and so forth.

The email entry may include information for populating the email. The information may be represented as characters, groups of characters, and/or variables. Alternatively, the email entry information may be represented as an expression whose valuation determines the content of the email. In either case, the information of the email entry may include, for example, a name assigned to or associated with one or more portions of the email, which may be obtained from the email record stored within the content record 526. Alternatively, the information for the email entry may be a reference, pointer, URI or other indicator to the location of the email record that the email is stored within the content record 526.

Although the email service definition and associated email service parameters are described herein as being included within the service definition record 522, the service definition record 522 may be omitted. If omitted, the parameters of the send email task may include information similar to the email service definition and associated email service parameters used to configure the email service.

Obtaining FTP task instance

Such as by obtaining ftp control 132₈As illustrated, the get-FTP task may cause the host-application server 324 to retrieve a file ("target-FTP file") from the service-FTP server 508 via the host-FTP engine, and store the target-FTP file in the memory 328. Examples of obtaining parameters for an ftp task may include obtaining an ftp service definition entry, a target file entry, a destination location entry, and obtaining additional file entries. The get-ftp-service definition, the target file, the destination location, and the get-extra-file entry may be represented as characters, strings, expressions, templates, and/or variables, and the like.

The get-FTP-service-definition entry may include a reference to a previously configured service definition that identifies an FTP service that is available for execution of the get-FTP task. The service definition ("FTP service definition") may include a number of parameters, which may be stored on the memory 338 in the service definition record 522. These parameters ("FTP service parameters") may include information for configuring FTP software 574 and/or servicing FTP server 510 to perform the task of acquiring FTP. This information may include, for example, a name or address assigned to or associated with service FTP server 508, a setting specifying a transfer mode type (e.g., ASCII or binary), and the like.

The target-file entry may include information for retrieving or obtaining the target-FTP file from service-FTP server 508 using the FTP service. This information may include a name or address assigned to or associated with the target-ftp file. Alternatively, the information for the target file entry may be a reference, pointer, URI or other indicator to the location of the target FTP file on the service FTP memory 560.

The destination location entry may include information indicating where the target-ftp file is stored on the memory 328. This information may include, for example, a reference, pointer, URI or other indicator to the location of the file on the memory 328.

The get attached file entry may include a setting for specifying whether more than one file is to be fetched from the service FTP storage 560. Although the destination location entry and the get-extra-file entry are described herein as being included within the get-FTP-task parameters, either or both of these entries (and parameters included therein) may be included as FTP-service parameters within the FTP-service definition, rather than included within the parameters of the get-FTP task. In this case, optionally, the parameters for obtaining the FTP task may include parameters for overriding, modifying, adjusting or changing such FTP service parameters. As another alternative, instead of service definition record 522, information in or similar to the FTP service definition and related FTP service parameters may be included in the parameters of the get-FTP task.

Sending FTP task instances

Such as with send ftp control 132₉As illustrated, sending the FTP task may cause the host application server 324 to transfer a file ("source-FTP file") from the memory 328 to the service device memory 556 of the first endpoint device 504 using FTP software 574. Examples of sending ftp task parameters may include sending an ftp service definition entry, a source file entry, a destination location entry, and sending an additional file entry.

The send-FTP-service-definition entry may include a reference to a previously-configured FTP service definition that may be used to perform the send-FTP task. The FTP service definition may include a plurality of parameters, which may be stored on the memory 338 in the service definition record 522. These parameters ("FTP service parameters") may include information for configuring FTP software 574 and/or the first endpoint device 504 to perform sending FTP tasks. This information may include, for example, a name or address assigned to or associated with FTP software 574 and/or first endpoint device 504, a setting specifying the type of transmission mode (e.g., ASCII or binary) to be used, and the like.

The source file entry may include information for extracting or retrieving the source-ftp file from the memory 328. This information may include a name or address assigned to or associated with the source-ftp file. Alternatively, the information for the source file entry may be a reference, pointer, URI or other indicator to the location of the source-ftp file on the memory 328.

The destination location entry may include information for storing the source-ftp file on the serving device memory 556. This information may be, for example, a reference, pointer, URI or other indicator to the location of the service device memory 556 and/or the first endpoint device 504.

Sending additional file entries may include a setting specifying whether to transfer more than one file on the service device memory 556 of the first endpoint device 504. Sending an ftp service definition, a source file, a destination location, and sending an additional file entry may be represented as characters, strings, expressions, templates, and/or variables, and the like.

Although the destination location entry and the send-attached-file entry are described herein as being included within the parameters of sending the FTP task, either or both of these entries (and the parameters included therein) may be included as FTP-service parameters within the FTP-service definition, rather than being included in the send-FTP-task parameters. In these cases, the sending FTP task parameters may optionally include parameters for overriding, modifying, adjusting or changing such FTP service parameters. As another alternative, information within or similar to the FTP service definition and related FTP service parameters may be included in the get-FTP-task parameters instead of the service definition record 522.

Obtaining database task instances

Such as with the get dB control 132₁₀The get dB task, as shown, may cause the host-application server 324 to extract or otherwise obtain targeted data from a targeted record in the memory 558 of the service database server 508, as well as store such targeted data in the content record 526. The get dB task may be in response to the host application server 324 submitting a query (e.g., one or more SQL commands) to the service database server 508, resulting in the transmission of such targeted data.

Examples of get dB task parameters may include a get dB service definition entry, a data request entry, and a destination location entry. The get dB service definition, data request, and destination location entries may be represented as characters, strings, expressions, templates, and/or variables, and the like.

The get dB service definition entry may include a reference to a previously configured service definition ("dB service definition") that identifies a database service that may be used to perform the get dB task. The dB service definition may include a number of parameters that may be stored on the memory 338 in the service definition record 522. These parameters ("dB service parameters") may include parameters for configuration dataThe library software 576 and/or the service database server 508 to perform the information for the get dB task. This information may include, for example: a name or address assigned to, or associated with, database software 576 and/or service database server 508; one or more settings for specifying at least one database management system ("DBMS") for querying service database Server 508, such as Oracle, DB2, Microsoft Access, Microsoft SQL Server, Postgres, MySQL, 4^thAny one of Dimension, FileMaker and Alpha Five DBMS; and so on.

The information for the dB-service parameters may also include a name, address, and a reference, pointer, URI or other indicator to the location of the source record within the memory 558 of the service database server 508. The information for the dB service parameters may also include a reference to a template or scheme into which the target data may be analyzed, transformed, and/or validated prior to transmission to the content record 526.

The template or schema may define, for example, a sequence of XML elements. Examples of such units are as follows:

<row>

…

</row>

</rowset>

the above-mentioned<row>To is formed by<column1-columnn>The partition boundary, and may correspond to, for example, a row of source data stored within a source database record or a row of destination data stored within the service database server 508.<column₁-column_n>The respective plurality of placeholders is bounded. The placeholders can be analyzed using content corresponding to a respective column of the row of source data.

Although the above examples include only one<row>For, however, XML sequences may also include more than one<row>And (4) carrying out pairing. These additional<row>For one or more of<column>And dividing a boundary. In addition, the above examples also include more than one column pair, i.e.<column₁-column_n>. However, the XML sequence may also include only one column pair.

The data request entry may include information for causing the database software 576 to generate a query for execution against a source record within the memory 558 of the service database server 508 to obtain target data from a target record within the memory 558 of the service database server 508. The destination location entry may include information for storing the target data within the variable record 526. This information may include a name, address, and a reference, pointer, URI or other indicator to the location of the content record 526.

Although the destination location entry is described herein as being included within the get dB task parameter, the entry (and parameters included therein) may also be included within the dB service definition as a dB service parameter, rather than within the get dB task parameter. In this case, the get dB task parameters may optionally include parameters for overriding, modifying, adjusting or changing these dB-service parameters. As another alternative, instead of service definition record 522, information within or similar to the dB service definition and associated dB service parameters may be included within the get dB task parameters.

Sending database task instances

Such as by sending dB control 132₁₁Illustratively, the send dB task may cause the host application server 324 to perform one or more operations on the service database server 508 to insert, update, deleteExtract or modify data or schema on service database server 508. For example, the send dB task may cause the host application server 324 to transmit the source data obtained from the content record 526 to the service database server 508 via the database software 576. Alternatively, the send dB task may cause the database software 576(i) to perform a query against the content records 526 to obtain the source data; and (ii) transmit the source data to the service database server 508.

Examples of sending the dB task parameters may include sending a dB service definition entry and a database operation entry. Each of the send dB service definition and the database operation entry may be represented as a character, a string, an expression, a template, and/or a variable.

The send dB service definition entry may include a reference to a previously configured dB service definition for performing the send dB task. This information may include, for example: a name or address assigned to, or associated with, database software 576 and/or service database server 508; one or more settings for specifying at least one DBMS to interface with service database server 508; one or more settings for specifying at least one DBMS to query content records 526, and the like.

The information for the dB service parameters may also include a name, address, and a reference, pointer, URI or other indicator to a location within a destination record in memory 558 of service database server 508 for storing the source data. The information for the dB service parameters may also include a reference to a template or schema (e.g., an XML sequence) into which the source data may be parsed before being transmitted to the target record in the memory 558 of the service database server 508.

The database operation entry may include information for inserting, updating, deleting, extracting, or modifying data and/or schema of the service database server 508 (e.g., information for the database software 576 to generate a query for execution by the database software 576). Alternatively, the database operation entry may include a name, address, and reference, pointer, URI or other indicator of the location of the source data within the content record 526.

To facilitate providing the source data to the service database server 508, the send dB task may cause the host-application server 324 to analyze the source data according to semantics such as substitution semantics. For example, the send-dB task may cause the host-application server 324 to update a < row > cell of the target data within the memory 558 of the service database server 508 with the source data corresponding to that < row > cell. On the other hand, when the target data within memory 558 of service database server 508 does not include a < row > element for such source data, the send-dB task may cause host-application server 324 to insert such < row > element.

Alternatively, instead of service definition record 522, information within or similar to the dB service definition and associated dB service parameters may be included within the Send dB task parameters.

HTTP snoop task instance

E.g., listening for control 132 with http₁₂As indicated, the HTTP listen task may cause the host HTTP server 564(i) to listen for a given HTTP service request from one or more applications of the service device, such as the web browser of the second endpoint device 506; (ii) establishing communication between the host HTTP server 564 and the application of the second endpoint device 506 in response to the given HTTP service request; and (iii) causing the host-application server 324 to execute a given set of tasks ("given task group") selected from one or more sets of tasks ("queued task group") that are queued for execution.

The HTTP snoop task may also cause the host application server 324 to extract information from the given HTTP service request and/or communications between the host HTTP server 564 and the application of the second endpoint device 506 (collectively "HTTP connection details"). The HTTP snoop task may use HTTP connection details to select a given task group from the queued task groups and execute the given task group.

Examples of http snoop task parameters may include an http snoop service definition entry and a destination location entry. The http listening service definition entry and the destination location entry may be represented as characters, strings, expressions, templates, variables, and/or the like.

The HTTP snoop service definition entry may include a reference to a previously configured service definition ("HTTP service definition") that identifies services available to perform the HTTP snoop task. The HTTP service definition may include a plurality of parameters that may be stored on the memory 338 within the service definition record 522. These parameters ("HTTP service parameters") may include information specifying the internet protocol ("IP") address and port of the host HTTP server 564 for listening for requests. This information may include, for example, a URI associated with the domain serving HTTP server 514. The URI may be complete or partial. The URI may be prepended with the IP and/or name of the service HTTP server 514 assigned by a domain name server ("DNS"). The information for the HTTP service definition may also include (i) one or more IP addresses associated with the service HTTP server 514; and (ii) information specifying the application and/or service device that the http listening task is listening to.

The destination location entry may include information for storing the HTTP connection details within the content record 526. This information may include, for example, a name, address, and a reference, pointer, URI or other indicator to the location of the content record 516.

HTTP Send task instance

Such as sending control 132 by http₁₃Note that the HTTP send task may cause the host application server 324 to (i) send a given HTTP request to the service HTTP server 514; (ii) establish communication between the host HTTP server 564 and the service HTTP server 514; (iii) receive HTTP responses from the service HTTP server 514; and (iv) store content associated with the HTTP response in the content record 526. Examples of the http send task parameter may include an http send service definition entry and an http send operation entry. http sending service definition and http sending operation itemEach of which may be represented as characters, character strings, expressions, templates, variables, and/or the like.

The HTTP send service definition entry may include a reference to a previously configured HTTP service definition. The HTTP service definition may include a plurality of HTTP service parameters, which may be stored on the memory 338 within the service definition record 522. Alternatively, instead of the service definition record 522, information in or similar to the HTTP service definition and related parameters ("HTTP service parameters") may be included in the HTTP send task parameters. The HTTP service parameters may include information specifying an IP address and/or port of the service HTTP server 514 configured to receive a given host HTTP request.

The HTTP send operation entry may include (i) a URL associated with the domain (full or partial) of the service HTTP server 514, which may be prefixed with the IP and/or name of the service HTTP server 514 assigned by the DNS; (ii) information indicating a transmission method such as HTTP GET, POST, and/or PUT to the service HTTP server 514; (iii) information used to extract and/or retrieve source data (e.g., variables, expressions, and/or templates) from the content records 526 for generating a given HTTP request; (iv) information for storing content associated with communications in the message channel for subsequent extraction; and (v) information for storing content associated with the HTTP response within content record 526.

Although the HTTP send operation entry is described herein as being included within the HTTP send task parameters, the entry (and parameters included therein) may also be included as HTTP service parameters within the HTTP service definition rather than within the HTTP send task parameters. In these cases, the HTTP send task parameters may optionally include parameters for overriding, modifying, adjusting, or changing such HTTP service parameters. As another alternative, information within or similar to the HTTP service definition and related HTTP service parameters may be included in the HTTP send task parameters instead of the service definition record 522.

HTTP response task instance

Such as by http response control 132₁₄As indicated, the HTTP response task may cause the host HTTP server 564 to issue a given host HTTP response to a given service HTTP request issued from one or more applications of the service device, such as the web browser of the second endpoint device 506. This may include having the host HTTP server 564(i) obtain content from the content records 526 for inclusion within a given host HTTP reply; and (ii) send the content to the service HTTP server 514. The content included within a given host HTTP response may be selected from information stored in the content records 526, or alternatively, from information constructed from information such as expression functions, templates, and the like.

Examples of http response task parameters may include an http connection definition entry and a source file entry. Each of the http connection definition and the source file entry may be represented as a character, a string, an expression, a template, and/or a variable.

The HTTP connection definition entry may include a reference to HTTP connection details stored on the memory 338 within the content record 526. As described above, the HTTP connection details may include information specifying the IP address and port of the web browser of the second endpoint device 506 to receive a given host HTTP reply.

The source file entry may include information for obtaining content from the content record 526. This information may include a name or address assigned to or associated with the content within the content record 526. Alternatively, the information may include a reference, pointer, URI or other indicator to the location of the content within the content record 526.

Obtaining message queue task instances

Such as by obtaining the MQ control 132₁₅Illustratively, the get MQ task may cause the host application server 324 to extract and transfer a message ("target message") from the remote message queue 512 to the content memory through the messaging software 570And recording 526. Obtaining instances of the MQ task parameters may include obtaining an MQ service definition entry, a target message entry, and a destination location entry. The get MA service definition entry, the target message entry, and the destination location entry may be represented as characters, strings, expressions, templates, variables, and/or the like.

The get MQ service definition entry may include a reference to a previously configured service definition that identifies a message queue service available to execute the get MQ task. The service definition ("MQ service definition") may include a number of parameters that may be stored on the memory 338 within the service definition record 522. These parameters ("MQ service parameters") may include information for configuring the messaging software 570 and/or the remote message store 512 to perform the retrieve MQ task. This information may include, for example, a URI associated with a domain of the remote message store 512; and/or one or more IP addresses associated with remote message store 512.

The target message entry may include information for distinguishing the target message from other messages within remote message store 512. This information may include, for example, terms for searching and monitoring for target messages within remote message store 512.

The destination location entry may include information for storing the targeted message within the content record 526. This information may include, for example, a name, address, and a reference, pointer, URI or other indicator to the location of the content record 526.

Although the destination location entry is described herein as being included within the get MQ task parameters, the entry (and parameters included therein) may also be included as MQ service parameters within the MQ service definition rather than within the get dB task parameters. In this case, optionally, the get MQ task parameters may include parameters for overriding, modifying, adjusting, or changing such MQ service parameters.

As another alternative, instead of the service definition record 522, information within, or similar to, the MQ service definition and the related MQ service parameters may be included within the get MQ task parameters.

Send message queue task instances

Such as with the send MQ control 132₁₆Illustratively, the send MQ task may cause the host application server 324 to retrieve content from the content records 526; populating one or more source messages with content obtained from the content records 526; and transmits the source message to remote message queue 512 via messaging software 570. The content obtained from the content records 526 may be selected from information stored within the content records 526, or alternatively from information constructed from information that is a function of expressions, templates, and the like.

Examples of sending MQ task parameters may include sending MQ service definition entries and message entries. The sending MQ service definition entries and message entries may be represented as characters, strings, expressions, templates, and/or variables, among others.

The sending MQ service definition entry may include a reference to a previously configured MQ service definition that may be used to perform the sending MQ task. The MQ service definition may include a plurality of MQ service parameters, which may be stored on the memory 338 within the service definition record 522. These MQ service parameters may include information for configuring the messaging software 570 and/or the remote message queue 512 to perform the task of sending MQs. This information may include, for example, a URI associated with the domain of the remote message queue 512, or alternatively, one or more IP addresses associated with the remote message queue 512.

The MQ service parameters may also include information for obtaining content from the content records 526. The information may include a name or address assigned to the information stored within the content record 526 or associated with the information stored within the content record 526. Alternatively, the information may include a reference, pointer, URI or other indicator to the location of the information within the content record 526. Additionally, the MQ service parameters may also include terms and/or instructions for constructing content from information stored within the content records 526.

The message entry may include (i) a first field that may be populated with a message subject and (ii) a second field that may be populated with a message body. The message entry may also include other fields.

Although the MQ service definitions and associated MQ service parameters are described herein as being included within the service definition record 522, the MQ service definitions and parameters included herein may be omitted. If omitted, the send MQ task parameters may include information for configuring the MQ services.

Web service task instances

Such as with web service control 132₁₇Illustratively, the web service task may cause the host-application server 324 to (i) obtain content from the variable record 526; and (ii) transmit the content to trigger execution of the web service on the remote web server 516. The web service task may also cause the host-application server 324 to store any results returned from the web service within one of the content records 526. The content obtained from the content records 526 may be selected from information stored within the content records 526 or constructed from information of functions such as expressions, templates, and the like.

Examples of web service task parameters may include web service definition entries and content entries. Web service definition entries and content entries may be represented as characters, strings, expressions, templates, variables, and/or the like.

The web service definition entry may include a reference to a previously configured service definition that identifies a service for performing the web service task. The service definition ("web service definition") may include a number of parameters that may be stored on the memory 338 within the service definition record 522. These parameters ("web service parameters") may include information for configuring the host application server 324 and/or the remote web server 516 to perform web service tasks. The configuration information may include, for example, information such as IP addresses, parameters, data types, key value pairs, image locations, etc. used to transfer input information between the host application server 324 and other devices, such as the web server 516.

The web service parameters may also include information for selecting a web service from a set of web services provided by remote web server 516; and/or information specifying a web service execution method. The web service parameters may further include information for storing the results, if any, within the content record 526. Such information may include a name, address, and a reference to a location in the content record 526, a pointer, a URI, or other indicator.

The content item may include information for retrieving content from the content record 526. This information may include a name or address assigned to or associated with the content within the content record 526. Alternatively, the information may include a reference, pointer, URI or other indicator to the location of the content within the content record 526.

Although the web service definition and associated web service parameters are described herein as being included within service definition record 522, the web service definition and parameters included therein may be omitted. If omitted, the web service task parameters may include information for configuring the web service.

Transforming task instances

Such as with transformation control 132₁₈As shown, the transformation task may cause the host-application server 324 to (i) retrieve content from the content records 526; (ii) applying the transformation to the content to generate a result; and (iii) transmit the results to the content record 526. Examples of transformation task parameters may include a transformation entry, a content entry, and a destination location entry. The transformations, content, and destination location entries may be represented as characters, strings, expressions, templates, variables, and/or the like.

The transformation entries may include information for extracting or otherwise obtaining transformations for transforming the content (e.g., rearranging and/or changing structure) from the content records 526. The information may include a reference to the transformation. The reference may point to one of a plurality of transforms stored within the content record 526. The content entry may include information for obtaining content from the content record 526. This information may include a name or address assigned to or associated with the content within the content record 526. Alternatively, the information may include a reference, pointer, URI or other indicator to the location of the content within the content record 526.

The destination location entry may include information for storing the result within the content record 526. This information may include a name, address, and a reference, pointer, URI, or other indicator to a location within the content record 526.

Transforming task instances

Such as with transition control 132₁₉As shown, the conversion task may cause the host-application server 324 to (i) obtain content from the content records 526; (ii) selecting a transformation template from template records 520 (the "selected transformation template"); (iii) applying the selected transformation template to the content to transform the content; and (v) storing the results obtained thereby within the content record 526. Examples of the conversion task parameters may include a conversion template entry, a content entry, and a destination location entry. The conversion template entry, content entry, and destination location entry may be represented as characters, character strings, expressions, templates, variables, and/or the like.

The translation template entry may include a reference to the selected translation template. The reference may point to any one of the translation templates stored within template record 520. The content item may include information for obtaining content from the content record 526. This information may include a name and/or address assigned to or associated with the content within the content record 526. Alternatively, the information may include a reference, pointer, URI or other indicator to the location of the content within the content record 526.

Semantic protocol task instances

Such as semantic protocol controls 132₂₀It is shown that a semantic protocol task comprises an input and at least two outputs, each of which can be connected to a different branch of a workflow. In operation, in response to receiving or retrieving content ("input content") that matches or conforms to a given schema template, the semantic protocol task may cause the host-application server 324 to perform one or more workflow branches.

To facilitate this, the semantic protocol task may cause the host-application server 324 to (i) select a project template ("selected project template") from the template record 520; (ii) comparing the input content to some or all of the solutions in the selected solution template to determine if the input content matches or conforms to the solutions; and (iii) one or more outputs that support or initiate semantic protocol tasks that are consistent with the determination of a match between the input content and the schema.

The parameters of the semantic agreement task may include a reference to the selected verification template. The reference may include a name, address, and reference, pointer, URI or other indicator that verifies the location of the template within the template record 520.

Deleting task instances

Such as with a delete control 132₂₁As indicated, the delete task may cause the host-application server 324 to delete or mark in order to delete one or more records and/or files stored on the memory 328. The delete task parameter may include a reference to a record or file to be deleted or marked for deletion. The reference may include a name and/or address of the record and/or file, and/or a pointer, URI, or other indicator of the location of the record and/or file on memory. The reference may be represented as a character, a string, an expression, and/or a variable, etc.

Validating task instances

Such as with verification control 132₂₂Of indication, experimentThe validation task may cause the host-application server 324 to verify that the structure (e.g., logical structure) of the record obtained from the content record 526 ("evaluation record") conforms to a verification template specified within the validation task. Alternatively and/or additionally, the validation task may cause the host-application server 324 to validate that the content within the evaluation record conforms to a set of rules specified within the validation task parameters. The authentication tasks may also cause the host-application server 324 to perform one or more tasks as a function of the authentication output. For example, if the verification result indicates a successful verification, the host-application server 324 may perform one or more tasks, whereas if the verification result indicates a failed verification, the host-application server 324 may issue an error message indicating the failed verification.

Examples of authentication task parameters include an authentication entry, a content entry, and a destination location entry. The verification, content, and destination location entries may be represented as characters, strings, expressions, templates, variables, and/or the like.

The validation entry may include information for extracting or obtaining the validation template and/or validation rules from the template record 520. This may include, for example, a name and/or address associated with the validation template and/or validation rule. Alternatively, the information may include a reference, pointer, URI or other indicator to the location of the verification template and/or verification rule within the template record 520. The verification entry may also include information specifying one or more tasks to be performed in response to the verification result (e.g., success or failure).

The content item may include information for extracting or obtaining the evaluation record and the content therein from the content record 526. This information may include a name and/or address assigned to or associated with the evaluation record within the content record 526. Alternatively, the information may include a reference, pointer, URI or other indicator to the location of the evaluation record within the content record 526.

The destination location entry may include information for storing results generated in response to performing the validation task. This information may include a reference, pointer, URI or other indicator to a name, address, and/or location within the content record 526.

TCP snoop, TCP get, and TCP send task instances

In addition to the detailed applications for performing the differences between TCP and HTTP communication protocols (e.g., TCP typically does not have URL parameters), such as through TCP snooping, TCP get, and TCP send controls 132₂₃-132₂₅It is shown that the TCP listen, TCP get and TCP send tasks are similar to the HTTP listen, HTTP response and HTTP send tasks described above. These details are known and are not described here for the sake of simplicity.

Waiting for task instance

Such as with wait control 132₂₆The waiting task, as shown, causes the host-application server 324 to pause execution of the workflow and/or one or more workflow branches for a given amount of time. The wait task parameter may include an entry specifying an amount of time to suspend execution. The parameters may be represented as characters, strings, variables, and/or expressions, etc.

Obtaining an email task instance

Such as with the get email control 132₂₇As shown, the retrieve email task may cause the host-application server 324 to retrieve or retrieve an email message (with or without an attachment) from the service email server 518 through a host email engine and send the email message to an email record for subsequent retrieval. An example of sending an email task parameter may include obtaining an email service definition entry. The get email service definition entry may be represented as a character, a string of characters, and/or a variable.

The get email service definition entry may include a reference to a previously configured service definition that identifies the email service for performing the get email task. The service definition ("get email service definition") may include a number of parameters stored on the memory 338 within the service definition record 522. Alternatively, information within, or similar to, the get email service definition and related parameters ("get email service parameters") may be included in the get email job parameters instead of the service definition record 522.

Obtaining email service parameters may include settings that identify the service email server 518. The settings may be, for example, the domain and/or service type of the service email server 517, such as POP, IMAP, and other email service types. Obtaining email service parameters may also include information for storing email messages and/or email attachments within the content record 526. This information may include a reference, pointer, URI or other indicator to a name, address, and/or location within the content record 526.

Although the email service definition and associated email service parameters are described herein as being included within the service definition record 522, the email service definition and parameters included therein may be omitted. If omitted, the get email task parameters may include information for configuring the email service.

Replicating instances of tasks

Such as with copy control 132₂₈As shown, the replication task may cause the host-application server 324 to assign values to the expressions to generate results and to communicate the results to one or more result records within the content records 526. The replication task may also cause the host application server 324 to create a result record; and/or overwrite any result records within content records 526.

Examples of replication task parameters may include expression entries and location destination entries. The expression definition may include an expression (e.g., a formula).

The location destination entry may include information for storing the results within one or more result records. The information may include a name or address assigned to or associated with the result record. Alternatively, the information for the location destination entry may include a reference, pointer, URI or other indicator to the location within the content record 526.

Repeating task instances

Such as with a repeat control 132₂₉Illustratively, repeating a task may cause the host-application server 324 to repeat the task a specified number of times ("repeat task") using a set of content obtained from the content records 526. Alternatively, the repeat task may cause the host-application server 324 to repeat the repeat task over the entire set of content obtained from the content records 526. This repeat task may, for example, cause the host-application server 324 to repeat the task of sending e-mail, thereby establishing and sending e-mail to the e-mail addresses of multiple recipients contained within the set of content (e.g., mailing list) obtained from the content records 526. This repetition may be performed a specified number of times or may be performed repeatedly as long as there remains content in the set of content obtained from the content record 526.

Examples of repeat task parameters may include collection entries and repeat-marker entries. The collection entries and repeat-marker entries may be represented as characters, strings, expressions, templates, and/or variables.

The collection entry includes information for extracting or otherwise obtaining the set of content input to the repetitive task from the content records 526. The information may include a name and/or address assigned to, or associated with, the set of content in the content record 526. Alternatively, the information may include a reference, pointer, URI or other indicator to the location of the set of content in the content record 526.

The duplicate tag entry may include information defining a tag indicating that the duplicate task is complete (e.g., there is no more unprocessed content in the set of content).

Initiating workflow task instances

Such as with workflow control 132₃₀The represented startup workflow task may be uniform to the host applicationThe server 324(i) selects a recorded workflow from the recorded workflow records 528; and (ii) triggering execution of the recorded workflow. To trigger the execution, initiating the workflow task may cause the host-application server 324 to obtain input information from the content record 526 for executing the recorded workflow. In addition, initiating a workflow task may cause the host-application server 324 to execute the recorded workflow in a synchronous or asynchronous mode.

In the synchronous mode, the initiating workflow task may cause the host-application server 324 to execute and complete the recorded workflow before executing the workflow or another task in the workflow branch containing the initiating workflow task. After executing the recorded workflow, initiating the workflow task may cause the host-application server 324 to store the execution results of the recorded workflow as input information for another task within the content record 526.

In asynchronous mode, the initiating workflow task may cause the host-application server 324 to execute the recorded workflow and continue executing other tasks within the workflow or workflow branch containing the initiating workflow task without waiting for the recorded workflow to complete. Initiating a workflow task may not cause the host-application server 324 to obtain input information for another task.

Examples of the startup workflow task definition may include a recorded workflow definition, a recorded workflow input definition, a startup workflow mode, and a return information definition. The recorded workflow and return information definitions may be represented as characters, strings, expressions, templates, variables, and/or the like.

The recorded workflow definition may include information for extracting or retrieving the recorded workflow from the recorded workflow record. This information may include a name or address assigned to or associated with the recorded workflow file 556 or, alternatively, a pointer to the location of the recorded workflow file 556 on the memory 328.

The recorded workflow-input definition may include input information for extracting or obtaining input for the recorded workflow input from the content record 526. This information may include a name or address assigned to or associated with the content record 526 or, alternatively, a pointer to the location of the content record 526 on the memory 328.

The startup workflow pattern definition may include information for specifying a synchronous or asynchronous pattern. The return information definition may include information used to obtain results from the content records 526. This information may include a name or address assigned to or associated with the content record 526 or, alternatively, a pointer to the location of the content record 526 on the memory 328.

Conclusion

Variations of the above-described apparatus and method are possible without departing from the scope of the invention. For example, in the above examples, controllers and other devices comprising processors are described. These devices may include at least one central processing unit ("CPU") and memory. Reference to acts and symbolic representations of operations or instructions may be implemented by various CPUs and memories according to the practices of those skilled in the art of computer programming. Such acts and operations or instructions may be referred to as being "executed," computer-executed, "or" CPU-executed.

Those of ordinary skill in the art will recognize that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. The electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signal and hold the data bits in memory locations within the memory system, thereby reconfiguring or changing the operation of the CPU and other signal processing. The storage locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the example embodiments are not limited to the above-described platform or CPU and other platforms and CPUs that may support the above-described methods.

The data bits may be maintained on a computer readable medium, including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read-only memory ("ROM")) mass storage system that is readable by a computer. The computer readable medium may include cooperating or interconnected computer readable media that exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It will be appreciated that these examples are not limited to the above memory and that other platforms and memories may support the described method.

In view of the wide variety of embodiments that can be employed, it should be understood that the illustrated examples are exemplary only, and should not limit the scope of the claims. Furthermore, the claims should not be read as limited to the described order or elements unless stated to that effect. Furthermore, the use of the term "device" in any claim shall apply to clause 112, clause 6 of the U.S. patent Law, and any claim not containing the term "device" shall not be applied thereto.

Claims

1. A method for generating, scheduling and/or executing a workflow, comprising:

forming a record for generating a workflow from information related to a graphical representation of the workflow;

sending the record to facilitate execution of the workflow, wherein the workflow comprises a plurality of tasks; each task defines a corresponding automation behavior, i.e. task function, for operating on at least one task parameter defined via at least one template input and outputting the input information to the task; and

issuing instructions from a graphical user interface to cause execution of the workflow,

wherein the record contains task and sequence parameters specifying an order in which the tasks are executed, the record being arranged as an instance of an object of one or more given classes.

2. The method of claim 1, further comprising: instructions are issued to generate executable instructions for executing the workflow.

3. The method of claim 2, wherein the executable instructions are generated remotely from a graphical user interface and in accordance with the record for generating the workflow.

4. The method of claim 2, wherein the issuing of the instruction to execute the workflow and the issuing of the instruction to generate the executable instruction to execute the workflow are both the same instruction.

5. The method of claim 1, further comprising: elements of the graphical user interface are operated to cause the graphical user interface to issue instructions to cause execution of the workflow.

6. The method of claim 1, further comprising: an instruction to send the record is issued from the graphical user interface.

7. The method of claim 6, further comprising: the elements of the graphical user interface are operated to cause the graphical user interface to issue an instruction for sending the record.

8. The method of claim 1, further comprising: an instruction to send the record is received from a device external to the graphical user interface.

9. The method of claim 1, further comprising: the graphical representation is formed by a graphical user interface.

10. The method of claim 9, wherein the graphical representation comprises first and second graphical elements, wherein the first and second graphical elements represent first and second tasks of the workflow, respectively.

11. The method of claim 9, wherein the graphical representation includes first and second graphical elements, wherein the first and second graphical elements represent first and second tasks of the workflow, respectively, the method further comprising: and acquiring a first task parameter and a second task parameter in a function form of the first task and the second task to form the record.

12. The method of claim 9, wherein the graphical representation comprises first and second graphical elements ordered together by a third graphical element, wherein the first and second graphical elements represent first and second tasks of the workflow, respectively, wherein the third graphical element represents an ordering of the first and second tasks.

13. The method of claim 9, wherein the graphical representation includes first and second graphical elements that are ordered together by a third graphical element, wherein the first and second graphical elements represent first and second tasks of the workflow, respectively, and wherein the third graphical element represents an ordering of the first and second tasks, the method further comprising: and acquiring a first task parameter and a second task parameter in the form of a function of the first task and the second task and the sequence of the first task and the second task to form the record.

14. A method for generating, scheduling and/or executing a workflow, comprising:

obtaining a record that facilitates execution of a workflow, the record comprised of information related to a graphical representation of the workflow; and

executing the workflow in response to instructions for executing the workflow, wherein the workflow comprises a plurality of tasks; each task defining a respective automation behavior, i.e. task function, for operating on at least one task parameter defined via at least one template input and outputting the input information to the task, the instructions being issued from a graphical user interface,

15. The method of claim 14, wherein executing the workflow comprises interpreting the record.

16. The method of claim 14, further comprising: instructions to execute the workflow are obtained from a graphical user interface.

17. The method of claim 14, further comprising: generating the workflow as a function of the record.

18. The method of claim 17, further comprising: instructions for generating a workflow are obtained from a graphical user interface.

19. The method of claim 18, wherein the instruction to execute the workflow and the instruction to generate the workflow are the same instruction.

20. The method of claim 17, wherein generating the workflow comprises: executable instructions are generated for executing the workflow.

21. The method of claim 20, wherein executing the workflow in response to instructions to execute the workflow comprises: the executable instructions are executed.

22. The method of claim 20, wherein executing the workflow in response to instructions to execute the workflow comprises: the executable instructions are executed under conditions to test the workflow.

23. The method of claim 22, further comprising receiving another instruction to execute the workflow, wherein executing the workflow in response to the instruction to schedule the workflow further comprises: the executable instructions are not executed under conditions of the test workflow.

24. A method for generating, scheduling and/or executing a workflow, comprising:

forming, on a graphical user interface, a record for facilitating execution of a workflow based on information related to a graphical representation of the workflow;

sending, from the graphical user interface, a record for facilitating execution of the workflow, wherein the workflow comprises a plurality of tasks; each task defines a corresponding automation behavior, i.e. task function, for operating on at least one task parameter defined via at least one template input and outputting the input information to the task;

issuing instructions from the graphical user interface for executing the workflow;

at a server, obtaining the record for facilitating execution of the workflow; and

executing the workflow in response to the instruction to execute the workflow,

25. The method of claim 24, further comprising: generating a workflow as a function of the record.

26. The method of claim 25, further comprising: instructions for generating a workflow are retrieved from a graphical user interface.

27. The method of claim 25, wherein the instruction to execute the workflow and the instruction to generate the workflow are the same instruction.

28. The method of claim 25, wherein generating the workflow comprises: executable instructions are generated for executing the workflow.

29. The method of claim 28, wherein executing the workflow in response to instructions to execute the workflow comprises: the executable instructions are executed.

30. The method of claim 28, wherein executing the workflow in response to instructions to execute the workflow comprises: executing the executable instructions under conditions of a test workflow.

31. The method of claim 30, wherein the instructions to execute the workflow comprise first and second instructions, wherein the second instruction is issued after the first instruction, the method further comprising: in response to the second instruction, the executable instruction is not executed under conditions to test the workflow.