Visibility and monitoring concepts

Each exchange of documents between your organization and a trading partner is made up of one or more events. You view the events that take place in an exchange to validate message processing or to determine whether there was a problem with the message exchange. You can configure the system to use monitoring applications to interact with the event messages that are generated during exchanges.

The information for an exchange, including flow, triggers, and actions, are defined in exchange profiles. When a document is received, the communications component determines which exchange profile to use to exchange the document. As the document is exchanged, each event generates a message that indicates whether the event succeeded or failed. Visibility provides a view of the event messages for an exchange.

Visibility and exchange profiles, exchanges, and events

Visibility provides access to event messages; visibility does not provide access to the exchange events themselves. Event messages are triggered by the events that occur during a document exchange between the system and trading partners. How documents are exchanged is defined in an exchange profile. The exchange profile, events, and messages are interrelated and understanding their relationship is key to using and troubleshooting exchanges.

Exchange profiles and exchanges

The exchange profile defines what to do when a document is received or sent.

An exchange is the actual movement of the document from one system to another.

The exchange profile defines what happens in an exchange. An exchange happens only when a document is received or sent.

Exchange profiles and trading partners

Each trading partner can have several exchange profiles, depending on the types of documents that are being transferred. You can send several different types of documents to the same trading partner. For example, for a trading partner you might send:

Inventory documents to a warehouse system.
Purchase order documents to an order fulfillment destination.
Payroll documents to an accounting system.

In this example, you have three unique exchange profiles for the trading partner because the documents are going to different destinations within the trading partner.

Exchange events

Each exchange is made up of a series of events. These events either complete successfully or fail. Events that happen in an exchange generates event messages. The event message indicates the event status.

Exchange state

The exchange state is calculated based on what happened in the exchange and all of the event statuses. One or more events in an exchange can fail and an exchange can still complete successfully. For example, it might take several retransmission attempts before a document is delivered. In this instance, there would be several failed events, but the exchange state would be successful because one of the retransmission attempts succeeded.

Event messages

Many event messages can be generated for an exchange. Events vary from exchange to exchange because different exchanges use different exchange profiles. Each exchange is unique and exchanges that use the same exchange profile can generate different event messages. For example, the number of retransmission attempts for one exchange can differ from the number of retransmission attempts for another exchange that uses the same exchange profile.

View exchange event messages

Event messages are processed in the order that they are received.

You can use the Search Transactions and View Transactions tasks to find and view event messages, and use this information to verify that exchanges succeeded. You can also use this information to troubleshoot if an exchange fails. You can view the following information:

The exchange profile that is used for an exchange and verify the triggers, actions, and destination.
The event details, including payload and attachment information.
Historical data for exchanges that used the same exchange profile.

One-way and two-way exchanges

Exchanges are either one-way or two-way. For one-way exchanges, all of the events are collected and identified by a single transaction identifier. For two-way exchanges, two exchanges occur:

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

The visibility user interface combines the two exchanges that occur in a two-way exchange into a single exchange for ease of viewing.

Visibility event messages and third-party applications

The event messages go to WebSphere® MQ queues identified by message fabric endpoints. The system administrator can create subscriptions to the visibility queue. When a message arrives in the queue, the message fabric sends the message to all of the queue subscribers. Third-party applications can use these queue subscriptions to get the event messages and use the messages for monitoring the system, for example. The messages that are used in the AS4 Microservice exchange details pages and the third-party applications are from the same source.

System messages

AS4 Microservice messages relay information about how the system or application is doing and can alert you to exceptional conditions when they occur. Messages also provide you with visibility into system processing.

Messages are displayed through the user interface and written to the log files. If you receive a warning or error message, you can do one of the following actions:

Follow the instructions that are listed in the detail section of the message to see what action you can take to correct the problem.
Consult the message log for the message ID, message description, time, and date of the message, and other data that you can use to diagnose and correct the problem.

The content of each information, warning, and error message is defined by a triplet format. The triplet format is as follows:

Message ID and short text: Product-specific unique message identifier and short description of the problem.
Explanation: Describes the cause of the problem and includes information to help you avoid this problem in the future.
User action: Describes what you must do to proceed, recover from the error, or to prevent a pending problem.

Message IDs are formatted as BCXSSNNNNT, in which these prefixes and identifiers are the constituent components.

BCX: Is the three-character prefix that identifies the AS4 Microservice software brand.
SS: Is the two character prefix extension that is used to identify one or more software components.
NNNN: Is a unique four-digit identifier for the message.
T: Indicates whether the message is information (I), warning (W), or an error message (E).