Patent Grant
9015648
Business processes designed by business analysts are generally implemented as part of applications or information technology (IT) systems by IT developers. For example, business processes may be designed using business process modeling notation (BPMN), and corresponding IT applications can be implemented using business process execution language (BPEL).
In typical operations, the business processes being designed (e.g., BPMN models), as well as the corresponding executable IT implementations (e.g., BPEL models) may undergo several iterations. During the course of such iterations, the models may undergo continuous changes over independent model lifecycles from the business process side and/or the IT developer side. As a result, the models may not always fully correspond, and can become out of synchronization.
In one embodiment, a method of performing a merge operation can include: mapping a BPMN model to a BPEL model; modifying the BPMN model to form a modified BPMN model; modifying the BPEL model to form a modified BPEL model; when the merge operation is a forward merge operation: exporting the modified BPMN model to an exported BPEL model; performing an activity level outline merge for added IT scopes and branches from the modified BPEL model; performing an activity level detail merge for added IT details from the modified BPEL model; and performing an attribute level merge for updated branch conditions in the merged BPEL model; and when the merge operation is a reverse merge operation, adding scopes and branches from the modified BPEL model to the BPMN model.
A further understanding of the nature and the advantages of particular embodiments disclosed herein may be realized by reference of the remaining portions of the specification and the attached drawings.
Business Process Modeling Notation (BPMN) is a standardized graphical notation for drawing business processes in a workflow. BPMN was developed by the Business Process Management Initiative (BPMI), and is now being maintained by the Object Management Group. The primary goal of BPMN is to provide a standard notation that is readily understandable by business stakeholders. These business stakeholders include the business analysts who create and refine the processes, the technical developers responsible for implementing the processes, and the business managers who monitor and manage the processes. Consequently, BPMN is intended to serve as common language to bridge the communication gap that frequently occurs between business process design and implementation.
Currently, there are many business process modeling languages, tools and methodologies. The adoption of the BPMN standard notation helps to unify the expression of basic business process concepts (e.g., public and private processes, choreographies, etc.), as well as advanced modeling concepts (e.g., exception handling, transaction compensation, etc.). Thus, BPMN can be thought of as defining the “what” and the “when” of business processes.
As defined in the abstract of the Web Services Business Process Execution Language OASIS Standard WS-BPEL 2.0, WS-BPEL (or “BPEL” for short) is a language for specifying business process behavior, e.g., based on web services. Processes in BPEL can export and import functionality by using web service interfaces. BPEL may also include both extensible markup language (XML) and graphical formats or representations, which provide visual images of XML “snippets.”
BPEL provides a language for the specification of both executable (e.g., via XML) and abstract business processes. By doing so, it extends the web services interaction model and enables it to support business transactions. BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces. Thus, BPEL can be thought of as defining the “how” of business processes. Examples of graphical representations of BPMN and BPEL models are shown below in
Due to the above reason BPMN and BPEL are often used in conjunction for business process definition and implementation, respectively. Under such a situation, though the mapping of the BPMN activities to BPEL might be somewhat straightforward, intelligently translating changes from one model (e.g., a BPMN model) to its counterpart (e.g., a BPEL model) so as to maintain these models in sync is a difficult task. Doing the same without losing information makes the task even more challenging.
Traditional business process modeling and/or execution systems may not seamlessly translate changes from one model representation (say BPMN) to a different model representation (say BPEL). Thus, a lack of synchronization may come to exist between the business process (e.g., BPMN model), and its corresponding executable information technology (IT) process (e.g., BPEL model). As used herein, a business user may be someone who defines the “what” and the “when” of business processes, such as by defining a business flow outline using BPMN. Also, an IT user may be someone who defines the “how” of a business process by implementing the business flow (e.g., using BPEL).
Particular embodiments allow close collaboration between the business users who define the Business Process Outline and IT users who provide the business process implementation, to accommodate software and/or routines that solve business problems. Particular embodiments support a “forward” merge, such as where changes are propagated from a BPMN model to a BPEL model, as well as a “reverse” merge where changes are propagated from a BPEL model to a BPMN model. In this fashion, an intelligent merging of such models accommodates synchronization between the business process and corresponding IT development.
Referring now to
Similarly, a forward merge application 108 may be loaded on computer 102-1 for an IT user. This allows the IT user (e.g., at computer 102-1) to see corresponding updates in the BPEL model that result from changes in the business process BPMN model made by business user (e.g., at computer 102-0). Computers 102-0 and 102-1 may also communicate via a network 104 (e.g., the Internet, a virtual private network (VPN), a wide area network (WAN), a local area network (LAN), etc.). Computers 102 can include any type of computing device (e.g., a portable computing device, a laptop, a personal computer (PC), etc.).
Referring now to
For example, modifications can be made to the BFO (e.g., by a business user), as well as to the BFI (e.g., by an IT user). Thus, a new version (version 1) of the BPMN model can be formed as BFO modified BPMN model (version 1) 206, which can also be mapped to a corresponding exported BPEL model (version 1) 208. On the IT user side, exported BPEL model (version 1) 204 can be modified to form BFI modified BPEL model (version 2) 210.
In a forward merge operation, changes made to a business flow outline can be merged into a business flow implementation. For example, exported BPEL model (version 1) 208 and BFI modified BPEL model (version 2) 210 can be merged to form forward merged BPEL model 212 (version 3). In a reverse merge operation (see dashed boxes 214 and 216), changes made to a business flow implementation can be merged into a business flow outline. For example, BFO modified BPMN model (version 1) 206 and BFI modified BPEL model (version 2) 210, as converted to BFI modified BPMN model (v2) 216, can be merged to form reverse merged BPMN model 214 (version 3).
Referring now to
A flag, blueprint, or other suitable indication, can convey that BPMN model 302 is ready for conversion or mapping to exported BPEL model 310 such that IT developers can implement executable code therefrom. Any suitable rules for mapping or exporting from BPMN to BPEL can be used in particular embodiments. As shown in the particular example of
The exported BPEL model 310 is an example graphical representation (e.g., using the JDeveloper tool, provided by Oracle Corporation) of one or more XML snippets, which is the underlying executable language. For example, an XML snippet corresponding to exported BPEL model 310 is shown below in Table 1:
Similarly, the modified BPEL model 308 is also a graphical representation of one or more XML snippets constituting the BPEL model. For example, an XML snippet corresponding to the modified BPEL model 308 is shown below in Table 2:
In a forward merge operation, BPMN model changes may be merged or propagated into the corresponding IT process blueprint or model (e.g., BPEL) in a substantially lossless fashion. In one example, each BPMN activity may be mapped to a corresponding BPEL “scope” or a logical collection of activities. Further, each BPMN activity may be uniquely identified by an identifier, and any changes to such activities can be captured via a timestamp or last update date. In addition, because a business user owns the process outline (e.g., BPMN model), an IT user may not typically delete activities in the outline of the business user. Instead, the IT user may make modifications by: (i) adding new BPEL or IT scopes between existing BPEL scopes representing process activities; and/or (ii) adding branches to existing switches and flows. Examples of these types of modifications will be shown below.
Referring now to
As will be discussed in more detail below, an activity level forward merge may be accomplished by performing an outline merge followed by a detail merge. A resulting forward merged BPEL model 402 can include added activity 304-A1 from an IT user, as well as activity 304-Z from a business user. As shown, activity 304-A1 can be anchored to previous activity 304-A, and activity 304-Z can be anchored to activity 304-B. Details of such an anchoring procedure will be discussed in more detail below. Further, while forward merged BPEL model 402 is shown as separate from exported BPEL model 404, the merge operations can alternatively be performed directly on the exported BPEL model 404.
While forward merged BPEL model 402 is shown as an example graphical representation of one or more XML snippets representing the BPEL model, an XML snippet corresponding to the forward merged BPEL model 402 is shown below in Table 3:
In performing the merge, two Hash Maps may be constructed. A Hash Map is a data structure, which is often used to store key-value pairs, where every value is uniquely identified using the hash code of its key. This makes it very easy and less time consuming to retrieve the value, provided the key is known. In particular embodiments, Hash Maps can be used to reference BPEL model Objects using their ids as the key. One such hash map may be created for the BPEL model generated from the BPMN model (e.g., exported BPEL model 404), and another hash map may be generated for the BPEL implementation model (e.g., modified BPEL model 308) available via an IT user. Each of these hash maps can map unique identifiers of each activity in a model with the activity itself and help in accomplishing activity level forward merge.
Referring now to
During the forward merge, the business process outline from the exported BPEL model is copied to the merged BPEL model. For gateways or switches existing in the business process outline, branches that have been added as part of implementation details may be added from the implementation model (e.g., modified BPEL model 508). For branches available as part of an outline generated from the BPMN process (e.g., exported BPEL model 504), the conditions are merged, and contents within the branches can be recursively merged. A forward merged BPEL model 502 can thus include activity 304-EL as part of a new branch from switch 506, as shown. Details regarding the merging of the conditions are discussed as part of attribute level merge described later on.
While modified BPEL model 508 represents an example graphical representation of one or more XML snippets representing the BPEL model, an XML snippet corresponding to modified BPEL model 508 is shown below in Table 4:
While forward merged BPEL model 502 is shown as an example graphical representation of the XML snippets representing the BPEL model, an XML snippet corresponding to forward merged BPEL model 502 is shown below in Table 5:
Referring now to
Referring now to
For example, IT scopes in a BPEL model may be mapped to automated activities, human activities, or any suitable type of activity, in a BPMN process. A reverse merge may include an outline merge operation whereby the IT scopes are added to the BPMN process model by anchoring the IT scopes to a previous activity or next activity (if the previous activity is not available), in that order. In the event that neither of the previous or the next activity are available, subsequent previous and next activities are used. For switches and flows, any IT added branches may then be added to the BPMN process model. Anchoring may be done using unique identifiers for activities.
In a reverse merge operation, there may be no need to do an attribute level merge, as may be performed with reference to forward merge operations. This is because a business user typically does not have the level of details that an IT user sees. In this fashion, only the activity level changes made to an IT process model are taken and propagated as changes in the BPMN model.
Reverse merge operations in particular embodiments may utilize an executable model (e.g., a BPEL model) to construct a hash map that contains the IT detail activities, along with the identifiers of their previous and next activities, if any. Each such activity may be recursively tagged to a previous or next activity in the business process model using the identifiers. In the case of new branches added to gateways or switches in the executable BPEL model, a previous identifier may be considered null, and a next identifier can be a next branch in the gateway.
As part of ensuring correctness and avoiding inconsistent states during the process lifecycle and merge operation, once a reverse merge is performed, further export, synchronization or upload operations may be halted until the business process outline changes effected by the merge are accepted or rejected.
If a forward merge operation (704) is to be performed, the forward merge can include an activity level merge and an attribute level merge. Further, the activity level merge can include an outline merge and a detail merge. A BPMN model may be exported or converted into a BPEL in order to provide common ground for comparison (706). An outline of the exported BPEL model can then be copied to the merged BPEL model (718). Next, an outline merge can be performed to add new IT scopes and branches from the modified BPEL model to the merged BPEL model (708). Next, a detailed merge can be performed to add IT details from the modified BPEL model to the merged BPEL model (710). An attribute level merge can then be performed to update branch conditions as well as some of task attributes in the merged BPEL model (712), completing the flow (714).
Referring now to
For switches and flows found in a search in the modified BPEL model (814), any IT added branches can be added to the appropriate switch (816) or flow in the merged BPEL model. If there are additional scopes and/or branches (818), the flow can return to searching for an IT scope (806). However, if no further scopes or branches remain (818) in the modified, previously generated, BPEL model, the flow can complete (820). In this fashion, the outline of the process is taken from the business process model and any IT detail activities and branches added by the IT user may be included in the process outline by either tagging the activity/branch to a preceding or succeeding activity available in the business process model. An outline at the implementation level can thus include scopes and gateways.
Once the outline level merge has been completed, a detail level merge can be performed. In the detail level merge, a determination is made for each activity to see if the exported BPEL model (from the business user) has been changed more recently than the modified BPEL model (from the IT user). This may be done by matching the activities in the exported BPEL model and the modified BPEL model by relating the identifiers in the previously constructed Hash Maps, as discussed above, and comparing their timestamps. If the business user has made the more recent change to a given activity, details of the activity from the modified BPEL model (which applied to a previous activity version) are not included in the merged BPEL model. In this case, the activity is retained in the merged BPEL model as in the exported BPEL model such that the most recent change to the business outline made by the Business user is reflected in the merged BPEL model, thus providing the IT user with the latest change. However, if the activity timestamps match, indicating that the business user has not updated a particular activity, the activity details (which still apply since the activity has not changed) from the modified BPEL model can be added to the appropriate scope in the merged BPEL mode. The rationale for the above logic being the fact that the business user changes to the process outline generally take precedence over the IT user changes.
Referring now to
If the timestamp from a scope in the exported BPEL model is less than or equal to a timestamp from a corresponding scope in the modified BPEL model (912), indicating that a last update by the business user has not changed the timestamp (no changes made to that particular activity), details of the scope from the modified BPEL process model can be added into the same scope in the merged BPEL process model (914), thus completing the flow (916). However, if the timestamp from the scope in the exported BPEL model is greater than a timestamp from a corresponding scope in the modified BPEL model (912), indicating that a last update by the business user has in fact made changes to that particular activity, the scope from the modified BPEL model (IT user side) may be ignored and instead the corresponding scope from the exported BPEL model is included in the forward merged BPEL model (918).
Thus for a detail level merge, an outline may already exist. The modified BPEL model may be traversed to see if there is a same unique identifier, and check to see if timestamp has changed, as compared with the timestamp of a corresponding scope of the exported BPEL process. As discussed above, if there has been a timestamp change, then the updated version from the business side can be included in the merged model. If the timestamp has not changed, details in the scope may be considered to see if anything has been changed therein. Each scope is a container for a set of activities, and/or may contain other lower scope levels therein. The algorithm in particular embodiments can be programmed to stop the merge detail at any such level. For example, a scope can contain two or more scopes. If the top-level scope has changed, a flow can proceed in top-down fashion to determine if a lower level scope within the top level scope has changed. Further, in addition to timestamps for determining last updates, other approaches can also be used (e.g., sequence numbers, flags, etc.).
Referring now to
An exported BPEL model (e.g., from the business user) can have the condition expression attribute specified by the business user: (i) as part of the normal process flow, which can be modified by the IT user during his implementation; and (ii) as part of annotations on the branches of the switch which may not be modified by the IT user. Annotations are extensions to the BPEL XML snippets specifically used for storing attribute values. During a time when a forward merge operation is performed, a comparison can be made of the business user's branch condition in an exported BPEL model to the previous business user's branch condition, which is stored as an annotation in the modified BPEL model. A comparison of these conditions can be made in automated fashion. An example of such an XML annotation is shown below in Table 6:
In
Particular embodiments can provide substantially no loss of process related data during merging, and this includes information specified by a business user and executable artifacts and/or information added by an IT user. Further, a business user may be assigned as owner of the process outline and high level process related data, while an IT user is assigned precedence over implementation details.
Particular embodiments support forward merging whereby model information may be translated to an IT implementation, but the implementation details specified by an IT user may also be reverse merged into the business process model. Particular embodiments may provide intelligent integration of a business process model to an executable counterpart thus allowing for seamless round tripping and substantially lossless translation of information (e.g., activities, attributes, etc.) from one to the other.
Although the description has been described with respect to particular embodiments thereof, these particular embodiments are merely illustrative, and not restrictive.
Any suitable programming language can be used to implement the routines of particular embodiments including C, C++, Java, assembly language, etc. Different programming techniques can be employed such as procedural or object oriented. The routines can execute on a single processing device or multiple processors. Although the steps, operations, or computations may be presented in a specific order, this order may be changed in different particular embodiments. In some particular embodiments, multiple steps shown as sequential in this specification can be performed at the same time.
Particular embodiments may be implemented in a computer-readable storage medium for use by or in connection with the instruction execution system, apparatus, system, or device. Particular embodiments can be implemented in the form of control logic in software or hardware or a combination of both. The control logic, when executed by one or more processors, may be operable to perform that which is described in particular embodiments.
Particular embodiments may be implemented by using a programmed general purpose digital computer, by using application specific integrated circuits, programmable logic devices, field programmable gate arrays, optical, chemical, biological, quantum or nanoengineered systems, components and mechanisms may be used. In general, the functions of particular embodiments can be achieved by any means as is known in the art. Distributed, networked systems, components, and/or circuits can be used. Communication, or transfer, of data may be wired, wireless, or by any other means.
It will also be appreciated that one or more of the elements depicted in the drawings/figures can also be implemented in a more separated or integrated manner, or even removed or rendered as inoperable in certain cases, as is useful in accordance with a particular application. It is also within the spirit and scope to implement a program or code that can be stored in a machine-readable medium to permit a computer to perform any of the methods described above.
As used in the description herein and throughout the claims that follow, “a”, “an”, and “the” includes plural references unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
Thus, while particular embodiments have been described herein, latitudes of modification, various changes, and substitutions are intended in the foregoing disclosures, and it will be appreciated that in some instances some features of particular embodiments will be employed without a corresponding use of other features without departing from the scope and spirit as set forth. Therefore, many modifications may be made to adapt a particular situation or material to the essential scope and spirit.
| Number | Name | Date | Kind |
|---|---|---|---|
| 7209933 | Saxena | Apr 2007 | B2 |
| 20050209993 | Koehler | Sep 2005 | A1 |
| 20070073567 | Challapalli | Mar 2007 | A1 |
| 20070162486 | Brueggemann et al. | Jul 2007 | A1 |
| 20080052384 | Marl et al. | Feb 2008 | A1 |
| 20080301684 | Barros et al. | Dec 2008 | A1 |
| 20090089078 | Bursey | Apr 2009 | A1 |
| 20090133019 | Dumas et al. | May 2009 | A1 |
| 20090265684 | Fuchs et al. | Oct 2009 | A1 |
| 20090327199 | Weber et al. | Dec 2009 | A1 |
| Entry |
|---|
| Recker, Jan and Mendling, Jan. “On the Translation between BPMN and BPEL: Conceptual Mismatch between Process Modeling Languages”. Technical Report, QUT ePrints, ID Code—4637, Jul. 2006. pp. 1-12. |
| Bridging the Gap Between Business & IT With BPMN & BPEL, obtained at http://soa.sys-con.com/node/492520, Retrieved Sep. 4, 2008. |
| Things BPMN—Vishal's BPM Corner, obtained at http://vishals.blogspot.com/, Retrieved Aug. 28, 2008, last updated Aug. 12, 2008. |
| Number | Date | Country | |
|---|---|---|---|
| 20100057482 A1 | Mar 2010 | US |
