This appendix discusses how to diagnose and troubleshoot basic issues in Oracle B2B.
The chapter contains the following sections:
When you encounter any error in sending or receiving messages by using Oracle B2B, you can diagnose the root cause of the error.
Studying error details and identifying the type of errors by using Oracle B2B is the first step to diagnose issues.
Errors can be of the following types:
Connection error
Document identification error
Document validation error
Agreement identification error
Table C-1 lists the common error types.
Table C-1 Types of Errors
| Error Type | Error Message | Possible Cause |
|---|---|---|
|
Connection |
|
Outbound Case: Delivery Channels: Trading Partner is not up or Trading Partner URL is not correct. |
|
Document Identification |
|
Inbound Case (depends on protocol):
Outbound Case:
|
|
Document Validation |
|
Inbound Case (EDI, HIPAA, HL7):
Outbound Case (EDI, HIPAA, HL7):
|
|
Agreement Identification |
|
Inbound or Outbound Case:
|
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.
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
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.
Check whether the Translator XML parameters have been set properly.
For any message that requires translation by Oracle B2B, the following parameters are required:
Standard (example: X12)
Version (example: 4010)
GUID (example: {12345678-1234-1234-1234-123456789012}
Check whether the Translator XML internal properties are set properly
The XML Schema generated by the Document Editor contains Internal Properties that enables you to override the defaults in Oracle B2B, which are used to generate the envelope for outbound transaction sets. In inbound direction, this structure supplies additional information for processing.
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:
Open Oracle Fusion Middleware Enterprise Manager Control console.
Navigate to SOA > <SOA Domain name>.
Right-click <SOA Domain name> and select Logs > View Log Messages.
Click Target Log Files on the right section.
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:
This section discusses how to troubleshoot a sample case in Oracle B2B.
The section includes the following sections:
Consider the following case:
A trading partner MarketInc sends a purchase order 850 document to OracleServices.
OracleServices first sends a Message Disposition Notification (MDN), and then a 997 Functional Acknowledgement back to MarketInc.
MarketInc then sends an MDN back to OracleServices for the 997 received.
MarketInc then expects a purchase order acknowledgement 855 from OracleServices. However, MarketInc does not receive an 855 message from OracleServices in 24 hours.
MarketInc then checks with OracleServices with the 850 OrderID about the message status.
OracleServices performs the following steps to troubleshoot the problem:
To trace the inbound message, you first start checking in Oracle B2B console, and if that does not yield any results, then check the Fusion Middleware Enterprise Manager Control console.
To check in Oracle B2B console:
Log on to Oracle B2B console.
Click the Reports link.
Click the Business Message tab.
Select the business message or search using the advanced search options by Order ID.
The advanced search options are available when you click the Advanced button and these enable you to query using additional fields. Enter the XPath expression for Order ID (as specified during design time.)
Click the required business message in the Results table and check the message details for any errors.
If there are no errors, then check the Wire Message reports by clicking the Wire Message link.
Check for any errors in the Wire Message details window.
If there are no errors, then return to the Business Message details and then check the Application Message reports by clicking the Application Message link.
Select the message from the Results table or search for the relevant message by using the Order ID.
Click the required business message in the Results table and check the message details for any errors.
If there are no errors, then the message has been delivered to the composite.
If you want to check, in the Business Message details in the B2B reports, there is a field called EM Flow. For example, EM Flow 0000KM6msHL2RPM5INc9yf1JLP3m00000z, where 0000KM6msHL2RPM5INc9yf1JLP3m00000z is a link where you can click and it will bring up the instance in Fusion Middleware Control.
If there are no errors in the Oracle B2B console, the next step is to check errors in the composite in Fusion Middleware Enterprise Management Control console.
To check in Fusion Middleware Enterprise Management Control console:
Log on to Fusion Middleware Enterprise Management Control console.
Navigate to the composite under SOA and check for any faults by clicking the Flow Instances tab and then clicking the Instances With Faults link on the top right part of the page.
If you want to check, in the Business Message details in the B2B reports, check the field called EM Flow., as you did in Checking for the inbound message errors in the Oracle B2B console, to view the Flow Trace.
Check the state of various parts of the composite, and click to view the error details.
To trace the outbound message, you first start checking in the Fusion Middleware Enterprise Manager Control console, and if that does not yield any results, then check the Oracle B2B console.
To check for errors in the outbound message:
Log on to Fusion Middleware Enterprise Management Control console.
Navigate to the composite under SOA and check for any faults by clicking the Flow Instances tab and then clicking the Instances With Faults link on the top right part of the page.
Click the faulty composite Instance ID.
Check the state of various parts of the composite, and click to view the error details.
If you cannot find any error, click the Oracle B2B binding component to display the Oracle B2B reports.
If there are no errors in the Fusion Middleware Enterprise Management Control console, the next step is to check errors in the Oracle B2B reports.
When you click the Oracle B2B binding component in the Fusion Middleware Enterprise Management Control console, the corresponding Business Message opens up.
Drill down on the message details by clicking the Details link and check for errors.
If there are no errors, then check the Wire Message report.
If you find any error, such as connection problem, then rectify the error and then resubmit the outbound message.