[CONF] Apache Ode > Instance Replayer

[confluence]

Instance Replayer Page edited by Rafał Rusin Changes (4) ... [https://issues.apache.org/jira/browse/ODE-483|https://issues.apache.org/jira/browse/ODE-483]. h2. Example Attached are example service assembly [^replayer-example-sa.zip] and SoapUI project [^replayer-example-soapui-project.xml]. h2. Usage ... # reproduce error scenarios between two instances of ODE (eg. production and development) Replayer extends management api by 2 operations: replay and getCommunication (see [attachment|^pmapi.wsdl]). pmapi.wsdl from ODE distribution). In order to do 1, you invoke: ... * 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. Check out attached example from attachment. It contains JBI SA with BPEL process and a SoapUI test case for replayer. Full Content Introduction With instance replayer, you are able to upgrade long running process instance to the newest version. There's an ongoing discussion on apache.org in a feature request: https://issues.apache.org/jira/browse/ODE-483. Example Attached are example service assembly replayer-example-sa.zip and SoapUI project replayer-example-soapui-project.xml. Usage The basic use cases for replayer are: migrate existing log running instances to newest process version given their communication (incoming and outgoing requests) reproduce error scenarios between two instances of ODE (eg. production and development) Replayer extends management api by 2 operations: replay and getCommunication (see pmapi.wsdl from ODE distribution). In order to do 1, you invoke: <pmap:replay xmlns:ns="http://www.apache.org/ode/pmapi/types/2006/08/02/"> <replay> <ns:upgradeInstance>1234</ns:upgradeInstance> </replay> </pmap:replay> After this operation, 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 xmlns:ns="http://www.apache.org/ode/pmapi/types/2006/08/02/"> <getCommunication> <ns:iid>1234</ns:iid> </getCommunication> </pmap:getCommunication> You will get some instance's communication, like this: <ns:restoreInstance> <ns:processType xmlns:p="http://sample.bpel.org/bpel/sample">p:OnEventCorrelation</ns:processType> <exchange xmlns="http://www.apache.org/ode/pmapi/types/2006/08/02/"> <type>M</type> <createTime>2009-04-01T16:41:29.873+02:00</createTime> <service xmlns:sam="http://sample.bpel.org/bpel/sample">sam:OnEventCorrelationInit</service> <operation>initiate</operation> <in> <initiate xmlns:sam="http://sample.bpel.org/bpel/sample" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns=""> <payload>abc7</payload> <payload2>abc8</payload2> </initiate> </in> <out> <message xmlns=""> <payload>test1</payload> <payload2/> </message> </out> </exchange> <exchange xmlns:ns="http://www.apache.org/ode/pmapi/types/2006/08/02/" xmlns="http://www.apache.org/ode/pmapi/types/2006/08/02/"> <type>P</type> <createTime>2009-04-01T16:41:32.998+02:00</createTime> <service xmlns:sam="http://sample.bpel.org/bpel/sample">sam:OnEventCorrelation</service> <operation>initiate</operation> <in> <initiate xmlns:sam="http://sample.bpel.org/bpel/sample" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns=""> <payload>abc7</payload> <payload2>abc8</payload2> </initiate> </in> <out> <message xmlns=""> <payload>test5</payload> <payload2/> </message> </out> </exchange> </ns:restoreInstance> 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> And that's it. Time control in BPEL To have control over time in bpel process, there is a new variable introduced, $ode:currentEventDateTime. It's equivalent to $fn:current-dateTime() during live session and it's set to corresponding time in past during replaying. Implementation notes Replaying 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. Replayer 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. Change Notification Preferences View Online | View Changes