GB2492440A - Migrating business process instances having compensation logic - Google Patents

Abstract

An improved method of migrating business process instances derived from business process models (2, 3) having compensation logic is disclosed. The method comprises determining if a corresponding business process instance derived from a business process model (2, 3) is applicable for migration, by statically analyzing an underlying business process model (2, 3) to create a static process control flow, deriving potential compensation control flows, identifying changes between the new business process version and a previous business process version and then walking the identified changes for separating and grouping changes related to compensation logic (200,210,211,212) and changes related to normal control flow (100,110,111,112) of the business process model (2, 3) into change groups. The business process instance is then migrated based on migration conditions which are determined based on the change groups.

Description

MIGRATING BUSINESS PROCESS INSTANCES

DESCRIPTION

S Technical Field

The present invention relates in general to the field of Business Process Management Systems (BPMS) and/or Workflow Management Systems, and in particular to a method of migrating business process instances and a system of migrating business process instances. Still more particularly, the present invention relates to a data processing program and a computer program product for migrating busincss process instances.

Background Art

In a Business Process Management System (BPMS), a business process template may be perceived as a graph which represents the ordering of the steps and/or activities involved in a business process, together with a description of other properties. Every time a business case is initiated, a new instance of the business process is created, based on the underlying business process model. Since business process instances are often long-running in nature, it becomes evident that changes might be required to the process model, resulting in a new model. This might impact instances still in flight that were created based on the original associated process model. The reasons for such changes are varied, for example, emerging business opportunities, changing market conditions or new government regulations might force a company to adjust the process model.

The issue of migrating process instances that were started on the original version of the process model, whcn the process model evolved, exists and has been (partially) solved in

prior art.

However, in today's world, business processes can only be migrated if the business process does not contain any compensation logic. Compensation can be seen as an "undoing action", e.g. when an activity of the process has charged a credit card and fails subsequently to deliver the order, compensation should take care of refimding the money, i.e. undoing the credit card charge. More precisely, compensation is some kind of logic that gets executed when a state is rcachcd in a process that is dccmed to be undcsirablc. The compensation logic is also executed if an unforeseen error occurred. Errors of such nature are normally caused by malfunctions of the underlying infrastructure. In such cases it becomes necessary to perform some explicit compensation steps in the business process to assure that a consistent state is reached. The goal is not always to return to a previous condition, but instead it is to maintain a balanced and consistent state for the process. As such, compensation logic is usually not modeled as part of the regular control flow of a business process, but rather as a "compensation flow" that only gets entered under certain (error) conditions.

Obviously, it would be very usefiui to support process instance migration for such processes, too. In order to show why this is not possible today, it is first shown how it is decided today whether an instance can be migrated or not.

Referring to FIG. 2 to 5, a prior art approach of migrating business process instances is described. FIG. 2 shows a process A that consists of a linear sequence of four activities Al, A2, A3, A4 that we call original process model A. FIG. 3 shows the evolved process model A' in which the activities AS, A6 and A7 and their corresponding links have been inserted. The delta between process A and process A' is calculated and grouped into one or more so-called "Change Groups". A Change Group is a set of activities that marks the boundaries of a change region, in the shown example, the region after activity Al and before activity A4 in FIG. 3 is affected by the change. FIG. 4 shows an instance I that has been based on the process A shown in FIG. 2 and stands at activity Al, and FIG. S shows an instance I' that has been bascd on the process A shown in FIG. 2 and stands at activity A3. This illustrates how a check whcthcr an instance I, I' can be migrated or not can be implemented. For thc implcmentation a changc group CG or changc rcgion and a so-called wavcfront W is used.

The wavefront W is a set of activities that represent "the present position" of the process instance 1, 1', i.e. the point of migration'. However, since business processes are parallel in nature, the point of migration' is not necessarily a singular point, but is rather determined by the wavefront W. In the examples shown in FIG. 4 and 5, the wave-front W consists of activity Al in FIG. 4, or A3 in FIG. 5, respectively. The criterion to decide whether a given change group CG is compliant with the corresponding instance I, I' is that the wavefront W must not intersect the change group CG. In the example, the instance I shown in FIG. 4 would be migrateable, because it is not intersecting the change group CG, and the instance I' shown in FIG. 5 would not be migrateable, because it is intersecting the change group CG.

Coming back to compensation, it becomes obvious that it is difficult to dccidc whether an instance can be migrated or not, because the check whether an instance can be migrated or not is performcd statically on a proccss template, and compensation logic usually results in a derivation from thc predefined control flow, making a static check more or less useless.

In the Patent Application Publication US 2010/0121668 Al "AUTOMATED COMPLIANCE CI-IECKTNG FOR PROCESS INSTANCE MIGRATION" by Hohmann, a business process workflow editorial data processing system is disclosed. The disclosed system can include a workflow management system such as a process editing tool and a repository of templates each template defining a process. At least two of the templates can include a new template and an existing template for an executing instance of a business process. The system also can include compliance checking logic coupled to the workflow management system. The logic can include program code enabled to derive a log of changes between the new template and the existing template based upon added and removed activities and links between activities in the executing process instance, to group the changes in the log according to common activities, to determine a wavefront for the executing process instance, and to migrate the executing process instance to the new template only if the wavefront does not cross any of the groups of the changes, but otherwise rejecting a migration of the process instance to the new template. The disclosed system covers the analysis and compliance check for business processes which do not contain compensation logic.

Existing approaches in the area of instance migration cannot deal with process instances which contain compensation logic effectively. The main difference is that compensation logic enables the underlying workflow management system to dcrivate from the predefined control flow logic at arbitrary positions. The approach mentioned in Patent Application Publication US 20]0/0121668 is based mainly on template information and therefore ineffective when dealing with compensation logic since it cannot be statically determined which logic was actually performed or not. So this would result in more instances which are rated incorrectly "incompliant".

Therefore, there is a need in the art to address the aforementioned problem.

Summary of the Invention

The technical proNem underlying the present invention is to provide a method of migrating business process instances and a system of migrating business process instances, which are able to migrate business process instances derived from business process models having compensation logic and to solve the above mentioned shortcomings and pain points of prior art migrating business process instances.

Viewed from a first aspect, the present invention provides a method for migrating business process instances derived from business process models having compensation logic comprising: modeling of a new business process version; determining if a corresponding business process instance derived from said business process model is applicable for migration, by the stcps: statically analyzing an underlying business process model to create a static process control flow; deriving potential compensation control flows; identifying changes between said new business process version and a previous business process version; walking said identified changes for separating and grouping changes related to compensation logic and changes related to normal control flow of said business process model into change groups; and migrating said business process instance based on migration conditions which are determined based on said change groups.

Viewed from a second aspect, the present invention provides a system for migrating business process instances derived from business process models having compensation logic, the system comprising: a modeling-tool for modeling a new business process version; a deployment infrastructure for installing said business process model onto at least one server, communicating with at least one client allowing said at least one client to interact with said business process; and a data processing engine interpreting and executing a process instance by navigating a flow described in said business process model; wherein said data processing engine determines if a corresponding business process instance derived from said business process model is applicable for migration by performing the steps: statically analyzing an underlying business process model to create a static process control flow; deriving potential compensation control flows; identi'ing changes between said new business process version and a previous business process version; walking said identified changes for separating and grouping changes related to compensation logic and changes related to normal control flow of said business process model into change groups; and migrating said business process instance based on migration conditions which are determined based on said change groups.

Viewed from a further aspect, the present invention provides a computer program stored on a computer readable medium and loadable into the internal memory of a digital computer, comprising software code portions, when said program is run on a computer, for performing the steps of the invention.

Viewed from a further aspect, the present invention provides a computer program product for migrating business process instances derived from business process models having compensation logic, the computer program product comprising: a computer readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method for performing the steps of the invention.

According to the present invention this problem is solved by providing a method of migrating business process instances having the features of claim 1, a system for migrating business process instances having the features of claim 10, a computer program for migrating business process instances having the features of claim 14, and a computer program product for migrating business process instances having the features of claim 15. Advantageous embodiments of the present invention are mentioned in the subclaims.

Accordingly, in a preferred embodiment of the present invention, a method of migrating business process instances derived from business process models having compensation logic comprises modeling of a new business process version; determining if a corresponding business process instance derived from the business process model is applicable for migration, by the steps: Statically analyzing an underlying business process model to create a static process control flow; deriving potential compensation control flows; identi'ing changes between the new business process version and a previous business process version; walking the identified changes for separating and grouping changes related to compensation logic and changes related to normal control flow of the business process model into change groups and migrating the business process instance based on migration conditions which are determined based on the change groups.

In further embodiments of the present invention, the static process control flow is extended by incorporating compensation information.

In further embodiments of the present invention, instance related information is attached to the static process control flow.

In further embodiments of the present invention, areas in the business process model are identified which have attached compensation logic.

In further embodiments of the present invention, the compensation logic is disposed to the process control flow at a Logical end of the areas, and a resulting modified control flow is then used as input for migration compliance analysis.

In thither embodiments of the present invention, the migration conditions are computed by extracting currently active activities from the business process instance; and taking and analyzing the static process control flow and the change groups, wherein migration of the business process instance is enabled if there is no change group in the past of the static process control flow of the business process instance.

In further embodiments of the present invention, migration of the business process instance is rejected if there is at least one change group in the past of the static process control flow of the business process instance and if the change group is not a compensation change group.

In further embodiments of the present invention, migration of the business process instance is enabled if at least one change group in the past of the static process control flow of the business process instance is a compensation change group and a state of a scope associated with the compensation change group is recognized as end state.

In further embodiments of the present invention, migration of the business process instance is rejected if the at least one change group in the past of the static process control flow of the business process instance is a compensation change group and a state of a scope associated with the compensation change group is recognized as error state.

In another embodiment of the present invention, a system of migrating business process instances derived from business process models having compensation logic comprises a modeling-tool for modeling a new business process version; a deployment infrastructure for installing the business process model onto at least one server, communicating with at least one client allowing the at least one client to interact with the business process; and a data processing engine interpreting and executing a process instance by navigating a flow described in the business process model; wherein the data processing engine determines if a corresponding business process instance derived from the business process model is applicable for migration by pethrming the steps: Statically analyzing an underlying business process model to create a static process control flow; deriving potential compensation control flows; identifying changes between the new business process version and a previous business process version; walking the identified changes for separating and grouping changes related to compensation logic and changes related to normal control flow of the business process model into change groups; and migrating the business process instance based on migration conditions which are determined based on the change groups.

In further embodiments of the present invention, the data processing engine extends the static process control flow by incorporating compensation information from a data base.

In ifirther embodiments of the present invention, the data processing engine attaches instance related information from the data base to the static process control flow.

In ffirthcr embodiments of the present invention, the data processing engine identifies areas in the business process model which have attached compensation logic, disposes the compensation logic to the process control flow at a logical end of the areas, and uses a resulting modified control flow as input for migration compliance analysis.

In another embodiment of the present invention, a data processing program for execution in a data processing system comprises software code portions for performing a method of migrating business process instances when the program is run on the data processing system.

In yet another embodiment of the present invention, a computer program product stored on a computer-usable medium, comprises computer-readable program means for causing a

S

computer to perform a method of migrating business process instances when the program is run Oil the computer.

All in afl, embodiments of the present invention address a method or system of associating compensation logic to compensate for the changes indicated by the change groups to the business process instance and deciding whether the business process instances arc migrateable or not based on the state of scope associated with the compensation change. Embodiments of the present invention improve the number of instances which can be migrated.

Embodiments of the present invention for deciding whether a process instance can be migrated or not for a business process where compensation logic is used consist basically on two steps, plus an additional step to explain this to the user. In a first step, the process model is analyzed and potential compensation control flows arc derived, i.e. extending the static process control flow by incorporating compensation information. This is an extension to the deployment infrastructure of the Business Process Management System (BPMS). In a second step, instance related information is attached to the static process control flow. Compensation logic is defined for a scope, i. e. a part of the control flow which is affected by the modeled compensation logic. This means, that if an unforeseen error occurs within a scope the compensation logic defined for this scope is triggered and the scope enters an error state like "failed" or "compensated" in order to indicate that this scope was not executed and its side effects were compensated. However, if a scope enters an end state like "finished" or "completed", it can be assured that the associated compensation logic was not executed, since it is only executed in case of an error. So this information, i.e. the state of the scopes which were already passed, is also extracted from a database and attached to the internal process model. If a scope is in an end state which clearly indicates that there was no compensation logic triggered for this scope, any changes to the compensation logic of this scope can safely be ignored, since the currently running instance cannot be affected by them. So for these scopes the compensation change groups are removed and not considered for further analysis.

In a third step, the "travelling" compensation change groups are visualized, so that the user understands better the extension to the modeling tool or to the client piece of a BPMS.

Embodiments of the present invention significantly improve the compliance check and thus making it more accurate and precise due to incorporating additional process instance based information and compensation information.

The above, as well as additional purposes, features, and advantages of the present invention will become apparent in the following detailed written description.

Brief Description of the Drawings

The present invention will now be described, by way of example only, with reference to preferred embodiments, as illustrated in the following figures: FIG. 1 is a schematic block diagram of a Business Process Management System (BPMS), in accordance with a preferred embodiment of the present invention; FIG. 2 and 3 are schematic block diagrams of embodiments of business process modcls, in accordance with the prior art, and in which a preferred embodiment of the present invention may be implemented; FIG. 4 and 5 are schematic block diagrams of embodiments of business process instances in accordance with the prior art, and in which a preferred embodiment of the present invention may be implemented; FIG. 6 is a schematic flow diagram of a method of migrating business process instances, in accordance with a preferred embodiment of the present invention; FIG. 7 is a schematic block diagram of a first embodiment of a business process model, in accordance with preferred embodiments of the present invention; FIG. 8 is a schematic control flow of the first business process model shown in HG. 7, in accordance with a preferred embodiment of the present invention, in accordance with preferred embodiments of the present invent ion; FIG. 9 is a schematic block diagram of a second embodiment of a business process model, in accordance with preferred embodiments of the present invention; FIG. 10 and 11 are schematic control flows of the second business process model shown in FIG. 9, in accordance with preferred embodiments of the present invention; and FIG. 12 to 17 are schematic control flows of different states of a business process instance derived from the second business process model shown in FIG. 9, in accordance with preferred embodiments of the present invention.

Detailed Description

FIG. I shows a Business Process Management System (BPMS) 1, in accordance with a preferred embodiment of the present invention.

Referring to FIG. 1, the shown Business Process Management System (BPMS) 1 comprises a deployment structure 10, a modeling tool 20, a client system 30, and a data base 40. The modeling tool 20 allows modeling a business process in a graphical fashion a so called "Business Process Model" 2, 3. The deployment infrastructure 10 comprises a data processing engine 12 and installs such a business process model 2, 3 onto at least one server, wherein the business process model 2, 3 becomes a so-called "Business Process Template". The client system 30 allows interacting with the business process, i.e. starting it, send messages to it etc. When a process gets started from a business process template, it becomes a "business process instance". The data processing engine 12 interprets and executes a process instance by navigating the graph described in the business process model 2, 3 andior business process template.

A system of migrating business process instances derived from business process models 2,3 having compensation logic, comprises the modeling-tool 20 for modeling a new business process version; the deployment infrastructure 10 for installing the business process model 2, 3 onto at least one server, communicating with the client system 30 allowing the client 30 to interact with the business process 2, 3; and the data processing engine 12 interpreting and executing a process instance by navigating a flow described in said business process model 2, 3. According to the present invention the data processing engine 12 determines if a corresponding business process instance derived from the business process model 2, 3 is applicable for migration by performing the steps: Statically analyzing an underlying business process model 2, 3 to crcatc a static process control flow CF2, CF3, CF3'; deriving potential compensation control flows CCFI to CCF6; identifying changes between the new business process version and a previous business process version; walking the identified changes for separating and grouping changes related to compensation logic 200, 210, 211, 212, 600, 610, 611,612,6l3andchangcsrclatedtonormalcontrolflowloo,500, 110,510,111,511, 112, 512 of the business process model 2, 3 into change groups; and migrating the business process instance based on migration conditions which are determined based on the change groups.

FIG. 6 shows a method of migrating business proccss instances, in accordancc with a preferred embodiment of the present invention; FIG. 7 shows a first embodiment of a business process model; FIG. 8 shows a control flow of the first business process model shown in FIG. 7, in accordance with a preferred embodiment of the present invention; FIG. 9 shows a second embodiment of a business process model; FIG. 10 and 11 show control flows of the second business process model shown in FIG. 9, in accordance with embodiments of the present invention; and FIG. 12 to 17 show control flows of different states of a business process instance derived from the second business process model shown in FIG. 9, in accordance with embodiments of the present invention.

Referring to FIG. 6, in step SI 00 currently active activities from a business process instance are extracted. In step Sll0 a static process control flow CF2, CF3, CF3' and change groups are taken and analyzed. In step S 120, it is checked, whether there are any change groups in the past of the business process instance in view of a current workflow position, or not. If not, in step S 150, the business process instance is migrated on a new business process template. If yes, it is checked, whether the change group positioned in the past of the business process instance is a compensation change group, or not. If not, in step S 160. migration of the business process instance is rejected and the business process instance is rated as incompliant.

If yes, in step S 140, it is checked if a scope associated with the compensation change group is in an end state like "finished" or "completed", for example, or in an error state like "failed" or "compensated", for example. If the associated scope is in the end state "finished", in step S 150, the business process instance is migrated on a new business process template. If the associated scope is in the error state "failed", in step S 160, migration of the business process instance is rejected and the business process instance is rated as incompliant.

Referring to FIG. 7 and 8, the first embodiment of a business process model 2 contains four units of compensation logic 200, 210, 211, 212. Each unit of compensation logic 200, 210, 211, 212 is associated with a different scope 100, 110, 111, 112 of the business process model 2. The shown first embodiment of the business process model 2 comprises a global scope 100 comprising a first activity "Receive", a second activity "AetivityO", a local scope 110, a local compensation logic 210 for the local scope 110, a third activity "Activity7" and a fourth activity "Reply", and a global compensation logic 200 comprising a fifth activity "Catch", and a sixth activity "Activity 12". The local scope 110 comprises a first inner scope 111 comprising a seventh activity "Activity] ", an eighth activity "Activity2", and a ninth activity "Activity3", a first inner compensation logic 211 comprising a tenth activity "Activity8", and an eleventh activity "Activity9", for the first inner scope 111, a twelfth activity "Activity4", a second inner scope 112 comprising a thirteenth activity "ActivityS", and a fourteenth activity "Activity6", and a sccond inner compensation logic 212 comprising a fifteenth activity "ActivitylO", and a sixteenth activity "Activityl 1". The local compensation logic 210 for the local scope 110 comprises a seventeenth activity "SnippetO", an eighteenth activity "Compcnsatc0", a nineteenth activity "Snippetl" and a twentieth activity "Compensate 1".

During deployment time, the business process model 2 is analyzed statically and potential compensation control flows are derived. Those derived compensation control flows then are incorporated into the regular control flow CF2 ofthe business process. First, the inner compensation logics 211, 212 gets lined in the local compensation logic 210 at corresponding places "Compensateo", "Compensatel" where it is called. So the eighteenth activity "Compcnsate0" is replaced by the tenth activity "Activity8", and the eleventh activity "Activity9" forming the first inner compensation logic 211. The twentieth activity "Compensatel" is replaced by the fifteenth activity "ActivitylO", and the sixteenth activity "Activity 1 1" forming the second inner compensation logic 212. Now the local compensation logic 210 for the local scope 110 comprises the activities "SnippetO", "ActivityS", "Activ[ty9", "Snippetl ", "AetivitylO", and "Activity] 1", and the compensation logics for the first inner scope 111 and the second inner scope 112 have been detached.

Next, the local compensation logic 210 for the local scope 110 gets detached, too, and inserted in regular control flow CF2 after the local scope 110, yielding the restructured process shown in FIG. 8. Referring to FIG. 8, the local compensation logic 210 for the local scope 110 is inserted at a logical end 310 of the local scope 110; and the global compensation logic 200 is inserted at a logical end 300 of the global scope 100. This restructured process with lined in compensation logic 200,210,211, 212, can now be used to make a static check to decide whether a process instance can be migrated or not using the standard method

described in prior art.

Additionally, instance based information can be leveraged to improve accuracy of the migration compliance check, i.e. reduce the number of false negative results. This is achieved by separating compensation related changc logic from changes which affect the standard path, i. e. the normal path which is exccutcd if there are no errors. Therefore, all changes in the S compensation logic, i.e. within compensation handler, are grouped into separate change groups (one for each scope the compensation logic is added during transformation). All changes outside of the compensation logic remain in another change group. This information can then be used in an extended compliance cheek for compensation changes. If there is a change within a compensation handler then select the direct enclosing scope and check if it is in state finished. Please note that the latte step requires instance based information and therefore is an extension to the cxisting purely static bascd approach used for instance migration scenarios. If the parent scope is a non-compensable scope then proceed with its parent until a compensable scope is found. This assures that modified compensation logic has not been entered yet Since compensation logic can potentially trigger in at certain points in the control flow of the process, when the restructured process created with the lined in compensation logic, certain parts of the compensation logic are "duplicated" to make sure all the appropriate places where it could get triggered are appropriately respected. This step is required to handle the non-deterministic behavior which comes along with a business process containing compensation logic. It cannot be determined statically when the compensation logic is triggered and if it is triggered at all. Each such insertion is called a "compensation change group". However, since this is an over-approximation caused by the static nature of the restructuring, only one of these compensation change groups would be valid considering the actual state of a process instance. Thus, when visualizing is wanted whether a process instance that contains compensation logic can be migrated or not, the visualization must take that into account.

Referring to FIG. 9, the second embodiment of a business process model 3 contains five units of compensation logic 600, 610. 611, 612, 613. Each unit of compensation logic 600, 610, 611, 612, 613 is scoped to a different scope 500, 510, 511, 512, 513 ofthe business process model 2. The shown second embodiment of the business process model 3 comprises a global scope 500 comprising a first activity "Receive", a local scope 510, a local compensation logic 610 for the local scope 510, a second activity "Activity4", a global compensation logic 600 comprising a third activity "Compensate00"; and a fourth activity "Reply". The local scope 510 comprises a first inner scope 511 comprising a fifth activity "Activity0". and a sixth activity "Activity]"; a first inner compensation logic 611 comprising a seventh activity "Compcnsatcl" for the first inner scope 511; a second inner scope 512 comprising an eighth activity "Invokc0"; a second inner compensation logic 612 comprising a ninth activity "SnippetO" for the second inner scope 512; a third inner scope 513 comprising a tenth activity "Activity2", and a eleventh activity "Activity3"; and a third inner compensation logic 613 comprising a thirteenth activity "Comensate3" for the third inner scope 513. The Local compensation logic 610 for the Local scope 510 comprises a fourteenth activity "Compensate0".

Referring to FIG. 10, in a regular control flow CF3 of the business process model 3 derived compensation control flows are incorporated. The inner compensation logics 611,612,613 arc lined in the local compcnsation logic 610 at the corresponding place "Compcnsate0". So the fourteenth activity "Compensate0" is replaced by the seventh activity "Compensate 1", the ninth activity "SnippetO", and the thirteenth activity "Compcnsatc3" forming the first, second and third inner compensation logic 611, 612, 613, respectively. Also, the third activity "Compensateoo" of the global compensation logic 600 is replaced by the fourteenth activity "Compcnsatc0" of the local compensation logic 610 which is in turn replaced by the seventh activity "Compensatcl", the ninth activity "Snippcto", and the thirteenth activity "Compensate3" forming the first, second and third inner compensation logic 6]], 612, 613, respectively. Now the local compensation logic 610 for the local scope 510 comprises the activities "Compcnsatel", "Snippct0", and "Compensate3", and the compensation logics for the first inner scope 6]], the second inner scope 612, and the third inner scope 613 have been detached.

Next, the local compensation logic 6] 0 for the local scope 510 gets detached, too, and inserted in regular control flow CF3 after the local scope 510, yielding the restructured process shown in FIG. 10. Referring to FIG. 10, the local compensation logic 610 for the local scope 510 is inserted at a logical end 710 of the local scope 510. The global compensation logic 600 for the global scope 500 comprises the activities "Compcnsatel", "Snippct0", and "Compensate3", and the global compensation logic 600 [s inserted at a logical end 700 of the global scope 500. This restructured process with lined in compensation logic 600. 610, 611, 612, 613 can now be used to make a static check to decide whether a process instance can be migrated or not using the standard method described in prior art.

Assuming, that the first inner compensation logic 611 and the third inner compensation logic 613 are empty, which means, that no activities are performed, the regular control flow DF3 may be simplified. The simplified control flow DF3' is shown in FIG. II.

Referring to FIG. 11, in the simplified regular control flow CF3' of thc business process model 3, the fourteenth activity "Compensateo" is replaced by the ninth activity "SnippetO".

Also, the third activity "Compeasate00" of the global compensation logic 600 is replaced by thc fourteenth activity "Compcnsate0" of the local compensation logic 610 which is in turn replaced by the ninth activity "SnippetO". Now the local compensation logic 610 for the local scope 510 comprises the activity "Snippct0". Still referring to FIG. 11, the local compensation logic 610 for the local scope 510 is inserted at a logical end 710 ofthe local scopc 510. The global compensation logic 600 for the global scope 500 comprises the activity "Snippct0"; and the global compensation logic 600 is inserted at a logical end 700 of the global scope 500.

This restructured process is now' used to decide whether a process instance can be migrated or not.

FIG. 12 to 17 show workflow graphs CCFI, CCF2, CCF3, CCF3', CCF3", CCF4 of sample processes with lined in compensation logic and compensation change groups depending on the state of the process instance. In FIG. 12 to 17, a compensation change group CG, lying in the future in view of the current state of the process instance which is labeled as wavefront W, is highlighted as a dotted block. A compensation change group CGP, lying in the past in view of the current state of the process instance W is highlighted as block with fat lines. A compensation change group CGI lying in the past and being "irrelevant" for the migration process of the process instance is highlighted as shaded block.

As stated before, the compensation change groups CG, that need to be considered, depend on the current state of the process instance. Referring to Fig. 12, in the shown first workflow graph CCFI of the business process instance, the current state of the process instance W is the first activity "Receive" of the global scope 500 in the business process model 3. In the future only the very next compensation change group CG is of interest. All remaining future compensation change groups are omitted. Therefore, in this state, the next compensation change group CG to be considered in the future is the ninth action "SnippetO" of the second inner compensation logic 612 only. There are no change group CGP, lying in the past in view of the current state of the process instance W. All compensation change groups CGP lying in the past prevent the instance from being migrateable if their directly enclosing scope is in the state "compensated" or "Failed".

Referring to Fig. 13, in the shown second workilow graph CCF2 of the business process instance, the current state of the process instance W is the eleventh activity "Activity3" of the third inner scope 513 in the local scope 510 of the business process model 3. In this state, the next compensation change group CG to be considered in the future is still the ninth action "SnippetO" of the second inner compensation logic 612. There are also no change group CGP, lying in the past in view of the current state of the process instance W. Referring to Fig. 14, in the shown third workflow graph CCF3 of the business process instance, the current state of the process instance W is the second activity "Activity4" of the global scope 500 in the business process model 3. Tn this state, the next compensation change group CU to be considered in the future is the ninth action "SnippetO" of the local compensation logic 610 in the business process model 3. There is a first change group CGP, lying in the past in view of the current state of the process instance W, that is to be considered. At this point, it is to proof, if the directly associated scope, here the second inner scope 512, is in the state "Compensated/Failed" or "Finished". Assuming that the second inner scope 512 is in the state "Finished", which means that the associated second inner compensation logic 612 has not been executed, the first change group in the past CUP is not influencing the compliance check. So in order to reduce the number of false negative compliance cheeks it is necessary to reduce the number of compensation change groups CliP in the past. Whenever such a change group CGP is passed the previously described instance based information, i. e. the state of the surrounding scope, here the second inner scope 612, is leveraged to check if this change group CGP can be automatically deleted from the workflow graph as shown in FIG. 15, and therefore the compliance check is not influenced by this change group. FIG. 15 shows the optimized third workflow graph CCF3' without the ninth action "SnippetO" of the second inner compensation logic 612. To optimize the business process instance the change group CUP can also be marked as "irrelevant" in case that a deletion is expensive depending on the used system. FIG. 16 shows the optimized third workfiow graph CCF3" with the ninth action "SnippetO" of the second inner compensation logic 612 as change group CGI marked as "irrelevant".

Referring to Fig. 17, in the shown fourth workflow graph CCF4 of the business process instance, the current state of the process instance W is the fourth activity "Reply" of the business process model 3. In this state, there is no next compensation change group CG to be considered in the future. There is a first change group COP, lying in the past in view of the current state of the process instance W, that is marked as "irrelevant" and therefore not influencing the compliance check. Further, there is a second change group CGP, lying in the past in view of the current state of the process instance W. At this point, it is to proof, if the directly associated scope, here the global scope 500, is in the state "Compensated/Failed" or "Finished". Assuming that the global scope 500 is in the state "Compensated", which means that the associated global compensation logic 600 has been executed, the second change group in the past CGP is influencing the compliance check. Therefore the migration is rejected and the business process instance is rated as incompliant.

The inventive method of migrating business process instances can be implemented as an entirely sofiware embodiment, or a preferred embodiment containing both hardware and software elements, in a preferred embodiment, the present invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. Furthermore, the present inventLon can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disc, and an optical disc. Current examples of optical discs include Compact Disc -read only memory (CD-ROM), Compact Disc -read!write (CD-R/W), and DYD. A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus.

The memory elements can include local memory employed during actual execution of the program code, bulk storagc, and cache memorics which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through S intervening I/O controllers.

Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the currently available types of network adapters.

Claims (1)

1. <claim-text>CLAIMSA method for migrating business process instances derived from business process models having compensation logic comprising: modeling of a new business process version; determining if a corresponding business process instance derived from said business process model (2, 3)is applicable for migration, by the steps: statically analyzing an underlying business process model (2, 3) to create a static process control flow (CF2, CF3, CF3'); dcriving potential compensation control flows (CCII to CCF6); identi'ing changes between said new business process version and a previous business process versiom walking said identified changes for separating and grouping changes related to compensation logic (200,210,211,212,600,610,611, 612, 613) and changes related to normal control flow (100, 500, 110, 510, 111, 511, 112, 512) of said business process model (2, 3) into change groups; and migrating said business process instance based on migration conditions which are determined based on said change groups.</claim-text> <claim-text>2. The method according to claim 1, wherein said static process control flow (CF2, CF3, CF3') is extended by incorporating compensation information.</claim-text> <claim-text>3. The method according to claim 1 or 2, wherein instance related information are attached to said static process control flow (CF2, CF3, CF3').</claim-text> <claim-text>4. The method according to one of the preceding claims I to 3, wherein areas (100, 110, 111, 112, 500, 510, 511, 512, 513) in said business process model are identified which have attached compensation logic (200, 210, 211, 212, 600, 610, 611, 612, 613).</claim-text> <claim-text>5. The method according to claim 4, wherein said compensation logic (200, 210, 211, 212, 600, 610, 611, 612, 613) is disposed to said process control flow at a logical end of said areas (300, 310, 700, 710), and a resulting modified control flow (CF2, CF3, CF3') is then used as input for migration compliance analysis.</claim-text> <claim-text>6. The method according to one of the prcccding claims Ito 5, whcrcin said migration conditions are computed by extracting currently active activities from said business process instance; and taking and analyzing said static process control flow (CF2, CF3, CF3') and said change groups, wherein migration of said business process instance is enabled if there is no change group in the past of said static process control flow (CF2, CF3, CF3') of said business process instance.</claim-text> <claim-text>7. The method according to claim 6, wherein migration of said business process instance is rejected if there is at least one change group iii the past of said static process control flow (CF2, CR, CR') of said business process instance and if said change group is not a compensation change group.</claim-text> <claim-text>8. The method according to claim 6 or 7, wherein migration of said business process instance is enabled if said at least one change group in the past of said static process control flow (CF2, CF3, CF3') of said business process instance is a compensation change group and a state of a scope (100, 500, 110, 510, 111, 511, 112, 512) associated with said compensation change group is recognized as end state.</claim-text> <claim-text>9. The method according to claim 7 or 8, wherein migration of said business process instance is rejected if said at least one change group in the past of said static process control flow (CF2, CF3, CR') of said business process instance is a compensation change group and a state ofa scope (100, 500, 110, 510, 111, 511, 112, 512) associated with said compensation change group is recognized as error state.</claim-text> <claim-text>10. A system for migrating business process instances derived from business process models having compensation logic, the system comprising: a modeling-tool (20) for modeling a new business process version; a deployment infrastructure (10) for installing said business process model (2, 3) onto at least one server, communicating with at least one client (30) allowing said at least one client (30) to interact with said business process (2, 3); arid a data processing engine (12) interpreting and executing a process instance by navigating a flow described in said business process model (2, 3); wherein said data processing engine (12) dctermines if a corresponding business process instance derived from said business process model (2, 3) is applicable for migration by performing the steps: statically analyzing an underlying business process model (2, 3) to create a static process control flow (CF2, CF3, CF3'); deriving potential compensation control flows (CCFI to CCFÔ); identi'ing changes between said new business process version and a previous business process version; walking said identified changes for separating and grouping changes related to compensation logic(200,210,211,212,600,610,611,612,613)andchangesrelatedto normal control flow (100, 500, 110, 510, 111, 511, 112,512) ofsaid business process model (2, 3) into change groups; and migrating said business process instance based on migration conditions which are determined based on said change groups.</claim-text> <claim-text>11. The system according to claim 1 0, wherein said data processing engine (12) extends said static process control flow (CF2, CF3, CF3') by incorporating compensation information from a data base (40).</claim-text> <claim-text>12. The system according to claim 10 or 11, wherein said data processing engine (12) attaches instance related information from said data base (40) to said static process control flow (CF2, CF3, CF3').</claim-text> <claim-text>13. The system according to one of the preceding claims 10 to 12, wherein said data processing engine (12) identifies areas (100, 110, 111, 112, 500, 510, 511, 512, 513) in said business process model which have attached compensation logic (200, 210, 211, 212, 600, 610, 611, 612, 613), disposes said compensation logic (200, 210, 211,212,600,610, 611, 612, 613) to said process control flow at a logical end ofsaid areas (300, 310, 700, 710), and uses a resulting modified control flow (CF2, CF3, CF3') as input for migration compliance analysis.</claim-text> <claim-text>14. A computer program stored on a computer readable medium and loadable into the internal memory of a digital computer, comprising software code portions, when said program is run on a computer, for performing the method of any of claims I to 9.</claim-text> <claim-text>15. A computer program product for migrating business process instances derived from business process models having compensation logic, the computer program product comprising: a computcr readable storagc mcdium readable by a proccssing circuit and storing instructions for execution by thc processing circuit for performing a method according to any of claims 1 to 9.</claim-text>