1. Using Oracle B2B
  2. Appendices
  3. Diagnosing Generic Issues

D Diagnosing Generic Issues

This appendix discusses how to diagnose and troubleshoot basic issues in Oracle B2B.

Generic Diagnostics

When you encounter any error in sending or receiving messages by using Oracle B2B, you can diagnose the root cause of the error.

Identifying the Error in Oracle B2B Console

Studying error details and identifying the type of errors by using Oracle B2B is the first step to diagnose issues.

Identifying the Error Type

Errors can be of the following types:

  • Connection error

  • Document identification error

  • Document validation error

  • Agreement identification error

Table D-1 lists the common error types.

Table D-1 Types of Errors

Error Type Error Message Possible Cause

Connection

Transport error: [IPT_HttpSendConnectionRefused

Outbound Case:

Delivery Channels: Trading Partner is not up or Trading Partner URL is not correct.

Document Identification

Document protocol identification error

Inbound Case (depends on protocol):

  • Incorrect XPath, Positional file, Document type, or filename

Outbound Case:

  • B2B parameters not set properly

  • Incorrect XML: Internal-properties

Document Validation

General Validation Error

Depends on the document protocol.

Agreement Identification

Trading partner agreement not found for the given input values

Inbound or Outbound Case:

  • No agreement found for Partner and Document combination

  • Wrong direction in agreement
Identifying the Location of the Error

After you identify the error type, you need to find the location of the error.

Errors can occur at the following levels:

  • Trading Partner: If you have sent a message, but did not receive an ACK from the trading partner, something might have gone wrong at the partner side.

  • B2B: At the Oracle B2B end, it could be a Control Number issue (duplicate Control Number), a validation issue, or an identification issue. Identification could be document identification or agreement identification.

  • Composite: At the composite end, it can be a routing issue where the msg was received by a wrong composite. In addition, it can be a validation issue, XSLT issue, or even the endpoint may be down, so there is a communication failure with the application.

  • Application: At the application level, it can be an issue with incorrect documents or authorization, or a data validation error in the application.

Checking the Message Flow

You can also check the message flow and view the error report to figure out the error details. The message flow can be from:

  • From the trading partner:

    Wire > Business > Application

  • From Middleware:

    Application > Business > Wire

Sample Diagnosis

Consider a situation where an agreement between two trading partners is not found leading to an error.

In this case, do the following checks:

  • Check the order of identification:

    • Partner: First identify the partners between whom the message is getting exchanged

    • Document: Identify the document types and document revision of the message

    • Agreement: Identify the agreement based on the partners and the documents exchanged

    • Document Validation: Check whether the document is valid for the agreement

  • Check from the trading partner side:

    • Check the identifiers. Identifier types enable Oracle B2B to identify a trading partner at runtime. In general, the identification process is to identify the partner, then the document, and then the partner-document pair identifies the agreement. Oracle B2B provides each trading partner with a default identifier type, Name, whose value is the name of the trading partner.

    • Check whether the correct document identification method has been used.

  • Check from the middleware side:

    • Check whether the correct B2B parameters related to agreements are set properly in Oracle Fusion Middleware Enterprise Manager Control console.

Examining the Log Files and Composites in Fusion Middleware Enterprise Manager Control Console

Apart from the Oracle B2B console, you can diagnose issues with message exchange by using the Oracle Fusion Middleware Enterprise Manager Control console.

Note:

All errors that are created are queued up in the B2B exception queue by default. You can also monitor that queue. If there is an error handling framework built around the error queue, then you can receive error notifications rather than checking the console for any errors that might have occurred. This might be covered in the exception handling section so you can point them there as well. For additional related information, see Using a Custom Exception Queue for Error Message Delivery and other sections in Exception Handling.

To view diagnostic logs for Oracle B2B, you need to set the log levels by using the Enterprise Manager Control console.

See Configuring "Oracle B2B Logging Mode" in Oracle Fusion Middleware Administering Oracle SOA Suite and Oracle BPM Suite.

Note:

For more information about log files and the level and type of logging information to write to a log file, see Oracle Fusion Middleware Administrator's Guide.

To view Oracle B2B related log files:

  1. Open Oracle Fusion Middleware Enterprise Manager Control console.

  2. Navigate to SOA > <SOA Domain name>.

  3. Right-click <SOA Domain name> and select Logs > View Log Messages.

  4. Click Target Log Files on the right section.

  5. Select <Managed_Server name>-diagnostic.log and click View Log File.

You can also check the deployed composite and perform a flow tracing for any error that may have occurred.

To check the composite and perform flow tracing:

  1. Open Oracle Fusion Middleware Enterprise Manager Control console.
  2. Navigate to the deployed composite under SOA > <SOA Domain name>.
  3. Click the Flow Instances tab and search for an instance.
  4. Click the relevant Flow ID link and view the flow trace.

Displaying the Actual Thread ID in the Log File

Thread IDs can be used to trace the execution of each thread in the diagnostic log. You can use them to associate each trace line with its thread ID. By default, the log file contains the thread name, which can be generic, such as Workmanager.

You can display the actual thread ID in the log file by changing the configuration of the handlers in the logging.xml file. Use the ODLHandler properties useThreadName and useRealThreadId to control logging of thread name or ID. Setting useThreadName to false stops the logging of the thread name. Setting useRealThreadId to true adds the actual thread ID to the log.

This is a generic configuration:
<log_handler name='odl-handler'
class='oracle.core.ojdl.logging.ODLHandlerFactory'>
     <property name="path" value="..."/>
     ....
     <property name="useThreadName" value="false"/>
     <property name="useRealThreadId" value="true"/>
</log_handler>
This is an example configuration:
$Domain/config/fmwconfig/servers/soa_server1/logging.xml
   <property name='useThreadName' value='false'/>
   <property name='useRealThreadId' value='true'/>
Note that the location of the logging.xml file can vary slightly, depending on the version you are using.

  • For 12.1.3: oracle_common/modules/oracle.odl_12.1.3/server_config/logging.xml

  • For 12.2.1: oracle_common/modules/oracle.odl/server_config/logging.xml