Patent Application
20070156487
Typically all software employed in enterprises today support business processes. Some of such processes are entirely automated, relying solely on communication among applications, while others rely on people to initiate the process, approve documents the process uses, resolve any exceptional situations that arise, and more. In either case, it is common to specify a discrete series of steps known as a workflow that describes the activities of the people and software involved in the process. Once such workflow has been defined, an application can be built around that definition to support the business process.
Put differently, workflow generally is the flow of information and control in such organizations. Businesses continually strive to define, document, and streamline such processes in order to effectively compete. In a business setting, these processes include sales and order processing, purchasing tasks, inventory control and management, manufacturing and production control, shipping and receiving, accounts payable, and the like.
Computer systems and associated software now provide tools with which businesses and other organizations can improve their workflow. Software tools can be used to model business workflow processes or schedules and identify inefficiencies and possible improvements. In addition, where a process involves exchanging data between people, departments, plants, or even between separate companies, computer systems and networks can be used to implement such exchanges. These systems and software tools are further able to implement large-scale computations and other data or information processing that are typically associated with business related information.
Accordingly, workflow management includes the effective management of information flow and control in an organization's business processes, wherein automation of such information processing has led to many efficiency improvements in the modem business world. Moreover, such automation of workflow management is now allowing businesses and other organizations to further improve performance by executing workflow transactions in computer systems, including global computer networks, such as the Internet.
A typical workflow-based application often requires a plurality of conditions to be satisfied. For example, one such condition is the ability to make decisions based on business rules. This can include simple rules, (e.g., like as a yes-or-no decision based on the result of a credit check), and more complex rules, (e.g., the potentially large set that must be evaluated to make an initial underwriting decision.) Another requirement is communication with other software and other systems outside the workflow. For example, an initial request can be received from one part of the application, while some aspects, (e.g., contacting a credit service) can require communication using other web services or technologies. A further condition to be satisfied is the proper interaction of the workflow with users. For example, the workflow should typically be able to display a user interface itself or interact with human beings through other software. Moreover, another condition that needs to be satisfied is the ability to maintain state throughout the workflow's lifetime. Accordingly, creating and executing a workflow in software poses unique challenges.
For example, some business processes can take hours, days, or weeks to complete, and maintaining information about the workflow's current state for such length of time is demanding. Moreover, such kind of long-running workflow will also typically communicate with other software in a non-blocking way, and an asynchronous communication can pose difficulties. At the same time, while modeling fixed interactions among software is relatively straightforward, consumers tend to continuously require additional flexibility, such as the ability to change a business process on-the-fly. Handling diverse applications can further add to the complexities involved in workflow creation and management.
Many applications for workflow tools are internal to a business or organization. With the advent of networked computers having modems or other type communications links, computer systems at remote locations can now communicate easily with one another. Such enhanced communication allows computer system workflow applications to be used between remote facilities within a company. An example would include forwarding a customer order from a corporate headquarters to a remote field sales office for verification by the appropriate sales person, and returning a verification to the headquarters. Workflow applications also can be of particular utility in processing business transactions between different companies. In a typical application, two companies having a buyer-seller relationship may desire to automate the generation and processing of purchase orders, product shipments, billing, and collections.
For example, an application targeting a specific problem, such as customer relationship management (CRM), or a specific vertical market, such as financial services, can be built around a workflow. Such kind of application commonly implements a number of different business processes. Building the logic that drives those processes on a common workflow foundation such as Windows Workflow Foundation can make the application faster to build, quicker to change, and easier to customize. Moreover automating such processes can result in significant efficiency improvements, which are not otherwise possible. However, such inter-company application of workflow technology requires co-operation of the companies and proper interfacing and proper persistence service implementation of the individual company's existing computer systems and applications.
Thus far, workflow application tools have been developed which provide some capability for automating business workflow by defining workflow schedules. Nonetheless, the ability to further establish a higher degree of isomorphism between objects found in the problem space (the enterprise/process domain) and those employed in the solution (the actual workflow model/definition) is burdensome, and nonetheless is considered an important requirement to a high quality software.
Therefore, there is a need to overcome the aforementioned exemplary deficiencies associated with conventional systems and devices.
The following presents a simplified summary in order to provide a basic understanding of some aspects of the claimed subject matter. This summary is not an extensive overview. It is not intended to identify key/critical elements or to delineate the scope of the claimed subject matter. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
The subject innovation provides for systems and methods that objectify view of workflows and management behavior via an access component (e.g., GetWorkflow<workflow> method) that provides a host access to the workflow instance, wherein custom features can be defined for interaction during run time. Such custom features (e.g., strongly typed workflow) can include, a property(ies), a method(s), an event(s), an interface and the like. Moreover, the subject innovation provides for a workflow instance that is being created from a workflow definition, and is typically not a proxy, facade, or wrapper around the actual workflow instance object. Thus, the actual workflow instance can be accessed directly. Accordingly, the workflow can be exposed as an object type or class, wherein new members can be added and the workflow extended. Such provides flexibility and enables a user to interact with custom properties.
In a related aspect, custom methods and properties can be called during data exchange between a host and the workflow instance. The host can interact with the workflow instance to associate a custom behavior with the workflow class. For example, the host can subscribe to custom events for accessing such workflow instance, and manipulate the workflow as an object. Enriched types for the workflow can be defined programmatically and/or through a visual tool.
According to a methodology of the subject innovation, a new workflow definition that has custom properties, custom methods, custom events, and the like can be defined from a base workflow definition. Moreover, the host application can request a workflow instance from a workflow provider thru an identification associated with the workflow instance. Such identification uniquely identifies the instance of the workflow and can be generated programmatically or assigned/accessed by the host application. The workflow provider can generate/return an instance of the workflow, and the user can interact with such instance by calling class members such as properties, methods, events and the like. Subsequently, and upon completion of such interaction the workflow instance can be saved.
To the accomplishment of the foregoing and related ends, certain illustrative aspects of the claimed subject matter are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways in which the subject matter may be practiced, all of which are intended to be within the scope of the claimed subject matter. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.
The various aspects of the subject invention are now described with reference to the annexed drawings, wherein like numerals refer to like or corresponding elements throughout. It should be understood, however, that the drawings and detailed description relating thereto are not intended to limit the claimed subject matter to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the claimed subject matter.
As used herein, the terms “component,” “system”, “service” and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on computer and the computer can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.
The term “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs.
Furthermore, the disclosed subject matter may be implemented as a system, method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer or processor based device to implement aspects detailed herein. The term computer program as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. For example, computer readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips . . . ), optical disks (e.g., compact disk (CD), digital versatile disk (DVD) . . . ), smart cards, and flash memory devices (e.g., card, stick). Additionally it should be appreciated that a carrier wave can be employed to carry computer-readable electronic data such as those used in transmitting and receiving electronic mail or in accessing a network such as the Internet or a local area network (LAN). Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.
Turning initially to
The host 110 interacts with the workflow system 130, via an access component 120 that provides access to the workflow instance, wherein custom features can be defined for interaction during run time. Such custom features (e.g., strongly typed workflow) can include, a method(s), an event(s), a property (ies), an interface and the like. Accordingly, the workflow can be exposed as an object type or class, wherein new members can be added and the workflow extended. Such provides flexibility and enables a user to interact with custom properties.
Moreover, thru such access component 120, the host 110 can exchange data with a workflow instance of the workflow system 130, as described in detail infra. The host 110 can be responsible for a number of additional and critical aspects, such as the creation of one or more workflows, marshaling of calls between various components as needed for proper execution of the workflow; and setup of isolation mechanisms. In addition, the host 110 can create multiple processes to take advantage of multiple CPUs in a machine for scalability reasons, or to run a large number of workflow instances on a farm of machines. The host 110 can further control the policies to apply when a workflow is subject to a long wait, listen for specific events and communicate them to a user or administrator, set timeouts and retries for each workflow, expose performance counters, and write log information for debugging and diagnostic purposes.
A workflow associated with the workflow system 130 can communicate with the outside world through a service established specifically for that purpose, wherein such service can raise events that event-driven activities inside the workflow will hook up. Likewise, the service exposes public methods for the workflow to call and send data to the host 110. The Workflow can be defined in the form of a schedule for execution in a computer system. A schedule can include a set of actions having a specified concurrency, dependency, and transaction attributes associated therewith. Each schedule has an associated schedule state, which includes a definition of the schedule, the current location within the schedule, as well as active or live data and objects associated with the schedule. Within a schedule, transaction boundaries may exist based on groupings of actions. In this regard, a transaction may encompass individual actions, or transactions, or groups thereof. As discussed further hereinafter, actions may be grouped into sequences, which are executed in serial fashion, as well as tasks in which the actions are executed concurrently. Based on the groupings, therefore, concurrency attributes may be resolved for the actions and transactions within a schedule.
As illustrated in
The following provides an exemplary definition for the access component 120, wherein the method GetWorkflow<WorkflowType> supplies an access to the running workflow definition and its custom properties, methods and events (e.g., when the workflow is idled). Such usage of a generics based mechanism for the (<WorkflowType>) can typically facilitate obtaining a strongly typed workflow definition in a type-safe manner.
Referring now to
For example, the framework can define a core set of activity base classes, as well as few specific activities. Such can include: StartActivity, and StopActivity (representing starting and stopping points in a workflow); CodeActivity (allowing the workflow developer to implement the functionality associated with the activity in an event handler within the workflow type); ControlFlowActivity (allowing workflow developers to introduce branching logic into the workflow based on conditions and rules); SuspendableActivity (allowing workflow developers to model a suspension in the execution of the workflow, either in terms of time, or by switching the current user, e.g., DelayActivity and SwitchUserActivity); InteractiveActivity (allowing workflow developers to model a user interaction point, where an action from the end-user determines when and how the execution within a workflow proceeds) such InteractiveActivity can be treated as a type of SuspendableActivity that suspends the execution until a valid action is performed); CompositeActivity (allowing the workflow developer to group activities together); LoopActivity (being an example of a CompositeActivity that repeats the execution of its contained activities); IMultiActionActivity: (an interface being implemented by activities that support multiple actions, and require one of those actions to be selected before execution can proceed and the InteractiveActivity can implements such interface); IMultiResultActivity (an interface being implemented by activities that generate one of a set of possible results during their execution) and ControlFlowActivity implements this interface; ISuspendableActivity (an interface being implemented by activities that can suspend execution of the workflow for a set of specific wait conditions.)
The workflow can start execution by executing the contained StartActivity, and end when the StopActivity is executed. During the course of executing, each activity can be checked to verify if it can be executed. If the activity cannot continue to execute because it is waiting for some information from the host (e.g., messages, timers, and the like) the workflow is suspended, for example. If an activity can be executed, an associated Execute method is invoked, and if the method returns a success result, the appropriate activity transition is used to determine the next activity. Moreover, workflows can be suspended for a number of reasons during their lifetime, such as: canceling of an activity execution, inability for an activity to continue execution because it is waiting for some information such as messages, timers, and the like from the host, a specific delay introduced to postpone subsequent execution, and switching of user context requiring subsequent execution to be carried out by a different user. Once suspended, the workflow instance can be serialized into a database or equivalent storage, from which it can be subsequently retrieved, deserialized, and resumed. A workflow can also enter an error state, if an activity execution results in an error, which is not handled.
Otherwise, the methodology proceeds to act 440 wherein the workflow provider can generate an instance of the workflow. The host application can then interact with such instance at 450, by calling class members such as properties, methods, events and the like at 460. Upon completion of such interaction, the workflow process can be saved, as described in detail infra.
The workflow provider 510 can create/retrieve an instance of the workflow, and the host application can interact with such instance by calling class members such as properties, methods, events and the like. As such, Based on the workflow instance identification (e.g., ID number), the workflow instance can then be accessed (e.g., via the host application). The host can interact with the workflow instance through its custom behavior associated with the workflow type/class. For example, the host can subscribe to custom events for accessing such workflow instance, to manipulate the workflow as an object. Enriched types for the workflow definition can be defined programmatically and/or through a visual tool.
Similarly, and as illustrated in
The workflow provider can create/retrieve an instance of the workflow, and the developer can interact with such instance by calling class members such as properties, methods, events and the like.
In order to provide a context for the various aspects of the disclosed subject matter,
With reference to
The system bus 918 can be any of several types of bus structure(s) including the memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, 11-bit bus, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), and Small Computer Systems Interface (SCSI).
The system memory 916 includes volatile memory 920 and nonvolatile memory 922. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 912, such as during start-up, is stored in nonvolatile memory 922. By way of illustration, and not limitation, nonvolatile memory 922 can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory 920 includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM).
Computer 912 also includes removable/non-removable, volatile/non-volatile computer storage media.
It is to be appreciated that
A user enters commands or information into the computer 912 through input device(s) 936. Input devices 936 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit 914 through the system bus 918 via interface port(s) 938. Interface port(s) 938 include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) 940 use some of the same type of ports as input device(s) 936. Thus, for example, a USB port may be used to provide input to computer 912, and to output information from computer 912 to an output device 940. Output adapter 942 is provided to illustrate that there are some output devices 940 like monitors, speakers, and printers, among other output devices 940 that require special adapters. The output adapters 942 include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device 940 and the system bus 918. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s) 944.
Computer 912 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 944. The remote computer(s) 944 can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer 912. For purposes of brevity, only a memory storage device 946 is illustrated with remote computer(s) 944. Remote computer(s) 944 is logically connected to computer 912 through a network interface 948 and then physically connected via communication connection 950. Network interface 948 encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).
Communication connection(s) 950 refers to the hardware/software employed to connect the network interface 948 to the bus 918. While communication connection 950 is shown for illustrative clarity inside computer 912, it can also be external to computer 912. The hardware/software necessary for connection to the network interface 948 includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.
What has been described above includes various exemplary aspects. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing these aspects, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the aspects described herein are intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.
