[jira] Commented: (ODE-483) Add serialize/deserialize process instances in Management API

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