[
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.
