Author: buildbot
Date: Fri Jul 14 05:36:19 2017
New Revision: 1015448
Log:
Staging update by buildbot for ode
Modified:
websites/staging/ode/trunk/content/ (props changed)
websites/staging/ode/trunk/content/ode-execution-events.html
Propchange: websites/staging/ode/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Fri Jul 14 05:36:19 2017
@@ -1 +1 @@
-1801145
+1801908
Modified: websites/staging/ode/trunk/content/ode-execution-events.html
==============================================================================
--- websites/staging/ode/trunk/content/ode-execution-events.html (original)
+++ websites/staging/ode/trunk/content/ode-execution-events.html Fri Jul 14
05:36:19 2017
@@ -97,10 +97,21 @@
<div class="row">
<div class="span12">
- <h2 id="overview">Overview</h2>
+ <style type="text/css">
+/* The following code is added by mdx_elementid.py
+ It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+ visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink,
h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink,
dt:hover > .elementid-permalink { visibility: visible }</style>
+<h2 id="overview">Overview<a class="headerlink" href="#overview"
title="Permanent link">¶</a></h2>
<p>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 <a
href="management-api.html">Management API</a>. 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.</p>
<p><a name="ODEExecutionEvents-Eventtypes"></a></p>
-<h2 id="event-types">Event types</h2>
+<h2 id="event-types">Event types<a class="headerlink" href="#event-types"
title="Permanent link">¶</a></h2>
<p>The following table details each event possibly generated by ODE:</p>
<table class="table table-hover table-bordered">
<tr><th>Event
Name</th><th>Process/Scope</th><th>Description</th><th>Type</th></tr>
@@ -154,9 +165,9 @@
<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.</p>
<p><a name="ODEExecutionEvents-Filteringevents"></a></p>
-<h2 id="filtering-events">Filtering events</h2>
+<h2 id="filtering-events">Filtering events<a class="headerlink"
href="#filtering-events" title="Permanent link">¶</a></h2>
<p><a name="ODEExecutionEvents-Filteringattheprocesslevel"></a></p>
-<h3 id="filtering-at-the-process-level">Filtering at the process level</h3>
+<h3 id="filtering-at-the-process-level">Filtering at the process level<a
class="headerlink" href="#filtering-at-the-process-level" title="Permanent
link">¶</a></h3>
<p>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:</p>
<div class="codehilite"><pre><span class="nt"><dd:process-events</span>
<span class="na">generate=</span><span class="s">"all"</span><span
class="nt">/></span> <span class="c"><!-- Default configuration
--></span>
@@ -171,7 +182,7 @@
<p>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:
<code>instanceLifecycle</code>, <code>activityLifecycle</code>,
<code>dataHandling</code>, <code>scopeHandling</code>,
<code>correlation</code>.</p>
<p><a name="ODEExecutionEvents-Filteringatthescopelevel"></a></p>
-<h3 id="filtering-at-the-scope-level">Filtering at the scope level</h3>
+<h3 id="filtering-at-the-scope-level">Filtering at the scope level<a
class="headerlink" href="#filtering-at-the-scope-level" title="Permanent
link">¶</a></h3>
<p>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:</p>
<div class="codehilite"><pre><span class="nt"><dd:deploy</span> <span
class="na">xmlns:dd=</span><span
class="s">"http://www.apache.org/ode/schemas/dd/2007/03"</span><span
class="nt">></span>
...
@@ -192,13 +203,16 @@
<p>Note that it's useless to enable an event associated with the process
itself when filtering events on scopes.</p>
<p>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.</p>
<p><a name="ODEExecutionEvents-Eventlisteners"></a></p>
-<h2 id="event-listeners">Event listeners</h2>
+<h2 id="event-listeners">Event listeners<a class="headerlink"
href="#event-listeners" title="Permanent link">¶</a></h2>
<p>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 <a
href="https://svn.apache.org/repos/asf/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/BpelEventListener.java";>org.apache.ode.bpel.iapi.BpelEventListener</a>
interface.</p>
<p>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:</p>
<div class="codehilite"><pre><span
class="na">ode-axis2.event.listeners</span><span class="o">=</span><span
class="s">com.compamy.product.MyOdeEventListener</span>
</pre></div>
+<p>Note: These events are generated in the same thread running a JTA
transaction which is being executed to process the bpel activities.
+Subscribed consumers of these events should look for releasing the executing
thread as soon as possible. Holding on to the executing thread
+would delay the transactions and the jobs executions within ODE. May be look
towards asynchronous way of consuming these events.</p>
<p>Start your server and you're done!</p>
</div>
</div>
