WO2017148508A1

WO2017148508A1 - Multi-phase high performance business process management engine

Info

Publication number: WO2017148508A1
Application number: PCT/EP2016/054338
Authority: WO
Inventors: Jorge Cardoso; Goetz BRASCHE; Xing ZHU
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2016-03-01
Filing date: 2016-03-01
Publication date: 2017-09-08
Also published as: CN107924502A

Abstract

There is provided an apparatus for rescheduling execution of phases of activities, comprising an interface adapted for designating business process activities, a processing unit adapted for receiving as an input an execution sequence of phases of each one of the business process activities, selecting one of domains for one or more of the business process activities according to a semantic analysis of respective the phases of the one or more business process activities, selecting a set of domain specific scheduling rules according to the selected domain, and creating one or more new execution sequences by scheduling the phases of each one of the business process activities according to the set of domain specific scheduling rules.

Description

MULTI-PHASE HIGH PERFORMANCE BUSINESS PROCESS

MANAGEMENT ENGINE

BACKGROUND

The present invention, in some embodiments thereof, relates to business process management systems (BPMS) and, more specifically, but not exclusively, to a advanced scheduling mechanisms for BPMS.

Business process management (BPM) was introduced to support the design, orchestration (also known as enactment or execution), management, and analysis of business processes. Business processes, also called process models or workflows, are structured collections of activities that produce a specific service (outcome) for a particular customer. Processes may be organized and visualized as graph structures with nodes (representing activities and decision points) and edges connecting nodes (representing logical/temporal dependencies). Process models are commonly used to represent administrative processes (e.g., leave applications or business trip requests), scientific workflows (e.g., DNA sequencing), big data processing (e.g., data analysis), and distributed application coordination (e.g., cloud/client computing).

The software platforms responsible for managing process models are called business process management systems. BPMS generally bring together subsystems for the design, execution, and monitoring of process models. The subsystem responsible for the execution of process models is often called the orchestration engine or execution engine. The execution engine may read a process model description from a data file, create a process instance, and supervise its execution using information and communication technologies (ICT). BPMS are used in different applications, for example, distributed systems coordination, information systems integration, management of work (workflows), Business Process as a Service (BPaaS), and cloud BPM to orchestrate single services into complex business-valued services.

Existing business process management systems handle activities as atomic entities. A process engine schedules the execution of activities and waits for their (successful or failed) completion. When an activity terminates, the engine schedules the next activity (activities) for execution according to the defined process model.

Different solutions have been proposed to try and improve performance of

BPMS: * Leymann et al., in European Patent Application No. EP 0831406 appear to propose to increase the performance of WFMS by storing control functions and process state in Database Management Systems (DBMS). Marginal improvement of performance may result based on the assumption that all functions can be executed within a database system.

* Du et al, United States Patent No. US 6041306 appear to propose decentralized workflow management systems, which require utilizing more distributed resource hardware, which is expensive.

* Pechanec et al., United States Patent Application Publication No. US2012/0060150 appear to propose to translate BPM process definitions into a Java source code. The method/system is only applicable to Java-based systems. Furthermore, the translation limits the flexibility and adaptability of processes.

SUMMARY

It is an object of the present invention to provide an apparatus, a system, a computer program product, and a method for rescheduling execution of phases of activities.

The foregoing and other objects are achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

According to a first aspect, an apparatus for rescheduling execution of phases of activities, comprises an interface adapted for designating business process activities, a processing unit adapted for receiving as an input an execution sequence of phases of each one of the business process activities, selecting one of domains for one or more of the business process activities according to a semantic analysis of respective the phases of the one or more business process activities, selecting a set of domain specific scheduling rules according to the selected domain, and creating one or more new execution sequences by scheduling the phases of each one of the business process activities according to the set of domain specific scheduling rules.

The method and/or apparatus provides for a higher throughput and/or lower latency of the processing unit and/or executing computing system in executing business process activities. The multi-phase design of business process activities allows the processing unit to be aware of what is happening during execution of the business process activity, allowing the processing unit to make advanced scheduling decisions according to the execution progress of activities.

The apparatus, systems, and/or methods described herein may be used to improve performance of existing available resources of computing systems (e.g., BPM engines) and/or executing computing system without necessarily requiring adding additional hardware components (e.g., without necessarily adding additional faster processors, a larger number of processors, and/or memory with faster access).

The semantics (e.g., stored as labels and/or description) of the phases enable developers and/or programmers to know in which phase they should place their code (e.g., instructions, script, functions, libraries). During scheduling, the labels are used by the BPM engine (e.g., processing unit) to understand the semantics of the code of the respective phases in execution (e.g. at any moment in time). The BPM engine analyzes the label and/or schematics to perform advanced scheduling decisions to improve performance (e.g., reduced latency and/or increased throughput optionally using existing hardware).

The semantics may be implemented as a programming model, which may help programmers develop high performance BPM engines (e.g., orchestration engines), for example, take advantage of locality of data, to bring data near where it is processed.

Domain specific scheduling rules defines scheduling of new business process activities and respective phases based on the completion of other business process activities phases, improve performance of the processing unit and/or executing computing system.

According to a second aspect, a method of rescheduling execution of phases of activities comprises receiving business process activities, receiving as an input an execution sequence of phases of each one of the business process activities, selecting one of multiple domains for one or more of the business process activities according to a semantic analysis of respective the phases of the one or more business process activities, selecting a set of domain specific scheduling rules according to the selected domain, and creating one or more new execution sequences by scheduling the phases of each one of the business process activities according to the set of domain specific scheduling rules.

In a first possible implementation form of the method according to the second aspect as such, the method further comprises allocating one or more resources for an execution of a first of the business process activities while a second of the business process activities being executed; wherein the one or more resources are used by the second business process activity.

The allocation of a resource that is currently being used by the second business process activity may be made to the first business process activity according to the created schedule, allowing the first business process to use the resources with a shorter delay (e.g., time to start execution of the first business process activity upon completion of the second business process activity).

In a second possible implementation form of the method according to the second aspect as such or according to any of the preceding implementation forms of the second aspect, the creating comprises freeing a resource used by one of the business process activities for another of the business process activities while the another of the business process activities is not fully executed.

The resource may be freed before the business process activity started execution, so that when the other business activity begins execution the other business activity process may utilize the resource without having to wait and experience a delay.

In a third possible implementation form of the method according to the second aspect as such or according to any of the preceding implementation forms of the second aspect, the set of domain specific scheduling rules comprises phase execution heuristics.

The phase execution heuristics may improve future phase scheduling by learning and/or analyzing current and/or historical execution results.

In a fourth possible implementation form of the method according to the second aspect as such or according to any of the preceding implementation forms of the second aspect, the set of domain specific scheduling rules induces rescheduling of the phases of one of the business process activities among themselves and among phases of one or more another of the business process activities.

The execution performance of multiple business processes activities may be simultaneously improved.

In a fifth possible implementation form of the method according to the second aspect as such or according to any of the preceding implementation forms of the second aspect, the set of domain specific scheduling rules are acquired from a shared repository by the apparatus and by similar apparatuses for rescheduling execution of phases.

The shared repository allows multiple computing units to use the same set of domain specific rules for scheduling phases, optionally of different business process activities, within the same or similar domain.

The shared repository allows multiple computing units, each processing different phases of the same business process activity to use common scheduling rules, which allows the different computing units to coordinate scheduling of the phases.

In a sixth possible implementation form of the method according to the second aspect as such or according to any of the preceding implementation forms of the second aspect, the phases are scheduled by the one or more new execution sequences to be executed by one of multiple different processors.

Processors may be selected according to the processing requirements of each phase, which may improve execution performance.

In a seventh possible implementation form of the method according to the second aspect as such or according to the preceding implementation form of the second aspect, the different processors are selected from a group consisting of graphics processing unit (GPU) core processors, distributed processing units and processing units of a multi core processing system.

The phases may be executed in a distributed system (which may increase computational performance), which may be a heterogeneous distributed system and/or a homogenous distributed system.

In an eighth possible implementation form of the method according to the second aspect as such or according to any of the preceding implementation forms of the second aspect, the set of domain specific scheduling rules comprises instructions for distributing a processing of respective phases for processing by execution resources.

Distributing the phases for execution by different computing units provides scalability to processing a large number of business process activities (which may include a large number of phases) with high performance.

In a ninth possible implementation form of the method according to the second aspect as such or according to any of the preceding implementation forms of the second aspect, a first phase of the phases which precedes a second phase of the phases in a respective the sequence is subsequent to the second phase in the one or more new execution sequences.

The rearrangement of the execution schedule of the phases improves performance of the processing unit and/or of the executing computing system.

In a tenth possible implementation form of the method according to the second aspect as such or according to any of the preceding implementation forms of the second aspect, the semantic analysis is performed based on one or more semantics associated with each phase, the one or more semantics selected from a group consisting of: activity pattern, phase label, and phase property.

In an eleventh possible implementation form of the method according to the second aspect as such or according to the preceding implementation form of the second aspect, the activity pattern is selected from the group consisting of: read, execution, and write.

In a twelfth possible implementation form of the method according to the second aspect as such or according to the preceding tenth or eleventh implementation forms of the second aspect, the phase property is one or more members or a combination of members selected from the group consisting of: safe, unsafe, idempotent, non-idempotent, autonomous, and non-autonomous.

In a thirteenth possible implementation form of the method according to the second aspect as such or according to any of the preceding implementation forms of the second aspect, each one of the phases is adapted to be executed independently from others of the phases.

Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention pertains. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the invention, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Some embodiments of the invention are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the invention. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the invention may be practiced.

In the drawings:

FIG. 1 is a schematic of an exemplary BPM engine processing single-phase business process activities, in accordance with some embodiments of the present invention;

FIG. 2 is a schematic depicting communication of possible exemplary states between single phase activities and an activity manager of the BPM engine of FIG. 1, in accordance with some embodiments of the present invention;

FIG. 3 is a flowchart of a computer-implemented method that schedules multiple phases of business process activities, in accordance with some embodiments of the present invention;

FIG. 4 is a block diagram of a components of a system that schedules multiple phases of business process activities, in accordance with some embodiments of the present invention;

FIG. 5 is a schematic representing relationships between a multi-phase activity manager and multiple phases of a business process activity, in accordance with some embodiments of the present invention;

FIG. 6 is an exemplary architecture of a multi-phase BPM, in accordance with some embodiments of the present invention;

FIG. 7 is a schematic representing a multi-phase activity pattern including 3 categories that may be used to assign semantics to phases of a business process activity, in accordance with some embodiments of the present invention;

FIG. 8 is a schematic of an exemplary multi phase activity controller implemented as a finite state machine, in accordance with some embodiments of the present invention;

FIG. 9 is a schematic representing example values for components discussed with reference to FIG. 6, in accordance with some embodiments of the present invention; and

FIG. 10 is a schematic graphically depicting yet another example of domain specific rules for creating a new scheduling sequence, in accordance with some embodiments of the present invention. DETAILED DESCRIPTION

An aspect of some embodiments of the present invention relates to an apparatus (e.g., a processing unit) and/or a method (e.g., implemented by code stored in a memory executed by a processor) that reschedules execution of multiple phases of business process activities. Each business process activity is segmented into multiple phases, each designed to be executed (e.g., by the processing unit scheduling execution of the phase by an execution computing system optionally a distributed computing system) independently from other phases. Each phase is associated with semantics. A domain and associated set of domain specific rules are selected for each business process activity according to an analysis of the semantics of the phases of the respective business process activity. The processing unit may be aware of the execution of each business process activity according to the execution state of the phases associated with the respective business process activity. The processing unit implements scheduling decisions to improve execution performance of the business process activities. A new execution sequence is created by scheduling the phases of the business process activities according to the set of domain specific scheduling rules. The method and/or apparatus provides for a higher throughput and/or lower latency of the processing unit and/or the executing computing system in executing business process activities. The multi-phase design of business process activities allows the processing unit to be aware of what is happening during execution of the business process activity, allowing the processing unit to make advanced scheduling decisions according to the execution progress of activities. For example, during execution the processing unit is aware of the progress of execution of each business process activity according to the state of execution of the phases associated with the business process activity. Scheduling decisions, which increase performance of the processing unit and/or executing computing system may be made, for example, preemptively scheduling the execution of another business process activity.

Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the Examples. The invention is capable of other embodiments or of being practiced or carried out in various ways.

The present invention may be a system, a method and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network.

The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

The flowchart 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 the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

As used herein, the term activity is sometimes used as the short version of the phrase business process activity.

As used herein, the terms BPM engine, computing unit, orchestration engine, multi phase activity manager and execution engine are sometimes interchangeable.

Reference is now made to FIG. 1, which is a schematic depicting an exemplary architecture of a BPM engine 100 (e.g., code instructions stored in a memory executed by a processing unit of a computing unit) that is designed to process single-phase activities 102, in accordance with some embodiments of the present invention. BPM engine 100 operates without the systems and/or methods described herein. In contrast, the apparatus, systems, and/or methods described herein process multiple phases of business process activities, as described herein in additional detail. BPM engine 100 is described to help explain the novelty of the apparatus, system, and/or methods described herein. The activity manager component of BPM engine 100 schedules execution of the single-phase activities, waits for the activity to finish execution, and registers whether the execution was completed successfully or failed. BPM engine 100 cannot obtain information about the progress of the atomic (i.e., single phase) business process activities. Each activity is fully processed before BPM engine 100 decides on the next activity to execute. Reference is also made to FIG. 2, which is a schematic depicting communication of possible exemplary states between single phase activities 102 and activity manager 104, in accordance with some embodiments of the present invention. Three exemplary types of events are represented: start _activity, activity _completed, and activity Jailed (other possible exemplary events are terminate, suspend, and resume). One event is generated when an activity starts execution (start _activity) and one of two events are generated when the activity finishes (activity ^completed or activity Jailed).

Reference is now made to FIG. 3, which is a flowchart of a computer- implemented method that schedules multiple phases of business process activities, in accordance with some embodiments of the present invention. Reference is also made to FIG. 4, which is a block diagram of components of a system 400 that improves performance of a computing unit 402 (may also be referred to herein as an apparatus) by scheduling execution of multiple phases of business process activities, in accordance with some embodiments of the present invention. Computing unit 402 may implemented the acts of the method of FIG. 3, by instruction code stored in a memory executed by a processing unit 406 of computing unit 402.

Computing unit 402 may be implemented, for example, as a server (e.g., providing services to one or more client terminals over a network connection via business process activity interface 408 which may be implemented as a network interface), as a web server (e.g., providing service to clients terminals using a web browser optionally via business process activity interface 408 and/or another interface), and/or a client running locally stored code. Computing unit 402 may be implemented as a hardware component (e.g., standalone computing unit), as a software component (e.g., implemented within an existing computing unit), and/or as a hardware component inserted into an existing computing unit (e.g., plug-in card, attachable unit). The server implementation may provide services to client terminals by providing software as a service (SAAS), providing an application that may be installed on the client that communicates with the server, and/or providing functions using remote access sessions. Other exemplary implementations of computing unit 402 include, for example, a mobile device, a desktop computer, a thin client, a Smartphone, a Tablet computer, a laptop computer, a wearable computer, glasses computer, and a watch computer. Processing unit 406 may be implemented, for example, as a central processing unit(s) (CPU), a graphics processing unit(s) (GPU), field programmable gate array(s) (FPGA), digital signal processor(s) (DSP), and application specific integrated circuit(s) (ASIC). Processing unit(s) 406 may include one or more processors (homogenous or heterogeneous), which may be arranged for parallel processing, as clusters and/or as one or more multi core processing units.

Memory 404 stores code instructions executed by processing unit 406, for example, a random access memory (RAM), read-only memory (ROM), and/or a storage device, for example, non-volatile memory, magnetic media, semiconductor memory devices, hard drive, removable storage, and optical media (e.g., DVD, CD- ROM).

Computing unit 402 includes a storage unit 410 that acts as a data repository for storing data, for example, a memory, a hard-drive, an optical disc, a storage unit, an interface to a remote storage server, and interface to a cloud server, and/or other storage units. Data repository 410 may include a domain specific rule repository 41 OA that stores a set-of-rules for each domain, as described herein.

Computing unit 402 includes or is in communication with a user interface 412 (which may be integrated with a display 414, or be implemented as a separate device), for example, a touchscreen, a keyboard, a mouse, and voice activated software using speakers and microphone.

Computing unit 402 is implemented within (e.g., as software installed thereto and/or as a hardware component connected to) and/or in communication with (e.g., using a wired and/or wireless network connection) an execution computing system 418 that executes code instructions of the phases of the multi phase business process activities. Execution computing system 418 includes one or more processing units 410 and/or one or more memory and/or storage units 422. Execution computing system 418 may be implemented as a distributed system, which may be organized in computing clusters. The distributed system implementation of execution computing system 418 may be implemented as a heterogeneous distributed system (composed of different processing architectures and/or different storage architectures) and/or a homogenous distributed system (composed of processors and/or storage units of similar architecture).

The apparatus (including the processing unit) and/or method (e.g., implemented by the apparatus) described herein provide improved performance of BPMS in terms of throughput (i.e., the maximum number of process instances that the processing unit may complete or process per unit time) and/or latency (i.e., the time (e.g., average) to process or complete the execution of a process instance). The latency may represent the interval of time which mediates a request for process execution and the time when the process instance completes. It is noted that throughput and latency are considered together in achieving a combined performance effect, since one affects the other, for example, as the number of requests for execution of business process activities per unit of time increases, the latency may increase and the throughput may decrease.

The high performance of the method and/or apparatus described herein (e.g., in terms of higher throughput and/or lower latency of the processing unit in processing business process activities) may be used in applications requiring scalability and/or the ability to handle a large number of clients, for example, computing cloud architectures implementing distributed applications based on heterogeneous processing environments while serving a large number of clients (e.g., in the thousands or millions). The apparatus, systems, and/or methods described herein may be used to improve performance of existing available resources of computing systems (e.g., BPM engines) without necessarily requiring adding additional hardware components (e.g., without necessarily adding additional faster processors, a larger number of processors, and/or memory with faster access).

Latency of business process activities (and/or of phases of each business process activity) may be calculated by the following exemplary equations. A set of instances processed by a BPM engine may be represented as ..., »). Each instance ij may be represented as a vector (t_s, tc,p_m), where t_s is the time when the request for the processing of the instance was requested by a client, t_c the time when the instance processing was completed by the BPM engine, and p_m the process model used to create the instance. The latency of a single instance ij (1), and the latency (2) and the throughput (3) of a BPM engine may be calculated, respectively, using the following exemplary equations:

latency {i_j) = ¾(t_c) - i_:j(t_s} (1)

(2) n

I¹

throughput

max(ii(t_c)) - min(i_m{t_s))

l. m E j . . . j + k (3) At 302, business process activities are received by computing unit 402 using business process activity interface 408, for example, from a business process activity repository 416, which may be implemented, for example, as a server, as a client terminal, as a storage unit, as a file, as manually entered user data, and/or other implementations.

Business process activities may be defined, for example, by code instructions, by compiled code, by a script (e.g., human readable text), by a graph, by a set of rules, and/or based on a domain specific language. The business process activities may be automatically generated, for example, by specialized software. The business process activities may be manually defined, for example, by users and/or programmers, by writing code and/or using specialized software.

Each business process activity is segmented into multiple phases (i.e., each phase is shorter than the respective business process activity). The segmentation into phases may be manually defined by the programmer, for example, using a domain specific language, a set of rules, a script, code, a interface (e.g., API), or other implementations. The segmentation into phases may be automatically performed by a processor executing code instructions that analyze relationships of functions (e.g., code) within the activity to identify independent portions that may be segmented (e.g., using a dataflow graph or other methods).

Reference is now made to FIG. 5, which is a schematic representing relationships between a multi-phase activity manager 502 (e.g., code stored in memory 404 implemented by processing unit 406) and multiple phases 504, in accordance with some embodiments of the present invention. Multi-phase activity manager 502 controls the execution of phases 504. Each phase 504 notifies activity manager 502 of its state, optionally upon completion of execution. Activity manager 502 (or another code component) decides the next phase to execute. The phases may be independent of one another, allowing for parallel execution of phases, and/or starting execution of a later phase before an earlier phase completed execution.

Each phase 504 is designated with a start _phase_X event (where X is assigned a value from 1, 2, 3, n (where n represents the total number of phases)) when execution of the respective phase is started. The respective phase is designated with an event phase _completed_Y or phase _failed_Y \.o signal to activity manager 502 that processing has completed or failed (where Y is assigned a value from 1, 2, 3, n (where n represents the total number of phases)). It is noted that not all of the phases 504 of the business activity process need to have an implementation and/or need to be executed. The number of phases of each business process activity may depend for example, on the domain of application.

Reference is now made to FIG. 6, which is an exemplary architecture of a multi-phase BPM 602, in accordance with some embodiments of the present invention. Multi-phase BPM 602 may be implemented by code instructions stored in memory 404 and executed by processing unit 406 of computing unit 402.

Exemplary components (e.g., implemented as code, functions, libraries, scripts, hardware modules, and/or files) of multi-phase BPM 602 include one or more of: multi-phase business process activity 604 (e.g., as described with reference to phases 504 of FIG. 5), multi-phase activity manager 606 (e.g., as described with reference to activity manager 502 of FIG. 5), multi-phase control table 608 (e.g., as described herein), advanced process instance manager 610 (e.g., as described herein), and scheduling strategies table 612 (e.g., as described herein). It is noted that one or more components 604-612 may be implemented as additional components (e.g., code and/or hardware units) added and/or integrated with single-phase BPM (e.g., BPM 100 described with reference to FIG. 1).

Referring now back to FIG. 3, at 304, an execution sequence of the multiple phases of each one of the business process activities is received as input by computing unit 402, optionally via business process activity interface 408. The execution sequence may be represented, for example, as a finite state machine, a linked list, a graph, based on a linear sequence (e.g., not defined but assumed by code that phases follow one another sequentially based on a numbering). The execution sequence may be manually defined by the user and/or automatically defined by code instructions executed by the processing unit.

Optionally, each one of the phases is adapted to be executed independently from other phases of the business process activity. The phases may not be related to one another in terms of data input and output, such that output by a certain phase is not used by another independent phase, and/or a certain phase may not use input generated from another independent phase. Phases that do not depend on one another for data transfer may be independently executed. In another example, phases that do not alter data may be safely executed independently of other phases. In yet another example, the phases are related to one another in terms of data dependencies (i.e., a certain phase uses the output generated by another phase) but may be executed independently and adjusted once the phases complete execution, for example, when one of three phases is to be executed upon completion of another phase, the three phases may be executed independently, with the results stored once the another phase completed execution (with the results of the other two phases ignored or discarded).

The execution of the sequence of the multiple phases of respective business process activities may be defined and/or monitored and/or managed based on a data structure defining relationships between the phases, for example, a state machine, a linked list (or graph), or other implementations.

Each independent phase may be executed by a different computing cluster of a distributed system implementation of execution computing system 418.

At 306, a semantic analysis of the respective phases associated with one or more business process activities is performed by computing unit 402. Each phase is associated with one or more semantics. The semantics may be stored, for example, as metadata with the phase (e.g., metadata with instructions and/or code of the phase), as tags associated with the phase, in a database indexed by phases, and/or automatically calculated by code (e.g., by a machine learning algorithm that analyzes the phase and automatically extracts semantics, for example, a statistical classifier). The semantics associated with each phase are analyzed by computing unit 402 (e.g., BPM engine 602) in the process of making scheduling decisions of the phases, and/or controlling execution of the phases, as described herein.

The semantics (e.g., stored as labels and/or description) of the phases enable developers and/or programmers to know in which phase they should place their code (e.g., instructions, script, functions, libraries). During scheduling, the labels are used by the BPM engine (e.g., processing unit 406 of computing unit 402) to understand the semantics of the code of the respective phases in execution (e.g. at any moment in time). The BPM engine analyzes the label and/or schematics to perform advanced scheduling decisions to improve performance (e.g., reduced latency and/or increased throughput optionally using existing hardware).

The semantics may be manually defined by programmers, for example, to guide scheduling of the respective phases by the processing unit. The semantics may be automatically generated (e.g., by code instructions execution by a processor such as processing unit 406 or an external processor) based on an automatic analysis of the respective phase, for example, using machine learning methods (e.g., statistical classifier) that analyzes content (e.g., code, instructions) of the phase and outputs one or more semantic labels.

The semantics and/or state of the phases may be communicated between the executing phases and the processing unit 406 of computing unit 402 (e.g., a multi phase activity manager), for example, by function calls defined by respective programming languages, software libraries, application programming interfaces (API), distributed Web APIs invocations, software development kits (SDK) and/or other interface implementations.

Exemplary semantics include: an activity pattern, a phase labeling, and properties.

Activity Pattern: phases may be categorized (and/or labeled, e.g., using metadata and/or tags) according to a multi-phase activity pattern. The multi-phase pattern may relate to separation of concerns, such that each phase addresses a separate concern. When each phase is categorized, individual phases may be executed with specialized systems/resources and/or by computing unit 402 and/or be optimized (e.g., for performance, cost reduction, high reliability, and high availability). The pattern may related to the domain of application, and/or may be simple or complex according to the domain, for example, the number of categories may rise with complexity according to the domain.

Reference is now made to FIG. 7, which is a schematic representing a multiphase activity pattern (of a multi-phase business process activity 702) including 3 categories that may be used to assign semantics (i.e., activity pattern category semantic) to phases of a business process activity, in accordance with some embodiments of the present invention. The categories include read (R), execution (X), and write (W). The multi-phase activity pattern of the discussed example is referred to as the RXW pattern. It is noted that the pattern is exemplary and may differ for other domains. For example, for a data analytics domain, an exemplary pattern includes the phases load data (L), clean data ( C), process data (P), and store results (S). A multiphase activity manager 704 (e.g., code stored in memory 404 executed by processing unit 406 of computing unit 402) relates to multi phase activity 702 as described herein. In our example, the RXW pattern may be used as a programming model by programmers in developing high performance computing units (e.g., orchestration engines), for example, by utilizing the principle of locality of data to bring data closer to where it is processed. The phase R brings data near where the data is processed (i.e., in phase X), for example, to a local file system (FS) or a cache system (e.g., memory 404 of computing unit 402 and/or another location) where phase X is executed. Phase W copies the data to a final location (e.g., in storage unit 410, in memory 404, or other storage units). The BPM engine (e.g., computing unit 402) may analyze the semantics including the RXW pattern, and based on the analysis preemptively execute the phases of the category R since the R phases do not modify the state of a process model (i.e., the R phases only read data). The discussed benefits of implementing a multi-phase activity pattern based on semantics are exemplary, and other performance improves may be obtained.

Phase Labeling: Phases may be labeled according to respective semantics. FIG. 7 depicts an exemplary relationship between the RXW activity pattern and the multiple phases of multi phase activity 702 that includes 7 phases (for example purposes only, other number of phases may be used, and/or other patterns of phases may be represented). The 7 phases include: two read phases (R), 3 execution phases (X), and 2 write phases (W). The semantic phase labels are phase 1 (Rl), phase 2 (R2), phase 3 (XI), phase 4 (X2), phase 5 (X3), phase 6 (Wl), and phase 7 (W2). Each of the 7 phases is now discussed in additional detail:

* Phase 1 (Read Input - Rl): The Read Input phase represents reading of the input provided by the execution engine (e.g., BPM 602, computing unit 402).

* Phase 2 (Read Data - R2) The Read Data phase represents reading of the data (e.g., from a distributed file system), for use by the execution phase (as described below).

* Phase 3 (Activity Execution - XI ) The Activity Execution phase represents processing. The Activity Execution phase may be implemented, for example, by local function calls defined by respective programming languages, software libraries, and/or distributed Web application programming interface (APIs) invocations, or other technologies.

* Phase 4 (Exception Handling - X2) The Exception Handling phase represents processing of the data in case of failure of phase XI . * Phase 5 (Rollback Activity - X3) The Rollback Activity phase represents undoing of action(s) performed in phases XI and/or X2 to recover to a previous state were no processing was performed.

* Phase 6 (Write Data - Wl ) The Write Data phase represents writing the data to a storage location (e.g., the final destination). The input may be transferred, for example, from a local file system to a distributed file system, remote data store, or other storage device.

* Phase 7 (Write Output - W2) The Write Output phase represents writing the output of the business process activity (e.g., to the execution engine). It is noted that W2 represents the opposite phase of the phase R2.

Properties of Phases: Phases may be labeled by developers, designers, or programmers, using the exemplary set properties of phases: safe, unsafe, idempotent, non-idempotent, autonomous and/or non- autonomous (other properties may be defined). Each phase may be labeled with one property, or a combination of properties. For example, the phase may be safe, idempotent, and autonomous, or safe, non-idempotent and non-autonomous.

* A safe (or unsafe ) phase represents an implementation that does not modify resources in a way in which the modification cannot be rollback. For example, phase XI may calculate a complex mathematical computation of an integral from the data collected in phases Rl and R2 using a specialized (local) software library. Phase XI is designated safe since no resources are modified during its execution. In contrast, a phase XI which adds a new record to a database is designated as unsafe since the state of the data store changes.

* An idempotent (or non idempotent) phase represents an implementation that may be called repetitively without yielding different outcomes. For example, reading the input of an activity from the execution engine multiple times does not changes the value read. In another example (e.g., the example discussed with respect to the safe phase implementation) calling phase XI several times to calculate an integral always yields the same result. In yet another example, a phase R2 that implements copying a remote file to the local file system (which may replace a existing file having the same name) is designated as idempotent since the action can be called many times without yielding different outcomes (i.e., the result is always the same for each execution of the phase). In another example, a phase XI which implements instructions to add a new and/or different record to a database during each execution is designated as not idempotent.

* An autonomous (or non autonomous) (also termed independent or non independent or dependent) phase is independent from the other phases. For example, an independent phase R2 is allowed (or able) to read a dataset, which will be later processed in phase XI, without requiring any additional data from phase Rl. During scheduling, the engine verifies that dependencies between the phases (i.e., between non independent phases) are respected. As depicted in FIG. 7, phases R2, XI, X2, X3, Wl and W2 are dependent on the outcome of phase Rl. A dependency may occur when data generated in a phase is needed in another phase. For example, when phase R2 accesses a distributed file system which requires a login and password retrieved from the BPM engine in phase Rl, a dependency exists between R2 and Rl. As another example, execution of Rl may depend on input from the BPM engine.

The properties of the phases enable the BPM engine (e.g., orchestration engine, the multi-phase activity manager 606 component of BPM engine 602 of FIG. 6) to designate scheduling of phases to improve computational performance (e.g. in terms of latency and/or throughput). For example, autonomous and safe phases may be preemptively called. When phases are designated as idempotent, the respective phases may be called several time, for example, as a process that handles exceptions (e.g., phase X2) and/or avoids unnecessary, costly instance failures (e.g., phase X3). Phases designated as dependent may be stalled for execution to wait for the phase from which the dependent phase depends from to complete execution.

At 308, a domain is selected (e.g., from multiple available domains) for one or more of the business process activities according to the semantic analysis. Alternatively, the domain is predefined for each business process activity, for example, manually by the user and/or automatically by code instructions.

The selection may be performed by processing unit 406, for example, by a mapping function that maps semantic labels to a domain, a statistical classifier that accepts semantic labels as inputs and outputs a domain, a look-up table, or other methods.

The domains may represent general classifications of business process activities, for example, big data processing, distributed applications, and database management. At 310, a set of domain specific scheduling rules is selected by processing unit 406 according to the selected domain. Each domain may be associated with one or more sets of scheduling rules designed to improve scheduling of phases based on the respective domain. The domain specific schedule rules may be stored in domain specific rule repository 41 OA of storage unit 410 (and/or another storage unit), for example, as a script, as textual instructions, as code, or other implementation.

Optionally, the set of domain specific scheduling rules include phase execution heuristics. The phase execution heuristics may include one or more machine learning methods, for example, a statistical classifier. The phase execution heuristics may define an analysis of the results of execution of the phases (e.g. in terms of errors, latency, throughput, data transfer between phase) using the machine learning method to improve scheduling of the phases. The phase execution heuristics may improve future phase scheduling by learning and/or analyzing current and/or historical execution results. The phase execution heuristics may be predefined, optionally manually by programmers. The programmers may categorize and/or characterize code (e.g., instructions) of the phase, for example, by designating activity patterns, phase labeling, and/or other semantics and/or rules. In this manner, the programmers provide information to processing unit 406 on the effects of executing respective phases, which may be used to schedule execution of business process activities and/or phases according to the set of domain specific scheduling rules including phase execution heuristics.

Optionally, the set of domain specific scheduling rules induce rescheduling of the phases (of one or more of the business process activities) among themselves. The rescheduling may be performed within the phases of each business process activity, without consideration of other phases of other business process activities. Alternatively or additionally, the set of domain specific scheduling rules induce rescheduling of phases of a certain business process activity among phases of one or more other business process activities. The rescheduling is performed in consideration of the scheduling of other business process activities. In this manner, the execution performance of multiple business processes activities may be simultaneously improved.

Optionally, the set of domain specific scheduling rules are acquired from a shared repository (e.g., domain specific rule repository 410A) by computing unit 402. The shared repository is accessible (e.g., in parallel) by multiple other similar computing units 416 for rescheduling execution of phases. The shared repository allows multiple computing units to use the same set of domain specific rules for scheduling phases, optionally of different business process activities, within the same or similar domain. The shared repository allows multiple computing units, each processing different phases of the same business process activity to use common scheduling rules, which allows the different computing units to coordinate scheduling of the phases.

Optionally, the set of domain specific scheduling rules include instructions for distributing processing of respective phases (of the same and/or different business process activities) for processing by multiple execution resources, for example, different computing clusters of execution computing system 418. Multi-phase business process activities may be managed by multiple computing units (402 and/or 416). Each computing unit 402 and/or 416 may manage one or more phases of the business process activity being executed by execution computing system 418. The architecture provides scalability to processing a large number of business process activities (which may include a large number of phases) with high performance.

At 312, processing unit 406 (e.g., multiple phase activity manager 704 of FIG. 7) creates one or more new execution sequences. The new execution sequence is created by scheduling the phases of each one of the business process activities according to the set of domain specific scheduling rules, for example, a state machine selected according to the domain.

Referring now back to FIG. 7, multiple phase activity manager 704 (which may correspond to processing unit 406 of FIG. 4) manages multiple phase activity pattern 702. The progress of each business process activity may be controlled and/or managed, for example, using a state machine 706, linked list, graph, or other data structures representing a current state of each phase and/or relationships between phases. The arrows of state machine 706 connect the states (represented as circles connected by the arrows) and the phases represent the transfer of input (il) from activity manager 704 to the respective phase (of multiple phase activity 702) and the transfer of output (ol) from the respective phase (of multiple phase activity 702) to activity manager 704. Multi-phase activity manager 704 may interact with each phase of the multiple phase activity 702 via an API (application program interface) 709, or other interface (e.g., software development kit (SDK). The number of defined events (e.g., interrupts, signals, network messages, interface codes, or other electronic transmissions) is extended in computing unit 402 processing multiple phases for each business process activity as compared to an orchestration engine that processes single phase business process activities. For example, in addition to events used in single phase systems (e.g., start _activity, activity _^completed, and activity Jailed) additional exemplary events may be defined per phase n: start _phase_n, phase _n_completed, and phase _n Jailed.

The events may be generated when the state of the multi-phase state machine 706 changes. For example, when a token is placed in Rl, the event start jphase_Rl is generated (represented with el in FIG. 7). Activity manager 704 calls phase Rl using API 708 and sends input il, expecting to receive output ol. When the respective phase completes execution, event phase _R1 _completed (represented with e2 in FIG. 7) is sent to activity manager 704, which decides on the next phase to execute (and/or rescheduling execution of phases) according to the state machine. The transition to state XI occurs when the event phase _R2_completed is received. The event phase _R2 Ja^' iled is handled differently by activity manager 704, which may cancel the instance execution or execute the recovery phase X2. Multi-phase state machine 706 starts at state Rl and changes its state until it reaches state W2.

Referring now back to FIG. 3 and FIG. 4, processing unit 406 of computing unit 402 (e.g., multiple phase activity manager 704 of FIG. 7, and/or multiple phase activity manager 606 of FIG. 6) schedules phases of the business process activity based on the set of domain specific scheduling rules, which may include the current state of the phases (e.g., as defined by a state machine, e.g., finite state machine 706 of FIG. 7), generated events (e.g., phase _n_completed, phase _n Jailed), and/or the semantics such as the properties of the phases (e.g., safe, idempotent, and autonomous ).

Multi phase activity manager 704 uses finite state machine (FSM) 706, or another implementation of a multi-phase activity controller to create a new schedule (i.e. execution sequence) of the phases of each business process activity. FSM 706 may be automatically generated from a multi phase control table (e.g., table 608 of FIG. 6), which optionally represents a state table. Multi phase control table 608 may be stored in storage unit 410, optionally in domain specific rule repository 41 OA in association with a specific domain. Multi phase control table 608 (or other domain specific rule implementations) may be manually defined (e.g., by a programmer using user interface 412 and/or display 414) and/or automatically generated (e.g., by code) to reflect a desired behavior for the generated state machine (or other controller implementations), for example, as a script, a set of rules written in a domain specific language, compiled code, or other implementations. Customized controllers (e.g., state machines) adapted to the domain of operations of processes may be created. A base controller (e.g., FSM) may be generated automatically by using the properties of phases (e.g., safe, idempotent, and autonomous) and sequential dependencies between phase.

Optionally, the state machine and/or other domain specific set of rules may be shared by multiple (e.g., all) process models being executed. Each process model may include multiple business process activities that may access the state machine and/or other domain specific set of rules, which may be stored in domain specific rule repository 41 OA made accessible to code (e.g., on the same computing unit 402 and/or another computing unit(s) 416) executing other business process activities and/or other process modules. For example, other computing units 416 may access domain specific rule repository 41 OA using a network connection, an API, or other software and/or hardware interfaces.

Reference is now made to FIG. 8, which is a schematic of an exemplary multi phase activity controller implemented as a finite state machine 802, in accordance with some embodiments of the present invention. FSM 802 (which represents an implementation of domain specific rules) defines the creation of new execute sequences for the phases of business process activities. FSM 802 represents that when phase XI is independent of the results of phase Rl and R2, then XI may be scheduled as soon as the business process activity instance starts execution. When phase Rl is designated as idempotent and the execution of phase Rl has failed up to x times, phase Rl may be re-executed (i.e., since Rl is designated as idempotent and therefore calling phase Rl multiple times will not result in an inconsistent instance state or other errors).

Multi-phase activity controller (e.g., FSM) 802 may serve as a scheduling controller and/or as a phase monitoring data structure that stores the current state (i.e., execution progress) of an executing business process activity, by tracking the current state of the phases of the business process activity. By monitoring the state of the independent phases of the business activity process, FSM 802 proves a finer monitoring capability in comparison to BPM engines that monitor single phase business process activities. The fine grained state description is used by processing unit 406 to perform advanced scheduling decisions, and/or create new execution sequences of the phases. For example, when phase XI completes execution, the following activity may be scheduled when phase Rl does not have an implementation since the following activity does not depend on an input supplied by the BPM engine.

Referring now back to FIG. 6, Advanced Process Instance Manager 610 (e.g., code stored in memory 404 executed by processing unit 406 of computing unit 402 in FIG. 2) creates new execution sequences (i.e., schedules) the business process activities of a process model. When a business process activity completes execution, the business process activity notifies activity manager 606 (e.g., by using an API, transmitting a message, raising an interrupt, or other implementations), which schedules the next business process activity (or activities).

Advanced process instance manager 610 includes a coordination mechanism for managing process models created by end users (e.g., manually, using specialized software, defined by a script, a set of rules, using code, using a domain specific language, using an interface, or other methods). The FSM may be generated once, and shared and/or reused by process models (e.g., all models or a subset) executed by instance manager 610. The scheduling of execution of phases is performed by BPM engine 602 (e.g., code stored in memory 404 executed by processing unit 406). The definition of how process models are orchestrated is manually defined by end users. Process models may be constructed in a less complex and/or more rapid manner since end users do not need to deal with the low-level implementation of scheduling of phases. The users may focus on higher-level abstract implementations of the process model.

Reference is now made to FIG. 9, which is a schematic representing example values for components discussed with reference to FIG. 6, in accordance with some embodiments of the present invention. Advanced process instance manager 610 reads advanced scheduling strategies (e.g., implemented as a script, a file, code, in a domain specific language, or other implementations) from scheduling strategies table 612 (e.g., stored in storage unit 410, optionally in domain specific rule repository 41 OA). Feedback on which phases are in execution is generated by multi-phase activity manager 606 and received by advanced process instance manager 610. Advanced process instance manager 610 creates a schedule for execution of the next activity(ies) based on an analysis of the state of the executed phases according to the schedule strategies (i.e., set of domain specific rules) for the domain.

Scheduling strategies table 612 has an example entry which defines that when activity A completes execution of phase XI, advanced process instance manager 610 may schedule the execution of phase Rl of activity B, C, and D (for process models with a structure of the form A XOR (B, C, D, ...)).

Scheduling strategies table 612 stores strategies (i.e., domain specific rules) used by advanced process instance manager 610 to improve the performance of BPM engine 602 and/or the execution computing system. The set of rules may be based on interplay between phases to improve performance.

Scheduling strategies table 612 (or other domain specific scheduling rules) provide a level of flexibility to advanced process instance manager 610. Table 612 defines scheduling of new business process activities and respective phases based on the completion of other business process activities phases. Table 612 (or other domain specific sets of rules) improves performance of the BPM engine and/or processing unit and/or executing computing system.

An exemplary strategy (i.e., domain specific rules) termed herein eager execution is described. Eager execution is based on speculative execution where all the outgoing activities of a gateway (e.g., or, and, xor gates) are executed. Eager execution is enabled based on the multiple phase design described herein. In comparison, in single phase BPM engines, the next activity is scheduled for execution only when a current activity (known to the activities execution manager) completes execution. In contrast to the single phase BPM engine, processing unit 406 (which schedules execution of multiple phases) starts execution of all (or selected subset of) outgoing business process activities of the respective gateway. An activity may start execution by starting any (or subset of) of its phases (e.g., the independent phases) according to the domain specific rules stored in scheduling strategies table 612. When the control-flow of the gateway becomes known (e.g., by state events created by the executing phases of the business process activities), the phases of the business process activities that were incorrectly executed are rolled-back or ignored (when they are designated as safe semantics).

An example of the eager execution domain specific rules is described with reference to FIG. 9. An example set of domain specific rules implementing the eager execution strategy (e.g., stored in repository 410A, and/or table 612) includes: For process model: A XOR (B, C, D, ...) do if phase_Xl_completed (A) then

begin

start_phase_Rl (B) AND

start_phase_Rl (C) AND

start_phase_Rl (D) ...

end

When activity A completes phase XI, advanced process instance manager 610 schedules the execution of phase Rl of activity B, C, D, .... for process models with a structure of the form A XOR (B, C, D, ...). When the control-flow of the gateway becomes known, for example, the path leading to activity B, the phases that were executed in the context of C, D, ...will be rolled-back or ignored. Since only the read phases are executed and labeled semantically as safe, the read phases may be simply ignored. When Rl of activity B completes, multi-phase activity manager 606 coordinates the execution of the following phases (i.e., R2, XI, ...). Eager execution executes a business process activity before it is known whether the respective business process activity is needed at all, preventing or reducing a delay (and thereby increasing performance) that would otherwise be incurred by only executing the business process activity after it is known whether data based on the executed business process activity is needed.

Another example of domain specific rules used for creating a new scheduling sequence is termed herein predictive execution. Predictive execution is a form of speculative execution, in which control-flow (i.e., outgoing branches) of a gateway (e.g., or, and, xor gates) is predicted. Execution proceeds along the predicted branch(es) until the actual result of the gateway is received. When the prediction is correct, the predicted activity/phases execution is/are allowed to commit. When there is a misprediction, the activity/phases execution are rolled back and re-executed via the correct branch(es). The prediction of branches may be improved, for example, by using historical data, data mining, and/or branching bits to decide which outgoing branch to follow.

Yet another example of domain specific rules used for creating a new scheduling sequence is termed data prefetching. Data prefetching is a data access latency hiding technique, which may be used to reduce data access time. For example, a phase R2 of a business process activity may be executed preemptively when semantically labeled safe and autonomous. Data fetching brings data closer to the computing processor of phase XI or X2 before the data is requested, which reduces latency.

Reference is now made to FIG. 10, which is a schematic graphically depicting yet another example of domain specific rules for creating a new scheduling sequence termed early output, in accordance with some embodiments of the present invention. Early output enables process instance manager 610 of FIG. 6 (and/or processor 406 of FIG. 4) to create schedules earlier in comparison to single-phase BPM engines where activities are scheduled only when the activities are known to be part of the execution of a process instance. For example, schematic 1002 depicts scheduling without implementing the early output domain specific rules. Business process activity B, C, or D is schedule for execution when activity A completes execution at time tl. Instance manager 610 waits for the completion of business process activity A since activity A is a XOR gateway (i.e., only one outgoing path is followed). In comparison, schematic 1004 depicts scheduling (i.e., creation of a new execution sequence) by implementing the early output domain specific rules. The execution of business process activity B, C, or D is scheduled before completion of activity A. The creation of the new execution sequence may be performed when phase XI from activity A completes at time tl (it is noted that tl < tl).

Optionally, the created execution sequence includes freeing a resource (e.g., database, file, memory location, network communication interface) used by one of the business process activities for another of the business process activities (which is determined to require the resource), while the other business process activity is not fully executed. The resource may be freed before the business process activity started execution, so that when the other business activity beings execution the other business activity process may utilize the resource without having to wait and experience a delay. The multi-phase activities streamline the use of resources by using the resources for shorter periods of time. The resource is locked during the phase in which it is needed (and unlocking the resource when it is not used), in comparison to, for example, single-phase engines which may lock a database transaction from the start of execution of the business process activity until completion of execution of the business process activity.

Optionally, the multiple phases are scheduled according to the new execution sequence for execution, for example, by one of multiple different processors 420 of execution computing system 418, and/or in a distributed manner by multiple computing clusters (e.g., processing units 420) of execution computing system 418. Processors may be selected according to the processing requirements of each phase, which may improve execution performance. The phases may be executed in a distributed system (which may increase computational performance), which may be a heterogeneous distributed system and/or a homogenous distributed system.

Exemplary processors 420 of executing computing system 419 (which may be organized into computing clusters as part of a distributed system, and/or used independently in a non-distributed manner) include one or more of: one or a group of graphics processing unit (GPU) core processors, distributed processing units, and multiple processing units of a multi core processing system.

The created new execution sequence may include phases in a different execution order and/or which may be executed in parallel with other phases, which is different than the received execution sequence of the phases prior to the created new execution sequence (e.g., as received in block 304). Optionally, the created new execution sequence includes a first phase (of phases associated with a certain business process activity) which precedes a second phase (associated with the same certain business process activity) in a respective execution sequence (i.e., as received in block 304, prior to creation of the new sequence) is subsequent to the second phase in the new execution sequence. The rearrangement of the execution schedule of the phases improves performance of the processing unit and/or of the executing computing system.

At 314, resources are allocated for execution of the phase of the business process activities. The resources may be allocated from execution computing system 418, for example, one or more processing units 420, one or more storage units 422, and/or one or more computing clusters (which may be organized to include processing units 420 paired with respective storage units 422). The resource allocation may be performed by computing unit 402, and/or a scheduler computing unit. The resources may be allocated dynamically. The resources may be allocated in a distributed manner, to perform distributed processing of the phases.

Optionally, one or more resources are allocated for execution of a first business process activity while a second business process activity is being executed. The one or more resources may be used by the second business process activity. The allocation of a resource that is currently being used by the second business process activity may be made to the first business process activity according to the created schedule, allowing the first business process to use the resources with a shorter delay (e.g., time to start execution of the first business process activity upon completion of the second business process activity).

The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

It is expected that during the life of a patent maturing from this application many relevant business process activities will be developed and the scope of the term business process activity is intended to include all such new technologies a priori.

As used herein the term "about" refers to ± 10 %.

The terms "comprises", "comprising", "includes", "including", "having" and their conjugates mean "including but not limited to". This term encompasses the terms "consisting of and "consisting essentially of.

The phrase "consisting essentially of means that the composition or method may include additional ingredients and/or steps, but only if the additional ingredients and/or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

As used herein, the singular form "a", "an" and "the" include plural references unless the context clearly dictates otherwise. For example, the term "a compound" or "at least one compound" may include a plurality of compounds, including mixtures thereof.

The word "exemplary" is used herein to mean "serving as an example, instance or illustration". Any embodiment described as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments.

The word "optionally" is used herein to mean "is provided in some embodiments and not provided in other embodiments". Any particular embodiment of the invention may include a plurality of "optional" features unless such features conflict. Throughout this application, various embodiments of this invention may be presented in a range format. It should be understood that the description in range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of the invention. Accordingly, the description of a range should be considered to have specifically disclosed all the possible subranges as well as individual numerical values within that range. For example, description of a range such as from 1 to 6 should be considered to have specifically disclosed subranges such as from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6 etc., as well as individual numbers within that range, for example, 1, 2, 3, 4, 5, and 6. This applies regardless of the breadth of the range.

Whenever a numerical range is indicated herein, it is meant to include any cited numeral (fractional or integral) within the indicated range. The phrases "ranging/ranges between" a first indicate number and a second indicate number and "ranging/ranges from" a first indicate number "to" a second indicate number are used herein interchangeably and are meant to include the first and second indicated numbers and all the fractional and integral numerals therebetween.

It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the invention. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

All publications, patents and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present invention. To the extent that section headings are used, they should not be construed as necessarily limiting.

Claims

1. An apparatus for rescheduling execution of phases of a plurality of activities, comprising:

an interface adapted for designating a plurality of business process activities; a processing unit adapted for:

receiving as an input an execution sequence of a plurality of phases of each one of said plurality of business process activities;

selecting one of a plurality of domains for at least one of said plurality of business process activities according to a semantic analysis of respective said plurality of phases of said at least one business process activity;

selecting a set of domain specific scheduling rules according to said selected domain; and

creating at least one new execution sequence by scheduling said plurality of phases of each one of said plurality of business process activities according to said set of domain specific scheduling rules.

2. A method of rescheduling execution of phases of a plurality of activities, comprising:

receiving a plurality of business process activities;

3. The method of claim 2, further comprising allocating at least one resource for an execution of a first of said plurality of business process activities while a second of said plurality of business process activities being executed; wherein said at least one resource is used by said second business process activity.

4. The method of claim 2 or 3, wherein said creating comprises freeing a resource used by one of said plurality of business process activities for another of said plurality of business process activities while said another of said plurality of business process activities is not fully executed.

5. The method of one of claims 2 to 4, wherein said set of domain specific scheduling rules comprises phase execution heuristics.

6. The method of one of claims 2 to 5, wherein said set of domain specific scheduling rules induces rescheduling of said plurality of phases of one of said plurality of business process activities among themselves and among phases of at least one another of said plurality of business process activities.

7. The method of one of claims 2 to 6, wherein said set of domain specific scheduling rules are acquired from a shared repository by said apparatus and by a plurality of similar apparatuses for rescheduling execution of phases.

8. The method of one of claims 2 to 7, wherein said plurality of phases are scheduled by said at least one new execution sequence to be executed by one of a plurality of different processors.

9. The method of claim 8, wherein said plurality of different processors are selected from a group consisting of a plurality of graphics processing unit (GPU) core processors, a plurality of distributed processing units and a plurality of processing units of a multi core processing system.

10. The method of one of claims 2 to 9, wherein said set of domain specific scheduling rules comprises instructions for distributing a processing of respective said plurality of phases for processing by a plurality of execution resources.

11. The method of one of claims 2 to 10, wherein a first phase of said plurality of phases which precedes a second phase of said plurality of phases in a respective said sequence is subsequent to said second phase in said at least one new execution sequence.

12. The method of one of claims 2 to 11, wherein said semantic analysis is performed based on at least one semantic associated with each phase, the at least one semantic selected from a group consisting of: activity pattern, phase label, and phase property.

13. The method of claim 12, wherein said activity pattern is selected from the group consisting of: read, execution, and write.

14. The method of claim 12 or 13, wherein said phase property is at least one member or a combination of members selected from the group consisting of: safe, unsafe, idempotent, non-idempotent, autonomous, and non-autonomous.

15. The method of one of claims 2 to 14, wherein each one of said plurality of phases is adapted to be executed independently from others of said plurality of phases.