Using Execution Tracing to Diagnose Problems

18.1 Introduction to Execution Tracing

Service Bus lets you trace messages without having to shut down the server, a useful feature in both development and production environments. Execution tracing allows administrators, support engineers, and systems engineers to troubleshoot and diagnose a message flow in one or more pipelines or split-joins.

For example, if one of your pipelines is failing and you want to find out at which stage the problem exists, you can enable execution tracing for that pipeline. After tracing is enabled, the system logs various details extracted from the message flow such as stage name, name of the pipeline, and route node name. The log entry also includes the entire message context, including headers and message body. When a fault occurs in the message flow, additional details such as error code and reason are logged. Execution tracing occurs at the beginning and end of each component in the pipeline, which includes stages, pipeline pairs, branches, and nodes. Actions are not traced individually.

18.2 Enabling and Disabling Execution Tracing

Service Bus lets you trace messages without having to shut down the server, making it easier to troubleshoot and diagnose a message flow.

By default, execution tracing is disabled. After you enable execution tracing, the system logs various information culled from the pipeline context and the message context, including stage name; pipeline or route node name; and the current message context.

You can enable execution tracing for a pipeline or split-join in Fusion Middleware Control on the Operations tab for the server or project, or on the Properties tab for the pipeline or split-join.

18.2.1 Setting Oracle WebLogic Server Log Levels

To see tracing in the log file or standard out (server console), Oracle WebLogic Server logging must be set to the following severity levels:

Minimum severity to log: Info
Log file: Info
Standard out: Info

For information on setting log severity levels, see Using Log Severity Levels in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.

18.2.2 Configuring Execution Tracing for a Single Service

To configure execution tracing for one service:

Perform a search for services, as described in Searching for Services to Configure Their Operational Settings.
In the Operations table, click the pipeline or split-join you want to configure.

The Properties page for that service appears.
Next to Execution Tracing, select Enabled.
Click Apply.

18.2.3 Configuring Execution Tracing for Multiple Services

To configure execution tracing for multiple services:

Perform a search for services, as described in Searching for Services to Configure Their Operational Settings.
To enable execution tracing for any pipeline or split-join in the results list, select its check box in the Exe Tracing column.
To disable execution tracing for any pipeline or split-join in the results list, clear its check box in the Exe Tracing column.
Click Apply.

18.3 Accessing Execution Tracing Information

Execution tracing information is stored in the server directory logs.

It is stored in this location:

DOMAIN_HOME/servers/server_name/logs/server_name-diagnostic.log

You can view the log file directly, or you can view log entries in Oracle WebLogic Server Administration Console and Fusion Middleware Control.

Note:

The execution tracing pattern in the server log is identical to the execution tracing in the Test Console.

The following example shows a sample execution tracing entry in the log file.

Example - Tracing Entry Example

####<Dec 6, 2013 12:32:35 PM PST> <Info> <oracle.osb.pipeline.kernel.router>
<MyServer> <osb_server1> <[ACTIVE] ExecuteThread: '19' for queue:
'weblogic.kernel.Default (self-tuning)'> <<anonymous>>
<BEA1-7438AA7859AFBEC29BF0> <7f5b2958-8673-4439-87ec-f860ccac436b-0005f450>
<1386361955302> <OSB-382159> <[OSB Tracing] The following variables are changed:
$body = <soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
 <cus:Customer xmlns:cus="http://oracle.com/Customer">
   <cus:first>Mike</cus:first>
   <cus:last>Morse</cus:last>
   <cus:company>CompanyA</cus:company>
 </cus:Customer>
</soapenv:Body>
$inbound = <con:endpoint name="ProxyService$osb-102-FileHandling$CustomerPoller" 
            xmlns:con="http://www.bea.com/wli/sb/context">
  <con:service/>
  <con:transport>
    <con:uri>file:///customer/data/input</con:uri>
    <con:mode>request</con:mode>
    <con:qualityOfService>exactly-once</con:qualityOfService>
    <con:request xsi:type="file:FileRequestMetaData" 
                 xmlns:file="http://www.bea.com/wli/sb/transports/file" 
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
       <tran:headers xsi:type="file:FileRequestHeaders" 
                    xmlns:tran="http://www.bea.com/wli/sb/transports">
         <file:fileName>/customer/data/input/CustList.txt
         </file:fileName>
       </tran:headers>
       <tran:encoding xmlns:tran="http://www.bea.com/wli/sb/transports">utf-8 
       </tran:encoding>
      <file:isFilePath>false</file:isFilePath>
    </con:request>
  </con:transport>
  <con:security>
    <con:transportClient>
      <con:username>anonymous></con:username>
    </con:transportClient>
  </con:security>
</con:endpoint>
> 
####<Dec 6, 2013 12:32:35 PM PST> <Info> <oracle.osb.pipeline.kernel.router>
 <MyServer> <osb_server1> <[ACTIVE] ExecuteThread: '19' for queue:
 'weblogic.kernel.Default (self-tuning)'> <<anonymous>>
 <BEA1-7438AA7859AFBEC29BF0> <7f5b2958-8673-4439-87ec-f860ccac436b-0005f450>
 <1386361955303> <OSB-382186> <[OSB Tracing] Exiting Pipeline>