Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: Wishlist
    • Fix Version/s: 1.3.4
    • Component/s: None
    • Labels:
      None

      Description

      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

      1. replayer-test2-soapui-project.xml
        89 kB
        Enrico Levesque
      2. replayer-proposal.diff
        68 kB
        Rafal Rusin
      3. replayer-example.zip
        27 kB
        Rafal Rusin
      4. Khriss-AdaptabilitySupport.pdf
        454 kB
        Enrico Levesque
      5. bookshop-example-4.zip
        62 kB
        Enrico Levesque
      6. bookshop-example-1.zip
        61 kB
        Enrico Levesque

        Activity

        Hide
        Rafal Rusin added a comment -

        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

        Show
        Rafal Rusin added a comment - 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
        Hide
        Rafal Rusin added a comment -

        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.

        Show
        Rafal Rusin added a comment - 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.
        Hide
        Enrico Levesque added a comment - - edited

        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.

        Show
        Enrico Levesque added a comment - - edited 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.
        Hide
        Enrico Levesque added a comment - - edited

        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.

        Show
        Enrico Levesque added a comment - - edited 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.
        Hide
        Rafal Rusin added a comment -

        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.

        Show
        Rafal Rusin added a comment - 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.
        Hide
        Enrico Levesque added a comment - - edited

        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.

        Show
        Enrico Levesque added a comment - - edited 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.
        Hide
        Enrico Levesque added a comment - - edited

        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)

        Show
        Enrico Levesque added a comment - - edited 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)
        Hide
        Enrico Levesque added a comment - - edited

        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?

        Show
        Enrico Levesque added a comment - - edited 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?
        Hide
        Rafal Rusin added a comment -

        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="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.
        Show
        Rafal Rusin added a comment - 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 ="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.
        Hide
        Rafal Rusin added a comment -

        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.

        Show
        Rafal Rusin added a comment - 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.
        Hide
        Alex Boisvert added a comment -

        Indeed, a comprehensive solution requires taking into account timers and continuations.... e.g., by migrating all outstanding (internal) timer events

        Show
        Alex Boisvert added a comment - Indeed, a comprehensive solution requires taking into account timers and continuations.... e.g., by migrating all outstanding (internal) timer events
        Hide
        Tammo van Lessen added a comment -

        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?

        Show
        Tammo van Lessen added a comment - 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?
        Hide
        Rafal Rusin added a comment -

        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.

        Show
        Rafal Rusin added a comment - 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.
        Hide
        Tammo van Lessen added a comment -

        Some thoughts on that were discussed on the mailinglist. Here is the link: http://markmail.org/thread/kvklwqjadkjfa52d

        Show
        Tammo van Lessen added a comment - Some thoughts on that were discussed on the mailinglist. Here is the link: http://markmail.org/thread/kvklwqjadkjfa52d

          People

          • Assignee:
            Rafal Rusin
            Reporter:
            Rafal Rusin
          • Votes:
            8 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development