U.S. patent application number 14/461948 was filed with the patent office on 2014-12-18 for long term workflow management.
The applicant listed for this patent is Microsoft Corporation. Invention is credited to Marc Mercuri.
Application Number | 20140372324 14/461948 |
Document ID | / |
Family ID | 46020559 |
Filed Date | 2014-12-18 |
United States Patent
Application |
20140372324 |
Kind Code |
A1 |
Mercuri; Marc |
December 18, 2014 |
LONG TERM WORKFLOW MANAGEMENT
Abstract
A workflow may be moved from one provider to another provider by
extracting the metadata from an executing workflow describing the
workflow state as part of dehydrating the workflow, and
transferring the metadata to a second workflow and rehydrating the
workflow at a second provider. An automated workflow manager may
determine when to move the workflow and may facilitate moving with
or without human intervention. When a workflow is moved from one
provider to another, the workflow state may be moved without
transferring executable code that executes the workflow.
Inventors: |
Mercuri; Marc; (Bothell,
WA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Microsoft Corporation |
Redmond |
UT |
US |
|
|
Family ID: |
46020559 |
Appl. No.: |
14/461948 |
Filed: |
August 18, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12941086 |
Nov 8, 2010 |
8812403 |
|
|
14461948 |
|
|
|
|
Current U.S.
Class: |
705/301 |
Current CPC
Class: |
G06Q 10/103
20130101 |
Class at
Publication: |
705/301 |
International
Class: |
G06Q 10/10 20060101
G06Q010/10 |
Claims
1. A method performed on a computer processor, the method
comprising: determining that a first representation of a workflow
running on a first workflow provider is to be transferred from the
first workflow provider to a second workflow provider; in response
to the transfer determination: transferring a first portion of
workflow state from said first workflow provider to the second
workflow provider, the first portion of workflow state for use by
the second workflow provider to configure a second representation
of the workflow to accept new work items; issuing a stop command to
the first workflow provider, the stop command placing the first
representation of the workflow in a transfer state for transferring
the workflow, the transfer state permitting the first
representation of the workflow to continue in parallel with the
second representation of the workflow, the first representation of
the workflow and the second representation of the workflow
continuing in parallel to complete the handling of in-process work
items to a state where transfer can be performed, the in-process
work items being work items received prior to issuance of the stop
command; after issuance of the stop command, transferring a second
portion of workflow state to the second workflow provider, the
second portion of workflow state including the in-process items;
and causing said second workflow provider to execute the second
representation of said workflow with the first and second portions
of workflow state at the second workflow provider.
2. The method of claim 1, further comprising prior to determining
that the first representation of the workflow is to be transferred:
identifying the first representation of the workflow, the first
representation of the workflow being an automated succession of a
first set of work steps, which when performed on work items,
produces a workflow result, the work items being provided by a work
requester; and identifying a second representation of the workflow
available at the second workflow provider, the second
representation of the workflow having a second set of work steps,
which when performed on the work items also produces the workflow
result, at least one work step in the second set of work steps
differing from at least one work step in the first set of work
steps.
3. The method of claim 2, wherein at least one other work step in
the second set of work steps is the same as at least one other work
step in the first set of work steps.
4. The method of claim 2, wherein transferring a first portion of
workflow state from the first workflow provider to the second
workflow provider comprises transferring parameters from the first
workflow provider, the parameters defining how the first
representation of the workflow behaves.
5. The method of claim 4, further comprising matching the
parameters to the second representation of the workflow by
transforming the parameters so as to compensate for the at least
one differing work step between the first set of work steps and the
second set of work steps.
6. The method of claim 2, further comprising: querying the first
workflow provider to identify state information about the first
representation of the workflow; and receiving the first portion of
workflow state from the first workflow provider.
7. The method of claim 6, further comprising subsequent to issuing
the stop command: receiving a second part of workflow state from
the first workflow provider, the second part of workflow state
including the in-process items, the second part of workflow state
received after the issuance of the stop command; and sending the
second part of workflow state to the second workflow provider.
8. The method of claim 1, further comprising causing new work items
to be directed to the second representation of the workflow for
processing after the first portion of workflow state is transferred
to the second workflow provider.
9. The method of claim 1, wherein causing the second workflow
provider to execute the second representation of the workflow
comprises sending a portion of executable code to the second
workflow provider, the portion of executable code for implementing
a customized workflow component within the second representation of
the second representation of the workflow, the customized workflow
component having also been implemented in the first representation
of the workflow.
10. A computer program product for use at a computer system, the
computer program product for implementing a method for transferring
a workflow, the computer program product comprising one or more
storage devices having stored thereon computer-executable
instructions that, when executed by a processor, cause the computer
system to perform the method, including the following: determine
that a first representation of a workflow running on a first
workflow provider is to be transferred from the first workflow
provider to a second workflow provider; in response to the transfer
determination: transfer a first portion of workflow state from said
first workflow provider to the second workflow provider, the first
portion of workflow state for use by the second workflow provider
to configure a second representation of the workflow to accept new
work items; issue a stop command to the first workflow provider,
the stop command placing the first representation of the workflow
in a transfer state for transferring the workflow, the transfer
state permitting the first representation of the workflow to
continue in parallel with the second representation of the
workflow, the first representation of the workflow and the second
representation of the workflow continuing in parallel to complete
the handling of in-process work items to a state where transfer can
be performed, the in-process work items being work items received
prior to issuance of the stop command; after issuance of the stop
command, transfer a second portion of workflow state to the second
workflow provider, the second portion of workflow state including
the in-process items; and cause said second workflow provider to
execute the second representation of said workflow with the first
and second portions of workflow state at the second workflow
provider.
11. The computer program product of claim 10, further comprising
computer-executable instructions that, when executed, cause the
computer system to: identify the first representation of the
workflow, the first representation of the workflow being an
automated succession of a first set of work steps, which when
performed on work items, produces a workflow result, the work items
being provided by a work requester; and identifying a second
representation of the workflow available at the second workflow
provider, the second representation of the workflow having a second
set of work steps, which when performed on the work items also
produces the workflow result, at least one work step in the second
set of work steps differing from at least one work step in the
first set of work steps, at least one other work step in the second
set of work steps being the same as at least one other work step in
the first set of work steps.
12. The computer program product of claim 11, wherein
computer-executable instructions that, when executed, cause the
computer system to transfer a first portion of workflow state from
the first workflow provider to the second workflow provider
comprise computer-executable instructions that, when executed,
cause the computer system to transfer parameters from the first
workflow provider, the parameters defining how the first
representation of the workflow behaves.
13. The computer program product of claim 11, further comprising
computer-executable instructions that, when executed, cause the
computer system to match the parameters to the second
representation of the workflow by transforming the parameters so as
to compensate for the at least one differing work step between the
first set of work steps and the second set of work steps.
14. The computer program product of claim 11, further comprising
computer-executable instructions that, when executed, cause the
computer system to: query the first workflow provider to identify
state information about the first representation of the workflow;
and receive the first portion of workflow state from the first
workflow provider.
15. The computer program product of claim 14, further comprising
computer-executable instructions that, when executed, cause the
computer system to subsequent to issuing the stop command: receive
a second part of workflow state from the first workflow provider,
the second part of workflow state including the in-process items,
the second part of workflow state received after the issuance of
the stop command; and send the second part of workflow state to the
second workflow provider.
16. The computer program product of claim 11, further comprising
computer-executable instructions that, when executed, cause the
computer system to cause new work items to be directed to the
second representation of the workflow for processing after the
first portion of workflow state is transferred to the second
workflow provider.
17. The method of claim 11, wherein computer-executable
instructions that, when executed, cause the computer system to
cause the second workflow provider to execute the second
representation of the workflow comprise computer-executable
instructions that, when executed, cause the computer system to send
a portion of executable code to the second workflow provider, the
portion of executable code for implementing a customized workflow
component within the second representation of the second
representation of the workflow, the customized workflow component
having also been implemented in the first representation of the
workflow.
18. A computer system, the computer system comprising: one or more
processors; system memory; one or more storage devices having
stored thereon computer-executable instructions representing a
workflow manager, the workflow manager configured to: determine
that a first representation of a workflow running on a first
workflow provider is to be transferred from the first workflow
provider to a second workflow provider; in response to the transfer
determination: transfer a first portion of workflow state from said
first workflow provider to the second workflow provider, the first
portion of workflow state for use by the second workflow provider
to configure a second representation of the workflow to accept new
work items; issue a stop command to the first workflow provider,
the stop command placing the first representation of the workflow
in a transfer state for transferring the workflow, the transfer
state permitting the first representation of the workflow to
continue in parallel with the second representation of the
workflow, the first representation of the workflow and the second
representation of the workflow continuing in parallel to complete
the handling of in-process work items to a state where transfer can
be performed, the in-process work items being work items received
prior to issuance of the stop command; after issuance of the stop
command, transfer a second portion of workflow state to the second
workflow provider, the second portion of workflow state including
the in-process items; and cause said second workflow provider to
execute the second representation of said workflow with the first
and second portions of workflow state at the second workflow
provider.
19. The computer system of claim of claim 18, wherein the workflow
manager is further configured to: identify the first representation
of the workflow, the first representation of the workflow being an
automated succession of a first set of work steps, which when
performed on work items, produces a workflow result, the work items
being provided by a work requester; and identifying a second
representation of the workflow available at the second workflow
provider, the second representation of the workflow having a second
set of work steps, which when performed on the work items also
produces the workflow result, at least one work step in the second
set of work steps differing from at least one work step in the
first set of work steps, at least one other work step in the second
set of work steps being the same as at least one other work step in
the first set of work steps.
20. The computer system of claim 19, wherein the workflow manager
being configured to transfer a first portion of workflow state from
the first workflow provider to the second workflow provider
comprises the workflow manager being configured to transfer
parameters from the first workflow provider, the parameters
defining how the first representation of the workflow behaves.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of and claims the benefit
of and priority to U.S. patent application Ser. No. 12/941,086,
entitled "Long Term Workflow Management", filed Nov. 8, 2010 by
Marc Mercuri, the entire contents of which are expressly
incorporated by reference.
BACKGROUND
[0002] Long running workflows and services may execute for many
minutes, days, months, or even years. An example of a long running
workflow may be an online agent that constantly searches for
products or information that meet certain criteria, or an expense
report system that processes a company's expense reports. Over
time, the workflows may experience hardware availability, change of
ownership of a service provider, or other events.
SUMMARY
[0003] A workflow may be moved from one provider to another
provider by extracting the metadata from an executing workflow
describing the workflow state as part of dehydrating the workflow,
and transferring the metadata to a second workflow and rehydrating
the workflow at a second provider. An automated workflow manager
may determine when to move the workflow and may facilitate moving
with or without human intervention. When a workflow is moved from
one provider to another, the workflow state may be moved without
transferring executable code that executes the workflow.
[0004] This Summary is provided to introduce a selection of
concepts in a simplified form that are further described below in
the Detailed Description. This Summary is not intended to identify
key features or essential features of the claimed subject matter,
nor is it intended to be used to limit the scope of the claimed
subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] In the drawings,
[0006] FIG. 1 is a diagram illustration of an embodiment showing a
system with a workflow manager.
[0007] FIG. 2 is a timeline illustration of an embodiment showing a
method for transferring a workflow from one workflow provider to
another.
[0008] FIG. 3 is a timeline illustration of an embodiment showing a
two stage method for transferring a workflow from one workflow
provider to another.
DETAILED DESCRIPTION
[0009] A workflow may be moved from one workflow provider to a
second workflow provider by transferring the workflow state between
the providers. The workflow state may be transferred so that the
second workflow provider may resume the workflow without losing
work items being processed by the workflow.
[0010] A workflow may be a sequence of work steps that may be
executed by a computer system and may operate on work items. The
sequence of work steps may or may not be exactly the same between
the two workflow providers, and the workflow providers may or may
not share the same executable code.
[0011] A workflow may include steps that operate automatically and
steps that include human interaction. For example, a workflow that
processes travel expense reports may include a work step that
involves a human to review and approve certain expenses in certain
conditions.
[0012] The workflow may be a long running workflow that may operate
for months or even years. By having the ability to move the
workflow from one provider to another, an administrator may have
the flexibility to change providers to achieve lower costs or
better service, or to change providers in the event that a current
provider goes out of business or for some other reason. The
workflow may be moved without losing the workflow state, so that
work may not be lost or compromised when transferring to another
provider.
[0013] Throughout this specification and claims, the term
"workflow" is used to designate a service performed by a workflow
provider that may contain one or more work steps. The service may
be a workflow application, which may be a software application
which automates, at least to some degree, a process or processes.
The processes may be any process that can be defined in a series of
steps that may be automated using software. In many embodiments, a
workflow may be business-related. Some steps of the process may
require human intervention, such as an approval or the addition of
specific information, but functions that can be automated may
generally be handled by the workflow application.
[0014] As an example of a workflow, a purchase order may move
through various departments for authorization and eventual
purchase. The order may be automatically moved from department to
department for approval by human members of a department. In some
cases, a department may perform an automated analysis to approve or
disapprove the purchase order. When all authorizations are
obtained, the requester of the purchase order may be notified and
given authorization to make the purchase. A workflow process may
involve change and update. For example, the normal approver of
purchase orders may be on vacation, in which case, the application
may request approval from alternate approvers.
[0015] Throughout this specification, like reference numbers
signify the same elements throughout the description of the
figures.
[0016] When elements are referred to as being "connected" or
"coupled," the elements can be directly connected or coupled
together or one or more intervening elements may also be present.
In contrast, when elements are referred to as being "directly
connected" or "directly coupled," there are no intervening elements
present.
[0017] The subject matter may be embodied as devices, systems,
methods, and/or computer program products. Accordingly, some or all
of the subject matter may be embodied in hardware and/or in
software (including firmware, resident software, micro-code, state
machines, gate arrays, etc.) Furthermore, the subject matter may
take the form of a computer program product on a computer-usable or
computer-readable storage medium having computer-usable or
computer-readable program code embodied in the medium for use by or
in connection with an instruction execution system. In the context
of this document, a computer-usable or computer-readable medium may
be any medium that can contain, store, communicate, propagate, or
transport the program for use by or in connection with the
instruction execution system, apparatus, or device.
[0018] The computer-usable or computer-readable medium may be for
example, but not limited to, an electronic, magnetic, optical,
electromagnetic, infrared, or semiconductor system, apparatus,
device, or propagation medium. By way of example, and not
limitation, computer-readable media may comprise computer storage
media and communication media.
[0019] Computer storage media includes volatile and nonvolatile,
removable and non-removable media implemented in any method or
technology for storage of information such as computer-readable
instructions, data structures, program modules, or other data.
Computer storage media includes, but is not limited to, RAM, ROM,
EEPROM, flash memory or other memory technology, CD-ROM, digital
versatile disks (DVD) or other optical storage, magnetic cassettes,
magnetic tape, magnetic disk storage or other magnetic storage
devices, or any other medium which can be used to store the desired
information and may be accessed by an instruction execution system.
Note that the computer-usable or computer-readable medium can be
paper or other suitable medium upon which the program is printed,
as the program can be electronically captured via, for instance,
optical scanning of the paper or other suitable medium, then
compiled, interpreted, of otherwise processed in a suitable manner,
if necessary, and then stored in a computer memory.
[0020] Communication media typically embodies computer-readable
instructions, data structures, program modules or other data in a
modulated data signal such as a carrier wave or other transport
mechanism and includes any information delivery media. The term
"modulated data signal" can be defined as a signal that has one or
more of its characteristics set or changed in such a manner as to
encode information in the signal. By way of example, and not
limitation, communication media includes wired media such as a
wired network or direct-wired connection, and wireless media such
as acoustic, RF, infrared and other wireless media. Combinations of
any of the above-mentioned should also be included within the scope
of computer-readable media.
[0021] When the subject matter is embodied in the general context
of computer-executable instructions, the embodiment may comprise
program modules, executed by one or more systems, computers, or
other devices. Generally, program modules include routines,
programs, objects, components, data structures, and the like, that
perform particular tasks or implement particular abstract data
types. Typically, the functionality of the program modules may be
combined or distributed as desired in various embodiments.
[0022] FIG. 1 is a diagram of an embodiment 100, showing an
environment in which a workflow manager may manage workflows
between different workflow providers by moving workflows from one
provider to another. Embodiment 100 is a simplified example of a
network environment in which multiple workflow providers may
operate.
[0023] The diagram of FIG. 1 illustrates functional components of a
system. In some cases, the component may be a hardware component, a
software component, or a combination of hardware and software. Some
of the components may be application level software, while other
components may be operating system level components. In some cases,
the connection of one component to another may be a close
connection where two or more components are operating on a single
hardware platform. In other cases, the connections may be made over
network connections spanning long distances. Each embodiment may
use different hardware, software, and interconnection architectures
to achieve the described functions.
[0024] Embodiment 100 is an example embodiment showing a device 102
and two workflow providers 130 and 132 that are connected through a
network 128. The device 102 may have a workflow manager that may be
capable of moving a workflow from one workflow provider to another.
The operations of moving a workflow from one provider to another
may be a component in an automated system for managing
workflows.
[0025] Some workflows may be long running, and may stay active and
operational for days, weeks, months, or even years. During such a
long time, the workflow service provider may go out of business, be
acquired, raise their rates, change their service level agreements,
change the geography in which a workflow is run and/or stored,
suffer performance problems, or have other issues that may cause a
workflow owner or user to desire to have the workflow transferred
to another provider.
[0026] In some instances, a workflow may be moved from one provider
to another with changes to the rate structures, which may vary with
the time of day or current workflow. In such instances, an
automated workflow manager may monitor the current costs of a
workflow provider and compare the costs to another workflow
provider, and may move the workflow between providers to achieve a
best cost. In some such embodiments, an automated workflow manager
may transfer a workflow between several workflow providers multiple
times per day.
[0027] A workflow manager may transfer a workflow between providers
by transferring the workflow state from one provider to another.
The workflow state may define the items in process as well as any
items in queue for processing, along with the results of any
processed items. The workflow state may also include customizations
or specialized settings that may be applied to the workflow to
adapt the workflow for a particular user.
[0028] In some cases, the representation of a workflow on one
workflow provider may not be exactly the same as the workflow
available on a second provider. In such cases, the state from one
workflow may be transformed, translated, converted, or otherwise
processed so that the state may match the state on a destination
workflow provider. In some such embodiments, a schema may be
defined for each workflow and a translator or converter may convert
the state from one workflow provider to be compatible with another
workflow provider.
[0029] In general, a workflow may be transferred from one workflow
provider without having to transfer all of the executable code
associated with the workflow. In some cases, a portion of the
executable code associated with a workflow may be transferred to
another workflow provider.
[0030] When a workflow is transferred, the state of the workflow
may be transferred, and the state may be used by the workflow
provider receiving the workflow to rehydrate the workflow. Prior to
transferring the workflow, the workflow may be dehydrated by
causing the processes being performed to be halted and the state of
those processes captured.
[0031] A workflow may be executed by a workflow engine that may be
a software application that may manage and execute modeled computer
processes. The workflow engine may interpret events, such as
documents submitted to a server or due dates expiring, and may act
on the events according to defined computer processes. The events
may be considered work items processed by the workflow. The actions
may be, for example, saving a document in a document management
system or issuing new work by sending an e-mail to users or
escalating overdue work items to management. A workflow engine may
facilitate the flow of information, tasks, and events. In some
embodiments, workflow engines may also be referred to as a Workflow
Orchestration Engines.
[0032] Many workflows may be designed to process various work
items. In a document-centric workflow, a document may be a work
item that may be processed. In an event-centric workflow, an event
or group of events may be a work item. Other embodiments may have
different types of work items.
[0033] Each workflow may be defined by a series of work steps. In
many workflow languages, the steps may be distinct decision points
or operations that may be performed. In some instances, the
operations may be performed on the work item itself, or may spawn
other actions that may not affect the work item.
[0034] Workflows may be defined with various decision points and
branches. The decision points or branches may allow various options
or conditions to be assessed and the workflow may change paths
based on the decision points. In many embodiments, a decision point
may be defined in the form of an IF-THEN-ELSE statement or other
decision mechanisms may be used.
[0035] In some embodiments, workflows may be defined using
specialized workflow definition languages, such as XPDL, BPEL,
BPMN, ASAP, Wf-XML, Windows Workflow Foundation, and others. In
some embodiments, the workflows may be defined in a language that
may be interpreted, while other embodiments, the workflows may be
defined in a compiled language. Some embodiments may have graphical
mechanisms for defining workflows using graphical flowcharts or
other mechanisms.
[0036] In still other embodiments, the workflows may be defined in
a manner that may not be exposed to a user. In such embodiments,
the workflow may receive requests and respond with results. The
requests may contain a work item to process and the workflow may
return some type of results. Such embodiments may operate as an
Application Programming Interface (API).
[0037] In some embodiments, a workflow may be transferred in
stages. A staged transfer of a workflow may be useful in
embodiments where work items may be in a state that may be
non-transferrable. In such embodiments, the first workflow may be
allowed to continue to process work items that are still in-process
until either the work items are completed or brought to a state
where the work items may be transferred.
[0038] In some staged transfers, a workflow may be moved by first
redirecting any new requests to the new workflow provider, then
notifying the existing workflow provider to begin a shutdown
operation. The shutdown operation may allow existing work items to
execute to completion, or may process work items to a point where
the work items may be transferred to the new workflow provider. In
some such embodiments, work items may be transferred to a new
workflow provider when the work items have not been processed to
completion.
[0039] Several examples of workflows may aid in understanding the
transfer process.
[0040] In one example, a search workflow may be defined that
searches the Internet, weblogs, scientific journals, financial and
business literature, or some other group of publications for
specific set of keywords or relating to specific subjects. The
search workflow may be configured to identify a matching
publication and transmit a summary of the publication to a user's
email. Over time, the search workflow may refine the search terms
by receiving feedback from the user for the search results. In such
an example, the search workflow may identify a publication and
transmit the publication to the user, then receive feedback from
the user as to the relevance of the publication. The work item may
be the search result and feedback response, and the state of the
workflow may be the current search terms, the most recent results,
the frequency at which to perform the search, and other items.
[0041] When such a workflow is transferred to another workflow
provider, the workflow providers may each be a specialized search
engine with separate and proprietary search algorithms. The
workload may be transferred by retrieving the workload state from
the first workflow provider, which may include the current search
terms, weighting for the search terms, scope of search, frequency
of search, email addresses for the recipients, and other
parameters. Those parameters may be transferred to the new workload
provider, which may be another search engine. The new search engine
may receive the parameters and begin performing the search.
[0042] The search engine workflow may be a simple workflow but an
example of a workflow that may be operational for many weeks,
months, or even years. For search engines that search specialized
databases, a user may pay a subscription fee. An automated workflow
manager may analyze the subscription fees between two workflow
providers and may determine that the workflow may be transferred
from one provider to another when a periodic subscription may be
due for renewal, for example.
[0043] In some embodiments, the parameters from one workflow may be
translated, converted, or otherwise modified to match parameters
used by the receiving workflow. In some cases, the parameters may
be readily translated or reformatted to match a schema defined for
the receiving workflow. In other cases, an executable process may
perform complex translations from one schema to another.
[0044] In another example, a workflow provider may provide a
workflow for managing expense reports for a business. In such an
example, employees of a company may submit expenses for business
trips to the workflow and those expenses may be analyzed by the
workflow and sent to various people within the business for
approval. In the workflow, certain types of expenses may be
approved by different managers and certain employees may be granted
higher or lower limits on the types of approved expenses. Within
the workflow, the expenses may be analyzed to determine which
managers are authorized to approve the expenses and the workflow
may route the expenses to the appropriate manager for approval. The
workflow may detect that a manager may be unavailable and may route
the expenses to an alternate manager. When the expenses are
approved, the workflow may pay the expenses by transferring money
from various accounts and paying the employee.
[0045] In such an example, the work items for the workflow may be
individual expense reports. The workflow may manage communication
between the various approval managers and maintain a database of
in-process expense reports, as well as financial accounts for
different types of expenses and various rules that may be
periodically updated that define which managers are authorized to
approve which expenses.
[0046] An automated workflow manager may transfer such a workflow
to another provider when there may be a cost advantage to change
providers, or when a new provider may have an improved workflow
that has additional features not available in a current workflow,
among other conditions.
[0047] In transferring such a workflow, an automated workflow
manager may configure the new workflow provider by requesting a
workflow state from the existing workflow provider. The workflow
state may be transferred in two parts. In the first part, the
workflow state may include parameters defining how the first
workflow behaves and input from actors engaged in the
workflow--both human and software or machine driven. In the
example, the first part may include email addresses of the various
managers, their approval limits and conditions, and whether they
have opted to approve or reject the expenses on the report. The
first set of workflow state may be transferred to the new workflow
provider and used to configure the new workflow provider to accept
new work items.
[0048] Once the new workflow provider has been configured, the new
workflow provider may begin receiving new work items. At such a
point, the automated workflow manager may stop sending new work
items to the current workflow and may begin directing new work
items to the new workflow.
[0049] The automated workflow manager may issue a stop command to
the existing workflow provider to place the workflow in a state for
transferring the workflow. In the example, the current workflow may
have some expenses that are out for approval by certain managers
but where the approval has not been received from the manager. The
approvals may be, for example, an email message that the manager
may approve or disapprove and return to the workflow.
[0050] In such a situation, the approvals that are out for approval
may not be in a state for transfer. After receiving a command to
stop processing, the current workflow may wait for any items out
for approval to be returned and may further process the returns to
a point where the work items may be transferrable. Meanwhile, the
second workflow provider may begin processing new work items. In
the example, the approval process may allow the approval managers
several days to approve or disapprove certain expenses. Some
expenses may be automatically approved when the expenses are below
a certain dollar amount, while other expenses over a certain dollar
amount may only be approved or disapproved after the approving
manager takes affirmative action to approve or deny. In such cases,
the expenses may be in process for an extended period of time.
[0051] If the workflow was moved while an expense was in the
approval cycle, an approval manager may receive one set of expenses
from the first workflow and then another request to approve or deny
the same expenses from the second workflow. Such a situation may be
confusing to the manager, who may approve the first set of expenses
and deny the second. In order to avoid the confusion, the items in
the approval process may be permitted to continue the workflow
until the work items are in a state for transfer.
[0052] Once the in-process work items have been processed to a
state where transfer may be performed, a second part of the
workflow state may be transferred to the new workflow provider. The
second part may include items that were in-process when the initial
transfer may have been performed.
[0053] In the example, the expense report workflows from each
provider may have different steps and may provide different
features. In such an embodiment, the executable code performed by
the two workflow providers may be different, and the workflow state
may be the only information transferred between the workflow
providers.
[0054] In some embodiments, some executable code may be transferred
between the workflow providers. In such embodiments, a script or
customized workflow component may be transferred between workflow
providers when a workflow may be moved. For example, two different
workflow providers may have generic expense report processing
workflows. When establishing and configuring the workflow, a
business may include a script or other executable that customizes a
portion of the workflow to the specific business process. When that
workflow may be moved to another workflow provider, the customized
executable may also be transferred to the new workflow
provider.
[0055] In many embodiments, the workflow providers may include
audit logs and may have various authorization procedures for
transferring workflows. Many workflows may be sensitive business
processes on which a business may rely for the operation of the
business, and where stopping a business workflow may have serious
financial consequences to the business. In such embodiments, an
automated workflow manager may have authorization credentials that
may be used to authenticate requests to change the workflows,
including starting, stopping, and reconfiguring the workflow. The
authorization credentials may be used to establish relationships
with new workflow providers and to authorized moving workflows
between providers.
[0056] The workflow providers may maintain and provide audit logs
that record changes to the workflows. When a workflow provider may
receive authorization to stop operation, for example, the audit log
may record the authorization. For business sensitive workflows,
such an audit log may be used in the event of a lawsuit to verify
that there was proper authorization to halt the business sensitive
workflow, for example.
[0057] The device 102 is illustrated as having an automated
workflow manager. The device 102 is illustrated having hardware
components 104 and software components 106. The device 102 as
illustrated represents a conventional computing device, although
other embodiments may have different configurations, architectures,
or components.
[0058] The device 102 may be a server computer, desktop computer,
or comparable device. In some embodiments, the device 102 may be a
laptop computer, netbook computer, tablet or slate computer,
wireless handset, cellular telephone, or any other type of
computing device.
[0059] The hardware components 104 may include a processor 108,
random access memory 110, and nonvolatile storage 112. The hardware
components 104 may also include a user interface 114 and network
interface 116. The processor 108 may be made up of several
processors or processor cores in some embodiments. The random
access memory 110 may be memory that may be readily accessible to
and addressable by the processor 108. The nonvolatile storage 112
may be storage that persists after the device 102 is shut down. The
nonvolatile storage 112 may be any type of storage device,
including hard disk, solid state memory devices, magnetic tape,
optical storage, or other type of storage. The nonvolatile storage
112 may be read only or read/write capable.
[0060] The user interface 114 may be any type of hardware capable
of displaying output and receiving input from a user. In many
cases, the output display may be a graphical display monitor,
although output devices may include lights and other visual output,
audio output, kinetic actuator output, as well as other output
devices. Conventional input devices may include keyboards and
pointing devices such as a mouse, stylus, trackball, or other
pointing device. Other input devices may include various sensors,
including biometric input devices, audio and video input devices,
and other sensors.
[0061] The network interface 116 may be any type of connection to
another computer. In many embodiments, the network interface 116
may be a wired Ethernet connection. Other embodiments may include
wired or wireless connections over various communication
protocols.
[0062] The software components 106 may include an operating system
118 on which various applications and services may operate. An
operating system may provide an abstraction layer between executing
routines and the hardware platform 104, and may include various
routines and functions that communicate directly with various
hardware components.
[0063] A workflow manager 120 may be an application executing
within the operating system 118. The workflow manager 120 may
coordinate the transfer of workflows from one workflow provider to
another, as well as perform other management tasks. In some
embodiments, the workflow manager 120 may have a user interface
through which an administrator may configure an existing workflow,
observe performance statistics of a workflow, and perform other
management tasks.
[0064] In some embodiments, the workflow manager 120 may perform
workflow transfers based on a human authorization. In such
embodiments, an administrator may manually cause a workflow to be
transferred, and the administrator may perform some of the tasks
related to transferring the workflow, including establishing an
account or authorization with a new workflow provider.
[0065] In many embodiments, the workflow manager 120 may be capable
of automatically determining when to change workflow providers and
to automatically cause a workflow to be transferred.
[0066] The workflow manager 120 may have a set of policies 122
which may be used to determine when to change workflow providers.
The policies 122 may define conditions for when to evaluate
different workflow providers and for when to move a workflow from
one workflow provider to another.
[0067] The workflow manager 120 may be capable of evaluating
different workflow providers. For example, the workflow manager 120
may be capable of contacting one, two, or many different workflow
providers to request various criteria that may be used to determine
whether or not a workflow may be moved and to which workflow
provider the move may occur. For example, the workflow manager 120
may be capable of requesting cost, performance, or other
information from two or more workflow providers and comparing that
information with a current workflow provider. Based on the criteria
defined in the policies 122, the workflow manager 120 may select a
new workflow provider and cause a workflow to be moved to the new
provider.
[0068] In some cases, the device 102 may include a converter 124
that may convert the state from one workflow to a state compatible
with a new provider. The converter 124 may use a schema 126 to
define how the conversion may take place. The schema 126 may
include schemas for both the current and new workflows and may
determine a mapping between the two schemas. In some embodiments,
only one schema may be provided and the converter 124 may perform a
conversion. Some converters 124 may not use a schema 126 to perform
a conversion.
[0069] The workflow manager 120 may have a set of credentials 123
that may be used to authenticate against different workflow
providers. The credentials 123 may be used when performing changes
to the workflows, including authorizing workflows to start, stop,
and be transferred.
[0070] In many embodiments, accounts may be set up with different
workflow providers. An administrator may establish an account,
which may include authentication credentials, method of payment,
and other information. After setting up the account with various
workflow providers, the workflow manager 120 may evaluate whether
or not to move a workflow to one of the workflow providers and may
cause the workflow to be moved with or without human
intervention.
[0071] In some cases, the workflow manager 120 may evaluate
different workflow providers and identify a potential provider that
may have additional features, operate at a lower cost, offer better
performance, or otherwise meet the criteria in the policies 122 for
transferring the workflow. After the potential workflow provider
may be identified, an administrator may establish an account with
the new workflow provider, receive credentials for operating with
the new workflow provider, and the workflow manager 120 may
transfer the workflow.
[0072] The workflow providers 130 and 132 may be accessible over a
network 128. In many cases, the network 128 may be the Internet,
and the network 128 may include various local area networks, wide
area networks, or other types of networks.
[0073] The workflow provider 130 may have a hardware platform 134
on which a workflow engine 136 may execute a first workflow 138.
The hardware platform 134 may be a single hardware platform, such
as a server computer. In some embodiments, the hardware platform
134 may be a cloud computing hardware platform, virtual machine, or
other type of computing platform.
[0074] The workflow engine 136 may execute the workflow 138 using
any type of workflow definition. In some embodiments, the workflow
may be defined using various languages specific to workflows. In
other embodiments, the workflow may be defined using custom
designed computer code that may execute a workflow. Such
embodiments may or may not have a separate workflow engine 136.
[0075] The workflow engine 136 may include an authentication system
137 which may authenticate an administrator or a workflow manager
120 when receiving various commands that may change the operation
of the workflow 138. In many embodiments, the workflow 138 may be a
business-sensitive operation that may result in substantial
financial loss if the workflow were halted or changed. In some
embodiments, the authentication system 137 may be used to verify
the identity of an agent who may make changes to the workflow.
[0076] In many embodiments, the workflow provider 130 may include a
converter 144 and schema 146. The converter 144 and schema 146 may
be used to translate incoming or outgoing workflow states into or
out of formats that may be compatible with the workflow engine
136.
[0077] Similar to workflow provider 130, workflow provider 132 may
have a hardware platform 141, a workflow engine 140 that may
execute a workflow 142, an authentication system 143, and a
converter 148 that may consume a schema 150.
[0078] FIG. 2 is a timeline illustration of an embodiment 200
showing a method for moving workflows between providers. Embodiment
200 is a simplified example of a basic method for moving workflows.
Embodiment 300, presented later in this specification, illustrates
a staged method for moving workflows between providers. Embodiment
200 illustrates the operations of a workflow manager 202 in the
left hand column, the operations of a first workflow provider 204
in the center column, and the operations of the second workflow
provider 206 in the right hand column.
[0079] Other embodiments may use different sequencing, additional
or fewer steps, and different nomenclature or terminology to
accomplish similar functions. In some embodiments, various
operations or set of operations may be performed in parallel with
other operations, either in a synchronous or asynchronous manner.
The steps selected here were chosen to illustrate some principles
of operations in a simplified form.
[0080] Embodiment 200 illustrates a simplified method for moving a
workflow from one provider to another. The workflow may be moved in
a single step by receiving the workflow state from the first
provider and transferring the workflow state to the second
provider. Once the second provider receives the workflow state, the
second provider may begin executing the workflow.
[0081] In block 208, a workflow manager 202 may establish a
workflow which may be executed by the first workflow provider 204
in block 210. In some cases, the process of establishing,
configuring, testing, and launching a workflow may be a long
process.
[0082] The normal operation of the workflow may be illustrated in
block 212. A workflow manager 202 or other entity may transmit work
items in block 214, which may be received by the first provider 202
in block 216. The work items may be processed in block 218 and
results may be returned in block 220, which may be received by the
workflow manager 202 or other entity in block 222. In some
embodiments, a work item may be transmitted to the workflow and
processed. In other embodiments, a work item may be created by the
workflow based on some condition or event.
[0083] In block 224, the workflow manager 202 may determine that
the workflow may be moved to another workflow provider. In some
embodiments, the workflow manager 202 may determine such a
condition exists automatically, while in other embodiments, a human
administrator may determine the condition. In some embodiments, the
workflow manager 202 may determine that the condition exists, but
no action may be taken until a human administrator approves the
change.
[0084] In block 226, the workflow manager 202 may send a request to
the first workflow provider 204 for the workflow state. The request
may be received in block 228 by the first workflow provider 204.
The workflow may be paused in block 230 and the workflow state may
be stored in block 232. The workflow state may be transmitted in
block 234 and received by the workflow manager 202 in block
236.
[0085] The existing workflow may be paused or stopped in block 230.
In some embodiments, in-process work items may be executed until a
stopping point may be reached. In other embodiments, the workflow
may be capable of transferring the workflow state at any time.
[0086] The first workflow provider 204 may create an audit trail in
block 238. The audit trail of block 238 may include information
relating to the request to change the workflow operation. In the
case of embodiment 200, the change may be to stop the workflow. The
audit trail of block 238 may be used to reconstruct the
authorization and sequence of commands that may have led to the
workflow being shut down.
[0087] Once the workflow state is received in block 236 by the
workflow manager 202, the workflow manager 202 may establish a
workflow in block 240 with a second workflow provider 206, which
may prepare the workflow in block 242. After the workflow is
prepared, the workflow manager 202 may transmit the workflow state
in block 244, which the second provider 206 may receive in block
246 and begin executing the workflow in block 248. Because the
second workflow provider 206 uses the existing workflow state to
begin executing the workflow, the workflow may resume operations
from where the first workflow provider left off.
[0088] Embodiment 200 illustrates a method whereby the workflow
state may be transmitted to the workflow manager and then to the
second workflow provider. In some embodiments, the workflow manager
202 may instruct the first workflow provider 204 to transmit the
workflow state directly to the second workflow provider 206 without
passing the workflow state through the workflow manager 202.
[0089] FIG. 3 is a timeline illustration of an embodiment 300
showing a second method for moving workflows between providers.
Embodiment 300 illustrates a staged method for moving workflows
between providers. Embodiment 300 illustrates the operations of a
workflow manager 302 in the left hand column, the operations of a
first workflow provider 304 in the center column, and the
operations of the second workflow provider 306 in the right hand
column.
[0090] Other embodiments may use different sequencing, additional
or fewer steps, and different nomenclature or terminology to
accomplish similar functions. In some embodiments, various
operations or set of operations may be performed in parallel with
other operations, either in a synchronous or asynchronous manner.
The steps selected here were chosen to illustrate some principles
of operations in a simplified form.
[0091] Embodiment 300 illustrates a more complex method for moving
a workflow between providers than embodiment 200. Embodiment 300
includes some steps that may be used prior to a workflow transfer
to evaluate workflow providers, and also illustrates a two stage
transfer, where some in-process work items may be processed to a
transferrable state.
[0092] In block 308, the workflow manager 302 may establish a
workflow with the first workflow provider 304, which may execute
the workflow in block 310.
[0093] At some point after the workflow has begun execution, the
workflow manager 302 may request operational information in block
312 from both the first workflow provider 304 and second workflow
provider 306. The first workflow provider 304 may receive the
request in block 314 and return operational information in block
316. Similarly, the second workflow provider 306 may receive the
request in block 318 and return operational information in block
320. The operational information may be received by the workflow
manager 302 in block 322.
[0094] The operational information may include information that may
be used to determine whether or not to change workflow providers.
In various embodiments, the operational information may be cost,
performance metrics such as throughput or response time, feature
set, or other information.
[0095] The operational information may be analyzed in block 324 and
a determination may be made in block 326 to change workflow
providers. Once the determination is made in block 326, a workflow
may be established in block 328 between the workflow manager 302
and the second workflow provider 306, which may prepare the new
workflow in block 330.
[0096] In block 332, the workflow manager 302 may begin
transmitting new work items to the second workflow provider 304,
which may receive the new work items in block 334 and begin
processing the work items in block 336.
[0097] By begin transmitting new work items in block 332, two
workflows may be operating in parallel. In some embodiments, a
first set of state information may be requested from the first
workflow provider 304 and transmitted to the second workflow
provider 306 to configure the second workflow. The first set of
state information may include state parameters used by the second
workflow provider to configure the second workflow. A second set of
state information may be transmitted later that may include the
state associated with in-process work items.
[0098] In block 338, the workflow manager 302 may issue a stop
command to the first workflow provider 304, which may be received
in block 340. The first workflow provider 304 may generate an audit
entry in block 342 that may log the stop command and the
authorization used for the command.
[0099] In block 344, the first workflow provider 304 may process
in-process work items to a transferrable state. In some
embodiments, work items may be in a state that may not be
transferrable, such as a transaction that may not be completed.
Once the transactions are completed or when the work items are in a
transferrable state, the workflow state may be stored in block 346
and may be transmitted in block 348.
[0100] The workflow state may be received in block 350 by the
workflow manager 302 and may be transmitted to the second workflow
provider 306 in block 354. The second workflow provider 306 may
receive the workflow state in block 356 and may perform a
translation or conversion in block 358 to match the local schema.
The second workflow provider 306 may continue executing the
workflow with the new state in block 360.
[0101] The foregoing description of the subject matter has been
presented for purposes of illustration and description. It is not
intended to be exhaustive or to limit the subject matter to the
precise form disclosed, and other modifications and variations may
be possible in light of the above teachings. The embodiment was
chosen and described in order to best explain the principles of the
invention and its practical application to thereby enable others
skilled in the art to best utilize the invention in various
embodiments and various modifications as are suited to the
particular use contemplated. It is intended that the appended
claims be construed to include other alternative embodiments except
insofar as limited by the prior art.
* * * * *