Author: vanto
Date: Mon Dec 31 15:37:16 2012
New Revision: 1427153
URL: http://svn.apache.org/viewvc?rev=1427153&view=rev
Log:
formatting tweaks.
Modified:
ode/site/trunk/content/bpel-management-api-specification.mdtext
ode/site/trunk/content/instance-replayer.mdtext
ode/site/trunk/content/ode-execution-events.mdtext
ode/site/trunk/content/process-versioning.mdtext
Modified: ode/site/trunk/content/bpel-management-api-specification.mdtext
URL:
http://svn.apache.org/viewvc/ode/site/trunk/content/bpel-management-api-specification.mdtext?rev=1427153&r1=1427152&r2=1427153&view=diff
==============================================================================
--- ode/site/trunk/content/bpel-management-api-specification.mdtext (original)
+++ ode/site/trunk/content/bpel-management-api-specification.mdtext Mon Dec 31
15:37:16 2012
@@ -3,7 +3,7 @@ Category: documentation
<a name="BPELManagementAPISpecification-BPELManagementAPISpecification"></a>
# BPEL Management API Specification
-The BPEL Management API {excerpt} exposes management functions related to BPEL
processes and their instances{excerpt}.
+The BPEL Management API exposes management functions related to BPEL processes
and their instances.
<a name="BPELManagementAPISpecification-GeneralDesignPrinciples"></a>
## General Design Principles
Modified: ode/site/trunk/content/instance-replayer.mdtext
URL:
http://svn.apache.org/viewvc/ode/site/trunk/content/instance-replayer.mdtext?rev=1427153&r1=1427152&r2=1427153&view=diff
==============================================================================
--- ode/site/trunk/content/instance-replayer.mdtext (original)
+++ ode/site/trunk/content/instance-replayer.mdtext Mon Dec 31 15:37:16 2012
@@ -26,75 +26,73 @@ Replayer extends management api by 2 ope
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>
+ <pmap:replay xmlns:ns="http://www.apache.org/ode/pmapi/types/2006/08/02/";>
+ <replay>
+ <ns:upgradeInstance>1234</ns:upgradeInstance>
+ </replay>
+ </pmap:replay>
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>
-
-
- <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>
+ <pmap:getCommunication
xmlns:ns="http://www.apache.org/ode/pmapi/types/2006/08/02/";>
+ <getCommunication>
+ <ns:iid>1234</ns:iid>
+ </getCommunication>
+ </pmap:getCommunication>
+
+
+ <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>
-
-
+ <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>
+ <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>
@@ -115,9 +113,9 @@ You can migrate a few instances at once
* 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)
+ * 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
Modified: ode/site/trunk/content/ode-execution-events.mdtext
URL:
http://svn.apache.org/viewvc/ode/site/trunk/content/ode-execution-events.mdtext?rev=1427153&r1=1427152&r2=1427153&view=diff
==============================================================================
--- ode/site/trunk/content/ode-execution-events.mdtext (original)
+++ ode/site/trunk/content/ode-execution-events.mdtext Mon Dec 31 15:37:16 2012
@@ -1,12 +1,16 @@
Title: ODE Execution Events
+Category: documentation
+
+## Overview
+
ODE generates events to let you track what is exactly happening in the engine
and produces detailed information about process executions. These events are
persisted in ODE's database and can be queried using the [Management
API](management-api.html). The default behavior for the engine is to always
generate all events for every executed action. However from a performance
standpoint it's a good idea to deactivate some of the events you're not
interested in (or even all of them). Inserting all these events generates a
non-negligeable overhead.
<a name="ODEExecutionEvents-Eventtypes"></a>
-### Event types
+## Event types
The following table details each event possibly generated by ODE:
-<table>
+<table class="table table-hover table-bordered">
<tr><th>Event
Name</th><th>Process/Scope</th><th>Description</th><th>Type</th></tr>
<tr><td>ActivityEnabledEvent </td><td> Scope </td><td> An activity is enabled
(just before it's started) </td><td> activityLifecycle
</tr>
@@ -59,10 +63,10 @@ The following table details each event p
The second column specifies wether an event is associated with the process
itself or with one of its scopes. The event type is used for filtering events.
<a name="ODEExecutionEvents-Filteringevents"></a>
-### Filtering events
+## Filtering events
<a name="ODEExecutionEvents-Filteringattheprocesslevel"></a>
-#### Filtering at the process level
+### Filtering at the process level
Using ODE's deployment descriptor, it's possible to tweak events generation to
filtrate which ones get created. First, events can be filtered at the process
level using one of the following stanza:
@@ -80,7 +84,7 @@ Using ODE's deployment descriptor, it's
The first form just duplicates the default behaviour, when nothing is
specified in the deployment descriptor, all events are generated. The third
form lets you define which type of event is generated, possible types are:
`instanceLifecycle`, `activityLifecycle`, `dataHandling`, `scopeHandling`,
`correlation`.
<a name="ODEExecutionEvents-Filteringatthescopelevel"></a>
-#### Filtering at the scope level
+### Filtering at the scope level
It's also possible to define filtering for each scope of your process. This
overrides the settings defined on the process. In order to define event
filtering on a scope, the scope activity MUST have a name in your process
definition. Scopes are referenced by name in the deployment descriptor:
@@ -105,13 +109,13 @@ Note that it's useless to enable an even
The filter defined on a scope is automatically inherited by its inner scopes.
So if no filter is defined on a scope, it will use the settings of its closest
parent scope having event filters (up to the process). Note that what gets
inherited is the full list of selected events, not each event definition
individually.
<a name="ODEExecutionEvents-Eventlisteners"></a>
-### Event listeners
+## Event listeners
ODE lets you register your own event listeners to analyze all produced events
and do whatever you want to do with them. To create a listener you just need to
implement the
[org.apache.ode.bpel.iapi.BpelEventListener](https://svn.apache.org/repos/asf/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/BpelEventListener.java)
interface.
Then add your implementation in the server's classpath and add a property in
ode-axis2.properties giving your fully qualified implementation class name.
Something like:
-
+ :::properties
ode-axis2.event.listeners=com.compamy.product.MyOdeEventListener
Modified: ode/site/trunk/content/process-versioning.mdtext
URL:
http://svn.apache.org/viewvc/ode/site/trunk/content/process-versioning.mdtext?rev=1427153&r1=1427152&r2=1427153&view=diff
==============================================================================
--- ode/site/trunk/content/process-versioning.mdtext (original)
+++ ode/site/trunk/content/process-versioning.mdtext Mon Dec 31 15:37:16 2012
@@ -17,14 +17,14 @@ At this time there's no simple automated
So here is the crude and sad truth: without having some versioning goodness in
it, a process engine will always delete all the running instances when a new
process definition is deployed.
<a name="ProcessVersioning-HowVersioningWorks"></a>
-### How Versioning Works
+## How Versioning Works
So if existing executions can't be migrated, what are you going to do with
them? Well, just let them be. Versioning is based on the fact that, instead of
directly updating the original process definition (leaving its instances to
their dreadful fate), another new version of this definition is created. The
older one is declared retired so no new executions can be started on that one,
the new process is the one to be used now on. But running instances can still
finish their job peacefully as the process they've been using to execute so
far is still available and unchanged.
However ODE also has the concept of deployment bundles and supports 2 modes of
deployment (remotely or manually directly on the filsesystem). Let's see how we
get versioning to work under those conditions.
<a name="ProcessVersioning-ProcessVersioninginOde"></a>
-#### Process Versioning in ODE
+### Process Versioning in ODE
In ODE, processes are deployed in what we call a deployment bundle. When you
come down to it, it's just a zip file or a directory containing ODE's
deployment descriptor
([deploy.xml](creating-a-process#deployment-descriptor.html)), the processes
BPEL and all the other goodies necessary for your BPEL to run (WSDLs, schemas,
xsl stylesheets, you name it). And what ODE is using to know you're redeploying
the same thing is the deployment bundle name.
@@ -52,7 +52,7 @@ There's still a last question left unsol
If two identical process definitions are deployed at the same time, the
behavior of the engine is unspecified. Which one of the two process will pick
up the message? Who knows!? But this can be a very useful feature in specific
cases when you want to deploy the same process twice (by same understand same
name and same namespace) but the 2 definitions are actually different and
enable different endpoints. This allows the parallel deployment of two
different version of the same process provided that they don't overlap in their
endpoint implementation.
<a name="ProcessVersioning-RemoteDeploymentvs.Hand-MadeDeployment"></a>
-#### Remote Deployment vs. Hand-Made Deployment
+### Remote Deployment vs. Hand-Made Deployment
ODE supports 2 different ways of deploying bundles:
