In a cluster environment, if system time stamps are not synchronized for all nodes in the cluster, then you may see message time stamps that look incorrect, but are not. For example, given an unsynchronized, multinode cluster, if an outbound message is received on one node, but the reply is sent from another node, it is possible for a report to show message receipt at 4 a.m., but an acknowledgment sent at 3:55 a.m.

18.1.1 The Monitor User Role

For individuals such as business analysts who create and analyze message reports, Oracle B2B provides a monitor user role that an administrator can assign to trading partner users. This role provides a user with access to only the functionality of the Reports tab of Oracle B2B. A user with the Monitor role cannot see or access the other parts of the interface or see data for other trading partners. See Section 5.3, "Adding Trading Partner Users," for how to assign the Monitor role.

18.1.2 Purging Messages

From the Business Message tab, use the Purge button to purge one or more messages that display after you search the instance data.

18.1.3 Resubmitting Messages from Oracle B2B

If errors that occur when sending an inbound or outbound message are internal to Oracle B2B, then you can correct the problem and resend the message. For example, if B2B attempts to send a message to an endpoint that is not configured correctly, or if the agreement is not configured correctly, correct the error and use Resubmit for application messages or wire messages.

Resubmitting an application message, for an outbound message, replays the message from the time of receipt of the message and goes through agreement lookup, message translation (for EDI) and then finally the delivery is attempted. An application message resubmit is helpful when the agreement settings or document configuration is not as required and the message must be restructured with updated settings.

Resubmitting an application message, for an inbound message, attempts to deliver the message again to the back-end application. Resubmitting is useful when the back-end application is down and the delivery must be retried.

Resubmitting a wire message, for an outbound message, tries to redeliver only the previously processed message. There is no repackaging or other message transformation. This is helpful when the problem was with the delivery endpoint (for example, the partner's server is down and unable to receive the message).

Resubmitting a wire message, for an inbound message, replays the message from the time of receipt from the trading partner. The exchange and document are re-identified and an agreement lookup is done. The processed message is then delivered to the back-end. This is useful when the agreement or document setting are not correct and the message must be translated and validated again.

Note:

For EDI/EDIFACT documents, the user can set XPath expressions to check for, and thus avoid duplicates. If two messages arrive with the same XPath values, the latter of the messages is marked as duplicate and it errors out.

When you resubmit this errored duplicate message (a wire message resubmit), Oracle B2B processes the message ignoring the fact that it is a duplicate, because the resubmission is done intentionally. So, if you do not want Oracle B2B to process duplicate messages, you should not resubmit those messages.

Note:

If you resubmit an inbound AS2 synchronous wire message, the MDN is generated, but it is not returned to the sender in synchronous mode. This is because the sender is not the one who is initiating the originating message. In this scenario, the MDN message state is in the MSG_COMPLETE state.

18.2 Creating Business Message Reports

Business message status reports identify business message instance details for a document protocol. These details include the sending and receiving trading partners, the agreement name, the business action, the business message ID, the status, the exchange protocol and document protocol, and message details.

Select from a previously created document type, for example, 850 for EDI X12. (Equals is the only operator.)

Document Protocol Version

Select from a previously created document protocol version. (Equals is the only operator.)

Document Definition

Select from a previously created document definition. (Equals is the only operator.)

Use the document search parameters as follows: Select a document protocol name first to populate the list of document protocol versions; next select a document protocol version to populate the list of document types; and then select a document type to populate the list of document definitions.

18.3 Creating Wire Message Reports

Wire messages are the native format of data sent from trading partners. Wire messages can contain several sections, such as payloads, attachments, or trailers. Wire message status reports identify details about wire message instances, such as the transport protocol name, the transport protocol revision, and the protocol message identification and its state. The reports enable you to go from a business message to its corresponding wire message and from a wire message to its corresponding business messages.

18.6 Creating Conversation Reports

A conversation message results when the correlation XPath is set in a document definition to correlate messages. A correlation message also shows messages that are correlated automatically. For example, an AS2 message and its acknowledgment (MDN) are automatically correlated as part of a conversation. In RosettaNet, request and response messages are also correlated, in addition to the acknowledgments sent and received. These related messages are displayed on the Conversation tab.