Workflow Patching

Abstract

A method is provided for patching a workflow in a computing environment by one or more processors in a computing system. One or more patches may be extracted from a source workflow. The one or more patches may be applied to a target workflow at a plurality of nodes to statically or dynamically modify the target workflow. One or more of the plurality of nodes may be added, removed, or modified in the target workflow while the target workflow is active following application of the one or more patches.

Description

[Technical Field]

[0001] The present invention relates generally to computing systems, and more particularly to various embodiments for static or dynamic patching of workflows by computing processors in a computing environment in a computing system. Summary of the Invention

[0002] According to one embodiment of the present invention, a method is provided for statically or dynamically patching a workflow in a computing system. One or more patches extracted from a source workflow may be applied to a target workflow at a plurality of nodes. In response to application of the one or more patches, one or more of a plurality of nodes in the target workflow may be added, removed, or modified while the target workflow is active.

[0003] In further embodiments, one or more patches may be extracted from the source workflow. The target workflow may be statically or dynamically modified by applying one or more patches to the target workflow at the plurality of nodes. In response to applying the one or more patches, one or more of the plurality of nodes may be added, removed, or modified in the target workflow while the target workflow is active.

[0004] In another embodiment, one or more patches may be extracted from the source workflow. The target workflow may be statically or dynamically modified by applying one or more patches to the target workflow at multiple nodes. In response to applying one or more patches, the configuration of nodes of the multiple nodes in the target workflow may be modified. In response to applying one or more patches, nodes of the multiple nodes in the target workflow, and active or inactive dependent nodes, may be identified and selectively deleted.

[0005] One embodiment includes a computer usable program product that includes a computer readable storage device and program instructions stored on the storage device.

[0006] One embodiment includes a computer system including a processor, a computer-readable memory, a computer-readable storage device, and program instructions stored on the storage device for execution by the processor via the memory.

[0007] Thus, in addition to the exemplary method embodiments described above, other exemplary system and computer product embodiments are provided for static or dynamic patching of workflows in a computing environment. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 2 is a block diagram illustrating an example of a cloud computing node, according to one embodiment of the present invention. [Figure 2] FIG. 1 illustrates a cloud computing environment, according to one embodiment of the present invention. [Figure 3] FIG. 2 illustrates abstraction model layers according to one embodiment of the present invention. [Figure 4] 10 is an additional block diagram illustrating an example of the functional relationships between various aspects of the present invention. [Figure 5A] 1 is a block flow diagram illustrating an exemplary system and functionality for static or dynamic patching of workflows in a computing environment by a processor capable of implementing aspects of the present invention. [Figure 5B] 1 is a block flow diagram illustrating an exemplary system and functionality for static or dynamic patching of workflows in a computing environment by a processor capable of implementing aspects of the present invention. [Figure 5C]1 is a block flow diagram illustrating an exemplary system and functionality for static or dynamic patching of workflows in a computing environment by a processor capable of implementing aspects of the present invention. [Figure 5D] 1 is a block flow diagram illustrating an exemplary system and functionality for static or dynamic patching of workflows in a computing environment by a processor capable of implementing aspects of the present invention. [Figure 5E] 1 is a block flow diagram illustrating an exemplary system and functionality for static or dynamic patching of workflows in a computing environment by a processor capable of implementing aspects of the present invention. [Figure 6] 1 is a flowchart of an exemplary method for static or dynamic patching of workflows in a computing environment by a processor capable of implementing aspects of the present invention. [Figure 7] 1 is a flowchart of an exemplary method for static or dynamic patching of workflows in a computing environment by a processor capable of implementing aspects of the present invention. [Figure 8] 1 is a flowchart of an exemplary method for static or dynamic patching of workflows in a computing environment by a processor capable of implementing aspects of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0009] Computing resources are typically pre-configured by vendors to a fixed level of configuration. On the one hand, individual computing resources such as memory size, number of CPUs, disk size, etc. have limited boundaries. On the other hand, each computing platform has a limited number of physical customization options. Today's workloads run within these limitations, which in turn is why techniques such as memory swapping and cache optimization are used in computing environments.

[0010] For example, cloud computing generally provides a seemingly infinite pool of resources that are elastically provisioned and de-provisioned to users. This dynamic provisioning comes at a cost for performance-sensitive workloads, such as deep learning training and high-performance computing ("HPC"). These workloads require provisioned resources to be located as close together as possible to achieve optimal execution times. These workloads alternate between computational and communication cycles, and progress is limited by the machines with the slowest computational cycles and the longest communication cycles with other machines.

[0011] Workflow management provides the infrastructure for setting up, executing, and monitoring defined tasks in processes that can be deployed as workflows. Current workflow systems assume that a model of the process is available, and the system's primary task is to ensure that all activities are performed in the correct order and that the process terminates successfully. Individual tasks in a workflow process may depend on the completion of predecessor tasks before subsequent tasks can be started and completed. At any stage in the process, a delay in the completion of a predecessor task can have a cascading effect, delaying the completion of subsequent tasks and therefore the completion of the entire process.

[0012] Several applications have used workflow schedulers to accelerate job performance, e.g., scientists' research velocity. For example, workflow schedulers allow end users (e.g., scientists) to focus on a specific subject (e.g., their research) using high-performance computing (HPC) and cloud resources without requiring HPC / cloud computing expertise. Workflows also promote the idea of ​​reproducible and portable pipelines. As a result, users (e.g., scientists, researchers) can share information, e.g., scientists' research, with other entities (e.g., research teams). Intuitively, workflows have a significant impact on research, similar to the impact containers have had on cloud computing. Of course, end users, e.g., scientists, are not limited to using workflows. Users can and commonly do modify workflows to suit their needs. Workflows may be retrieved from libraries. They may adjust workflows to add, remove, or modify nodes before launching them on some HPC / cloud infrastructure. Once the workflow is finished, researchers / tools may analyze the workflow's output and use this information to improve it. This feedback loop can be repeated over and over until the desired result is reached.

[0013] Working with workflows becomes complicated when end users want to modify an active workflow. This is a particularly difficult operation, which is why workflow users typically stop, modify, and restart the workflow via static patching. While static patching is much easier, stopping a workflow can result in the immediate termination of a node's tasks, which can result in lost progress. Therefore, there is a demand for users to be able to modify workflows either statically (i.e., while the workflow is not active) or dynamically.

[0014] Accordingly, various embodiments of the present invention enable static or dynamic patching of workflows. In one aspect, a patch may be extracted from a source workflow and applied to a target workflow. A static patch may 1) inject new nodes, 2) remove nodes from the target workflow, or 3) modify any nodes in the target workflow. A dynamic patch may 1) be applied without requiring the workflow to be stopped and restarted, or 2) modify future tasks of nodes in the target workflow (e.g., nodes that are active or inactive at the time of the dynamic patching, or nodes that actively generate multiple tasks over their lifetime), or both. In one aspect, a “patch” (static or dynamic) may be a computer application patch, a piece of software designed to fix / address a problem in a computer program. For example, a patch may be used to fix a security vulnerability, fix a programming bug (error), improve existing functionality, or change the software behavior of a computer program. Patches may be applied to hypervisors, operating systems, middleware, and various other computer software applications.

[0015] In one aspect, the workflow may be modified statically (i.e., when the workflow is inactive) or dynamically using machine learning operations (e.g., artificial intelligence). The machine learning operations may learn to statically or dynamically modify extracted patches from the source workflow to the target workflow. The target workflow may be identified by the machine learning operations.

[0016] In a further aspect, the mechanisms of the illustrated embodiments enable the extraction of robust patches from a source workflow and the application of the extracted patches via static or dynamic patching. Dynamic patching can be applied to a target workload without requiring the target workflow, which is active, to be stopped and / or restarted when the dynamic patching is performed. In this manner, static or dynamic patching of workflows from a source workflow to a target workflow reduces testing and debugging time (e.g., development time) using HPC and cloud infrastructures, or the "time to market" of research / products that utilize the workflow during the production cycle, or both. These improvements can also reduce research and development costs.

[0017] As used herein, a workflow may be a directed acyclic graph. Nodes of the graph may be applications / services, and edges of the graph may indicate one or more dependencies between nodes. Tasks (e.g., workflow tasks) may be executions of applications / services. A workflow orchestrator / manager may be a framework that interprets the composition of a workflow and its nodes to create, manage, and monitor the nodes of the graph.

[0018] A scheduler (e.g., a workflow scheduler) receives instructions from a workflow orchestrator / manager and can process, manipulate, or coordinate the scheduling, management, and monitoring of tasks, or any combination thereof. A node's configuration, or "node configuration," can be information that specifies the node's behavior and the node's tasks. The information can include, but is not limited to, executable tasks, arguments to executable tasks, container images, environment variables, file dependencies, input dependencies to other nodes, backend options (i.e., queues, cluster selectors, etc.), metadata to improve scheduling, and / or error detection and correction.

[0019] Additionally, in another aspect, the present invention enables the input of a patched-in node to be automatically connected to the output of a node in a target workflow. One or more conflicts may be detected and resolved between the configuration of a target node providing input to the patched node and the expected configuration of an input node to the patched node. The mechanisms of the illustrated embodiments further understand various concepts of external dependencies on a workflow (e.g., files that should exist on a file system, files provided to a workflow as it runs, etc.). Dynamic patching as described herein also does not require additional software / application code to be implemented for patching operations, and further, dynamic patching does not require stopping and restarting an active workflow to perform patching operations. In this manner, dynamic patching supports and enables the modification of active nodes in an active target workflow while also supporting and enabling the removal of existing nodes from the active target workflow. Thus, dynamic patching allows for dynamic modification of a workflow by a) adding new nodes, b) modifying existing nodes, or c) removing existing nodes without starting, stopping, or restarting the active target workload.

[0020] In a further aspect, static or dynamic patching of a workflow considers the resulting workflow as a new workflow. The new workflow may reuse artifacts / nodes. This allows static or dynamic patching of a workflow to operate with greater freedom and perform more drastic changes to the target workflow. Static or dynamic patching of a workflow may add new nodes to any sub-workflows. The sub-workflow may automatically map its inputs to existing nodes in the target workflow, remove any nodes in the target workflow, or change the signature / structure and functionality of the entire target workflow, or a combination thereof, etc.

[0021] Additionally, static or dynamic patching of a workflow may operate based on the following set of rules and definitions: A "backend" uses some physical / virtual hardware to run a process or service. A backend may be, for example, OpenShift, Kubernetes, a cloud / hybrid cloud, a load sharing facility (LSF), etc. A task may be a process or service that runs on a backend. A workflow node may contain information that the backend uses to execute tasks. A workflow manager coordinates the execution of the workflow and delegates scheduling decisions for individual tasks of a workflow node to a scheduler. The scheduler understands dependencies between nodes in the workflow. The scheduler determines when a node is runnable and when the node's tasks should be executed in the backend. Online / dynamic patching may refer to the process of modifying a workflow while it is active (i.e., at least one of the nodes is either runnable or actively executing a task in the backend). Patching may include adding new nodes to the workflow graph, modifying existing nodes in the workflow, or removing existing nodes in the workflow. Existing nodes that have been modified will only see the modifications reflected in tasks that are run in the future (i.e., after the patch application is finished).

[0022] Although this disclosure includes detailed descriptions of cloud computing, it is understood in advance that implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the present invention may be practiced in conjunction with any other type of computing environment now known or later developed.

[0023] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a service provider. This cloud model includes at least five characteristics, at least three service models, and at least four deployment models.

[0024] The characteristics are as follows:

[0025] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time or network storage, automatically as needed, without the need for human interaction with the service provider.

[0026] Broad network access: Computing power is available over the network and can be accessed through standard mechanisms, facilitating use by heterogeneous thin or thick client platforms (e.g., cell phones, laptops, PDAs).

[0027] Resource Pooling: Computing resources from a provider are pooled and offered to multiple consumers using a multi-tenant model. Various physical and virtual resources are dynamically allocated and reallocated based on demand. Consumers generally have no control or knowledge of the exact location of the resources they are provided with, resulting in a sense of location independence. However, consumers may be able to determine location at a higher level of abstraction (e.g., country, state, data center).

[0028] Rapid Elasticity: Computing capacity can be provisioned quickly and elastically, sometimes automatically, to instantly scale out and quickly release to instantly scale in. To the consumer, the computing power available for provisioning often appears unlimited, and can be purchased at any time and in any quantity.

[0029] Metered Services: Cloud systems leverage measurement capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts) to automatically control and optimize resource usage. Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of utilized services.

[0030] The service model is as follows:

[0031] Software as a Service (SaaS): The functionality offered to the consumer is the availability of a provider's applications running on a cloud infrastructure that can be accessed from a variety of client devices through a thin client interface such as a web browser (e.g., webmail). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functionality, except for limited user-specific application configuration settings.

[0032] Platform as a Service (PaaS): The capability offered to consumers is to deploy applications they create or acquire using programming languages ​​and tools supported by the provider onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of their hosting environment.

[0033] Infrastructure as a Service (IaaS): The functionality offered to consumers is the provisioning of processors, storage, networking, and other basic computing resources on which they can deploy and run any software, including operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating system, storage, and deployed applications, and in some cases partial control over some network components (e.g., host firewalls).

[0034] The deployment model is as follows:

[0035] Private Cloud: This cloud infrastructure is dedicated to a specific organization and can be managed by that organization or a third party, and can exist on-premise or off-premise.

[0036] Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with common concerns (e.g., mission, security requirements, policies, and compliance). This cloud infrastructure can be managed by those organizations or a third party and can exist on-premises or off-premises.

[0037] Public cloud: This cloud infrastructure is available to the general public or large industry organizations and is owned by an organization that sells cloud services.

[0038] Hybrid cloud: This cloud infrastructure combines two or more cloud models (private, community, or public), each of which retains its inherent nuances but is bound by standards or specific technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0039] A cloud computing environment is a service-oriented environment that emphasizes statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0040] 1, a schematic diagram of an example cloud computing node is shown. It should be noted that cloud computing node 10 is merely one example of a suitable cloud computing node and is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the present invention described herein. In any event, cloud computing node 10 is capable of implementing and / or performing any of the functionality described herein.

[0041] Within cloud computing node 10 resides computer system / server 12. Computer system / server 12 is operable with numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, that may be suitable for use with computer system / server 12 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable appliances, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of these systems or devices.

[0042] The computer system / server 12 may be described in the general context of computer system-executable instructions, such as program modules, executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular data types. The computer system / server 12 may be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be stored in both local and remote computer system storage media, including memory storage devices.

[0043] 1, computer system / server 12 within cloud computing node 10 is depicted as a general-purpose computing device. Components of computer system / server 12 may include, but are not limited to, one or more processors or processing units 16, a system memory 28, and a bus 18 connecting various system components, including system memory 28, to processor 16.

[0044] Bus 18 represents any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an Accelerated Graphics Port (AGP), and a processor or local bus using any of a variety of bus architectures. By way of non-limiting example, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0045] Computer system / server 12 typically includes a variety of computer system-readable media, which can be any available media that can be accessed by computer system / server 12 and includes both volatile and nonvolatile media, removable and non-removable media.

[0046] The system memory 28 may include a computer system-readable medium such as volatile memory (e.g., RAM 30 and / or cache memory 32). The computer system / server 12 may also include other removable / non-removable, volatile / non-volatile computer system-readable media. By way of example only, the storage system 34 may be provided for reading from and writing to a non-removable, non-volatile magnetic medium (not shown, commonly referred to as a "hard drive"). Also, although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from and writing to a removable, non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these examples, each may be connected to the bus 18 by one or more data medium interfaces. As further shown and described below, the system memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of embodiments of the present invention.

[0047] As one non-limiting example, a program / utility 40 having a set (at least one) of program modules 42 may be stored in system memory 28, as may an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may include an implementation of a network environment. The program modules 42 generally implement the functions and / or methods of embodiments of the present invention described herein.

[0048] The computer system / server 12 may also communicate with one or more external devices 14, such as a keyboard, pointing device, display 24, one or more devices that enable a user to interact with the computer system / server 12, or any device (e.g., a network card, modem, etc.) that enables communication between the computer system / server 12 and one or more other computing devices. Such communication may occur via an input / output (I / O) interface 22. The computer system / server 12 may also communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, via a network adapter 20. As shown, the network adapter 20 may communicate with other components of the computer system / server 12 via a bus 18. Note that other hardware and / or software components (not shown) may be used with the computer system / server 12, including, but not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data archive storage systems, etc.

[0049] FIG. 2 illustrates an exemplary cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, with which local computing devices used by cloud consumers (e.g., PDAs or cell phones 54A, desktop computers 54B, laptop computers 54C, or automobile computer systems 54N, or combinations thereof) can communicate. The nodes 10 can communicate with each other. The nodes 10 can be physically or virtually grouped (not shown) in one or more networks, such as the private, community, public, or hybrid clouds described above, or combinations thereof. This enables the cloud computing environment 50 to provide infrastructure, platform, or software as a service, or combinations thereof, for which cloud consumers are not required to maintain resources on their local computing devices. It should be understood that the types of computing devices 54A-N illustrated in FIG. 2 are merely exemplary, and that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of electronic device via any type of network or network-addressable connection (e.g., using a web browser), or both.

[0050] A set of functional abstraction layers provided by the cloud computing environment 50 (FIG. 2) is now shown in FIG. 3. It should be understood in advance that the components, layers, and functions shown in FIG. 3 are merely exemplary, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0051] The device layer 55 includes physical and / or virtual devices, embedded and / or standalone electronics, sensors, actuators, and other objects for performing various tasks in the cloud computing environment 50. Each of the devices in the device layer 55 may incorporate network connectivity capabilities to other functional abstraction layers so that information obtained from these devices may be provided to the other functional abstraction layers, information from other abstraction layers may be provided to the devices, or both. In one embodiment, the various devices comprising the device layer 55 may incorporate a network of entities collectively known as the “Internet of Things” (IoT). As one skilled in the art will recognize, this network of entities enables communication between, collection, and dissemination of data to accomplish a variety of purposes.

[0052] The illustrated device layer 55 includes sensors 52, actuators 53, a "learning" thermostat 56 with integrated processing electronics, sensor electronics, and network-connected electronics, a camera 57, a controllable household outlet / receptacle 58, and a controllable light switch 59. Other possible devices include, but are not limited to, various additional sensor devices, network-connected devices, electronic devices (e.g., remote control devices), additional actuator devices, so-called "smart" appliances such as refrigerators or washer / dryers, and various other interconnected objects.

[0053] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, reduced instruction set computer (RISC) architecture-based server 62, server 63, blade server 64, storage device 65, and network and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0054] The virtualization layer 70 provides an abstraction layer from which virtual entities such as virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75 can be provided.

[0055] By way of example, the management layer 80 may provide the following functionality: Resource provisioning 81 enables dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 enables cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. By way of example, these resources may include application software licenses. Security enables identification and verification of cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 enables allocation and management of cloud computing resources so that requested service levels are met. Service level agreement (SLA) planning and fulfillment 85 enables advance arrangement and procurement of anticipated future cloud computing resources required in accordance with SLAs.

[0056] The workload layer 90 provides examples of functionality available in a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and, in connection with the illustrated embodiment of the present invention, various workloads and functionality for static or dynamic patching of workflows in a computing environment (e.g., neural network architectures) 96. Additionally, the workloads and functionality for static or dynamic patching of workflows in a computing environment 96 can include operations such as analytics, deep learning, and (as discussed further below) user and device management functions. As will be appreciated by those skilled in the art, the workloads and functionality for static or dynamic patching of workflows in a computing environment 96 may cooperate with other portions of various abstraction layers, such as those in hardware and software 60, virtualization 70, management 80, and other workloads 90 (e.g., data analytics processing 94, etc.), to achieve various objectives of the illustrated embodiment of the present invention.

[0057] As described above, the present invention provides a novel solution for realizing static or dynamic patching of workflows in a computing environment in a computing system. One or more patches may be extracted from a source workflow. A target workflow in a plurality of nodes may be statically or dynamically modified by applying one or more patches to the target workflow. In response to application of one or more patches, one or more nodes of the plurality of nodes may be added, removed, or modified in the target workflow while the target workflow is active.

[0058] 4, which is a block diagram illustrating example functional components of a system 400 for static or dynamic patching of workflows in a computing environment (e.g., a neural network architecture) in accordance with various mechanisms of an illustrated embodiment. In one aspect, one or more of the components, modules, services, applications, or functions described in FIGS. 1-3, or combinations thereof, may be used in FIG. 4. As can be seen, many of the functional blocks may also be considered functional "modules" or "components" in the same descriptive sense as previously described in FIGS. 1-3.

[0059] A workflow patching service 410 is shown. The workflow patching service 410 incorporates a processing unit 420 (“processor”) that performs various computations, data processing, and other functions in accordance with various aspects of the present invention. In one aspect, the processor 420 and memory 430 may reside internally and / or externally to the workflow patching service 410, and may reside internally and / or externally to the computing system / server 12. As described in FIG. 1 , the workflow patching service 410 may be included in the computer system / server 12, may reside externally, or both. The processing unit 420 may be in communication with the memory 430. The workflow patching service 410 may include a manager component 440 (e.g., an orchestrator), a configuration component 450, a scheduler component 460, and a node component 470.

[0060] In one aspect, system 400 may provide virtualized computing services (i.e., virtualized computing, virtualized storage, virtualized networking, etc.) More specifically, system 400 may provide virtualized computing, virtualized storage, virtualized networking, and other virtualized services that run on a hardware board.

[0061] In one aspect, manager component 440, in association with node component 470, may identify one or more source workflows (e.g., source workflows having one or more tasks) at a node or group of nodes. Manager component 440 may extract one or more patches from the source workflows. Manager component 440 may apply one or more patches extracted from the source workflows to target workflows at multiple nodes. That is, manager component 440 may apply one or more patches to the target workflows dynamically or statically.

[0062] The manager component 440, in conjunction with the node component 470, may identify one or more splice points to apply one or more patches to. A splice point may be a node in the target workflow that provides input to a node identified in one or more patches.

[0063] Manager component 440, in conjunction with configuration component 450, may add, remove, or modify one or more of the nodes in the target workflow while the target workflow is active in response to the application of one or more patches.

[0064] The manager component 440, in conjunction with the scheduler component 460, may schedule each workflow task on a node or group of nodes. The manager component 440, in conjunction with the scheduler component 460, may restrict the scheduling of additional nodes for multiple nodes while applying one or more patches.

[0065] Manager component 440, in conjunction with configuration component 450 and / or node component 470, may identify conflicts between metadata defined in one or more patches and metadata of multiple nodes in the target workflow. Manager component 440, in conjunction with configuration component 450 and / or node component 470, may generate one or more resolution actions to resolve the identified conflicts so that the one or more patches are compatible with the target workflow.

[0066] The manager component 440, in conjunction with the configuration component 450 and / or the node component 470, may initialize nodes included in one or more patches to be included in a target workflow. In one aspect, the target workflow is an active workflow. The manager component 440, in conjunction with the scheduler component 460 and / or the node component 470, may schedule active nodes or groups of nodes in the target workflow associated with one or more patches.

[0067] By way of example only, in operation, the workflow patching service 410 and one or more components of the workflow patching service 410 illustrated in FIG. 4 may perform the following steps: In step 1, the workflow patching service 410 may extract a patch from a source workflow. In step 2, the workflow patching service 410 (via the manager component 440 (e.g., an orchestrator)) may instruct the scheduler component 460 not to schedule new nodes. In step 3, the workflow patching service 410 may delete “to-delete” nodes (e.g., nodes that need to be removed from the workflow) and downstream nodes associated with the “to-delete nodes” from the target workflow. In step 4, the workflow patching service 410 may identify one or more splice points in the target workflow (e.g., nodes in the target workflow that provide inputs to nodes defined in the patch). In step 5, the workflow patching service 410 may identify conflicts between metadata defined in the extracted patch and nodes in the target workflow (because leaving the conflicts unaddressed would prevent the patch from being applied). In step 6, the workflow patching service 410 may resolve conflicts (e.g., generate actions that allow the patch to be compatible with the target workflow). In step 7, the workflow patching service 410 may initialize nodes that are present in the patch but not in the active workflow. In step 8, the workflow patching service 410 may modify the configuration of nodes in the target workflow that conflict with the patch. In step 9, the workflow patching service 410 may instruct the scheduler component 460 (via the manager component 440 (e.g., orchestrator)) to schedule ready-to-execute nodes.

[0068] It should be noted that for dynamic patching, each of the above steps may be performed, whereas a static patching algorithm may include only steps 1, 3, 4, 5, 6, 7, and 8 (in this order, or any other selected / arranged order of steps 1, 3, 4, 5, 6, 7, and 8). Also, in one embodiment, the source workflow and the target workflow may be the same workflow, although in another embodiment, the source workflow and the target workflow may be different workflows.

[0069] 5A-5E, block flowcharts 500, 515, 525, 535, and 545 are now described in detail, further illustrating exemplary systems and functions for statically or dynamically patching workflows from steps 1-9 above. In one embodiment, one or more of the components, modules, services, applications, or functions, or combinations thereof, described in FIGS. 1-3 may be used in FIG. 4. As such, it will be appreciated that many of the functional blocks may also be considered functional "modules," "components," or "nodes" in the same descriptive sense as previously described in FIGS. 1-3.

[0070] 5A and 5B, workflow diagram 500 is an example source workflow illustrating step 1 for extracting a patch from a source workflow 500.

[0071] First, a source workflow may be identified having one or more nodes, such as, for example, nodes 502A-G and nodes 504A-C.

[0072] Second, identify a subgraph for extraction in the workflow. For example, the subgraph may include nodes 502A-G. This involves selecting nodes (e.g., nodes 502A-G) that exist in a subgraph connecting component sets "A" and "B," where the output of A is (eventually) consumed by B (the subgraph includes sets A and B). Additionally, nodes that are not extracted and included in the patch may be identified and labeled, e.g., nodes 504A-C.

[0073] Third, step 1 may also include identifying one or more input nodes (I) for the subgraph of the source workflow 500, such as node 502A.

[0074] Fourth, sub-graph dependencies may be split into internal dependencies 512 and external dependencies 510 (e.g., metadata of the external dependencies). That is, internal dependencies 512 may be references to data / files / binaries included in the source workflow package. External dependencies 510 may be references to data, files, or binaries that are not part of the source workflow package (e.g., absolute paths to the execution platform file system, or references to input data provided at runtime).

[0075] Fifth, one or more workflow elements of the subgraph may be identified (e.g., component configurations, environment variable definitions, node variables, etc.). Sixth, the collected information may be converted into a set of files containing a) metadata representing the subgraph's node definitions and dependencies on the subgraph's producer nodes, b) definitions of inputs to the subgraph nodes, and c) internal dependencies of the source workflow (e.g., binaries, data files).

[0076] It should be noted that step 2 of instructing scheduler component 460 not to schedule new nodes may be limited to or used exclusively for online / dynamic patching operations. As such, operations for performing step 2 of instructing scheduler component 460 not to schedule new nodes may include the following operations:

[0077] First, the orchestrator / manager of the target workflow (e.g., manager component 440 of FIG. 4) may notify the scheduler (e.g., scheduler component 460 of FIG. 5) that a patch is being applied. In response, the scheduler a) postpones tagging, labeling, or identifying the node as "ready" once the node's input dependencies to upstream nodes are satisfied (e.g., existing active nodes and associated tasks are not affected in any way), and b) postpones processing of scheduling events from the completed node until the patch is complete.

[0078] Tasks for new nodes will not be scheduled for execution while the patch is in progress, even if dependencies between nodes are satisfied, to ensure that the "task configuration" does not change while the node is scheduled for execution. Also, nodes that already have tasks submitted to their execution backends will not be affected. The scheduler may continue to submit tasks on behalf of the node as if the patch had not been performed. In this way, the target workflow will not experience any slowdown due to the patching process.

[0079] Next, FIG. 5C is a block flowchart 525 illustrating step 3 for deleting a “to be deleted” node (e.g., a node that needs to be deleted from the workflow) and downstream nodes associated with the “to be deleted node” from the target workflow.

[0080] As shown in Figure 5C, the mechanism of the illustrated embodiment provides the ability to remove nodes from the workflow graph, as well as add new nodes and modify existing nodes in the target workflow. For example, an initial list of "to be removed" nodes (e.g., identifying, tagging, or labeling nodes as for removal) can be specified similar to the process of defining a subgraph described in step 1, but instead of referencing nodes in the source workflow, reference nodes are identified in the target workflow. During this operation, the orchestrator / manager discovers and identifies all nodes in the target workflow that have dependencies on the list of nodes to be removed and adds them to the list of "to be removed" nodes.

[0081] The scheduler is notified or informed by the orchestrator / manager of the target workflow (e.g., manager component 440 of FIG. 4 ) that tasks associated with nodes (e.g., a list of “to be deleted” nodes) are to terminate in the target workflow. The scheduler is then notified or informed to consider the list of “to be deleted” nodes as a normal termination. In other words, the scheduler does not consider the list of “to be deleted” nodes as an abnormal termination or error. The scheduler may perform a dependency analysis to ensure that the output of the first “to be deleted” node (e.g., nodes 502F, 502I, 502J, 502K, etc., that the user / machine learning system desires / intends to remove from the target workflow) propagates to the input of the identified “to be deleted” node list. The scheduler is notified or informed by the orchestrator / manager of the target workflow (e.g., manager component 440 of FIG. 4 ) to shut down and terminate tasks associated with the “to be deleted” node list. The resulting remaining target workflow ("Result"), such as nodes 502A-H, is shown in FIG. 5C.

[0082] Note that the "initial-to-delete" nodes may be one or more sets of nodes that a user and / or machine learning system desire to remove from the target workflow. After dependency analysis is complete, the "to-delete" nodes include the "initial-to-delete" node and other nodes that directly or indirectly consume the output of the "initial-to-delete" node.

[0083] For example, the "initial deletion target" node in Figure 5C is node 502D (e.g., the node selected for deletion / removal). Applying dependency analysis (i.e., tracing the output of node 502D through its downstream workflow nodes) reveals that nodes 502F, 502I, 502J, and 502K all depend directly or indirectly on 502D. Specifically, node 502F directly consumes the output of node 502D, and the others indirectly consume it (i.e., the path between node 502D and any of these nodes includes at least one more node).

[0084] Next, FIG. 5D is a block flowchart 535 illustrating step 4 for identifying one or more splice points in the target workflow (e.g., nodes in the target workflow that provide inputs to nodes defined in the patch).

[0085] In one aspect, the one or more splice points are nodes of the target workflow. The one or more splice points may be automatically identified, for example, by machine learning. A splice point is a node that serves as an input node to a node present in the patch. For example, automatically identifying splice points may include one or more of the following operations: First, a feature vector may be generated for all input nodes (e.g., hereinafter referred to and labeled as "inputs of novel nodes") of nodes included or identified in the patch. The feature vector may be a set of fields such as, for example, [node namespace], [node name], [executable], and [arguments].

[0086] Feature vectors may then be generated for all nodes in the target workflow graph. In a further embodiment, one or more input-feature vectors may be generated from one or more root nodes of the patch and compared to one or more output-feature vectors in the target (e.g., matching a domain to a codomain). A "feature" (as used in machine learning) may be considered, for example, as a characteristic of any entity. A "feature vector" may be a collection of features. An operation may be performed to identify, discover, or locate nodes in the target workflow whose feature vectors are similar to those of the "inputs of the new node" with a similarity coefficient higher than a selected threshold (e.g., a "feature vector match" threshold). Identified matching pairs (e.g., nodes with similar feature vectors) may be recorded. Additionally, a user and / or machine learning operation may specify nodes in the target workflow to use as inputs to nodes included in the patch by providing pairs of target workflow node identifiers (namespace and name) and "inputs of the new node" identifiers.

[0087] In this way, the configuration of nodes (e.g., nodes 502Q-W) in the patch and their input nodes (e.g., node 502Q) are identified, as shown in Figure 5D. For example, node 502E in the target workflow has a feature vector that matches node 502Q included in the patch. Node 502Q includes each of node dependencies of node 502Q, and these are identified.

[0088] At this point, the patch contains information about the "input new nodes" extracted from the source workflow and the patched nodes. A conflict may occur if any of the nodes in the patch already exist in the target workflow. A conflict may also occur between the definition of the "input new nodes" and the matching nodes found in step 4. In one embodiment, by way of example only, a conflict is the difference in the configuration of two nodes, where one node is part of the patch and the other node is part of the target workflow. Thus, following step 4, the operations of step 5 may be performed to identify conflicts between the metadata defined in the extracted patch and the nodes of the target workflow. Step 5 may also traverse the nodes of the target workflow and record conflicts between the target workflow and the patch.

[0089] Following step 5, step 6 may again be performed in which the workflow patching service 410 resolves the conflict (e.g., generates actions that enable the patch to be compatible with the target workflow). In this case, there are multiple ways to resolve such conflicts. For example, tools using semantic knowledge and language processing techniques (e.g., machine learning operation tools) may be used to determine how to properly merge the conflicting configurations of the two nodes. In further aspects, machine learning operations may be used to examine the conflicting information and determine how to resolve the conflict by doing one of the following: 1) accept the configuration of the target node; 2) accept the configuration of the source node; or 3) enter a new configuration that combines the two nodes. Thus, the purpose of step 6 is to enable the components / nodes of the patch and the existing nodes of the target workflow to successfully perform their respective tasks.

[0090] Next, FIG. 5E is a block flowchart 545 illustrating step 7 for initializing nodes that are present in the patch but not in the active workflow. In the case of static patching, each new node may be inserted into the target workflow. In a dynamic patching operation, a list of nodes that are included in the patch but not present in the target workflow is provided. The orchestrator / manager may update its internal data structures and initialize "new node inputs" through steps including, but not limited to: a) initializing the backend, b) modifying files on the file system (e.g., copying "internal dependencies" from the patch (see step 1 or more information)), c) updating the metadata of the target workflow, or d) updating the scheduler's data structures, or a combination thereof.

[0091] Following step 7, step 8 may be performed again to modify the configuration of nodes in the target workflow that conflict with the patch. As part of step 8, the orchestrator / manager of the target workflow may modify the configuration of nodes that conflict with the information contained in the patch. The orchestrator / manager of the target workflow may replay and consider the decisions made in step 6. The orchestrator / manager may update its internal data structures and perform initialization steps for each of the conflicting nodes, including, but not limited to: a) backend initialization, b) modifying files on the file system (e.g., copying "internal dependencies" from the patch (see step 1 or More Information)), c) updating the target workflow's metadata, or d) updating the scheduler's data structures, or any combination thereof. In this way, step 8 completes the transformation of the target workflow to include the information encoded in the patch.

[0092] Additionally, step 9, instructing the scheduler component 460 to schedule runnable nodes, may be applicable only to dynamic patching operations. As part of step 9, the orchestrator / manager of the target workflow may notify the scheduler that dynamic patching is complete. The scheduler may a) retroactively process any scheduling events postponed in step 2, and b) lift any prohibitions / restrictions on scheduling tasks for nodes that were not ready to run before the dynamic patching process began.

[0093] 6 illustrates a method 600 for patching a workflow in a computing environment by a processor, which may implement various aspects of the illustrated embodiments. Function 600 may be implemented as a method (e.g., a computer-implemented method) executed as instructions on a machine, where the instructions are contained on at least one computer-readable medium or at least one non-transitory machine-readable storage medium. Function 600 may begin at block 602.

[0094] One or more patches extracted from the source workflow may be applied to the target workflow at the plurality of nodes, as per block 604. One or more of the plurality of nodes in the target workflow may be added, removed (via machine learning or at the direction of a user / administrator, or both), or modified in accordance with the application of the one or more patches while the target workflow is active, as per block 606. Function 600 may end at block 608.

[0095] 7 illustrates a further method 700 for statically or dynamically patching a workflow in a computing environment by a processor. The function 700 may be implemented as a method (e.g., a computer-implemented method) executed as instructions on a machine, where the instructions are contained on at least one computer-readable medium or at least one non-transitory machine-readable storage medium. The function 700 may begin at block 702.

[0096] One or more patches may be extracted from the source workflow, as in block 704. The target workflow may be statically or dynamically modified at a plurality of nodes by applying one or more patches to the target workflow, as in block 706. One or more of the plurality of nodes may be added, removed, or modified in the target workflow while the target workflow is active following application of the one or more patches, as in block 708. Function 700 may end at block 710.

[0097] 8 illustrates a further method 800 for statically or dynamically patching a workflow in a computing environment by a processor. Function 800 may be implemented as a method (e.g., a computer-implemented method) executed as instructions on a machine, where the instructions are contained on at least one computer-readable medium or at least one non-transitory machine-readable storage medium. Function 800 may begin at block 802.

[0098] One or more patches may be extracted from the source workflow, as in block 804. The target workflow may be statically or dynamically modified at a plurality of nodes by applying one or more patches to the target workflow, as in block 806. The configuration of a node of the plurality of nodes in the target workflow may be modified in accordance with the application of the one or more patches, as in block 808. In response to the application of the one or more patches, a node of the plurality of nodes, and active or inactive nodes with dependencies, may be identified and removed in the target workflow in response to the application of the one or more patches, as in block 810. In one aspect, active or inactive nodes (e.g., undesirable nodes) may be removed based on machine learning or user preference, rather than just because the node is inherently inactive. Function 800 may end at block 812.

[0099] In one embodiment, in connection with, as part of, or both of at least one block of Figures 6-8, the operations in 600, 700, or 800, or a combination thereof, may include each of the following: The operations in 600, 700, or 800, or a combination thereof, may extract one or more patches from a source workflow and dynamically or statically apply the one or more patches to a target workflow.

[0100] The operations at 600, 700, or 800, or a combination thereof, may restrict scheduling of additional nodes relative to the plurality of nodes while applying one or more patches and identify splice points at which to apply the one or more patches. A splice point may be a node in the target workflow that provides input to one or more nodes identified in the one or more patches. The operations at 600, 700, or 800, or a combination thereof, may identify conflicts between metadata defined in the one or more patches and metadata of the plurality of nodes in the target workflow, and generate one or more resolution actions to resolve the identified conflicts and enable the one or more patches to be compatible with the target workflow.

[0101] The operations at 600, 700, or 800, or a combination thereof, may generate feature vectors for all nodes in the target workflow graph. In further embodiments, the operations at 600, 700, or 800, or a combination thereof, may generate one or more input-feature vectors from one or more root nodes of the patch and compare the one or more input-feature vectors with one or more output-feature vectors in the target (e.g., matching domains to codomains).

[0102] The operations at 600, 700, or 800, or a combination thereof, may initialize nodes of a plurality of nodes included in one or more patches to be included in a target workflow (where the target workflow is active) and schedule nodes associated with one or more patches of a plurality of nodes active in the target workflow.

[0103] The present invention may be a system, a method, or a computer program product, or a combination thereof. The computer program product may include a computer-readable storage medium having stored thereon computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0104] A computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. The computer-readable storage medium may be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or a suitable combination thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROMs, DVDs, memory sticks, floppy disks, punch cards, or mechanically encoded devices having instructions recorded on ridge-in-groove structures, and the like, and suitable combinations thereof. As used herein, a computer-readable storage medium should not be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0105] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing device / processing device. Alternatively, they can be downloaded to an external computer or external storage device via a network (e.g., the Internet, a LAN, a WAN, or a wireless network, or a combination thereof). The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing device / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions to a computer-readable storage medium in the respective computing device / processing device for storage.

[0106] Computer-readable program instructions for carrying out operations of the present invention can be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-configuration data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as the "C" programming language and similar programming languages. The computer-readable program instructions can execute entirely on the user's computer as a standalone software package, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a LAN or WAN, or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), and programmable logic arrays (PLAs), can execute the computer-readable program instructions by utilizing state information from the computer-readable program instructions to customize the electronic circuit for carrying out aspects of the present invention.

[0107] Aspects of the present invention are described herein with reference to flowchart and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. Each block of the flowchart and / or block diagrams, and combinations of blocks in the flowchart and / or block diagrams, can be implemented by computer-readable program instructions.

[0108] These computer-readable program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, whereby the instructions, executed by the processor of such computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions can also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner. The computer-readable storage medium having instructions stored thereon thereby constitutes an article of manufacture including instructions for performing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0109] Computer-readable program instructions may also be loaded into a computer, other programmable apparatus, or other device and a series of operational steps executed on the computer, other programmable apparatus, or other device to create a computer-implemented process, whereby the instructions executing on the computer, other programmable apparatus, or other device perform the functions / operations identified in one or more blocks in the flowcharts and / or block diagrams.

[0110] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for performing specific logical functions. In some other implementations, the functions shown in the blocks may be executed in an order different from that shown in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may be executed in reverse order, depending on the functionality involved. Note that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs specific functions or operations or executes a combination of dedicated hardware and computer instructions.

[0111] While various embodiments of the present invention have been described by way of example, they are not intended to be exhaustive or limited to these embodiments. As will be apparent to those skilled in the art, many modifications and variations are possible without departing from the scope of the described embodiments. The terms used herein have been selected to best explain the principles, practical applications, or technical improvements of the embodiments over technologies recognized in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. 1. A method for patching a workflow in a computing environment by one or more processors, comprising: applying one or more patches extracted from a source workflow to a target workflow on a plurality of nodes; adding, deleting, or modifying one or more of the nodes in the target workflow while the target workflow is active in accordance with application of the one or more patches; A method comprising:

2. The method of claim 1 , further comprising extracting the one or more patches from the source workflow.

3. The method of claim 1 , further comprising dynamically or statically applying the one or more patches to the target workflow.

4. The method of claim 1 , further comprising restricting scheduling of additional nodes to the plurality of nodes while applying the one or more patches.

5. 10. The method of claim 1, further comprising identifying one or more splice points for applying the one or more patches, the splice points being nodes in the target workflow that provide input to nodes identified in the one or more patches.

6. identifying conflicts between metadata defined in the one or more patches and metadata of the plurality of nodes in the target workflow; generating one or more resolution actions to resolve the identified conflicts and make the one or more patches compatible with the target workflow; The method of claim 1 further comprising:

7. initializing a plurality of nodes included in the one or more patches to be included in the target workflow, the target workflow being active; and scheduling nodes associated with the one or more patches among the plurality of nodes active in the target workflow; The method of claim 1 further comprising:

8. 1. A system for patching a workflow in a computing environment, comprising: one or more computers having executable instructions that, when executed, cause the system to: applying one or more patches extracted from a source workflow to a target workflow on a plurality of nodes; adding, deleting, or modifying one or more of the nodes in the target workflow while the target workflow is active in accordance with application of the one or more patches; A system that executes the following.

9. The system of claim 8 , wherein the executable instructions, when executed, cause the system to extract the one or more patches from the source workflow.

10. The system of claim 8 , wherein the executable instructions, when executed, cause the system to dynamically or statically apply the one or more patches to the target workflow.

11. 9. The system of claim 8, wherein the executable instructions, when executed, cause the system to restrict scheduling of additional nodes to the plurality of nodes while applying the one or more patches.

12. 9. The system of claim 8, wherein the executable instructions, when executed, cause the system to identify one or more splice points for applying the one or more patches, the splice points being nodes in the target workflow that provide input to nodes identified in the one or more patches.

13. The executable instructions, when executed, cause the system to: identifying conflicts between metadata defined in the one or more patches and metadata of the plurality of nodes in the target workflow; generating one or more resolution actions to resolve the identified conflicts and make the one or more patches compatible with the target workflow; The system of claim 8 , wherein the system executes the following:

14. The executable instructions, when executed, cause the system to: initializing a plurality of nodes included in the one or more patches to be included in the target workflow, the target workflow being active; and scheduling nodes associated with the one or more patches among the plurality of nodes active in the target workflow; The system of claim 8 , wherein the system executes the following:

15. 1. A computer program for patching a workflow in a computing environment, the computer program comprising: program instructions for applying one or more patches extracted from a source workflow to a target workflow at a plurality of nodes; program instructions for adding, removing, or modifying one or more of the plurality of nodes in the target workflow while the target workflow is active in accordance with application of the one or more patches; a computer program comprising:

16. The computer program of claim 15 , further comprising program instructions for extracting the one or more patches from the source workflow.

17. The computer program product of claim 15 , further comprising program instructions for dynamically or statically applying the one or more patches to the target workflow.

18. 16. The computer program of claim 15, further comprising program instructions for restricting scheduling of additional nodes to the plurality of nodes while applying the one or more patches.

19. 16. The computer program of claim 15, further comprising program instructions for identifying one or more splice points for applying the one or more patches, the splice points being nodes in the target workflow that provide input to nodes identified in the one or more patches.

20. program instructions for identifying conflicts between metadata defined in the one or more patches and metadata of the plurality of nodes in the target workflow; program instructions for generating one or more resolution actions to resolve the identified conflicts and make the one or more patches compatible with the target workflow; 16. The computer program of claim 15, further comprising:

21. program instructions for identifying conflicts between metadata defined in the one or more patches and metadata of the plurality of nodes in the target workflow; program instructions for generating one or more resolution actions to resolve the conflict and make the one or more patches compatible with the target workflow; 16. The computer program of claim 15, further comprising:

22. 1. A method for patching a workflow in a computing environment by one or more processors, comprising: Extracting one or more patches from a source workflow; statically or dynamically modifying a target workflow by applying the one or more patches to the target workflow at a plurality of nodes; In response to applying the one or more patches, adding, removing, or modifying one or more of the plurality of nodes in the target workflow while the target workflow is active; and A method comprising:

23. 23. The method of claim 22, further comprising identifying one or more splice points for applying the one or more patches, the splice points being nodes in the target workflow that provide input to nodes identified in the one or more patches.

24. identifying conflicts between metadata defined in the one or more patches and metadata of the plurality of nodes in the target workflow; generating one or more resolution actions to resolve the identified conflicts and make the one or more patches compatible with the target workflow; 23. The method of claim 22, further comprising:

25. 1. A method for patching a workflow in a computing environment by one or more processors, comprising: Extracting one or more patches from a source workflow; statically or dynamically modifying a target workflow by applying the one or more patches to the target workflow at a plurality of nodes; modifying a configuration of a node of the plurality of nodes in the target workflow in response to applying the one or more patches; identifying and deleting nodes of the plurality of nodes and active or inactive dependent nodes in the target workflow in response to applying the one or more patches; A method comprising:

Images