Processing a pattern is providing a service that invokes 'sub-services', this service is called the 'original' service and its caller the 'original' consumer.

A Service unit contains:

one and only one Provides section, which describes the pattern that will be processed when a request message is received,
one or more Consumes sections, which reference services to invoke during the pattern processing. The order of the consumes sections is important, as it is the order taken account when a pattern need 'sub-service' coordination.

The number of consumes sections depends on the pattern implemented.

If the MEP InOut or InOptionalOut are supported by a pattern, the component returns to the original consumer an OUT or FAULT response built according to the pattern feature.

If an invoked service returns a Fault or an Error status, the behavior of process can be configured:

The process can terminate and the Fault or the Error is sent back to the 'original' consumer
The process can continue, ignoring the Fault or the Error received

Caution
The MEP is mandatory for each consumes sections.

Caution
Either an operation must be specified in the consumes sections or the 'original' operation is used for 'sub-service' requests.

The Provides section is configured through parameters divided in following groups:

JBI parameters that defines the service provider identification,
CDK parameters that are parameters driving the service provider implementation at CDK layer,
CDK interceptor parameters that are parameters driving interceptors at CDK layer,
Dedicated parameters that are parameters driving the service provider implementation at component layer.

The Consumes sections are configured through parameters divided in following groups:

JBI parameters that defines the service provider identification to invoke,
CDK parameters that are parameters driving the service consumer implementation at CDK layer,
CDK interceptor parameters that are parameters driving interceptors at CDK layer.

CDK parameters defining service provider implementation

The following parameters correspond to the CDK configuration of the service provider implementation.

The service provider is defined into the section 'provides' of the JBI descriptor, containing:

Parameter	Description	Default	Required	Support placeholders
`interface-name`	Interface name of the service provider. Must match the one defined in the WSDL.	-	Yes	No
`service-name`	Service name of the service provider. Must match the one defined in the WSDL.	-	Yes	No
`endpoint-name`	Endpoint name of the service provider. Must match the one defined in the WSDL. The value '`autogenerate`' will force Petals ESB to generate an endpoint name as UUID at deployment time.	-	Yes	No
`timeout`	Timeout in milliseconds of a synchronous send. This parameter is used by the method `sendSync(Exchange exchange)` proposes by the CDK `Listeners` classes. Set it to 0 for an infinite timeout.	30000	No	Yes
`su-interceptors`	Service unit interceptor configuration. See Service unit interceptor configuration.	-	No	No
`exchange-properties`	This sections defines the list of properties to set to the JBI exchange when processing a service.	-	No	No
`message-properties`	This sections defines the list of properties to set to the JBI message when processing a service.	-	No	No
`validate-wsdl`	Activate the validation of the WSDL when deploying a service unit.	true	No	No
`forward-security-subject`	Defines if the security subject will be forwarded from IN message to OUT message.	false	No	No
`forward-message-properties`	Defines if the message properties will be forwarded from IN message to OUT message.	false	No	No
`forward-attachments`	Defines if attachment will be forwarded from IN message to OUT message.	false	No	No
`activate-flow-tracing`	Enable ('`true`') or disable ('`false`') the flow tracing for this service provider. This value overrides the value defined at component level and can be overridden at incoming exchange level.	Value defined at component	No	Yes
`wsdl`	Path to the WSDL document describing services and operations exposed by the provided JBI endpoints defined in the SU. The value of this parameter is : an URL a file relative to the root of the SU package If not specified, a basic WSDL description is automatically provided by the CDK.	-	Yes	No

CDK parameters defining service consumer implementation

The following parameters correspond to the CDK configuration of the service consumer implementation.

A service consumer is defined into the section 'consumes' of the JBI descriptor, containing:

Parameter	Description	Default	Required	Support placeholders
`interface-name`	Interface name of the service provider to invoke.	-	Yes	No
`service-name`	Service name of the service provider to invoke.	-	No	No
`endpoint-name`	Endpoint name of the service provider to invoke.	-	No	No
`timeout`	Timeout in milliseconds of a synchronous send. This parameter can be used in conjunction with the `sendSync(Exchange exchange)` method of the Listeners. Set 0 for an infinite timeout.	30000	No	Yes
`operation`	Operation to call on the service provider. If no operation is specified in the Message Exchange to send, this parameter will be used.	-	No	No
~~`activate-flow-tracing`~~	~~This parameter makes sens only for service consumer running on binding component.~~	-	-	-
`propagate-flow-tracing-activation`	Control whether the flow tracing activation state must be propagated to next flow steps or not. If '`true`', the flow tracing activation state is propagated to the invoked service provider. This value overrides the value defined at component level.	Value defined at component	No	Yes
`su-interceptors`	Service unit interceptor configuration. See Service unit interceptor configuration.	-	No	No
`mep`	Message exchange pattern to use.	-	Yes	No

CDK parameters driving interceptors

The following parameters drive interceptors at CDK layer.

Interceptors can be defined to inject some post or pre-processing in the service provider processing or service consumer processing.

Using interceptor is very sensitive and must be manipulated only by power users. A non properly coded interceptor engaged in a component can lead to uncontrolled behaviors, out of the standard process.

Example of an interceptor configuration:

<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi xmlns:jbi="http://java.sun.com/xml/ns/jbi" xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5">
   <jbi:services>
      <jbi:provides|consumes>
         <!--...-->
         <petalsCDK:su-interceptors>
            <petalsCDK:send>
               <petalsCDK:interceptor name="myInterceptorName">
                  <petalsCDK:param name="myParamName">myParamValue</petalsCDK:param>
                  <petalsCDK:param name="myParamName2">myParamValue2</petalsCDK:param>
               </petalsCDK:interceptor>
            </petalsCDK:send>
            <petalsCDK:accept>
               <petalsCDK:interceptor name="myInterceptorName">
                  <petalsCDK:param name="myParamName">myParamValue</petalsCDK:param>
               </petalsCDK:interceptor>
            </petalsCDK:accept>
            <petalsCDK:send-response>
               <petalsCDK:Interceptor name="myInterceptorName">
                  <petalsCDK:param name="myParamName">myParamValue</petalsCDK:param>
               </petalsCDK:Interceptor>
            </petalsCDK:send-response>
            <petalsCDK:accept-response>
               <petalsCDK:Interceptor name="myInterceptorName">
                  <petalsCDK:param name="myParamName">myParamValue</petalsCDK:param>
               </petalsCDK:Interceptor>
            </petalsCDK:accept-response>
         </petalsCDK:su-interceptors>
         <!--...-->
      </jbi:provides|consumes>
      <!--...-->
   </jbi:services>
</jbi:jbi>

Interceptors configuration for SU (CDK)

Parameter	Description	Default	Required
send	Interceptor dedicated to send phase, for an exchange sent by a consumer	-	No
accept	Interceptor dedicated to receive phase, for an exchange received by a provider	-	No
send-response	Interceptor dedicated to send phase, for an exchange (a response) received by a consumer	-	No
accept-response	Interceptor dedicated to receive phase, for an exchange sent (a response) by a provider	-	No
interceptor - name	Logical name of the interceptor instance defined at component level, see CDK Component Interceptor configuration.	-	Yes
param[] - name	The name of the parameter to use for the interceptor for this SU	-	No
param[]	The value of the parameter to use for the interceptor for this SU	-	No

Service provider dedicated configuration

Parameter	Description	Default	Required
eip	The name of the EIP pattern to execute. See nested paragraph to get the values for each EIP patterns.	-	Yes

Other dedicated parameters can exist according to the EIP pattern used. See nested paragraphs to get more information on each EIP patterns.

Aggregator Pattern

Parameter	Description	Default	Required
eip	The name of the pattern to execute : `aggregator`	-	Yes
test	XPath condition applied on the message to complete or not the sequence and invoke the 'sub-service'	-	Yes
aggregator-correlation	XPath condition that is applied on the incoming message to correlate them together	-	Yes

The EIP Component receives 'original' exchanges and correlates their content amongst the aggregation configurations. The correlation is identified from the XPath expression specified in the SU parameter aggregator-correlation. If an 'original' exchange is on a InOut or InOptionalOut MEP, a standard response is sent back to the 'original' consumer :

<result xmlns="http://petals.ow2.org/petals-se-eip/aggregator">
  Aggregator: the content is buffered by the pattern
</result>

The exchange messages matching an aggregator-correlation condition are stored in memory.
Once an 'original' exchange message matches the XPath expression specified in the SU parameter test, the message and the previous stored messages on the condition aggregator-correlation are aggregated and send to the target 'sub-service'.
The current 'original' exchange properties are copied into the target exchange.
The aggregated content is the result of a concatenation of the messages in the following form :

<result xmlns="http://petals.ow2.org/petals-se-eip/aggregator">
  ...
</result>

The result of the 'sub-service' is sent back to the 'original' consumer of the last aggregated exchange.

An example of Service Unit configuration for the aggregator pattern :

<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi version="1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jbi="http://java.sun.com/xml/ns/jbi"
    xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5"
    xmlns:eip="http://petals.ow2.org/components/eip/version-2"
    xmlns:test="http://petals.ow2.org/test">

  <jbi:services binding-component="false">
    <jbi:provides
        interface-name="test:aggregator"
        service-name="test:aggregatorService1"
        endpoint-name="aggregatorService1Endpoint">
      <petalsCDK:wsdl xsi:nil="true" />
      <eip:eip>aggregator</eip:eip>
      <eip:aggregator-correlation>/*[local-name()='helloworld']/text()</eip:aggregator-correlation>
      <eip:test>
          boolean(/*[local-name()='helloworld' and namespace-uri()='http://petals.ow2.org/test3'])
      </eip:test>
    </jbi:provides>

    <jbi:consumes interface-name="test:aggregateProvider"
        service-name="test:aggregateProviderService1"
        endpoint-name="aggregateProviderService1Endpoint">
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
      <petalsCDK:mep>InOnly</petalsCDK:mep>
    </jbi:consumes>
  </jbi:services>
</jbi:jbi>

Caution
Message order is kept from incoming sequence to the outgoing message.

Caution
Consumes sections cardinality is [1-1].

Caution
All MEPs are accepted for the 'original' consumer and the 'sub-service'

Scatter-Gather Pattern

Parameter	Description	Default	Required
eip	The name of the pattern to execute : `scatter-gather`	-	Yes
fault-robust	If true, a fault returned by a 'sub-service' exchange do not interrupt the process of the pattern	false	No
exception-robust	If true, an exception thrown by a 'sub-service' exchange do not interrupt the process of the pattern	false	No

The EIP Component forwards the message to all the configured 'sub-service(s)'. The component waits for all the responses from these services, and aggregates them.
The aggregation is returned to the 'original' consumer in the following form :

<result xmlns="http://petals.ow2.org/petals-se-eip/scatter-gather">
  ...
</result>

An example of Service Unit configuration for the scatter-gather pattern :

<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi version="1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jbi="http://java.sun.com/xml/ns/jbi"
    xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5"
    xmlns:eip="http://petals.ow2.org/components/eip/version-2"
    xmlns:test="http://petals.ow2.org/test">

  <jbi:services binding-component="false">
    <jbi:provides
        interface-name="test:scatterGather"
        service-name="test:scatterGatherService1"
        endpoint-name="scatterGatherService1Endpoint">
      <petalsCDK:wsdl xsi:nil="true" />
      <eip:eip>scatter-gather</eip:eip>
    </jbi:provides>

    <jbi:consumes interface-name="test:scatterGatherProvider"
        service-name="test:scatterGatherProviderService1"
        endpoint-name="scatterGatherProviderService1Endpoint">
      <petalsCDK:mep>InOut</petalsCDK:mep>
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
    </jbi:consumes>

    <jbi:consumes interface-name="test:scatterGatherProvider"
        service-name="test:scatterGatherProviderService2"
        endpoint-name="scatterGatherProviderService2Endpoint">
      <petalsCDK:mep>InOut</petalsCDK:mep>
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
    </jbi:consumes>
  </jbi:services>
</jbi:jbi>

Caution
Consumes sections cardinality is [1-n].

Caution
Message exchange pattern accepted from the 'original' consumer is InOut.

Caution
By default, the process stops when a Fault is returned by a 'sub-service'. To continue the process even if a fault is returned, set the fault-robust parameter to TRUE. The fault is concatenated with the others results.

Caution
By default, the process stops when an Exception is returned by a 'sub-service'. To continue the process even if an exception is thrown, set the exception-robust to TRUE. The exception is concatenated with the others results.

Routing-Slip Pattern

Parameter	Description	Default	Required
eip	The name of the pattern to execute : `routing-slip`.	-	Yes
fault-to-exception	If true, a fault received from a 'sub-service' service is transformed to an exception into the 'original' exchange.	false	No

The EIP Component chains invocation of the 'sub-services', in the order that they are declared. The IN message of the incoming exchange is sent to the first 'sub-service', the OUT response of this service is sent to the second 'sub-service' as a IN message, and so on. The last exchange is matched with the 'original' exchange as better as possible:

If the source exchange needs a response (InOut patterns) and no response are received (InOnly, RobustInOnly patterns), a default response is returned :
```
<result xmlns="http://petals.ow2.org/petals-se-eip/bridge">
    Bridge: no content into the final target exchange
</result>
```
If the 'original' exchange do not accept a response (InOnly or RobustInOnly patterns) and a response is received (InOut or InOptionalOut patterns), the response is ignored.
If the 'original' exchange do not accept a fault (InOnly pattern) and a fault is received (RobustInOnly, InOut or InOptionalOut patterns), the fault is ignored.

An example of Service Unit configuration for the Routing-Slip pattern:

<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi version="1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jbi="http://java.sun.com/xml/ns/jbi"
    xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5"
    xmlns:eip="http://petals.ow2.org/components/eip/version-2"
    xmlns:test="http://petals.ow2.org/test">

  <jbi:services binding-component="false">
    <jbi:provides
        interface-name="test:routingSlip"
        service-name="test:routingSlipService1"
        endpoint-name="routingSlipService1Endpoint">

      <petalsCDK:wsdl xsi:nil="true" />
      <eip:eip>routing-slip</eip:eip>
      <eip:fault-to-exception>false</eip:fault-to-exception>
    </jbi:provides>

    <jbi:consumes interface-name="test:routingSlipProvider"
        service-name="test:routingSlipProviderService1"
        endpoint-name="routingSlipProviderService1Endpoint">

      <petalsCDK:mep>InOut</petalsCDK:mep>
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
    </jbi:consumes>

    <jbi:consumes interface-name="test:routingSlipProvider"
        service-name="test:routingSlipProviderService2"
        endpoint-name="routingSlipProviderService2Endpoint">

      <petalsCDK:mep>InOut</petalsCDK:mep>
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
    </jbi:consumes>
  </jbi:services>
</jbi:jbi>

Caution
Consumes sections cardinality is [1-n].

Caution
By default, the process stops when a Fault is returned or an exception is raised by a 'sub-service'.

Caution
MEP of all the 'sub-services' must be set to InOut, except the last one which can be accorded to the 'original' MEP.

Caution
All the MEP are accepted from the 'original' consumer.

Wire-Tap Pattern

Parameter	Description	Default	Required
eip	The name of the pattern to execute `wire-tap`	-	Yes
wiretap-way	Specify the step of a MEP on which the message should be copied and sent to the 'sub-service'. Values can be `request` (copy `IN`), `response` (copy `OUT`/`FAULT`), `request-response` (copy `IN` and `OUT`/`FAULT`), `request-on-response` (copy `IN` after `OUT` is received; no copy if `FAULT` received)	-	Yes

The EIP component acts a proxy to a target 'sub-service'. It intercepts the IN or OUT/FAULT messages during the exchange and relays it to a observer 'sub-service'.
The SU parameter wiretap-way determines at which step of the MEP and which message is relayed to the observer 'sub-service'.
The copied message is sent to the 'observer' service as an IN message using the InOnly exchange pattern.
The first Consumes section refers the target 'sub-service', the second one refers the observer 'sub-service'.

An example of Service Unit configuration to provide the Wire-Tap pattern :

<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi version="1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jbi="http://java.sun.com/xml/ns/jbi"
    xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5"
    xmlns:eip="http://petals.ow2.org/components/eip/version-2"
    xmlns:test="http://petals.ow2.org/test">    
    <jbi:services binding-component="false">        
        <jbi:provides         
            interface-name="test:wireTap"
            service-name="test:wireTapService1"
            endpoint-name="wireTapService1Endpoint">            
            <petalsCDK:wsdl xsi:nil="true" />            
            <eip:eip>wire-tap</eip:eip>
            <eip:wiretap-way>request</eip:wiretap-way>
        </jbi:provides>
        <jbi:consumes interface-name="test:wireTapProvider"
                      service-name="test:wireTapProviderService1"
                      endpoint-name="wireTapProviderService1Endpoint">
            <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
            <petalsCDK:mep>InOut</petalsCDK:mep>
        </jbi:consumes>
        <!-- monitoring -->
        <jbi:consumes interface-name="test:wireTapProvider"
                      service-name="test:wireTapProviderService2"
                      endpoint-name="wireTapProviderService2Endpoint">
            <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
            <petalsCDK:mep>InOnly</petalsCDK:mep>
        </jbi:consumes>
    </jbi:services>
</jbi:jbi>

Caution
Consumes sections cardinality is 2.

Caution
MEP of the observer 'sub-service' is InOnly.

Caution
All the MEP are accepted from the 'original' consumer and the target 'sub-service'.

Splitter Pattern

Parameter	Description	Default	Required
eip	The name of the pattern to execute : `splitter`	-	Yes
test	XPath condition applied on the message to split from the 'original' exchange	-	Yes
attachment	true to split the attachments of the incoming 'original' exchange, false to split against the `test` XPath expression on the In 'original' message	false	No
fault-robust	If true, a fault returned by a 'sub-service' exchange do not interrupt the process of the pattern	false	No
exception-robust	If true, an exception thrown by a 'sub-service' exchange do not interrupt the process of the pattern	false	No

For this pattern, the EIP Component splits the incoming 'original' message to multiple messages, then send them to the configured 'sub-service'.
If attachment parameter is not set, the IN message of the exchange is split against the Xpath expression specified in the parameter test.
If attachment parameter is set to true, The attachments contained in the 'original' exchange is split, element by element, to new messages.
Each message split is sent to the configured 'sub-service'.

The aggregation of the responses is returned to the 'original' consumer, in the following form :

<result xmlns="http://petals.ow2.org/petals-se-eip/splitter">
  ...
</result>

An example of Service Unit configuration for the Splitter pattern :

<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi version="1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jbi="http://java.sun.com/xml/ns/jbi"
    xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5"
    xmlns:eip="http://petals.ow2.org/components/eip/version-2"
    xmlns:test="http://petals.ow2.org/test">

<jbi:services binding-component="false">
  <jbi:provides
      interface-name="test:splitter"
      service-name="test:splitterService1"
      endpoint-name="splitterService1Endpoint">

    <petalsCDK:wsdl xsi:nil="true" />
      <eip:eip>splitter</eip:eip>
      <eip:test>
          /*[local-name()='helloworld' and namespace-uri()='http://petals.ow2.org/test']/*[local-name()='split']
      </eip:test>
      <eip:fault-robust>false</eip:fault-robust>
      <eip:exception-robust>false</eip:exception-robust>
      <eip:attachment-mode>false</eip:attachment-mode>
    </jbi:provides>

    <jbi:consumes interface-name="test:splitterProvider"
        service-name="test:splitterProviderService1"
        endpoint-name="splitterProviderService1Endpoint">
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
      <petalsCDK:mep>InOut</petalsCDK:mep>
    </jbi:consumes>
  </jbi:services>
</jbi:jbi>

Caution
consumes sections cardinality is 1.

Caution
MEP accepted from the 'original' consumer is InOut.

Caution
By default, the process stops when a Fault is returned by a 'sub-service'. To continue the process even if a fault is returned, set the fault-robust parameter to TRUE. The fault is concatenated with the others results.

Caution
By default, the process stops when an Exception is returned by a 'sub-service'. To continue the process even if an exception is thrown, set the exception-robust to TRUE. The exception is concatenated with the others results.

Bridge Pattern

Parameter	Description	Default	Required
eip	The name of the pattern to execute `bridge`	-	Yes
fault-to-exception	If true, a fault received from a 'sub-service' service is transformed to an exception into the 'original' exchange.	false	No

The EIP Component acts as exchange MEP bridge. For instance, it transforms an InOnly invocation into an InOut one. It is useful to correlate incompatible MEPs services.
Define in the Consumes section the 'sub-service' to invoke with its MEP, and the EIP component will match the incoming 'original' exchange against the outgoing exchange patterns as best as possible :

If the 'original' exchange demands a response (InOut patterns) and no response are received (InOnly,
RobustInOnly or InOptionalOut patterns), a default response is returned in the following form:
```
<result xmlns="http://petals.ow2.org/petals-se-eip/bridge">
  Bridge: no response from the last 'sub-service'
</result>
```
If the 'original' exchange do not expect a response (InOnly or RobustInOnly patterns) and a response is received (InOut or InOptionalOut patterns), the response is ignored.
If the 'original' exchange do not expect a fault (InOnly pattern) and a fault is received (RobustInOnly, InOut or InOptionalOut patterns), the fault is ignored.

An example of Service Unit configuration for the bridge pattern :

<?xml version="1.0"?>
<jbi:jbi version="1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jbi="http://java.sun.com/xml/ns/jbi"
    xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5"
    xmlns:eip="http://petals.ow2.org/components/eip/version-2"
    xmlns:test="http://petals.ow2.org/test">

  <jbi:services binding-component="false">
    <jbi:provides
        interface-name="test:splitter"
        service-name="test:splitterService1"
        endpoint-name="splitterService1Endpoint">


      <petalsCDK:wsdl xsi:nil="true" />
      <eip:eip>splitter</eip:eip>
      <eip:fault-to-exception>false</eip:fault-to-exception>
      <eip:test>
          /*[local-name()='helloworld' and namespace-uri()='http://petals.ow2.org/test']/*[local-name()='split']
      </eip:test>
      <eip:fault-robust>false</eip:fault-robust>
      <eip:exception-robust>false</eip:exception-robust>
      <eip:attachment-mode>false</eip:attachment-mode>
    </jbi:provides>

    <jbi:consumes interface-name="test:splitterProvider"
        service-name="test:splitterProviderService1"
        endpoint-name="splitterProviderService1Endpoint">
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
      <petalsCDK:mep>InOut</petalsCDK:mep>
    </jbi:consumes>
  </jbi:services>
</jbi:jbi>

Caution
Consumes sections cardinality is 1.

Router Pattern

Parameter	Description	Default	Required
eip	The name of the pattern to execute : `router`	-	Yes
test[]	XPath condition(s) applied on the message to select the 'sub-service'	-	Yes
test-operation[]	Operation condition(s) applied on the message to select the 'sub-service'	-	Yes
fault-to-exception	If true, a fault received from a 'sub-service' service is transformed to an exception into the 'original' exchange.	false	No

The EIP Component evaluates the list of conditions against the 'original' exchange.
Once a condition is matched, the message is forwarded to the 'sub-service' configured in the Consumes section at the same position than the condition.
The kind of condition can be either a XPath expression processed against the content of the 'original' IN message (parameter test), or a qualified operation processed against the 'original' exchange operation (parameter test-operation).
If none of the conditions are matched, the exchange is forwarded to the default 'sub-service', referenced in the last Consumes section.

An example of Service Unit configuration for the Router pattern :

<?xml version="1.0"?>
<jbi:jbi version="1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jbi="http://java.sun.com/xml/ns/jbi"
    xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5"
    xmlns:eip="http://petals.ow2.org/components/eip/version-2"
    xmlns:test="http://petals.ow2.org/test">

  <jbi:services binding-component="false">
    <jbi:provides
        interface-name="test:router"
        service-name="test:routerService1"
        endpoint-name="routerService1Endpoint">
      <petalsCDK:wsdl xsi:nil="true" />
        <eip:eip>router</eip:eip>
        <eip:test>
            boolean(/*[local-name()='helloworld' and namespace-uri()='http://petals.ow2.org/test1'])
        </eip:test>
        <eip:test>
            boolean(/*[local-name()='helloworld' and namespace-uri()='http://petals.ow2.org/test2'])
        </eip:test>
      <eip:fault-to-exception>false</eip:fault-to-exception>
    </jbi:provides>

    <jbi:consumes interface-name="test:routerProvider"
        service-name="test:routerProviderService1"
        endpoint-name="routerProviderService1Endpoint">
      <petalsCDK:mep>InOut</petalsCDK:mep>
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
    </jbi:consumes>

    <jbi:consumes interface-name="test:routerProvider"
        service-name="test:routerProviderService2"
        endpoint-name="routerProviderService2Endpoint">
      <petalsCDK:mep>InOut</petalsCDK:mep>
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
    </jbi:consumes>

    <!-- default -->
    <jbi:consumes interface-name="test:routerProvider"
        service-name="test:routerProviderService3"
        endpoint-name="routerProviderService3Endpoint">
      <petalsCDK:mep>InOut</petalsCDK:mep>
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
    </jbi:consumes>
  </jbi:services>
</jbi:jbi>

Caution
Consumes sections cardinality is the number of defined conditions plus 1.

Caution
The last Consumes section is the default service to invoke if no condition has been matched.

Dynamic Router Pattern

Parameter	Description	Default	Required
eip	The name of the pattern to execute : `dynamic-router`	-	Yes
test[]	XPath condition(s) applied on the message to select the 'sub-service'	-	Yes
fault-to-exception	If true, a fault received from a 'sub-service' service is transformed to an exception into the 'original' exchange.	false	No

This pattern is similar than the Router pattern but do not process the conditions evaluations on the 'original' exchange, but on a response of a conditioning 'sub-service'.
So, first at all, the IN message of the 'original' consumer is sent to the conditioning 'sub-service', which is the first Consumes section defined.
Then the component evaluates the list of conditions against the OUT response message.
The kind of condition is a XPath expression contained in parameter(s) test.
Once a condition is matched, the message is forwarded to the 'sub-service' configured in the Consumes section at the same position than the condition plus 1.
If none of the conditions are matched, the exchange is forwarded to the default 'sub-service', referenced in the last Consumes section.

An example of Service Unit configuration for the dynamic-router pattern :

<?xml version="1.0"?>
<jbi:jbi version="1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jbi="http://java.sun.com/xml/ns/jbi"
    xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5"
    xmlns:eip="http://petals.ow2.org/components/eip/version-2"
    xmlns:test="http://petals.ow2.org/test">
  <jbi:services binding-component="false">
    <jbi:provides
        interface-name="test:dynamicRouter"
        service-name="test:dynamicRouterService1"
        endpoint-name="dynamicRouterService1Endpoint">
      <petalsCDK:wsdl xsi:nil="true" />
      <eip:eip>dynamic-router</eip:eip>
      <eip:test>
          boolean(/*[local-name()='helloworld' and namespace-uri()='http://petals.ow2.org/test2'])
      </eip:test>
      <eip:test>
          boolean(/*[local-name()='helloworld' and namespace-uri()='http://petals.ow2.org/test3'])
      </eip:test>
      <eip:fault-to-exception>false</eip:fault-to-exception>
    </jbi:provides>

    <!-- router -->
    <jbi:consumes interface-name="test:dynamicRouterProvider"
        service-name="test:dynamicRouterProviderService1"
        endpoint-name="dynamicRouterProviderService1Endpoint">
      <petalsCDK:mep>InOut</petalsCDK:mep>
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
    </jbi:consumes>

    <jbi:consumes interface-name="test:dynamicRouterProvider"
        service-name="test:dynamicRouterProviderService2"
        endpoint-name="dynamicRouterProviderService2Endpoint">
      <petalsCDK:mep>InOut</petalsCDK:mep>
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
    </jbi:consumes>

    <jbi:consumes interface-name="test:dynamicRouterProvider"
        service-name="test:dynamicRouterProviderService3"
        endpoint-name="dynamicRouterProviderService3Endpoint">
      <petalsCDK:mep>InOut</petalsCDK:mep>
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
    </jbi:consumes>

    <!-- default -->
    <jbi:consumes interface-name="test:dynamicRouterProvider"
        service-name="test:dynamicRouterProviderService4"
        endpoint-name="dynamicRouterProviderService4Endpoint">
      <petalsCDK:mep>InOut</petalsCDK:mep>
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
    </jbi:consumes>
  </jbi:services>
</jbi:jbi>

Caution
Consumes sections cardinality is the number of conditions plus 2.

Caution
The first Consumes section is the 'sub-service' to invoke to get the message to evaluate. Its pattern is InOut.

Caution
The last consumes section is the default service to invoke if no condition has been matched.

Dispatcher Pattern

Parameter	Description	Default	Required
eip	The name of the pattern to execute : `dispatcher`.	-	Yes

The EIP Component dispatches the incoming IN message toward the configured 'sub-services' in Consumes sections. No response message is expected.

An example of Service Unit configuration for the Dispatcher pattern :

<?xml version="1.0"?>
<jbi:jbi version="1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jbi="http://java.sun.com/xml/ns/jbi"
    xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5"
    xmlns:eip="http://petals.ow2.org/components/eip/version-2"
    xmlns:test="http://petals.ow2.org/test">

  <jbi:services binding-component="false">
    <jbi:provides
        interface-name="test:dispatcher"
        service-name="test:dispatcherService1"
        endpoint-name="dispatcherService1Endpoint">
      <petalsCDK:wsdl xsi:nil="true" />
      <eip:eip>dispatcher</eip:eip>
    </jbi:provides>

    <jbi:consumes
        interface-name="test:dispatcherProvider"
        service-name="test:dispatcherProviderService1"
        endpoint-name="dispatcherProviderService1Endpoint">
      <petalsCDK:mep>InOnly</petalsCDK:mep>
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
    </jbi:consumes>

    <jbi:consumes
        interface-name="test:dispatcherProvider"
        service-name="test:dispatcherProviderService2"
        endpoint-name="dispatcherProviderService2Endpoint">
      <petalsCDK:mep>InOnly</petalsCDK:mep>
      <petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
    </jbi:consumes>
   </jbi:services>
</jbi:jbi>

Caution
Consumes sections cardinality is [1-n].

Caution
MEP of the 'original' exchange and the 'sub-services' must be InOnly.

Service unit content

The service unit has to contain the following elements, packaged in the archive:

the META-INF/jbi.xml descriptor file as described above,
it is also highly recommended to provide a WSDL description for service provider embedded in the service-unit.

service-unit.zip
  + META-INF
    - jbi.xml (as defined above)
  - service.wsdl (recommended)

Example

An example of a Service Unit descriptor to provide an EIP service:

<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi version="1.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xmlns:jbi="http://java.sun.com/xml/ns/jbi"
         xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5"
         xmlns:eip="http://petals.ow2.org/components/eip/version-2"
         xmlns:sample="http://petals.ow2.org/sample">
    <jbi:services binding-component="false">

        <!-- Service provider -->
        <jbi:provides interface-name="sample:interface" service-name="sample:service"
                      endpoint-name="endpoint">
            <petalsCDK:wsdl xsi:nil="true" />
            <eip:eip>pattern</eip:eip>
        </jbi:provides>

        <!-- Service consumers -->
        <jbi:consumes interface-name="sample:calledInterface1" service-name="sample:calledService1"
                      endpoint-name="calledEndpoint1">
            <petalsCDK:mep xsi:nil="true" />
        <!-- The second Consumes -->
        <jbi:consumes interface-name="sample:calledInterface2" service-name="sample:calledService2"
                      endpoint-name="calledEndpoint2">
            <petalsCDK:mep xsi:nil="true" />
        </jbi:consumes>
    </jbi:services>
</jbi:jbi>

Component Extension

The component can be extended by any contributor to provide the support of new EIP pattern.

To add a new pattern, provide a Java class implementing the interface Pattern :

/**
 * The pattern interface
 *
 * @author Adrien Louis
 * @author Christophe Hamerling
 * @author Frederic Gardes
 */
public interface Pattern {

    /**
     * Initialize the pattern
     *
     */
    void init();

    /**
     * Process the Pattern.
     *
     * @param exchange
     * 		The exchange to process
     * @param context
     * 		The context of the exchange
     */
    boolean processPattern(Exchange exchange, ExchangeContext context);

    /**
     * Process an exchange for an asynchronous pattern.
     *
     * @param exchange
     * 		The exchange to process
     * @param context
     * 		The context of the exchange
     * @param asyncContext
     * 		The EIP asynchronous context
     * @param expired
     * 		true if the asynchronous exchange is expired, false else
     */
    boolean processAsyncPattern(Exchange exchange, ExchangeContext context,
            EIPAsyncContext asyncContext, boolean expired);

    /**
     * Get the pattern name.
     *
     * @return The name
     */
    String getName();
}

Use the ExchangeContext to interact with the container, during your pattern processing :

/**
 * The exchange context.
 *
 * @author Adrien Louis
 * @author Frederic Gardes
 */
public interface ExchangeContext {

    /**
     * Get the logger
     *
     * @return the logger
     */
    public Logger getLogger();

    /**
     * get the Consumes for an endpoint
     *
     * @param endpoint
     * 		The endpoint
     * @return The Consumes of the endpoint
     */
    public List<Consumes> getSUConsumes(ServiceEndpoint endpoint);

    /**
     * Send synchronously an exchange. The response will be provided into the
     * same exchange
     *
     * @param exchange
     * 		The exchange to send
     * @return true if the exchange was sent, false else (reached timeout,
     * technical error,...)
     * @throws MessagingException
     */
    public boolean sendSync(final Exchange exchange) throws MessagingException;

    /**
     * Send asynchronously an exchange. The response will be provided as an
     * asynchronous exchange
     *
     * @param exchange
     * 		The exchange to send
     * @param asyncContext
     * 		The asynchronous context, provided on the response
     * @throws MessagingException
     */
    public void sendAsync(final Exchange exchange, AsyncContext asyncContext) throws MessagingException;

    /**
     * Send asynchronously an exchange. The response will be provided as a
     * synchronous exchange
     *
     * @param exchange
     * The exchange to send
     * @throws MessagingException
     */
    public void send(final Exchange exchange) throws MessagingException;

    /**
     * Create an exchange from a Consumes
     *
     * @param consumes
     * 		The Consumes used as JBI Consumer of the exchange
     * @return The exchange created
     * @throws MessagingException
     * @throws PEtALSCDKException
     */
    public Exchange createConsumeExchange(Consumes consumes) throws MessagingException, PEtALSCDKException;

    /**
     * Get the extensions
     *
     * @return The extensions
     */
    public ConfigurationExtensions getExtensions();
}

Extends the JBI.xml file of the component to reference your new pattern.

Configuring the component

The component can be configured through the parameters of its JBI descriptor file. These parameters are divided in following groups:

JBI parameters that have not to be changed otherwise the component will not work,
CDK parameters that are parameters driving the processing of the CDK layer,
Dedicated parameters that are parameters specific to this component.

CDK parameters

The component configuration includes the configuration of the CDK. The following parameters correspond to the CDK configuration.

Parameter	Description	Default	Scope*
acceptor-pool-size	The size of the thread pool used to accept Message Exchanges from the NMR. Once a message is accepted, its processing is delegated to the processor pool thread.	1	Runtime
acceptor-retry-number	Number of tries to submit a message exchange to a processor for processing before to declare that it cannot be processed.	40	Installation
acceptor-retry-wait	Base duration, in milliseconds, to wait between two processing submission tries. At each try, the new duration is the previous one plus this base duration.	250	Installation
acceptor-stop-max-wait	The max duration (in milliseconds) before, on component stop, each acceptor is stopped by force.	500	Runtime
processor-pool-size	The size of the thread pool used to process Message Exchanges. Once a message is accepted, its processing is delegated to one of the thread of this pool.	10	Runtime
processor-max-pool-size	The maximum size of the thread pool used to process Message Exchanges. The difference between this size and the processor-pool-size represents the dynamic threads that can be created and destroyed during overhead processing time.	50	Runtime
processor-keep-alive-time	When the number of processors is greater than the core, this is the maximum time that excess idle processors will wait for new tasks before terminating, in seconds.	300	Runtime
processor-stop-max-wait	The max duration (in milliseconds) of message exchange processing on stop phase (for all processors).	15000	Runtime
time-beetween-async-cleaner-runs	The time (in milliseconds) between two runs of the asynchronous message exchange cleaner.	2000	Installation
properties-file	Name of the file containing properties used as reference by other parameters. Parameters reference the property name using a placeholder in the following pattern ${myPropertyName}. At runtime, the expression is replaced by the value of the property. The properties file can be reloaded using the JMX API of the component. The runtime configuration MBean provides an operation to reload these place holders. Check the service unit parameters that support this reloading. The value of this parameter is : an URL a file relative to the PEtALS installation path an absolute file path an empty value to stipulate a non-using file.	-	Installation
monitoring-sampling-period	Period, in seconds, of a sample used by response time probes of the monitoring feature.	300	Installation
activate-flow-tracing	Enable ('`true`') or disable ('`false`') the flow tracing. This value can be overridden at service consumer or service provider level, or at exchange level.	`true`	Runtime
propagate-flow-tracing-activation	Control whether the flow tracing activation state must be propagated to next flow steps or not. If '`true`', the flow tracing activation state is propagated. This value can be overridden at service consumer level.	`true`	Runtime
component-interceptors	Component interceptor configuration. See CDK Component interceptor configuration.	-	See Maven Petals plugin to known how to inject component interceptor configuration in component configuration

* Definition of CDK parameter scopes:

Installation: The parameter can be set during the installation of the component, by using the installation MBean (see JBI specifications for details about the installation sequence). If the parameter is optional and has not been defined during the development of the component, it is not available at installation time.
Runtime: The paramater can be set during the installation of the component and during runtime. The runtime configuration can be changed using the CDK custom MBean named RuntimeConfiguration. If the parameter is optional and has not been defined during the development of the component, it is not available at installation and runtime times.

Interception configuration

Interceptors can be defined to inject some post or pre-processing in the component during service processing.

Using interceptor is very sensitive and must be manipulated only by power users. A non properly coded interceptor engaged in a component can lead to uncontrolled behaviors, out of the standard process.

Example of an interceptor configuration:

<?xml version="1.0" encoding="UTF-8"?>
<jbi:jbi xmlns:jbi="http://java.sun.com/xml/ns/jbi" xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5" ...>
   <jbi:component>
      <!--...-->
      <petalsCDK:component-interceptors>
         <petalsCDK:interceptor active="true" class="org.ow2.petals.myInterceptor" name="myInterceptorName">
            <petalsCDK:param name="myParamName">myParamValue</petalsCDK:param>
            <petalsCDK:param name="myParamName2">myParamValue2</petalsCDK:param>
         </petalsCDK:interceptor>
      </petalsCDK:component-interceptors>
      <!--...-->
   </jbi:component>
</jbi:jbi>

Interceptors configuration for Component (CDK)

Parameter	Description	Default	Required
interceptor - class	Name of the interceptor class to implement. This class must extend the abstract class org.ow2.petals.component.common.interceptor.Interceptor. This class must be loadable from the component classloader, or in a dependent Shared Library classloader.	-	Yes
interceptor - name	Logical name of the interceptor instance. It is referenced at service unit level to register this interceptor for services of the service unit. See SU Interceptor configuration.	-	Yes
interceptor - active	If true, the Interceptor instance is activated for every SU deployed on the component. If false, the Interceptor can be activated: -by the InterceptorManager Mbean at runtime, to activate the interceptor for every deployed SU. -by a SU configuration	-	Yes
param[] - name	The name of the parameter to use for the interceptor.	-	No
param[]	The value of the parameter to use for the interceptor.	-	No

Dedicated configuration

No dedicated configuration parameter is available.

Monitoring the component

Using metrics

Several probes providing metrics are included in the component, and are available through the JMX MBean 'org.ow2.petals:type=custom,name=monitoring_<component-id>', where <component-id> is the unique JBI identifier of the component.

Common metrics

The following metrics are provided through the Petals CDK, and are common to all components:

Metrics, as MBean attribute	Description	Detail of the value	Configurable
MessageExchangeAcceptorThreadPoolMaxSize	The maximum number of threads of the message exchange acceptor thread pool	integer value, since the last startup of the component	yes, through `acceptor-pool-size`
MessageExchangeAcceptorThreadPoolCurrentSize	The current number of threads of the message exchange acceptor thread pool. Should be always equals to `MessageExchangeAcceptorThreadPoolMaxSize`.	instant integer value	no
MessageExchangeAcceptorCurrentWorking	The current number of working message exchange acceptors.	instant long value	no
MessageExchangeAcceptorMaxWorking	The max number of working message exchange acceptors.	long value, since the last startup of the component	no
MessageExchangeAcceptorAbsoluteDurations	The aggregated durations of the working message exchange acceptors since the last startup of the component.	n-tuple value containing, in nanosecond: the maximum duration, the average duration, the minimum duration.	no
MessageExchangeAcceptorRelativeDurations	The aggregated durations of the working message exchange acceptors on the last sample.	n-tuple value containing, in nanosecond: the maximum duration, the average duration, the minimum duration, the 10-percentile duration (10% of the durations are lesser than this value), the 50-percentile duration (50% of the durations are lesser than this value), the 90-percentile duration (90% of the durations are upper than this value).	no
MessageExchangeProcessorAbsoluteDurations	The aggregated durations of the working message exchange processor since the last startup of the component.	n-tuple value containing, in milliseconds: the maximum duration, the average duration, the minimum duration.	no
MessageExchangeProcessorRelativeDurations	The aggregated durations of the working message exchange processor on the last sample.	n-tuple value containing, in milliseconds: the maximum duration, the average duration, the minimum duration, the 10-percentile duration (10% of the durations are lesser than this value), the 50-percentile duration (50% of the durations are lesser than this value), the 90-percentile duration (90% of the durations are upper than this value).	no
MessageExchangeProcessorThreadPoolActiveThreadsCurrent	The current number of active threads of the message exchange processor thread pool	instant integer value	no
MessageExchangeProcessorThreadPoolActiveThreadsMax	The maximum number of threads of the message exchange processor thread pool that was active	integer value, since the last startup of the component	no
MessageExchangeProcessorThreadPoolIdleThreadsCurrent	The current number of idle threads of the message exchange processor thread pool	instant integer value	no
MessageExchangeProcessorThreadPoolIdleThreadsMax	The maximum number of threads of the message exchange processor thread pool that was idle	integer value, since the last startup of the component	no
MessageExchangeProcessorThreadPoolMaxSize	The maximum size, in threads, of the message exchange processor thread pool	instant integer value	yes, through `http-thread-pool-size-max`
MessageExchangeProcessorThreadPoolMinSize	The minimum size, in threads, of the message exchange processor thread pool	instant integer value	yes, through `http-thread-pool-size-min`
MessageExchangeProcessorThreadPoolQueuedRequestsCurrent	The current number of enqueued requests waiting to be processed by the message exchange processor thread pool	instant integer value	no
MessageExchangeProcessorThreadPoolQueuedRequestsMax	The maximum number of enqueued requests waiting to be processed by the message exchange processor thread pool since the last startup of the component	instant integer value	no
ServiceProviderInvocations	The number of service provider invocations grouped by: interface name, as `QName`, the invoked service provider, service name, as `QName`, the invoked service provider, invoked operation, as `QName`, message exchange pattern, and execution status (PENDING, ERROR, FAULT, SUCCEEDED).	integer counter value since the last startup of the component	no
ServiceProviderInvocationsResponseTimeAbs	The aggregated response times of the service provider invocations since the last startup of the component grouped by: interface name, as `QName`, the invoked service provider, service name, as `QName`, the invoked service provider, invoked operation, as `QName`, message exchange pattern, and execution status (PENDING, ERROR, FAULT, SUCCEEDED).	n-tuple value containing, in millisecond: the maximum response time, the average response time, the minimum response time.	no
ServiceProviderInvocationsResponseTimeRel	The aggregated response times of the service provider invocations on the last sample, grouped by: interface name, as `QName`, the invoked service provider, service name, as `QName`, the invoked service provider, invoked operation, as `QName`, message exchange pattern, and execution status (PENDING, ERROR, FAULT, SUCCEEDED).	n-tuple value containing, in millisecond: the maximum response time, the average response time, the minimum response time, the 10-percentile response time (10% of the response times are lesser than this value), the 50-percentile response time (50% of the response times are lesser than this value), the 90-percentile response time (90% of the response times are lesser than this value).	no

Dedicated metrics

No dedicated metric is available.

Receiving alerts

Several alerts are notified by the component through notification of the JMX MBean 'org.ow2.petals:type=custom,name=monitoring_<component-id>', where <component-id> is the unique JBI identifier of the component.

To integrate these alerts with Nagios, see Receiving Petals ESB defects in Nagios.

Common alerts

Defect	JMX Notification
A message exchange acceptor thread is dead	`type`: `org.ow2.petals.component.framework.process.message.acceptor.pool.thread.dead` no user data
No more thread is available in the message exchange acceptor thread pool	`type`: `org.ow2.petals.component.framework.process.message.acceptor.pool.exhausted` no user data
No more thread is available to run a message exchange processor	`type`: `org.ow2.petals.component.framework.process.message.processor.thread.pool.exhausted` no user data

Dedicated alerts

No dedicated alert is available.

Business monitoring

MONIT traces

Each service provider implemented is able to log MONIT traces with following information:

on service provider invocation, when receiving an incoming request, with following attributes:
- traceCode set to provideFlowStepBegin,
- flowInstanceId set to the flow instance identifier retrieved from the incoming request,
- flowStepId set to an UUID value,
- flowStepInterfaceName set to the service provider interface name,
- flowStepServiceName set to the service provider service name,
- flowStepOperationName set to the operation of the invoked service provider,
- flowStepEndpointName set to the service provider endpoint name,
- flowPreviousStepId set to the step identifier of the previous step, retrieved from the incoming request.
on service provider termination, when returning the outgoing response, with following attributes:
- traceCode set to provideFlowStepEnd or provideFlowStepFailure,
- flowInstanceId set to the flow instance identifier retrieved from the incoming request,
- flowStepId set to the flow step identifier defined on incoming request receipt.

Flow tracing activation

The flow tracing (ie. MONIT traces generation) is defined according to the property 'org.ow2.petals.monitoring.business.activate-flow-tracing' of the incoming JBI request. If the property does not exist, the parameter activate-flow-tracing of the service provider definition will be inspected. If no parameter is defined at service provider level, the component configuration parameter 'activate-flow-tracing' is used. Finally, by default, the flow tracing is enabled.

Flow tracing propagation

The flow tracing propagation from a service provider implemented with this component to another service provider is driven by the parameter propagate-flow-tracing-activation of the service consumer definition. If no parameter is defined at service consumer level, the component configuration parameter 'propagate-flow-tracing-activation' is used. Finally, by default, the flow tracing propagation is enabled.

With the pattern 'Aggregator', the flow tracing propagation occurs only on the last aggregation request, the one that fires the sub-service provider invocation. The flow tracing propagation is driven according to this last request.

Petals Components Wiki

All versions of Petals ESB

Helpful links

Petals-SE-EIP 2.11.0+

Integration Pattern supported

Service Configuration

Service unit descriptor

CDK parameters defining service provider implementation

CDK parameters defining service consumer implementation

CDK parameters driving interceptors

Service provider dedicated configuration

Aggregator Pattern

Scatter-Gather Pattern

Routing-Slip Pattern

Wire-Tap Pattern

Splitter Pattern

Bridge Pattern

Router Pattern

Dynamic Router Pattern

Dispatcher Pattern

Service unit content

Example

Component Extension

Configuring the component

CDK parameters

Interception configuration

Dedicated configuration

Monitoring the component

Using metrics

Common metrics

Dedicated metrics

Receiving alerts

Common alerts

Dedicated alerts

Business monitoring

MONIT traces

Flow tracing activation

Flow tracing propagation

Labels