Monitoring and exchange patterns, direction, and identifiers

Message exchanges follow specific patterns, one-way or two-way, inbound and outbound. Large messages might be split into several exchanges. Each exchange has a unique identifier. Exchange identifiers are grouped and displayed differently for two-way exchanges and for exchanges that were split into multiple parts.

View exchange and event details

You can use the Advanced Search page and Exchange and Event Details page to find and view event messages for specific exchanges. Use this information to verify that exchanges succeeded or to troubleshoot failed exchanges. On the Exchange and Event Details page you can view the following information:

  • The exchange profile that is used for an exchange.
  • The links to related exchanges or exchange fragments.
  • The event details, including payload and attachment information.
  • The historical data for exchanges that used the same exchange profile.
  • The replay state of the transaction and whether the transaction is available to be replayed. Replay eligibility depends on the protocol and exchange profile pattern used. Only outbound processes in a stable final state such as completed successfully, completed with errors, or failed are available to be replayed.
  • The redelivery state of the transaction and whether the transaction is available to be redelivered. Redelivery eligibility depends on the protocol and exchange profile pattern used. Both inbound and outbound transactions can be redelivered for asynchronous exchange patterns that do not require an active partner connection (for example, a partner pull is not eligible for redelivery). For inbound transactions, when the redelivery is triggered the same payload and attachments is delivered to the configured destination queue.
  • For replayed or redelivered transactions, you can also view the most recent associated transaction identifier or identifiers.

Exchange patterns

Exchanges follow one of the following patterns:

  • AS4 one-way push - one-way exchange from the sender to the receiver. Exchange is initiated by the sender.
  • AS4 one-way pull - one-way exchange to the receiver. Exchange is initiated by the receiver.
  • AS4 two-way synchronous - two-way exchange between the sender and receiver in which the receiver sends a receipt to the sender. The sender initiates the first exchange and the receiver initiates the response exchange.
  • AS4 two-way push-push - two one-way exchanges in opposite directions where the message of the first exchange refers to the message of the second exchange
  • AS4 two-way push-pull - a one-way push exchange followed by a one-way pull exchange. Both exchanges are initiated by the sender.
  • AS4 two-way pull-push - a one-way pull exchange followed by a one-way push exchange. Both exchanges are initiated by the receiver.
  • RESTful HTTP or HTTPS one-way push - one-way exchange from the sender to the receiver. Exchange is initiated by the sender.
  • RESTful HTTP or HTTPS one-way pull - one-way exchange to the receiver. Exchange is initiated by the receiver.

One-way and two-way exchanges and identifiers

Exchanges are either one-way or two-way.

For two-way exchanges, for example, AS4, there are two exchanges:

  • An exchange from the sender to the receiver
  • An exchange from the receiver back to the sender

Two-way exchanges have two distinct exchanges, each with a unique transaction identifier. These two identifiers are associated with each other with a Conversation identifier.

You can search for the Conversation identifier on the Advanced Search page.

Two-way exchange event details

For AS4 two-way push-pull pattern exchanges, the Exchange Details area of the Exchange and Event Details page shows a list of Related Exchanges. The Related Exchanges are hyperlinks that you select to view the event details for the push exchange and the pull exchange.

For AS4 two-way synchronous exchanges, the Exchange and Event Details page groups the events by request and response. The Request grouping shows the events from the sender to the receiver and the Response grouping shows the events from the receiver back to the sender.

Split and join

Exchanges that have large messages can be split into fragments at the sender side and joined at the receiver side. The source message and each of the fragments has a unique transaction identifier. All of the fragments are associated with the source message transaction identifier.

The Exchange and Event Details page shows the source message transaction identifier and the transaction identifiers for each of the fragments. The source transaction identifier is shown in the Source Exchange section of the Exchange and Event Details. The fragment transaction identifiers are shown in the Related Fragment Exchanges section of the Exchange and Event Details page.

When you select the source transaction identifier, you see the events details for the source transaction and a list of the fragment transaction identifiers. When you select a fragment exchange, you see the event details for the fragment exchange and a list of the sibling fragment transaction identifiers and the source transaction identifier.

Event duration

Some exchange events, such as authentication, can take longer than other because of network conditions. For these events, a "time taken" is calculated and shown in the Event Details for the exchange. The events that show the "time taken" include these items:
  • HTTP server
  • Authentication and CRL
  • Signature checking
  • Authorization checking
  • Payload persistence
  • Business document object that is sent to message fabric