You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by "Rafal Rusin (JIRA)" <ji...@apache.org> on 2009/01/12 22:10:00 UTC
[jira] Created: (ODE-483) Add serialize/deserialize process
instances in Management API
Add serialize/deserialize process instances in Management API
-------------------------------------------------------------
Key: ODE-483
URL: https://issues.apache.org/jira/browse/ODE-483
Project: ODE
Issue Type: New Feature
Affects Versions: Wishlist
Reporter: Rafal Rusin
Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
Then, a bugfix procedure would look like this;
-pause ode
-serialize instances
-deploy newer version
-deserialize instances and fix manually any import errors
-resume ODE
It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
What do you think about it?
Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-483) Add serialize/deserialize process
instances in Management API
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717963#action_12717963 ]
Rafal Rusin commented on ODE-483:
---------------------------------
Here's a proposal for interface and implementation (includes proper timers support).
The basic use cases for replayer are:
1. migrate existing log running instances to newest process version
given their communication (incoming and outgoing requests)
2. reproduce error scenarios between two instances of ODE (eg.
production and development)
Interface:
Extends management api by 2 operations: replay and getCommunication.
In order to do 1, you invoke:
<pmap:replay>
<replay>
<ns:upgradeInstance>1234</ns:upgradeInstance>
</replay>
</pmap:replay>
You get a new instance in the newest process version. The old one is deleted.
To do 2, you need to retrieve exchanges from instance (or instances) by:
<pmap:getCommunication>
<getCommunication>
<ns:iid>1234</ns:iid>
</getCommunication>
</pmap:getCommunication>
Then, you execute replay on the other ODE installation to replicate instance:
<pmap:replay xmlns:ns="http://www.apache.org/ode/pmapi/types/2006/08/02/">
<replay>
<ns:restoreInstance>
<ns:processType
xmlns:p="http://sample.bpel.org/bpel/sample">p:OnEventCorrelation</ns:processType>
... exchanges
</ns:restoreInstance>
</replay>
</pmap:replay>
To have control over time in bpel process, I introduced a variable
$ode:currentEventDateTime. It's equivalent to $fn:current-dateTime()
during live session and it's set to corresponding time in past during
replaying.
I think this interface is quite simple and solves it's job well.
Implementation notes:
- It works in one transaction.
You can migrate a few instances at once and get an error, which will
roll back all work if an error occurrs in some case.
- It extends BpelRuntimeContextImpl by ReplayerBpelRuntimeContextImpl
class, which overrides methods like invoke and registerTimer to mock
up communication
- It implements ReplayerScheduler, which executes actions from past in
time sorted order (exchanges given to replayer have createTime field,
which is used for sorting)
- jobs from past are processed in ReplayerScheduler and jobs in
future are registered in engine's scheduler.
- In order to make integrity constraints, replaying returns error if:
- a first incoming request is routed to an existing instance instead
of creating a new one
- next incoming request is routed to other instance or creates a new instance
- there is some unprocessed communication while finishing replaying
(for example if there is some outgoing exchange for service, which did
not have INVOKE from replayed instance)
- It extends bpel-compiler and xpath evaluation by
$ode:currentEventDateTime variable
- It adds currentEventDateTime property to BpelRuntimeContext
- It adds replayer package to bpel engine in bpel-runtime module
- It changes visibility of some fields and methods in bpel engine from
private to protected and from optional to public.
Attached are:
- replayer-proposal.diff - an implementation applicable for ODE1X
branch, rev. 777412
- test process for axis2 distro with soapui 2.5.2 test case
demonstrating usage of replayer.
Limitations:
- It currently works only with hibernate DAO, on Axis2 and JBI distros.
> Add serialize/deserialize process instances in Management API
> -------------------------------------------------------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ODE-483) Instance replayer
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafal Rusin reassigned ODE-483:
-------------------------------
Assignee: Rafal Rusin
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Assignee: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff, replayer-test2-soapui-project.xml
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Enrico Levesque updated ODE-483:
--------------------------------
Attachment: (was: bookshop-example-4.zip)
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-483) Add serialize/deserialize process
instances in Management API
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676752#action_12676752 ]
Rafal Rusin commented on ODE-483:
---------------------------------
Current version doesn't consider other aspects that plain communication (without faults too). As for timers, a quick fix, which I'm going to do soon, will be to switch waits to wait(0) during migration. This won't be perfect, since it won't consider onAlarms for example, but will do some good job.
As for comprehensive solution, there are couple of issues, including also using now() like functions in xpaths.
This requires some research, but I think adding an execution timestamp to jobs, exposing it as additional xpath function (like current-dateTime2 or something) and replaying + mocking selected jobs instead of exchanges might solve all problems. All jobs in past could just be replayed without delays by scheduler. This would also solve migration persistence problem, which now isn't implemented.
I'm also thinking of some deploy.xml switch like enable-migration=true, which would indicate scheduler to not delete required jobs (like INVOKE_RESPONSE etc.), but put them into inactive state. Migration operation would resurrect those required jobs.
> Add serialize/deserialize process instances in Management API
> -------------------------------------------------------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: replayer.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749910#action_12749910 ]
Enrico Levesque edited comment on ODE-483 at 9/1/09 7:05 AM:
-------------------------------------------------------------
I added 2 project examples, deployment zip files and the soapUI xml projects to test the processes. They are 2 versions of a bookshop example, the first one without correlation and the second with correlation. I used those to test the Replayer, one all automatize and the second requires the response of a financial analyst.
The first one works fine with the Replayer, since there is no correlation. The second works if the instance stop before the exchange that comes in asynchronously from FinancialAnalyst, but it doesn't retrieve the instance by correlation during replay if you try to replay the whole process after completion.
For the processes to work, you need to run the mock services inside SoapUI. I just used SoapUI to send my messages from the interfaces provided. Sorry I didn't take the time to setup a one click test case yet.
was (Author: enricolds):
I added 2 project examples, deployment zip files and the soapUI xml projects to test the processes. They are 2 versions of a bookshop example, the first one without correlation and the second with correlation. I used those to test the Replayer, one all automatize and the second requires the response of a financial analyst.
The first one works fine with the Replayer, since there is no correlation. The second works if the instance stop before the exchange that comes in asynchronously from FinancialAnalyst, but it doesn't retrieve the instance by correlation during replay if you try to replay the whole process after completion.
For the processes to work, you need to run the mock services inside SoapUI. I just used SoapUI to send my messages from the interfaces provided. Sorry I didn't take the time to setup a one button test case yet.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749956#action_12749956 ]
Enrico Levesque commented on ODE-483:
-------------------------------------
ODE Replayer with process collaboration support : Project description
The project is to build a tool for migration into Apache ODE to enable it to replay long running collaborative process instances along with human assistance. The purpose of this tool is to ease the work of the analysts during the process of migrating multiple collaborative long running instances from one version of a process to another modified.
The tool will replay the exchange messages that occured during the past execution. It will take automatically new routes during process execution and will determine what kind of invokes to do, blank execution or synchronization with other processes.
The tool will ask for analyst intervention to determine the right values to insert when the instance is waiting for an asynchronous human exchange to be re-introduced into the process. For this purpose, a web interface will be created informing the analyst of all exchange messages waiting to be replayed. The analyst will be informed when the instances is waiting for a human exchange or any kind of non-process exchanges to be re-introduced. This interface will then permit the analyst to supervise, manage and pilot the migration process.
This Replayer will be able to determine which previous invokes need to be compensated due to data changes or flow changes. The compensations will be done by analysts directly into the databases, or will be ignored depending on each case.
For this kind of migration to work, an important assomption need to always be true: that we can at any time compensate a previous activity. If a critical compensation cannot be done, the migration will have to be aborted, therefore the necessity to be able to restore to original state at any time during migration.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-483) Instance replayer
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749782#action_12749782 ]
Rafal Rusin commented on ODE-483:
---------------------------------
It's great that you picked it up. I'm planning to commit it to 1.X as soon as I create a few test cases.
If you plan to add collaboration between processes for replayer, please describe your solution and then I'll create a branch on github and give you access, so you can work on it.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748912#action_12748912 ]
Enrico Levesque edited comment on ODE-483 at 8/28/09 10:35 AM:
---------------------------------------------------------------
Hi all,
I was able to run the Replayer on my own processes but with some modifications as explained earlier, but the processes need to be RUNNING IN MEMORY.
I added this fix to BpelRuntimeContextImpl.getCurrentEventDateTime() :
was -
public Date getCurrentEventDateTime() {
return _currentEventDateTime;
}
changed to -
public Date getCurrentEventDateTime() {
if (_currentEventDateTime == null)
return Calendar.getInstance().getTime();
else
return _currentEventDateTime;
}
This other fix to invoke(...) in the same class :
was -
...
MessageExchangeDAO mexDao = _dao.getConnection().createMessageExchange(
MessageExchangeDAO.DIR_BPEL_INVOKES_PARTNERROLE);
mexDao.setStatus(MessageExchange.Status.NEW.toString());
mexDao.setOperation(operation.getName());
...
changed to -
MessageExchangeDAO mexDao = _dao.getConnection().createMessageExchange(
MessageExchangeDAO.DIR_BPEL_INVOKES_PARTNERROLE);
/* modif enrico */
mexDao.setCreateTime(getCurrentEventDateTime());
mexDao.setStatus(MessageExchange.Status.NEW.toString());
mexDao.setOperation(operation.getName());
This fix to PartnerLinkMyRoleImpl.invoke(...) :
was -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.CREATE_INSTANCE);
mex.getDAO().setInstance(newInstance);
instance.execute();
changed to -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.CREATE_INSTANCE);
mex.getDAO().setInstance(newInstance);
/* modif enrico
* createTime needs to be initialized for getCommunication in Replayer*/
if (mex.getDAO().getCreateTime() == null)
mex.getDAO().setCreateTime(instance.getCurrentEventDateTime());
instance.execute();
And into invokeInstance(...) of the same class :
was -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.MATCHED);
mex.getDAO().setInstance(routing.messageRoute.getTargetInstance());
instance.execute();
changed to -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.MATCHED);
mex.getDAO().setInstance(routing.messageRoute.getTargetInstance());
/* modif enrico
* if createTime need to be initialized */
if (mex.getDAO().getCreateTime() == null)
mex.getDAO().setCreateTime(instance.getCurrentEventDateTime());
instance.execute();
I also did two other fix but I never verified if they where necessary.
ASSIGN
public Date getCurrentEventDateTime() {
/* enrico modif */
//return null;
return Calendar.getInstance().getTime();
}
PropertyAliasEvaluationContext
public Date getCurrentEventDateTime() {
/* enrico modif */
return Calendar.getInstance().getTime();
//return null;
}
These where necessary so we can use getCommunication on instances created without the Replayer.
replayInstances works again but only when processes are executed in memory.
was (Author: enricolds):
Hi all,
I was able to run the Replayer on my own processes but with some modifications as explained earlier, but the processes need to be running in memory.
I added this fix to BpelRuntimeContextImpl.getCurrentEventDateTime() :
was -
public Date getCurrentEventDateTime() {
return _currentEventDateTime;
}
changed to -
public Date getCurrentEventDateTime() {
if (_currentEventDateTime == null)
return Calendar.getInstance().getTime();
else
return _currentEventDateTime;
}
This other fix to invoke(...) in the same class :
was -
...
MessageExchangeDAO mexDao = _dao.getConnection().createMessageExchange(
MessageExchangeDAO.DIR_BPEL_INVOKES_PARTNERROLE);
mexDao.setStatus(MessageExchange.Status.NEW.toString());
mexDao.setOperation(operation.getName());
...
changed to -
MessageExchangeDAO mexDao = _dao.getConnection().createMessageExchange(
MessageExchangeDAO.DIR_BPEL_INVOKES_PARTNERROLE);
/* modif enrico */
mexDao.setCreateTime(getCurrentEventDateTime());
mexDao.setStatus(MessageExchange.Status.NEW.toString());
mexDao.setOperation(operation.getName());
This fix to PartnerLinkMyRoleImpl.invoke(...) :
was -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.CREATE_INSTANCE);
mex.getDAO().setInstance(newInstance);
instance.execute();
changed to -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.CREATE_INSTANCE);
mex.getDAO().setInstance(newInstance);
/* modif enrico
* createTime needs to be initialized for getCommunication in Replayer*/
if (mex.getDAO().getCreateTime() == null)
mex.getDAO().setCreateTime(instance.getCurrentEventDateTime());
instance.execute();
And into invokeInstance(...) of the same class :
was -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.MATCHED);
mex.getDAO().setInstance(routing.messageRoute.getTargetInstance());
instance.execute();
changed to -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.MATCHED);
mex.getDAO().setInstance(routing.messageRoute.getTargetInstance());
/* modif enrico
* if createTime need to be initialized */
if (mex.getDAO().getCreateTime() == null)
mex.getDAO().setCreateTime(instance.getCurrentEventDateTime());
instance.execute();
I also did two other fix but I never verified if they where necessary.
ASSIGN
public Date getCurrentEventDateTime() {
/* enrico modif */
//return null;
return Calendar.getInstance().getTime();
}
PropertyAliasEvaluationContext
public Date getCurrentEventDateTime() {
/* enrico modif */
return Calendar.getInstance().getTime();
//return null;
}
These where necessary so we can use getCommunication on instances created without the Replayer.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-483) Add serialize/deserialize process
instances in Management API
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafal Rusin updated ODE-483:
----------------------------
Attachment: replayer-example.zip
replayer-proposal.diff
> Add serialize/deserialize process instances in Management API
> -------------------------------------------------------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747460#action_12747460 ]
Enrico Levesque edited comment on ODE-483 at 8/25/09 8:28 AM:
--------------------------------------------------------------
Attached PDF : Towards Adaptability Support in Collaborative Business Processes
Extract from the abstract :
Some approaches propose solutions to support business process adaptability; however, they do not handle adaptability in the context of multi-partner collaborative business processes. In this paper, we propose a new approach to support adaptability for such collaborative processes. This approach uses a protocol, called Change Protocol for Collaboration (CPC), for managing the changes that can have incidence on the contract.
was (Author: enricolds):
Towards Adaptability Support in Collaborative Business Processes (attached PDF)
>From the abstract :
Some approaches propose solutions to support business process adaptability; however, they do not handle adaptability in the context of multi-partner collaborative business processes. In this paper, we propose a new approach to support adaptability for such collaborative processes. This approach uses a protocol, called Change Protocol for Collaboration (CPC), for managing the changes that can have incidence on the contract.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748912#action_12748912 ]
Enrico Levesque commented on ODE-483:
-------------------------------------
Hi all,
I was able to run the Replayer on my own processes but with some modifications as explained earlier, but the processes need to be running in memory.
I added this fix to BpelRuntimeContextImpl.getCurrentEventDateTime() :
was -
public Date getCurrentEventDateTime() {
return _currentEventDateTime;
}
changed to -
public Date getCurrentEventDateTime() {
if (_currentEventDateTime == null)
return Calendar.getInstance().getTime();
else
return _currentEventDateTime;
}
This other fix to invoke(...) in the same class :
was -
...
MessageExchangeDAO mexDao = _dao.getConnection().createMessageExchange(
MessageExchangeDAO.DIR_BPEL_INVOKES_PARTNERROLE);
mexDao.setStatus(MessageExchange.Status.NEW.toString());
mexDao.setOperation(operation.getName());
...
changed to -
MessageExchangeDAO mexDao = _dao.getConnection().createMessageExchange(
MessageExchangeDAO.DIR_BPEL_INVOKES_PARTNERROLE);
/* modif enrico */
mexDao.setCreateTime(getCurrentEventDateTime());
mexDao.setStatus(MessageExchange.Status.NEW.toString());
mexDao.setOperation(operation.getName());
This fix to PartnerLinkMyRoleImpl.invoke(...) :
was -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.CREATE_INSTANCE);
mex.getDAO().setInstance(newInstance);
instance.execute();
changed to -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.CREATE_INSTANCE);
mex.getDAO().setInstance(newInstance);
/* modif enrico
* createTime needs to be initialized for getCommunication in Replayer*/
if (mex.getDAO().getCreateTime() == null)
mex.getDAO().setCreateTime(instance.getCurrentEventDateTime());
instance.execute();
And into invokeInstance(...) of the same class :
was -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.MATCHED);
mex.getDAO().setInstance(routing.messageRoute.getTargetInstance());
instance.execute();
changed to -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.MATCHED);
mex.getDAO().setInstance(routing.messageRoute.getTargetInstance());
/* modif enrico
* if createTime need to be initialized */
if (mex.getDAO().getCreateTime() == null)
mex.getDAO().setCreateTime(instance.getCurrentEventDateTime());
instance.execute();
I also did two other fix but I never verified if they where necessary.
ASSIGN
public Date getCurrentEventDateTime() {
/* enrico modif */
//return null;
return Calendar.getInstance().getTime();
}
PropertyAliasEvaluationContext
public Date getCurrentEventDateTime() {
/* enrico modif */
return Calendar.getInstance().getTime();
//return null;
}
These where necessary so we can use getCommunication on instances created without the Replayer.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749956#action_12749956 ]
Enrico Levesque edited comment on ODE-483 at 9/2/09 6:40 AM:
-------------------------------------------------------------
ODE Replayer with process collaboration support : Project summary
The project will be to build a migration tool to enable ODE to replay with human assistance long running collaborative process instances. The purpose of this tool is to ease the work of the analysts during the process of migrating multiple collaborative long running instances from one version of a process to another.
The tool will replay the exchange messages that occured during past executions. It will take automatically new routes during process execution and will determine what kind of invokes to do, blank execution or synchronization with other processes.
A synchronization consist in sending a message to the server running another process each time the instance in migration calls that process through an invoke activity. When the engine receives a synchronization message, it replays the instance refered to using the same Replayer, expanding automatically the migration to the other collaborating processes.
The tool will ask for analyst intervention to determine the right values to insert when the instance is waiting for an asynchronous human exchange to be re-introduced into the process. For this purpose, a web interface will be created informing the analyst of all exchange messages waiting to be replayed. The analyst will be informed when the instances is waiting for a human exchange or any kind of unsynchronized exchange to be re-introduced. This interface will then permit the analyst to supervise, manage and pilot the migration process.
This Replayer will be able to determine which previous invokes need to be compensated due to data changes or flow changes. The compensations will be done by analysts directly into the databases, or will be ignored depending on each case.
For this kind of migration to work, an important assomption need to always be true: that we can at any time compensate a previous activity. If a critical compensation cannot be done, the migration will have to be aborted, therefore the necessity to be able to restore to original state at any time during migration.
was (Author: enricolds):
ODE Replayer with process collaboration support : Project description
The project will be to build a migration tool to enable ODE to replay with human assistance long running collaborative process instances. The purpose of this tool is to ease the work of the analysts during the process of migrating multiple collaborative long running instances from one version of a process to another.
The tool will replay the exchange messages that occured during past executions. It will take automatically new routes during process execution and will determine what kind of invokes to do, blank execution or synchronization with other processes.
A synchronization consist in sending a message to the server running another process each time the instance in migration calls that process through an invoke activity. When the engine receives a synchronization message, it replays the instance refered to using the same Replayer, expanding automatically the migration to the other collaborating processes.
The tool will ask for analyst intervention to determine the right values to insert when the instance is waiting for an asynchronous human exchange to be re-introduced into the process. For this purpose, a web interface will be created informing the analyst of all exchange messages waiting to be replayed. The analyst will be informed when the instances is waiting for a human exchange or any kind of unsynchronized exchange to be re-introduced. This interface will then permit the analyst to supervise, manage and pilot the migration process.
This Replayer will be able to determine which previous invokes need to be compensated due to data changes or flow changes. The compensations will be done by analysts directly into the databases, or will be ignored depending on each case.
For this kind of migration to work, an important assomption need to always be true: that we can at any time compensate a previous activity. If a critical compensation cannot be done, the migration will have to be aborted, therefore the necessity to be able to restore to original state at any time during migration.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff, replayer-test2-soapui-project.xml
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-483) Add serialize/deserialize process
instances in Management API
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafal Rusin updated ODE-483:
----------------------------
Attachment: replayer.diff
I case if somebody needs this, I'm attaching a patch which enables process instance migration by taking it's communications and replaying in a new instance. Current limitation is that this runs only in JBI, on hibernate DAO. But it's quite easy to add it to axis and extend to jpa dao.
I extended instance management api by following functions:
-getInstanceCommunication
-migrate (given communication and correlation ids, which are used to distinguish migrated instances from working ones)
-migrationStatus (to check whether migration has comleted; this means that every incoming exchange was sent and every outgoing exchnage from INVOKEs was mocked up)
You can apply it to ode1x, revision 738300 to try out, so there won't be any conflicts.
And a couple of notes:
1. I found it quite impossible to do instance migration from older to newer version of process using state serialization/deserialization. So I decided to do communications replaying.
2. I'm open to any suggestions and feedback.
3. In case if you need this too or if you are interested in adding it to ODE, I can extend/improve/document more/provide some samples to this code.
> Add serialize/deserialize process instances in Management API
> -------------------------------------------------------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: replayer.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747460#action_12747460 ]
Enrico Levesque edited comment on ODE-483 at 8/25/09 8:24 AM:
--------------------------------------------------------------
Towards Adaptability Support in Collaborative Business Processes (attached PDF)
>From the abstract :
Some approaches propose solutions to support business process adaptability; however, they do not handle adaptability in the context of multi-partner collaborative business processes. In this paper, we propose a new approach to support adaptability for such collaborative processes. This approach uses a protocol, called Change Protocol for Collaboration (CPC), for managing the changes that can have incidence on the contract.
was (Author: enricolds):
Towards Adaptability Support in Collaborative Business Processes
Some approaches propose solutions to support business process adaptability; however, they do not handle adaptability in the context of multi-partner collaborative business processes. In this paper, we propose a new approach to support adaptability for such collaborative processes. This approach uses a protocol, called Change Protocol for Collaboration (CPC), for managing the changes that can have incidence on the contract.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ODE-483) Instance replayer
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafal Rusin resolved ODE-483.
-----------------------------
Resolution: Fixed
Fix Version/s: (was: Wishlist)
1.3.4
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Assignee: Rafal Rusin
> Fix For: 1.3.4
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff, replayer-test2-soapui-project.xml
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-483) Instance replayer
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752689#action_12752689 ]
Rafal Rusin commented on ODE-483:
---------------------------------
I added test case for replayer and committed this version to 1.X. All other tests passed, so I think this commit is fine. Also, Replayer doesn't have backward compatibilty problems, because it's an extension, so it's safe to apply it to 1.X
Now main thing to do is migrate to trunk. It won't be staightforward, because of a lot of differences between engine's implementation. So don't expect it in near future.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff, replayer-test2-soapui-project.xml
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747456#action_12747456 ]
Enrico Levesque commented on ODE-483:
-------------------------------------
Hi Rafal (and others interested in the subject),
I'm a graduate student in computer science and we've been thinking a bit on this issue of migrating process instances. We've published an article on the subject in 2008 (http://portal.acm.org/citation.cfm?id=1397774). Although it was only the beginning of our thinking, we did came up with a sort of a replay for solution. We added the complexity of having to migrate also the collaborating processes, that's why we saw the replay as a possible solution, with the idea of a synchronization with the other processes.
This summer I was looking for an engine to work with and I saw that ODE came with some functionality to suspend instances for migration. I started to look up on migration in the forums, I followed some of the discussions on the subject and I was directed to this Replayer of yours. I was very delighted to see that the idea of replaying the exchanges between processes was thought of something worth to try. It's not an easy thing to achieve, I agree with the comments on the subject that it's probably not a task to fully automatize, but there are some things we can automatize.
Anyhow, I applied the patch and tried it out on my own processes. It didn't work right away, I had to fix the getCurrentEventDateTime in BpelRuntimeContextImpl so that I could use getCommunication on my own processes. I have another problem when I try to replay an incoming message that is suppose to be associated with the instance through correlation. I noticed that it doesn't find the routing info for the instance while it's looking into the database.
Is it possible that because the replay is done into a unique transaction, when it tries to retrieve the routing info into the database, it fails because the changes have not been commited yet? If this is the case, what would be the best approach to save the changes at each step? I'm guessing that to suspend and migrate the instances at play would be the right approach to take, so if migration fails, I can restore instances to what it was prior to the replay. Is the migration functionality of ODE ready to use? If yes, can someone direct me to some more info on how it works? I'm still not quite familiar with all the guts of ODE but I'll be working on this in the next few months, so any hints would be welcome.
I also noticed that the idea of replaying has been let down for complexity reasons, indeed it is very complexe. Try to add the collaborated processes into the picture... it makes it even harder just to modelize the problem. We've spent the winter playing with different scenarios of change and trying to visualize what would happen during a collaborated migration.
We've decided to go with ODE for implementing our approach. I'll let you know how it went. Thanks for this Replayer. It really helps for a good start in implementing our ideas. I attached our article for consultation, it's really just the beginning of our approach, we should submit another as soon as we have some interesting results with ODE.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747456#action_12747456 ]
Enrico Levesque edited comment on ODE-483 at 8/31/09 1:54 PM:
--------------------------------------------------------------
I'm a graduate student in computer science and we've been thinking a bit on this issue of migrating process instances. We've published an article on the subject in 2008 (http://portal.acm.org/citation.cfm?id=1397774). Although it was only the beginning of our thinking, we did came up with a sort of a replay for solution. We added the complexity of having to migrate also the collaborating processes, that's why we saw the replay as a possible solution, with the idea of a synchronization with the other processes.
This summer I was looking for an engine to work with and I saw that ODE came with some functionality to suspend instances for migration. I started to look up on migration in the forums, I followed some of the discussions on the subject and I was directed to this Replayer of yours. I was very delighted to see that the idea of replaying the exchanges between processes was thought of something worth to try. It's not an easy thing to achieve, I agree with the comments on the subject that it's probably not a task to fully automatize, but there are some things we can automatize.
Anyhow, I applied the patch and tried it out on my own processes. It didn't work right away, I had to fix the getCurrentEventDateTime in BpelRuntimeContextImpl so that I could use getCommunication on my own processes. I have another problem when I try to replay an incoming message that is suppose to be associated with the instance through correlation. I noticed that it doesn't find the routing info for the instance while it's looking into the database. Do you have any idea of what could cause the problem?
was (Author: enricolds):
Hi Rafal (and others interested in the subject),
I'm a graduate student in computer science and we've been thinking a bit on this issue of migrating process instances. We've published an article on the subject in 2008 (http://portal.acm.org/citation.cfm?id=1397774). Although it was only the beginning of our thinking, we did came up with a sort of a replay for solution. We added the complexity of having to migrate also the collaborating processes, that's why we saw the replay as a possible solution, with the idea of a synchronization with the other processes.
This summer I was looking for an engine to work with and I saw that ODE came with some functionality to suspend instances for migration. I started to look up on migration in the forums, I followed some of the discussions on the subject and I was directed to this Replayer of yours. I was very delighted to see that the idea of replaying the exchanges between processes was thought of something worth to try. It's not an easy thing to achieve, I agree with the comments on the subject that it's probably not a task to fully automatize, but there are some things we can automatize.
Anyhow, I applied the patch and tried it out on my own processes. It didn't work right away, I had to fix the getCurrentEventDateTime in BpelRuntimeContextImpl so that I could use getCommunication on my own processes. I have another problem when I try to replay an incoming message that is suppose to be associated with the instance through correlation. I noticed that it doesn't find the routing info for the instance while it's looking into the database. Do you have any idea of what could cause the problem?
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Enrico Levesque updated ODE-483:
--------------------------------
Attachment: bookshop-example-4.zip
bookshop-example-1.zip
I added 2 project examples, deployment zip files and the soapUI xml projects to test the processes. They are 2 versions of a bookshop example, the first one without correlation and the second with correlation. I used those to test the Replayer, one all automatize and the second requires the response of a financial analyst.
The first one works fine with the Replayer, since there is no correlation. The second works if the instance stop before the exchange that comes in asynchronously from FinancialAnalyst, but it doesn't retrieve the instance by correlation during replay if you try to replay the whole process after completion.
For the processes to work, you need to run the mock services inside SoapUI. I just used SoapUI to send my messages from the interfaces provided. Sorry I didn't take the time to setup a test case yet.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747456#action_12747456 ]
Enrico Levesque edited comment on ODE-483 at 8/31/09 1:51 PM:
--------------------------------------------------------------
Hi Rafal (and others interested in the subject),
I'm a graduate student in computer science and we've been thinking a bit on this issue of migrating process instances. We've published an article on the subject in 2008 (http://portal.acm.org/citation.cfm?id=1397774). Although it was only the beginning of our thinking, we did came up with a sort of a replay for solution. We added the complexity of having to migrate also the collaborating processes, that's why we saw the replay as a possible solution, with the idea of a synchronization with the other processes.
This summer I was looking for an engine to work with and I saw that ODE came with some functionality to suspend instances for migration. I started to look up on migration in the forums, I followed some of the discussions on the subject and I was directed to this Replayer of yours. I was very delighted to see that the idea of replaying the exchanges between processes was thought of something worth to try. It's not an easy thing to achieve, I agree with the comments on the subject that it's probably not a task to fully automatize, but there are some things we can automatize.
Anyhow, I applied the patch and tried it out on my own processes. It didn't work right away, I had to fix the getCurrentEventDateTime in BpelRuntimeContextImpl so that I could use getCommunication on my own processes. I have another problem when I try to replay an incoming message that is suppose to be associated with the instance through correlation. I noticed that it doesn't find the routing info for the instance while it's looking into the database. Do you have any idea of what could cause the problem?
was (Author: enricolds):
Hi Rafal (and others interested in the subject),
I'm a graduate student in computer science and we've been thinking a bit on this issue of migrating process instances. We've published an article on the subject in 2008 (http://portal.acm.org/citation.cfm?id=1397774). Although it was only the beginning of our thinking, we did came up with a sort of a replay for solution. We added the complexity of having to migrate also the collaborating processes, that's why we saw the replay as a possible solution, with the idea of a synchronization with the other processes.
This summer I was looking for an engine to work with and I saw that ODE came with some functionality to suspend instances for migration. I started to look up on migration in the forums, I followed some of the discussions on the subject and I was directed to this Replayer of yours. I was very delighted to see that the idea of replaying the exchanges between processes was thought of something worth to try. It's not an easy thing to achieve, I agree with the comments on the subject that it's probably not a task to fully automatize, but there are some things we can automatize.
Anyhow, I applied the patch and tried it out on my own processes. It didn't work right away, I had to fix the getCurrentEventDateTime in BpelRuntimeContextImpl so that I could use getCommunication on my own processes. I have another problem when I try to replay an incoming message that is suppose to be associated with the instance through correlation. I noticed that it doesn't find the routing info for the instance while it's looking into the database.
Is it possible that because the replay is done into a unique transaction, when it tries to retrieve the routing info into the database, it fails because the changes have not been commited yet? If this is the case, what would be the best approach to save the changes at each step? I'm guessing that to suspend and migrate the instances at play would be the right approach to take, so if migration fails, I can restore instances to what it was prior to the replay. Is the migration functionality of ODE ready to use? If yes, can someone direct me to some more info on how it works? I'm still not quite familiar with all the guts of ODE but I'll be working on this in the next few months, so any hints would be welcome.
I also noticed that the idea of replaying has been let down for complexity reasons, indeed it is very complexe. Try to add the collaborated processes into the picture... it makes it even harder just to modelize the problem. We've spent the winter playing with different scenarios of change and trying to visualize what would happen during a collaborated migration.
We've decided to go with ODE for implementing our approach. I'll let you know how it went. Thanks for this Replayer. It really helps for a good start in implementing our ideas. I attached our article for consultation, it's really just the beginning of our approach, we should submit another as soon as we have some interesting results with ODE.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-483) Add serialize/deserialize process
instances in Management API
Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676741#action_12676741 ]
Alex Boisvert commented on ODE-483:
-----------------------------------
Indeed, a comprehensive solution requires taking into account timers and continuations.... e.g., by migrating all outstanding (internal) timer events
> Add serialize/deserialize process instances in Management API
> -------------------------------------------------------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: replayer.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Enrico Levesque updated ODE-483:
--------------------------------
Attachment: Khriss-AdaptabilitySupport.pdf
Towards Adaptability Support in Collaborative Business Processes
Some approaches propose solutions to support business process adaptability; however, they do not handle adaptability in the context of multi-partner collaborative business processes. In this paper, we propose a new approach to support adaptability for such collaborative processes. This approach uses a protocol, called Change Protocol for Collaboration (CPC), for managing the changes that can have incidence on the contract.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Enrico Levesque updated ODE-483:
--------------------------------
Comment: was deleted
(was: I updated the 2 project examples with images of the BPMN diagrams to help understand the bookshop examples.)
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff, replayer-test2-soapui-project.xml
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Enrico Levesque updated ODE-483:
--------------------------------
Attachment: (was: bookshop-example-1.zip)
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-483) Add serialize/deserialize process
instances in Management API
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafal Rusin updated ODE-483:
----------------------------
Attachment: (was: replayer.diff)
> Add serialize/deserialize process instances in Management API
> -------------------------------------------------------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749969#action_12749969 ]
Enrico Levesque edited comment on ODE-483 at 9/2/09 6:48 AM:
-------------------------------------------------------------
I updated the 2 project examples with images of the BPMN diagrams to help understand the bookshop examples.
was (Author: enricolds):
I updated the 2 project examples with images of the BPMN diagram to help understanding the bookshop examples.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff, replayer-test2-soapui-project.xml
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748912#action_12748912 ]
Enrico Levesque edited comment on ODE-483 at 8/31/09 1:56 PM:
--------------------------------------------------------------
As I said earlier, I was able to run the Replayer on my own processes but with some modifications. I still get an error though when it needs to retrieve an instance by correlation.
I added this fix to BpelRuntimeContextImpl.getCurrentEventDateTime() :
was -
public Date getCurrentEventDateTime() {
return _currentEventDateTime;
}
changed to -
public Date getCurrentEventDateTime() {
if (_currentEventDateTime == null)
return Calendar.getInstance().getTime();
else
return _currentEventDateTime;
}
This other fix to invoke(...) in the same class :
was -
...
MessageExchangeDAO mexDao = _dao.getConnection().createMessageExchange(
MessageExchangeDAO.DIR_BPEL_INVOKES_PARTNERROLE);
mexDao.setStatus(MessageExchange.Status.NEW.toString());
mexDao.setOperation(operation.getName());
...
changed to -
MessageExchangeDAO mexDao = _dao.getConnection().createMessageExchange(
MessageExchangeDAO.DIR_BPEL_INVOKES_PARTNERROLE);
/* modif enrico */
mexDao.setCreateTime(getCurrentEventDateTime());
mexDao.setStatus(MessageExchange.Status.NEW.toString());
mexDao.setOperation(operation.getName());
This fix to PartnerLinkMyRoleImpl.invoke(...) :
was -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.CREATE_INSTANCE);
mex.getDAO().setInstance(newInstance);
instance.execute();
changed to -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.CREATE_INSTANCE);
mex.getDAO().setInstance(newInstance);
/* modif enrico
* createTime needs to be initialized for getCommunication in Replayer*/
if (mex.getDAO().getCreateTime() == null)
mex.getDAO().setCreateTime(instance.getCurrentEventDateTime());
instance.execute();
And into invokeInstance(...) of the same class :
was -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.MATCHED);
mex.getDAO().setInstance(routing.messageRoute.getTargetInstance());
instance.execute();
changed to -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.MATCHED);
mex.getDAO().setInstance(routing.messageRoute.getTargetInstance());
/* modif enrico
* if createTime need to be initialized */
if (mex.getDAO().getCreateTime() == null)
mex.getDAO().setCreateTime(instance.getCurrentEventDateTime());
instance.execute();
I also did two other fix but I never verified if they where necessary.
ASSIGN
public Date getCurrentEventDateTime() {
/* enrico modif */
//return null;
return Calendar.getInstance().getTime();
}
PropertyAliasEvaluationContext
public Date getCurrentEventDateTime() {
/* enrico modif */
return Calendar.getInstance().getTime();
//return null;
}
These where necessary so we can use getCommunication on instances created without the Replayer.
was (Author: enricolds):
Hi all,
I was able to run the Replayer on my own processes but with some modifications. I still get an error though when it needs to retrieve an instance by correlation.
I added this fix to BpelRuntimeContextImpl.getCurrentEventDateTime() :
was -
public Date getCurrentEventDateTime() {
return _currentEventDateTime;
}
changed to -
public Date getCurrentEventDateTime() {
if (_currentEventDateTime == null)
return Calendar.getInstance().getTime();
else
return _currentEventDateTime;
}
This other fix to invoke(...) in the same class :
was -
...
MessageExchangeDAO mexDao = _dao.getConnection().createMessageExchange(
MessageExchangeDAO.DIR_BPEL_INVOKES_PARTNERROLE);
mexDao.setStatus(MessageExchange.Status.NEW.toString());
mexDao.setOperation(operation.getName());
...
changed to -
MessageExchangeDAO mexDao = _dao.getConnection().createMessageExchange(
MessageExchangeDAO.DIR_BPEL_INVOKES_PARTNERROLE);
/* modif enrico */
mexDao.setCreateTime(getCurrentEventDateTime());
mexDao.setStatus(MessageExchange.Status.NEW.toString());
mexDao.setOperation(operation.getName());
This fix to PartnerLinkMyRoleImpl.invoke(...) :
was -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.CREATE_INSTANCE);
mex.getDAO().setInstance(newInstance);
instance.execute();
changed to -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.CREATE_INSTANCE);
mex.getDAO().setInstance(newInstance);
/* modif enrico
* createTime needs to be initialized for getCommunication in Replayer*/
if (mex.getDAO().getCreateTime() == null)
mex.getDAO().setCreateTime(instance.getCurrentEventDateTime());
instance.execute();
And into invokeInstance(...) of the same class :
was -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.MATCHED);
mex.getDAO().setInstance(routing.messageRoute.getTargetInstance());
instance.execute();
changed to -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.MATCHED);
mex.getDAO().setInstance(routing.messageRoute.getTargetInstance());
/* modif enrico
* if createTime need to be initialized */
if (mex.getDAO().getCreateTime() == null)
mex.getDAO().setCreateTime(instance.getCurrentEventDateTime());
instance.execute();
I also did two other fix but I never verified if they where necessary.
ASSIGN
public Date getCurrentEventDateTime() {
/* enrico modif */
//return null;
return Calendar.getInstance().getTime();
}
PropertyAliasEvaluationContext
public Date getCurrentEventDateTime() {
/* enrico modif */
return Calendar.getInstance().getTime();
//return null;
}
These where necessary so we can use getCommunication on instances created without the Replayer.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749956#action_12749956 ]
Enrico Levesque edited comment on ODE-483 at 9/2/09 6:40 AM:
-------------------------------------------------------------
ODE Replayer with process collaboration support : Project description
The project will be to build a migration tool to enable ODE to replay with human assistance long running collaborative process instances. The purpose of this tool is to ease the work of the analysts during the process of migrating multiple collaborative long running instances from one version of a process to another.
The tool will replay the exchange messages that occured during past executions. It will take automatically new routes during process execution and will determine what kind of invokes to do, blank execution or synchronization with other processes.
A synchronization consist in sending a message to the server running another process each time the instance in migration calls that process through an invoke activity. When the engine receives a synchronization message, it replays the instance refered to using the same Replayer, expanding automatically the migration to the other collaborating processes.
The tool will ask for analyst intervention to determine the right values to insert when the instance is waiting for an asynchronous human exchange to be re-introduced into the process. For this purpose, a web interface will be created informing the analyst of all exchange messages waiting to be replayed. The analyst will be informed when the instances is waiting for a human exchange or any kind of unsynchronized exchange to be re-introduced. This interface will then permit the analyst to supervise, manage and pilot the migration process.
This Replayer will be able to determine which previous invokes need to be compensated due to data changes or flow changes. The compensations will be done by analysts directly into the databases, or will be ignored depending on each case.
For this kind of migration to work, an important assomption need to always be true: that we can at any time compensate a previous activity. If a critical compensation cannot be done, the migration will have to be aborted, therefore the necessity to be able to restore to original state at any time during migration.
was (Author: enricolds):
ODE Replayer with process collaboration support : Project description
The project will be to build a migration tool to enable ODE to replay with human assistance long running collaborative process instances. The purpose of this tool is to ease the work of the analysts during the process of migrating multiple collaborative long running instances from one version of a process to another.
The tool will replay the exchange messages that occured during past executions. It will take automatically new routes during process execution and will determine what kind of invokes to do, blank execution or synchronization with other processes.
A synchronization consist in sending a message to the server running another process each time the instance in migration calls that process through an invoke activity. When the engine receives a synchronization message, it replays the instance refered to using the same Replayer, expanding the migration to the other collaborating processes.
The tool will ask for analyst intervention to determine the right values to insert when the instance is waiting for an asynchronous human exchange to be re-introduced into the process. For this purpose, a web interface will be created informing the analyst of all exchange messages waiting to be replayed. The analyst will be informed when the instances is waiting for a human exchange or any kind of unsynchronized exchange to be re-introduced. This interface will then permit the analyst to supervise, manage and pilot the migration process.
This Replayer will be able to determine which previous invokes need to be compensated due to data changes or flow changes. The compensations will be done by analysts directly into the databases, or will be ignored depending on each case.
For this kind of migration to work, an important assomption need to always be true: that we can at any time compensate a previous activity. If a critical compensation cannot be done, the migration will have to be aborted, therefore the necessity to be able to restore to original state at any time during migration.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff, replayer-test2-soapui-project.xml
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749910#action_12749910 ]
Enrico Levesque edited comment on ODE-483 at 9/1/09 7:05 AM:
-------------------------------------------------------------
I added 2 project examples, deployment zip files and the soapUI xml projects to test the processes. They are 2 versions of a bookshop example, the first one without correlation and the second with correlation. I used those to test the Replayer, one all automatize and the second requires the response of a financial analyst.
The first one works fine with the Replayer, since there is no correlation. The second works if the instance stop before the exchange that comes in asynchronously from FinancialAnalyst, but it doesn't retrieve the instance by correlation during replay if you try to replay the whole process after completion.
For the processes to work, you need to run the mock services inside SoapUI. I just used SoapUI to send my messages from the interfaces provided. Sorry I didn't take the time to setup a one button test case yet.
was (Author: enricolds):
I added 2 project examples, deployment zip files and the soapUI xml projects to test the processes. They are 2 versions of a bookshop example, the first one without correlation and the second with correlation. I used those to test the Replayer, one all automatize and the second requires the response of a financial analyst.
The first one works fine with the Replayer, since there is no correlation. The second works if the instance stop before the exchange that comes in asynchronously from FinancialAnalyst, but it doesn't retrieve the instance by correlation during replay if you try to replay the whole process after completion.
For the processes to work, you need to run the mock services inside SoapUI. I just used SoapUI to send my messages from the interfaces provided. Sorry I didn't take the time to setup a test case yet.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747460#action_12747460 ]
Enrico Levesque edited comment on ODE-483 at 8/25/09 8:28 AM:
--------------------------------------------------------------
Attached PDF : Towards Adaptability Support in Collaborative Business Processes
"Some approaches propose solutions to support business process adaptability; however, they do not handle adaptability in the context of multi-partner collaborative business processes. In this paper, we propose a new approach to support adaptability for such collaborative processes. This approach uses a protocol, called Change Protocol for Collaboration (CPC), for managing the changes that can have incidence on the contract." (extracted from the abstract)
was (Author: enricolds):
Attached PDF : Towards Adaptability Support in Collaborative Business Processes
Extract from the abstract :
Some approaches propose solutions to support business process adaptability; however, they do not handle adaptability in the context of multi-partner collaborative business processes. In this paper, we propose a new approach to support adaptability for such collaborative processes. This approach uses a protocol, called Change Protocol for Collaboration (CPC), for managing the changes that can have incidence on the contract.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Enrico Levesque updated ODE-483:
--------------------------------
Attachment: replayer-test2-soapui-project.xml
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff, replayer-test2-soapui-project.xml
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Enrico Levesque updated ODE-483:
--------------------------------
Attachment: bookshop-example-4.zip
bookshop-example-1.zip
I updated the 2 project examples with images of the BPMN diagram to help with the visualization of the bookshop examples.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749917#action_12749917 ]
Enrico Levesque commented on ODE-483:
-------------------------------------
Of course I'm planning to add collaboration to the Replayer. I'll work on a solution description and post it as soon as I comme up with something more concrete.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749969#action_12749969 ]
Enrico Levesque edited comment on ODE-483 at 9/2/09 6:21 AM:
-------------------------------------------------------------
I updated the 2 project examples with images of the BPMN diagram to help understanding the bookshop examples.
was (Author: enricolds):
I updated the 2 project examples with images of the BPMN diagram to help with the visualization of the bookshop examples.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747456#action_12747456 ]
Enrico Levesque edited comment on ODE-483 at 8/31/09 1:58 PM:
--------------------------------------------------------------
I'm a graduate student in computer science and we've been thinking a bit on this issue of migrating process instances. We've published an article on the subject in 2008 (http://portal.acm.org/citation.cfm?id=1397774). Although it was only the beginning of our thinking, we did came up with a sort of a replay for solution. We added the complexity of having to migrate also the collaborating processes, that's why we saw the replay as a possible solution, with the idea of a synchronization with the other processes.
We were looking for an engine to use to implement our approach and when I saw this Replayer I thought it would be good to give it a try for a start. I applied the patch and tried it out on my own processes. It didn't work right away, I had to fix the getCurrentEventDateTime in BpelRuntimeContextImpl so that I could use getCommunication on my own processes. I have another problem when I try to replay an incoming message that is suppose to be associated with the instance through correlation. I noticed that it doesn't find the routing info for the instance while it's looking into the database. Do you have any idea of what could cause the problem?
was (Author: enricolds):
I'm a graduate student in computer science and we've been thinking a bit on this issue of migrating process instances. We've published an article on the subject in 2008 (http://portal.acm.org/citation.cfm?id=1397774). Although it was only the beginning of our thinking, we did came up with a sort of a replay for solution. We added the complexity of having to migrate also the collaborating processes, that's why we saw the replay as a possible solution, with the idea of a synchronization with the other processes.
This summer I was looking for an engine to work with and I saw that ODE came with some functionality to suspend instances for migration. I started to look up on migration in the forums, I followed some of the discussions on the subject and I was directed to this Replayer of yours. I was very delighted to see that the idea of replaying the exchanges between processes was thought of something worth to try. It's not an easy thing to achieve, I agree with the comments on the subject that it's probably not a task to fully automatize, but there are some things we can automatize.
Anyhow, I applied the patch and tried it out on my own processes. It didn't work right away, I had to fix the getCurrentEventDateTime in BpelRuntimeContextImpl so that I could use getCommunication on my own processes. I have another problem when I try to replay an incoming message that is suppose to be associated with the instance through correlation. I noticed that it doesn't find the routing info for the instance while it's looking into the database. Do you have any idea of what could cause the problem?
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-483) Add serialize/deserialize process
instances in Management API
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafal Rusin updated ODE-483:
----------------------------
Fix Version/s: Wishlist
> Add serialize/deserialize process instances in Management API
> -------------------------------------------------------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749910#action_12749910 ]
Enrico Levesque edited comment on ODE-483 at 9/2/09 6:31 AM:
-------------------------------------------------------------
I added 2 project examples, deployment zip files and the soapUI xml projects to test the processes. They are 2 versions of a bookshop example, the first one without correlation and the second with correlation. I used those to test the Replayer, one all automatize and the second requires the response of a financial analyst.
The first one works fine with the Replayer, since there is no correlation. The second works if the instance stop before the exchange that comes in asynchronously from FinancialAnalyst, but it doesn't retrieve the instance by correlation during replay if you try to replay the whole process after completion.
To run tests, you need first to run the mock services inside SoapUI and then send the messages using the interfaces provided. Use CanonicBindingForClient to send the PurchaseOrder, and CanonicBindingForFinancialAnalyst to send the CreditAuthorization or CreditDenial in the second example. Then I used replayer-test2-soapui-project.xml to test the replayer. In the second example, you need to update the reference number at each run because this number is used to identify instances.
Sorry I didn't take the time to setup a one click test case yet.
was (Author: enricolds):
I added 2 project examples, deployment zip files and the soapUI xml projects to test the processes. They are 2 versions of a bookshop example, the first one without correlation and the second with correlation. I used those to test the Replayer, one all automatize and the second requires the response of a financial analyst.
The first one works fine with the Replayer, since there is no correlation. The second works if the instance stop before the exchange that comes in asynchronously from FinancialAnalyst, but it doesn't retrieve the instance by correlation during replay if you try to replay the whole process after completion.
For the processes to work, you need to run the mock services inside SoapUI. I just used SoapUI to send my messages from the interfaces provided. Sorry I didn't take the time to setup a one click test case yet.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff, replayer-test2-soapui-project.xml
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749956#action_12749956 ]
Enrico Levesque edited comment on ODE-483 at 9/1/09 8:55 AM:
-------------------------------------------------------------
ODE Replayer with process collaboration support : Project description
The project is to build a migration tool to enable ODE to replay with human assistance long running collaborative process instances. The purpose of this tool is to ease the work of the analysts during the process of migrating multiple collaborative long running instances from one version of a process to another.
The tool will replay the exchange messages that occured during past executions. It will take automatically new routes during process execution and will determine what kind of invokes to do, blank execution or synchronization with other processes.
The tool will ask for analyst intervention to determine the right values to insert when the instance is waiting for an asynchronous human exchange to be re-introduced into the process. For this purpose, a web interface will be created informing the analyst of all exchange messages waiting to be replayed. The analyst will be informed when the instances is waiting for a human exchange or any kind of non-process exchanges to be re-introduced. This interface will then permit the analyst to supervise, manage and pilot the migration process.
This Replayer will be able to determine which previous invokes need to be compensated due to data changes or flow changes. The compensations will be done by analysts directly into the databases, or will be ignored depending on each case.
For this kind of migration to work, an important assomption need to always be true: that we can at any time compensate a previous activity. If a critical compensation cannot be done, the migration will have to be aborted, therefore the necessity to be able to restore to original state at any time during migration.
was (Author: enricolds):
ODE Replayer with process collaboration support : Project description
The project is to build a tool for migration into Apache ODE to enable it to replay long running collaborative process instances along with human assistance. The purpose of this tool is to ease the work of the analysts during the process of migrating multiple collaborative long running instances from one version of a process to another modified.
The tool will replay the exchange messages that occured during the past execution. It will take automatically new routes during process execution and will determine what kind of invokes to do, blank execution or synchronization with other processes.
The tool will ask for analyst intervention to determine the right values to insert when the instance is waiting for an asynchronous human exchange to be re-introduced into the process. For this purpose, a web interface will be created informing the analyst of all exchange messages waiting to be replayed. The analyst will be informed when the instances is waiting for a human exchange or any kind of non-process exchanges to be re-introduced. This interface will then permit the analyst to supervise, manage and pilot the migration process.
This Replayer will be able to determine which previous invokes need to be compensated due to data changes or flow changes. The compensations will be done by analysts directly into the databases, or will be ignored depending on each case.
For this kind of migration to work, an important assomption need to always be true: that we can at any time compensate a previous activity. If a critical compensation cannot be done, the migration will have to be aborted, therefore the necessity to be able to restore to original state at any time during migration.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-483) Add serialize/deserialize process
instances in Management API
Posted by "Tammo van Lessen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668027#action_12668027 ]
Tammo van Lessen commented on ODE-483:
--------------------------------------
Some thoughts on that were discussed on the mailinglist. Here is the link: http://markmail.org/thread/kvklwqjadkjfa52d
> Add serialize/deserialize process instances in Management API
> -------------------------------------------------------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-483) Add serialize/deserialize process
instances in Management API
Posted by "Tammo van Lessen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676738#action_12676738 ]
Tammo van Lessen commented on ODE-483:
--------------------------------------
Sound very interesting. However, my gut feeling is that just considering the communication part of processes it not sufficient in all cases. How does it work with long-running processes?
Let's think of the following example (pseudo BPEL):
<sequence>
<receive operation="x" variable="v" createInstance="yes"/>
<wait for="3yrs"/>
<reply operation="x" variable="v"/>
</sequence>
What happens if I try to migrate the process after 2 years?
> Add serialize/deserialize process instances in Management API
> -------------------------------------------------------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: replayer.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748912#action_12748912 ]
Enrico Levesque edited comment on ODE-483 at 8/28/09 12:22 PM:
---------------------------------------------------------------
Hi all,
I was able to run the Replayer on my own processes but with some modifications. I still get an error though when it needs to retrieve an instance by correlation.
I added this fix to BpelRuntimeContextImpl.getCurrentEventDateTime() :
was -
public Date getCurrentEventDateTime() {
return _currentEventDateTime;
}
changed to -
public Date getCurrentEventDateTime() {
if (_currentEventDateTime == null)
return Calendar.getInstance().getTime();
else
return _currentEventDateTime;
}
This other fix to invoke(...) in the same class :
was -
...
MessageExchangeDAO mexDao = _dao.getConnection().createMessageExchange(
MessageExchangeDAO.DIR_BPEL_INVOKES_PARTNERROLE);
mexDao.setStatus(MessageExchange.Status.NEW.toString());
mexDao.setOperation(operation.getName());
...
changed to -
MessageExchangeDAO mexDao = _dao.getConnection().createMessageExchange(
MessageExchangeDAO.DIR_BPEL_INVOKES_PARTNERROLE);
/* modif enrico */
mexDao.setCreateTime(getCurrentEventDateTime());
mexDao.setStatus(MessageExchange.Status.NEW.toString());
mexDao.setOperation(operation.getName());
This fix to PartnerLinkMyRoleImpl.invoke(...) :
was -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.CREATE_INSTANCE);
mex.getDAO().setInstance(newInstance);
instance.execute();
changed to -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.CREATE_INSTANCE);
mex.getDAO().setInstance(newInstance);
/* modif enrico
* createTime needs to be initialized for getCommunication in Replayer*/
if (mex.getDAO().getCreateTime() == null)
mex.getDAO().setCreateTime(instance.getCurrentEventDateTime());
instance.execute();
And into invokeInstance(...) of the same class :
was -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.MATCHED);
mex.getDAO().setInstance(routing.messageRoute.getTargetInstance());
instance.execute();
changed to -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.MATCHED);
mex.getDAO().setInstance(routing.messageRoute.getTargetInstance());
/* modif enrico
* if createTime need to be initialized */
if (mex.getDAO().getCreateTime() == null)
mex.getDAO().setCreateTime(instance.getCurrentEventDateTime());
instance.execute();
I also did two other fix but I never verified if they where necessary.
ASSIGN
public Date getCurrentEventDateTime() {
/* enrico modif */
//return null;
return Calendar.getInstance().getTime();
}
PropertyAliasEvaluationContext
public Date getCurrentEventDateTime() {
/* enrico modif */
return Calendar.getInstance().getTime();
//return null;
}
These where necessary so we can use getCommunication on instances created without the Replayer.
was (Author: enricolds):
Hi all,
I was able to run the Replayer on my own processes but with some modifications as explained earlier, but the processes need to be RUNNING IN MEMORY.
I added this fix to BpelRuntimeContextImpl.getCurrentEventDateTime() :
was -
public Date getCurrentEventDateTime() {
return _currentEventDateTime;
}
changed to -
public Date getCurrentEventDateTime() {
if (_currentEventDateTime == null)
return Calendar.getInstance().getTime();
else
return _currentEventDateTime;
}
This other fix to invoke(...) in the same class :
was -
...
MessageExchangeDAO mexDao = _dao.getConnection().createMessageExchange(
MessageExchangeDAO.DIR_BPEL_INVOKES_PARTNERROLE);
mexDao.setStatus(MessageExchange.Status.NEW.toString());
mexDao.setOperation(operation.getName());
...
changed to -
MessageExchangeDAO mexDao = _dao.getConnection().createMessageExchange(
MessageExchangeDAO.DIR_BPEL_INVOKES_PARTNERROLE);
/* modif enrico */
mexDao.setCreateTime(getCurrentEventDateTime());
mexDao.setStatus(MessageExchange.Status.NEW.toString());
mexDao.setOperation(operation.getName());
This fix to PartnerLinkMyRoleImpl.invoke(...) :
was -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.CREATE_INSTANCE);
mex.getDAO().setInstance(newInstance);
instance.execute();
changed to -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.CREATE_INSTANCE);
mex.getDAO().setInstance(newInstance);
/* modif enrico
* createTime needs to be initialized for getCommunication in Replayer*/
if (mex.getDAO().getCreateTime() == null)
mex.getDAO().setCreateTime(instance.getCurrentEventDateTime());
instance.execute();
And into invokeInstance(...) of the same class :
was -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.MATCHED);
mex.getDAO().setInstance(routing.messageRoute.getTargetInstance());
instance.execute();
changed to -
mex.setCorrelationStatus(MyRoleMessageExchange.CorrelationStatus.MATCHED);
mex.getDAO().setInstance(routing.messageRoute.getTargetInstance());
/* modif enrico
* if createTime need to be initialized */
if (mex.getDAO().getCreateTime() == null)
mex.getDAO().setCreateTime(instance.getCurrentEventDateTime());
instance.execute();
I also did two other fix but I never verified if they where necessary.
ASSIGN
public Date getCurrentEventDateTime() {
/* enrico modif */
//return null;
return Calendar.getInstance().getTime();
}
PropertyAliasEvaluationContext
public Date getCurrentEventDateTime() {
/* enrico modif */
return Calendar.getInstance().getTime();
//return null;
}
These where necessary so we can use getCommunication on instances created without the Replayer.
replayInstances works again but only when processes are executed in memory.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Enrico Levesque updated ODE-483:
--------------------------------
Comment: was deleted
(was: Of course I'm planning to add collaboration to the Replayer. I'll work on a solution description and post it as soon as I comme up with something more concrete.)
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-483) Instance replayer
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafal Rusin updated ODE-483:
----------------------------
Summary: Instance replayer (was: Add serialize/deserialize process instances in Management API)
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: replayer-example.zip, replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-483) Instance replayer
Posted by "Enrico Levesque (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749956#action_12749956 ]
Enrico Levesque edited comment on ODE-483 at 9/2/09 6:37 AM:
-------------------------------------------------------------
ODE Replayer with process collaboration support : Project description
The project will be to build a migration tool to enable ODE to replay with human assistance long running collaborative process instances. The purpose of this tool is to ease the work of the analysts during the process of migrating multiple collaborative long running instances from one version of a process to another.
The tool will replay the exchange messages that occured during past executions. It will take automatically new routes during process execution and will determine what kind of invokes to do, blank execution or synchronization with other processes.
A synchronization consist in sending a message to the server running another process each time the instance in migration calls that process through an invoke activity. When the engine receives a synchronization message, it replays the instance refered to using the same Replayer, expanding the migration to the other collaborating processes.
The tool will ask for analyst intervention to determine the right values to insert when the instance is waiting for an asynchronous human exchange to be re-introduced into the process. For this purpose, a web interface will be created informing the analyst of all exchange messages waiting to be replayed. The analyst will be informed when the instances is waiting for a human exchange or any kind of unsynchronized exchange to be re-introduced. This interface will then permit the analyst to supervise, manage and pilot the migration process.
This Replayer will be able to determine which previous invokes need to be compensated due to data changes or flow changes. The compensations will be done by analysts directly into the databases, or will be ignored depending on each case.
For this kind of migration to work, an important assomption need to always be true: that we can at any time compensate a previous activity. If a critical compensation cannot be done, the migration will have to be aborted, therefore the necessity to be able to restore to original state at any time during migration.
was (Author: enricolds):
ODE Replayer with process collaboration support : Project description
The project is to build a migration tool to enable ODE to replay with human assistance long running collaborative process instances. The purpose of this tool is to ease the work of the analysts during the process of migrating multiple collaborative long running instances from one version of a process to another.
The tool will replay the exchange messages that occured during past executions. It will take automatically new routes during process execution and will determine what kind of invokes to do, blank execution or synchronization with other processes.
The tool will ask for analyst intervention to determine the right values to insert when the instance is waiting for an asynchronous human exchange to be re-introduced into the process. For this purpose, a web interface will be created informing the analyst of all exchange messages waiting to be replayed. The analyst will be informed when the instances is waiting for a human exchange or any kind of non-process exchanges to be re-introduced. This interface will then permit the analyst to supervise, manage and pilot the migration process.
This Replayer will be able to determine which previous invokes need to be compensated due to data changes or flow changes. The compensations will be done by analysts directly into the databases, or will be ignored depending on each case.
For this kind of migration to work, an important assomption need to always be true: that we can at any time compensate a previous activity. If a critical compensation cannot be done, the migration will have to be aborted, therefore the necessity to be able to restore to original state at any time during migration.
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff, replayer-test2-soapui-project.xml
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-483) Instance replayer
Posted by "Rafal Rusin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752690#action_12752690 ]
Rafal Rusin commented on ODE-483:
---------------------------------
I also submitted Enrico Lévesque's fixes, which he provided, Thanks Enrico for your involvement!
We cloned apache repo into github for collaboration, so detailed history of commits is available here: http://github.com/rafalrusin/apache-ode/tree/APACHE_ODE_1.X-Replayer
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: bookshop-example-1.zip, bookshop-example-4.zip, Khriss-AdaptabilitySupport.pdf, replayer-example.zip, replayer-proposal.diff, replayer-test2-soapui-project.xml
>
>
> Imagine situation when client has deployed a process with a lot of active, long running instances. Then he finds there's a bug in this process and a simple bugfix is needed. But with current versioning rules, new version is only used when new instances are created. So there's no simple way for doing such bufixes (which are usually possible with eg. java application using database connection). It is a blocking argument for deploying ODE Bpel solution instead of a regular java application.
> I think the best way to deal with such situations is to add serialize/deserialize to/from xml operations for process instances in management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.