Patent Application
20130226670
Business process engines typically execute business process scripts by instantiating a business process definition and orchestrating the execution of each activity contained within the business process. Execution involves marshalling and linking inputs and outputs of the different activities. A business process engine is usually centralized, but the execution of activities can be distributed. Alternatively, multiple business process engines interact to execute collaborating business processes, but each business process must be defined manually as separate business process scripts.
This disclosure is not limited to the particular systems, methodologies or protocols described, as these may vary. The terminology used in this description is for the purpose of describing the particular versions or embodiments only, and is not intended to limit the scope.
As used in this document, the singular forms “a,” “an,” and “the” include plural reference unless the context clearly dictates otherwise. Unless defined otherwise, all technical and scientific terms used herein have the same meanings as commonly understood by one of ordinary skill in the art. All publications mentioned in this document are incorporated by reference. All sizes recited in this document are by way of example only, and the invention is not limited to structures having the specific sizes or dimensions recited below. Nothing in this document is to be construed as an admission that the embodiments described in this document are not entitled to antedate such disclosure by virtue of prior invention. As used herein, the term “comprising” means “including, but not limited to.”
In an embodiment, a method of implementing a business process may include receiving business process information associated with a business process. The business process information may include a graph representing one or more activities to be performed to complete the business process. The method may include identifying, by a computing device, a number of groups associated with the business process information. Each group may be capable of performing at least a portion of the activities. The method may include partitioning, by the computing device, the graph into a number of fragments that is greater than or equal to the number of identified groups. Each fragment may include one or more activities from the graph. The method may include, for each fragment, transmitting the fragment to an identified group that is capable of performing each activity associated with the fragment, and orchestrating the performance of the activities associated with each fragment by each group.
A system for implementing a business process may include a computing device and a computer-readable storage medium in communication with the computing device. The computer-readable storage medium may include one or more programming instructions that, when executed, cause the computing device to receive business process information associated with a business process. The business process information may include a graph representing one or more activities to be performed to complete the business process. The computer-readable storage medium may include one or more programming instructions that, when executed, cause the computing device to identify a number of groups associated with the business process information. Each group may be capable of performing at least a portion of the activities. The computer-readable storage medium may include one or more programming instructions that, when executed, cause the computing device to partition the graph into a number of fragments that is greater than or equal to the number of identified groups. Each fragment may include one or more activities from the graph. The computer-readable storage medium may include one or more programming instructions that, when executed, cause the computing device to, for each fragment, transmit the fragment to an identified group that is capable of performing each activity associated with the fragment, and orchestrate the performance of the activities associated with each fragment by each group.
Aspects, features, benefits and advantages of the present invention will be apparent with regard to the following description and accompanying drawings, of which:
The following terms shall have, for purposes of this application, the respective meanings set forth below:
An “activity” is a task that is part of a business process. Examples of activities in a print production environment may include printing, scanning, copying and the like.
A “business process” is a collection of activities or tasks that produce a specific service or product. A business process may be represented by a graph or other workflow. An example of a business process may include document management activities such as printing, binding, scanning, copying and the like.
A “fragment” is a portion of a business process. For example, a fragment may pertain to a portion of a graph representing a business process.
A “group” is a context for the execution of at least a portion of a business process. A group may include an entity, a department within an organization, a business process engine, a service provider and/or the like.
A “module” is a component of a larger system, such as a business process system. A module may include software, hardware or a combination of hardware and software.
To “orchestrate” means to coordinate one or more activities of one or more fragments of a business process.
To “partition” means to divide, separate or otherwise apportion one or more business processes into one or more fragments.
In an embodiment, an assignment module may receive 105 business process information 220. For example, an assignment module may receive 105 information from a computing device, a print device or other similar device. Business process information 220 may include a workflow associated with a business process, a graph representation of a workflow, information about one or more tasks or activities of the business process and/or the like. In an embodiment, business process information 220 may be included in a file, a script or another electronic format. For example, business process information 220 may be included in an XML file. Additional and/or alternate formats may be used within the scope of this disclosure.
In an embodiment, an assignment module may be in communication with a storage medium 225, such as a database or other computer-readable storage medium. The assignment module may be configured to store at least a portion of the received business process information 220 in the storage medium 225.
In an embodiment, the assignment module may identify 110 one or more groups associated with business process information. In an embodiment, certain activities of a business process may be performable by a single group. For example, scanning and printing may be performable by a single group. In an embodiment, hardware, software and/or a combination of hardware and software may be used by a group to process at least a portion of a business process.
In an embodiment, the assignment module may identify 115 a group identifier associated with each identified group. A group identifier may be a unique identifier associated with a group. In an embodiment, the assignment module may retrieve one or more group identifiers from its associated storage medium 225. In an embodiment, the assignment module may retrieve one or more group identifiers from another storage medium.
In an embodiment, the assignment module may transmit 120 the business process information and associated group identifiers to the division module. In an embodiment, the division module may partition 125 the business process into a plurality of fragments. Each fragment may be associated with a group. In an embodiment, a business process may be partitioned 125 into a number of fragments greater than or equal to a number of groups. In an embodiment, the division module may transmit 130 the plurality of fragments and the corresponding group identifiers to a meta-orchestration module. The meta-orchestration module may coordinate distribution of the fragments to their corresponding group. Table 1 illustrates examples of fragments and corresponding group identifiers according to an embodiment.
In an embodiment, the meta-orchestration module may transmit 135 a fragment to its corresponding group. For example, as illustrated in Table 1, the meta-orchestration module may transmit 135 Fragment I to Group 1. Additional and/or alternate fragments, number of fragments, groups, number of groups and/or the like may be used within the scope of this disclosure.
In an embodiment, a group may include an orchestrator module 230a-n. An orchestrator module 230a-n may receive a fragment from the meta-orchestration module. In an embodiment, the orchestrator module for a group may instantiate 140 the portion of the business process described in the fragment. In an embodiment, the fragment having a start event that corresponds to the pre-division start event may proceed with its activities automatically. Other fragments may need to wait for a message or other input before beginning their activities. When an orchestration module encounters a message throw event, the orchestration module may use an attribute corresponding to the fragment to identify the group to which the payload of the message should be passed.
In an embodiment, a payload is one or more variables associated with a business process. In an embodiment, a payload may include one or more global process attributes. The global process attributes may be the same and/or similar to the attributes associated with the issuing fragment. In an embodiment, a payload may include data that is dependent on the type of the associated message. For example, payload data may differ depending on whether an associated message is an activity call message, an indicator message or a merge message.
In an embodiment, a fragment may not access all global process attributes associated with a payload. In an embodiment, not all objects generated by a fragment may be accessed by downstream fragments. As such, the size of a payload included in a message may be reduced in certain circumstances.
In an embodiment, a fragment graph data structure may be used. A fragment graph may be created by the meta-orchestration module when the meta-orchestration module distributes fragments to groups. The orchestration module for each group may receive a copy of the fragment graph from the meta-orchestration module. In an embodiment, the orchestration module for each group may store a copy of the fragment graph.
In an embodiment, the fragment graph may be a directed graph G(V,E), where V is the set of fragments. In an embodiment, E may be constructed as follows. If a fragment has a message throw event then for each fragment with a message catch event, cij, intended to be the recipient, an edge (fragment(mi), fragment (cij)) may be added to E.
In an embodiment, the global attributes to add to a payload may be determined. In an embodiment, when a message throw event is going to be generated, a depth-first search may be started on the fragment graph using the fragment where the message throw event originates as a starting vertex for the search. The search criteria may include write access to an attribute by a fragment. Write access may be determined using a tag or other information associated with the business process definition for each fragment. For example, write access may be determined using the ioSpecification tag of the Business Process Modeling Notation (BPMN) for each fragment. BPMN is a graphical representation for defining a business process.
In an embodiment, when the search determines that there is downstream access to an attribute, the attribute may be added to the payload. In an embodiment, the depth-first search may be aborted if all attributes have been added to the payload. In an embodiment, the orchestration module for a group may notify the meta-orchestration module of one or more objects and/or process attributes that are not passed downstream. As such, the meta orchestration module may be able to retrieve required data from the appropriate location when all fragments have reached their respective end events. In an embodiment, determining which data objects to add to a payload may be accomplished using a similar method to that described above.
In an embodiment, a BPMN element may be parameterized by attributes, which may be denoted by angle brackets, and referenced programmatically with object attribute notation. In an embodiment, a BPMN element may have a category attribute, which may be denoted by <category>. A category attribute may correspond to the element type of the BPMN element. For example, as illustrated in
In an embodiment, a BPMN element may be associated with one or more outbound attributes which may reference sequences or data flows that may serve as a connector to another BPMN element. In an embodiment, an outbound attribute may be denoted by <next_i>.
In an embodiment, a BPMN element may be a construct of one or more individual elements. Like an element, a construct may be parameterized by attributes. For example,
In an embodiment, specialized message types may be used to partition a business process definition. An activity call message, an indicator message and a merge message may be examples of specialized messages that may be used. In an embodiment, an activity message may represent an activity that does not belong to a group of a current fragment. An activity call message may include the activity name and parameters necessary to call the corresponding activity, as defined by the original business process definition.
In an embodiment, an indicator message may represent a choice that results from an exclusive conditional branch gateway. An indicator message may include the branch name and a condition corresponding to the path taken after the gateway.
In an embodiment, a merge message may represent a join gateway that is contained in a different fragment. A merge message may include a merge identifier and output of the previous activity or flow.
In an embodiment, a partitioning algorithm may use one or more specialized data structures. In an embodiment, a specialized data structure may include a search context. A search context may be described by the following:
In an embodiment, a specialized data structure may include a merge table. In an embodiment, each entry in a merge table may include the following:
In an embodiment, two global structures may be maintained: a set of search contexts, each of which may represent a depth-first search from a different starting point in a business process definition graph, and an initially empty merge table. In an embodiment, a search context may be initialized 500 for each start event in a business process definition. In an embodiment, a depth-first search may be conducted 502 for each active search context. In an embodiment, one or more nodes from the business process definition may be copied 504 into an output fragment.
In an embodiment, different actions may be performed depending on the category of each node that is encountered in a search. In an embodiment, if an exclusive branch gateway is encountered 506, the branch may be stored 508 in the current search context, and a new branch indicator may be created 510 in the output fragment for each outgoing path from the branch. The message of the branch indicator may correspond to the branch name and condition of the path. This condition may be stored 512 in a condition_true attribute of the stored gateway.
In an embodiment, a merge or join gateway may be encountered 514. If the gateway does not exist in the merge table 516, a new merge table entry with a reference to the gateway may be created 518, and the corresponding gateway may be created 520 in the output fragment. In an embodiment, if a gateway already exists in the merge table 522, meaning that the gateway has already been traversed, then a corresponding output gateway may be retrieved 524 from the merge table. In an embodiment, the output gateway may be connected 526 directly to the output fragment if it is in the same group. In an embodiment, a merge message may be created 528 and a corresponding send event may be connected 529 to the output fragment of the current search context. In an embodiment, a catch event for the merge message may be connected with an incoming edge to the output gateway retrieved from the merge table. In an embodiment, a depth-first search may not continue downstream from a merge that has already been traversed. If the join is for an exclusive branch, it may be removed from the search context branch stack.
In an embodiment, an activity node may be encountered 530. If the group of the activity node is the same as the group of the current search context 532, the activity may be copied 534 to the output fragment and the depth-first search may continue. In an embodiment, if the group of the activity node is different than the group of the current search context 536, a send event with an activity call message may be created 537 in the output fragment with the activity name and group destination. A new search context may be created 538 starting with the activity for the new group. In an embodiment, the branch stack and condition path may be copied 540 to the new search context before the new search context is stored in the context set.
In an embodiment, when a depth-first search for each context finishes, the partitioning method may start analyzing 542 a new search context in the context set. In an embodiment, the partitioning method may terminate 544 if the context set is empty. For each new search context that is started, a new output fragment may be initialized 546. In an embodiment, if the branch stack of the search context is empty 548, a receive start event may be connected 550 to the first activity in the depth-first search stack (DFS stack). The message of the start event may correspond to the activity call message for that activity. In an embodiment, if the branch stack is not empty 552, then the output fragment may start 554 with a conditional start where the active path message corresponds to the first activity in the DFS stack. In an embodiment, each of the terminate indicator messages may correspond to the conditions of the branches in the branch stack that do not match the current path true condition. In an embodiment, an end join may be created 556 for the output fragment. The end join may be used as a sink for all finished branches.
In an embodiment, a partitioning method may be represented as follows:
The example business process depicted in
A controller 820 interfaces with one or more optional memory devices 825 to the system bus 800. These memory devices 825 may include, for example, an external or internal DVD drive, a CD ROM drive, a hard drive, flash memory, a USB drive or the like. As indicated previously, these various drives and controllers are optional devices.
Program instructions may be stored in the ROM 810 and/or the RAM 815. Optionally, program instructions may be stored on a tangible computer readable storage medium such as a hard disk, compact disk, a digital disk, flash memory, a memory card, a USB drive, an optical disc storage medium, such as Blu-ray™ disc, and/or other recording medium.
An optional display interface 830 may permit information from the bus 800 to be displayed on the display 835 in audio, visual, graphic or alphanumeric format. Communication with external devices may occur using various communication ports 840. A communication port 840 may be attached to a communications network, such as the Internet or an intranet.
The hardware may also include an interface 845 which allows for receipt of data from input devices such as a keyboard 850 or other input device 855 such as a mouse, a joystick, a touch screen, a remote control, a pointing device, a video input device and/or an audio input device.
An embedded system, such as a sub-system within a xerographic apparatus, may optionally be used to perform one, some or all of the operations described herein. Likewise, a multiprocessor system may optionally be used to perform one, some or all of the operations described herein.
It will be appreciated that various of the above-disclosed and other features and functions, or alternatives thereof, may be desirably combined into many other different systems or applications. Also that various presently unforeseen or unanticipated alternatives, modifications, variations or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims.
