Patent Grant
9141345
Information Technology (IT), according to the Information Technology Association of America (ITAA), refers generally to the study, design, development, implementation, support, or management of computer-based information systems, particularly software applications and computer hardware. Most organizations of more than a handful of employees include an IT department responsible for a variety of tasks, including deployment of new computer hardware and applications, maintenance of one or more networks, monitoring of servers, and so forth. IT management applications, such as MICROSOFT System Center solutions, help organizations manage their IT environments, from physical to virtual, across desktops, devices, and datacenters. These applications are designed to provide a single window into IT services to allow proactive planning, deployment, management, and optimization across IT platforms. IT management applications capture and aggregate practical knowledge about infrastructure, policies, processes, and recommended practices so IT professionals can build manageable systems and automate operations to reduce costs, improve application availability, and enhance service delivery.
A common task in an IT department is the creation of scripts and workflows that help the IT department to automate some of its functions. For example, IT personnel may want to automate the steps involved in deploying new desktop computers for new employees, or the steps involved in deploying new servers to a data center. Today, IT personnel use a process to create these workflows that closely resembles computer programming. IT personnel often spend an extensive amount of time learning a particular scripting language, understanding control flow constructs (e.g., if, while, and goto statements), and understanding error and exception handling.
Although a programming environment provides a powerful environment for automation, the environment often does not map well to the way people think about IT problems. Many existing tools for authoring workflows have a graphical look and feel that makes the IT personnel think using the tools will be as easy as making a flow chart. Unfortunately, the terminology and design flow take their cues from developer tools. This often leads to disappointment and frustration, which wastes time and takes the IT professional away from other productive tasks he/she could be completing.
One area that demonstrates this disconnect is how existing tools handle control blocks. A basic workflow is a sequence of steps, where each step performs some function (e.g., reboot computer, install software, and check for updates). Control Block is the term that refers to a class of workflow controls that change a normal sequential flow of a workflow. For example, an IF/ELSE control block will change the flow of a workflow depending on some condition being true or false. Other examples of control blocks include FOR EACH, DO-UNTIL, WHILE, and TRY-CATCH. The typical experience includes the author placing one of these control blocks onto a design surface and then adding a sequence of steps that the control block influences within the control block's shape. This forces the author to first think about the workflow's control and then think about the work that needs to be done. This is similar to a developer's experience while developing code. First, the developer declares a control block (a loop for example), and then (in languages such as C++, C#, JavaScript, and Java) the developer places the lines of code within curly braces. However, many workflow authors (particularly those that have not had experience developing software or scripts) think instead about the work that needs to be done and then they go back and think about the control flow.
Another example of this disconnect is how error handling is authored. Traditional authoring environments have the main workflow and error handling workflows in different, disconnected views. The author views either the main workflow or the error workflow. While this is fine for a developer who develops using text, for an IT professional authoring a workflow visually, this is very difficult. Often what goes into the error handling workflow is determined by what is in the main workflow.
A workflow design system is described herein that provides user interface controls that allow a workflow author to focus on the steps of the workflow before deciding on how to control the flow of the workflow. With the system, an author can change the control flow of a workflow without re-ordering the sequence of steps within the workflow. Traditional workflow authoring environments force the author to add a control block and then plan a sequence of steps within it. In contrast, the workflow design system allows the author to define a sequence of steps and then drag a control block over these steps to capture them within the control block. The author can also later remove the control block without affecting the sequence of steps if his needs change. In addition, the system presents error-handling workflows side-by-side with the main workflow, so that the author can modify the main workflow and notice the effects and any corresponding changes for error handling workflows at the same time. Thus, the workflow design system allows workflow authors to design workflows in a way more closely aligned with how authors think about the problem to be solved and less like a programming model.
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.
A workflow design system is described herein that provides user interface controls that allow a workflow author to focus on the steps of the workflow before deciding on how to control the flow of the workflow. With the system, an author can change the control flow of a workflow without re-ordering the sequence of steps within the workflow. In addition, the system presents error-handling workflows side-by-side with the main workflow, so that the author can modify the main workflow and notice the effects and any corresponding changes for error handling workflows at the same time. In one example, the system receives a set of steps from an author that define a single instance of a task to be automated. For example, the set of steps may prepare a desktop computer for deployment. At any time, the system can receive a control flow that affects the set of steps from the author. For example, the author can capture a sequence of instructions into a control block by visually dragging the control block over the sequence of steps.
Traditional workflow authoring environments force the author to add a control block and then plan a sequence of steps within it. In contrast, the workflow design system allows the author to define a sequence of steps and then drag a control block over these steps to capture them within the control block. The author can also later remove the control block without affecting the sequence of steps if his needs change. In this way, an author can quickly take a sequence of steps designed to perform one task, and, for example, apply the sequence in a loop to perform the task on many computer systems (e.g., updating each of the computers in an organization). In addition, the author can add error handling to a sequence of steps by selecting the sequence of steps to which an error handler is applied. Thus, the workflow design system allows workflow authors to design workflows in a way more closely aligned with how authors typically think about the problem to be solved and less like a programming model.
Many types of workflow design actions are easier using the workflow design system. A few examples are:
1. Capturing a sequence of instructions into a control block. Traditional workflow authoring environments force the author to add a control block and then plan a sequence of steps within the control block. With the workflow design system, the author can first define a sequence of steps and then drag a control block over these steps to capture them within the control block.
2. Extend a control block to additional steps of a sequence. Traditional workflow authoring environments force the author to drag additional steps into a control block. With the workflow design system, the author can resize the control block to capture additional steps in the sequence of the workflow.
3. Shrink a control block to remove steps of a sequence. Traditional workflow authoring environments force the author to drag steps out of a control block and re-insert them elsewhere in the workflow's sequence of steps. With the workflow design system, the author can shrink the scope of the control block by visually resizing the control block.
4. Remove a control block from a set of steps in a sequence. Traditional workflow authoring environments remove all contained steps when an author deletes a control block. With the workflow design system, the author can remove the control block while maintaining the sequence of steps, as the control block is a separate visual entity in the designer.
5. Add error handling to any sequence of steps. Traditional workflow authoring environments force the author to add the error handler and then put the steps that will be checked for errors into the error handler. With the workflow design system, the author can select the sequence of steps to be checked for an error by creating an error handler around them.
6. Viewing the error handler along with the main workflow. Traditional workflow authoring environments show the main workflow and the error handling workflows on two separate screens. With the workflow design system, the author can design the main workflow and error handling workflows side-by-side.
In some embodiments, the workflow design system provides a designer application that includes a design surface on which authors can place various workflow controls. The author generally selects an action from a library of actions and drops the action onto the design surface as a step in a workflow sequence. The author can re-arrange steps within the sequence by dragging them and dropping them into a different location in the sequence. The author can also drag control blocks onto the design surface. Control blocks can have steps placed within them. Placing steps inside a control block submits the behavior within the sequence to the control of the control block. For example, if the block is a loop, the sequence of steps within the loop will repeat until the exit condition of the loop is met.
Although the designer may support a traditional way of putting steps within a control block, the designer used by the workflow design system also allows the author to place a control block on top of a step or sequence of steps to capture that sequence within the control block. The author can drag boundaries of the control block larger to capture additional steps or smaller to release contained steps. If the author decides that the control block is no longer needed, she can remove the control block without removing the steps the control block surrounds. Instead of being a container, the control block becomes more like an overlay, allowing the workflow author to focus on the sequence of steps and the control flow separately.
The user interface component 110 provides an interface between a user and a designer application. The component 110 receives user input (e.g., from a keyboard, mouse, touch, and so forth) and displays effects of the received input in a visual display, such as on a monitor. The user interface component 110 displays a design surface on which the user can place controls managed by the other components described herein.
The sequence layout component 120 receives a sequence of workflow steps and lays the steps out as graphical block elements visually on a design surface. For example, the component 120 may display each step as a rectangular block with a text string that describes the workflow function of the block (e.g., start virtual machine). The steps may have a particular order, so that when executed one step occurs after another in the order they appear on the design surface (e.g., top to bottom or left to right). The user can modify the sequence of steps by manipulating the blocks through the user interface component 110. For example, a user might drag a block representing a new step into the sequence by selecting the step from a toolbox of available workflow steps. The user may also reorder or remove steps by manipulating the graphical block elements on screen.
The control flow layout component 130 manages a size and a position of one or more control block elements. A user may surround a sequence of steps with a control block element to indicate that the control block element affects the control flow of the surrounded sequence. For example, if a user wants to repeat a sequence of steps five times, then the user may surround the sequence of steps with a FOR control block element with a loop count set to five. The user can change the steps affected by the control block by graphically resizing the control block to surround fewer steps or more steps. Each step within the control block is affected by the control block when the workflow executes.
The error handling layout component 140 graphically displays one or more error handling workflows that are associated with one or more steps in the sequence of workflow steps. For example, a step that moves a file may have an associated error handling workflow that handles a condition of the file not being found at a source location. Error handling workflows may apply to a single step or to sequences of two or more workflow steps. The error handling component 140 displays error-handling workflows in a manner that allows the user to view the sequence of workflow steps contemporaneously with an error handling workflow associated with the sequence of steps. This allows the user to consider the main workflow and error handling workflow separately, but also to view relationships between the two and make changes that keep the two in sync.
The workflow data store 150 stores one or more workflows that a user has saved in the designer application. A user may work on a workflow during multiple sessions of the designer application, saving his progress to the workflow data store 150 between each session. The workflow data store 150 may also store completed workflows for use within an organization whenever the workflows are needed. The workflow data store 150 may include a file (e.g., an extensible language markup (XML) file), a database, a storage area network (SAN), a cloud-based storage service, and other methods of persisting data. The user interface component 110 may provide controls for opening workflows from and saving workflows to the workflow data store 150.
The workflow execution component 160 provides an execution environment for executing the steps of workflows. The workflow execution component carries out the purpose of each sequence of steps, control block element, and error-handling element to implement the user's intent as expressed through the workflow. The workflow execution component 160 may be run in a production environment to process completed workflows as well as within the designer application so that the use can debug workflows that the user is still designing.
The computing device on which the workflow design system is implemented may include a central processing unit, memory, input devices (e.g., keyboard and pointing devices), output devices (e.g., display devices), and storage devices (e.g., disk drives or other non-volatile storage media). The memory and storage devices are computer-readable storage media that may be encoded with computer-executable instructions (e.g., software) that implement or enable the system. In addition, the data structures and message structures may be stored or transmitted via a data transmission medium, such as a signal on a communication link. Various communication links may be used, such as the Internet, a local area network, a wide area network, a point-to-point dial-up connection, a cell phone network, and so on.
Embodiments of the system may be implemented in various operating environments that include personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, digital cameras, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and so on. The computer systems may be cell phones, personal digital assistants, smart phones, personal computers, programmable consumer electronics, digital cameras, and so on.
The system may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, and so on 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.
Continuing in block 230, the system identifies a control flow element that the author has added to the design surface. For example, the author may drag a control flow element from a list of defined control flow elements and drop the control flow element onto the design surface. The user may also select the control flow element from a menu or other common user interface paradigm. The identified control flow element represents a particular type of control flow, such as a WHILE, IF, or FOR construct. Continuing in block 240, the system receives a position and size associated with the identified control flow element. For example, the designer application may maintain data structures with the position and size of each element on the design surface.
Continuing in block 250, the system identifies one or more workflow steps that are visually surrounded by the identified control flow element based on the received position and size. For example, the designer application may draw the control flow element as a rectangle on the design surface and the rectangle may encompass other rectangles representing workflow steps. These are the steps that are affected by the control of the control flow element. Continuing in decision block 260, the system determines whether the position or size of the identified control flow element has changed. If the position or size has changed, such as due to a user resizing the control flow element, then the system continues at block 270, else the system jumps to block 280. Continuing in block 270, the system identifies a new sequence of steps that are visually surrounded by the identified control flow element based on the changed position or size. For example, the author may have expanded the control flow element rectangle to encompass an additional workflow step.
Continuing in block 280, the system optionally receives properties associated with the identified control flow element. For example, the author may provide a loop variable, iteration variable, or other data specific to a particular control flow element. Continuing in block 290, the system stores the workflow to a data store. For example, the system may save the design surface and its contents to a file for later processing (e.g., executing the workflow or receiving further modifications). After block 290, these steps conclude.
Continuing in block 330, the system receives a selection of one or more workflow steps within the received sequence of workflow steps to which to associate an error handling sequence. For example, the author may graphically select one or more workflow steps by clicking on the steps or dragging a box around the steps. Continuing in block 340, the system receives an indication to add an error-handling element to the received selection of one or more workflow steps. For example, the author may right click the selected steps or select an error handling option from a menu of the designer application. Alternatively or additionally, a container of a group of steps may include an icon (e.g., an “E”) that the author can click to add error handling (see, e.g.,
Continuing in block 350, the system receives one or more error handling steps that comprise the error handling sequence. For example, the author may add one or more workflow steps that roll back the actions of the main workflow sequence when a workflow step fails. The error handling sequence can contain workflow steps similar to the main workflow, but may also include error-related steps designed for error handling. Continuing in block 360, the system displays the received sequence of workflow steps and the received error handling sequence so that both are visible on the design surface at the same time. Previous systems make it difficult to view both a workflow and the error handling for the workflow. The workflow design system can display the error handling sequence side-by-side with the main workflow, or in another manner that allows the author to maintain the workflow more easily. After block 360, these steps conclude.
In some embodiments, the workflow design system displays descriptive control structure text for control flow elements. For example, as shown in
In some embodiments, the workflow design system provides a visual indication that indicates something for the author to finish in a workflow. For example, a “Start Virtual Machine” step may have a property that defines which virtual machine to start. Until the user sets the property, the step may have a red exclamation point or other visual indicator in the designer view that indicates a problem. As another example, if a user removes a control flow element and steps within the sequence reference a variable defined by the control flow element, the sequence or individual steps may indicate the error visually.
From the foregoing, it will be appreciated that specific embodiments of the workflow design system have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. For example, although an IT environment has been used in examples, the system can be applied to other environments where workflows are defined for various purposes. Accordingly, the invention is not limited except as by the appended claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5169342 | Steele et al. | Dec 1992 | A |
| 5255181 | Chapman et al. | Oct 1993 | A |
| 5630040 | Furuya | May 1997 | A |
| 5630069 | Flores et al. | May 1997 | A |
| 5684963 | Clement | Nov 1997 | A |
| 5786816 | Macrae et al. | Jul 1998 | A |
| 5841959 | Guiremand | Nov 1998 | A |
| 5850221 | Macrae et al. | Dec 1998 | A |
| 5999911 | Berg et al. | Dec 1999 | A |
| 6020895 | Azami | Feb 2000 | A |
| 6147685 | Bliss et al. | Nov 2000 | A |
| 6225998 | Okita et al. | May 2001 | B1 |
| 6334193 | Buzsaki | Dec 2001 | B1 |
| 6380951 | Petchenkine et al. | Apr 2002 | B1 |
| 6483524 | Petchenkine et al. | Nov 2002 | B1 |
| 6544123 | Tanaka et al. | Apr 2003 | B1 |
| 6563512 | Azami et al. | May 2003 | B1 |
| 6624908 | Petchenkine et al. | Sep 2003 | B1 |
| 6658404 | Cecchini | Dec 2003 | B1 |
| 6970749 | Chinn et al. | Nov 2005 | B1 |
| 7184967 | Mital et al. | Feb 2007 | B1 |
| 7398473 | Stoner et al. | Jul 2008 | B2 |
| 7464366 | Shukla et al. | Dec 2008 | B2 |
| 7549128 | Snyder et al. | Jun 2009 | B2 |
| 7562085 | Bier et al. | Jul 2009 | B2 |
| 7865845 | Dettinger et al. | Jan 2011 | B2 |
| 7870184 | Bauer et al. | Jan 2011 | B2 |
| 7983943 | Morales et al. | Jul 2011 | B2 |
| 8032243 | Raviola et al. | Oct 2011 | B2 |
| 8121716 | Offenmuller | Feb 2012 | B2 |
| 8151202 | Cronin et al. | Apr 2012 | B1 |
| 8156431 | Kobashi | Apr 2012 | B2 |
| 8355928 | Spahn | Jan 2013 | B2 |
| 8661366 | Snyder et al. | Feb 2014 | B2 |
| 8726187 | Snyder et al. | May 2014 | B2 |
| 8843892 | Hamlin et al. | Sep 2014 | B2 |
| 8868353 | Parkhurst et al. | Oct 2014 | B2 |
| 8898442 | Stoitsev | Nov 2014 | B2 |
| 20020161772 | Bergelson et al. | Oct 2002 | A1 |
| 20030110185 | Rhoads | Jun 2003 | A1 |
| 20030142120 | Nii | Jul 2003 | A1 |
| 20030164817 | Graham et al. | Sep 2003 | A1 |
| 20040078105 | Moon et al. | Apr 2004 | A1 |
| 20040078776 | Moon et al. | Apr 2004 | A1 |
| 20040194112 | Whittenberger et al. | Sep 2004 | A1 |
| 20040205600 | Kakuta et al. | Oct 2004 | A1 |
| 20050060252 | Doddington | Mar 2005 | A1 |
| 20050198591 | Jarrett et al. | Sep 2005 | A1 |
| 20060015380 | Flinn et al. | Jan 2006 | A1 |
| 20060036670 | Musman | Feb 2006 | A1 |
| 20060136833 | Dettinger et al. | Jun 2006 | A1 |
| 20060200756 | Politi et al. | Sep 2006 | A1 |
| 20060271883 | Bier et al. | Nov 2006 | A1 |
| 20070055557 | Kloppmann et al. | Mar 2007 | A1 |
| 20070094306 | Kyriazakos | Apr 2007 | A1 |
| 20070245297 | Kuester et al. | Oct 2007 | A1 |
| 20070299906 | Bose et al. | Dec 2007 | A1 |
| 20080013792 | Houllier et al. | Jan 2008 | A1 |
| 20080040437 | Agarwal et al. | Feb 2008 | A1 |
| 20080102949 | Hasegawa et al. | May 2008 | A1 |
| 20080147610 | Mohanty et al. | Jun 2008 | A1 |
| 20080163123 | Bernstein | Jul 2008 | A1 |
| 20080204476 | Montague | Aug 2008 | A1 |
| 20080235610 | Dettinger et al. | Sep 2008 | A1 |
| 20080294986 | Seo et al. | Nov 2008 | A1 |
| 20090006154 | Hao et al. | Jan 2009 | A1 |
| 20090027421 | Servan-Schreiber et al. | Jan 2009 | A1 |
| 20090076785 | Raviola et al. | Mar 2009 | A1 |
| 20090119640 | Ramsey et al. | May 2009 | A1 |
| 20090125342 | Reichhart | May 2009 | A1 |
| 20090216731 | Markovic | Aug 2009 | A1 |
| 20100064277 | Baird et al. | Mar 2010 | A1 |
| 20100064357 | Baird et al. | Mar 2010 | A1 |
| 20100223295 | Stanley et al. | Sep 2010 | A1 |
| 20100306772 | Arnold et al. | Dec 2010 | A1 |
| 20100332581 | Mills et al. | Dec 2010 | A1 |
| 20110065082 | Gal et al. | Mar 2011 | A1 |
| 20110078509 | Wolf et al. | Mar 2011 | A1 |
| 20110080341 | Helmes et al. | Apr 2011 | A1 |
| Number | Date | Country |
|---|---|---|
| 1790241 | Jun 2006 | CN |
| 101364176 | Feb 2009 | CN |
| 101539861 | Sep 2009 | CN |
| Entry |
|---|
| Bing search q=workflow%20ediT%20group%20steps&qs May 27, 2015. |
| U.S. Appl. No. 11/813,800, Non-Final Rejection, Whole Document Dec. 7, 2010. |
| Bing search q=%28workflow%29+and+%28noncontrol%2 Sep. 4, 2014. |
| Bing search q=(workflow+or+work$1flow)+and+(nonc Sep. 4, 2014. |
| Bing search q=workflow%20group%20steps&qs=n&form May 27, 2015. |
| Bing search q=workflow+edit+steps&src=IE—SearchB May 27, 2015. |
| First Office Action and Search Report Issued in Chinese Patent Application No. 201110035132.4, Mail Date: Mar. 2, 2015, 15 pages. |
| Altintas, et al, “Kepler: An Extensible System for Design and Execution of Scientific Workflows”, Retreived at<<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.119.2117&rep=rep1&type=pdf>>, Proceedings of the 16th International Conference on Scientific and Statistical Database Management (SSDBM'04), 2004, pp. 2. |
| Bajcsy, et al., “A Meta-Workflow Cyber-infrastructure System Designed for Environmental Observatories”, Retreived at<<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.93.8058&rep=rep1 &type=pdf>>, Technical Report: NCSA Cyber-environments Division, Dec. 30, 2005, pp. 1-30. |
| Number | Date | Country | |
|---|---|---|---|
| 20110185315 A1 | Jul 2011 | US |
