Exchange concepts

An exchange is the transmission of data to and from your partners. Important exchange concepts include the exchange profile, exchange patterns, conformance policies, organizations, destinations, receivers, and internal message queue definitions. An exchange profile contains the necessary information that is needed by an owner organization and a trading partner organization to facilitate the exchange of messages between them.

The most fundamental concept of is that two parties want to exchange information. This concept is represented in the product by an owner organization (your organization) that wants to exchange information with a partner organization. The exchange between these parties references both the owner organization and the partner organization.

Exchange profile

The exchange profile contains the required configuration to enable the data exchange between the parties. This configuration information can be reused for other exchange profiles by creating reusable configuration resources such as security policies, conformance policies, destinations, receivers, and so forth. The necessary information includes details of the participating organizations, exchange pattern, and conformance policy or security policy. Additionally, the exchange profile includes credential information that is required to authenticate each party with the other, and the destination and the receiver information. A conformance policy is associated with an exchange profile. The owner organization and partner organization agree on the message exchange pattern that is used in a message exchange. For AS2, configuration of features such as transport layer security, integrity, nonrepudiation, and confidentiality depends on the parameters in the security policy. For AS4, configuration of features such as security, reliability, and error handling depends on the processing mode parameters in the conformance policy.

Message exchange patterns

A sender is an entity or partner that initiates the sending of a user message. A receiver is an entity or partner that receives the message. The user message unit, along with any referenced payload items, is part of a user message that is submitted by a sender (and subject to delivery to a consumer). The following message exchange patterns types are supported in :
  • One way – Controls the exchange of a single message unit. The message unit is unrelated to other user messages.
  • Two way – Controls the exchange of two user message units in opposite directions. The first message to occur in the exchange is the request and the second message is the reply, which is a response to the request.

These exchange patterns define the number of participants in the exchange, the roles of the participants, and the information that is required to configure the exchange. This required information allows the parties that are involved to successfully exchange information.

Message exchange pattern bindings

A message exchange pattern binds with the underlying transport channel to transfer messages. Based on how a message exchange pattern binds with the transport protocol, the following transport channel bound message exchange patterns are defined in the AS2 and AS4 specifications and supported in :
  • AS2 Inbound - Involves receiving a single message unit from the receiver to the sender (one way).
  • AS2 Outbound - Involves sending a single message unit from the sender to the receiver (one way).
  • AS4 One-Way/Push – Involves the transfer (push) of a single message unit from the sender to the receiver.
  • AS4 One-Way/Pull – Involves the transfer of a single message unit to the receiver. The receiving system initiates the transfer by sending a pull signal to the sender.
  • AS4 Two-Way/Sync – Involves the transfer of two user message units between the sender and the receiver. The sender or the initiator sends the first user message, the request, to the receiver (the responder). The receiver responds with a related user message, the reply.
  • AS4 Two-Way/Push-and-Push – Involves two one-way push transfers in opposite directions. The message unit of the first transfer refers to the message unit of the second transfer.
  • AS4 Two-Way/Push-and-Pull – Involves a one-way push followed by a one-way pull transfer. Both the transfers are initiated by the sender. The message unit that is pulled refers to the message unit that was pushed.
  • AS4 Two-Way/Pull-and-Push – Involves a one-way pull followed by a one-way push transfer. Both the transfers are initiated by the receiver. The message unit that is pushed refers to the message unit that was pulled.

AS4 conformance policies

AS4 simplifies the ebMS 3.0 specification for web services business-to-business messaging. The AS4 conformance policy is a subset of the ebMS specification. It provides guidelines for secure and payload-agnostic exchange of B2B documents when using web services. In addition to the predefined AS4 conformance policies, supports a custom conformance policy.

Each conformance policy includes a defined set of features, web services interoperability requirements, and processing mode (p-mode) parameters. The set of features determines the p-mode parameters that are required for an end-to-end message flow for a specific conformance policy. The p-mode parameters can be configured when you are creating a conformance policy. The AS4 custom conformance policy is a superset of the AS4 ebHandler, AS4 light client, AS4 minimal client conformance policies. It contains all the p-mode parameters that are specified in these conformance policies. You can define a custom conformance policy to take advantage of the benefits of the p-mode parameters that are not available in the individual predefined AS4 conformance policies.

AS2 security policies

Security policies establish guidelines to govern and ensure secure partner communications via AS2. The security policies define transport security options, integrity options, nonrepudiation options, and confidentiality options for AS2 message exchanges.

Organization

An organization represents either your company (the owner organization) or a trading partner in an exchange. The organization consists of a profile that describes the identity information, contact information, and contact persons for the organization.

Organizations can have many contacts that are associated with them. However, each organization has only one primary contact that represents the person who can speak for the organization.

AS4 anonymous partner

supports an anonymous partner for authentication and authorization with AS4 exchanges, instead of configuring a partner organization in the system. This anonymous partner is useful because you can then receive AS4 messages without onboarding the partner from whom the messages are received. The anonymous partner can represent more than one partner through the anonymous partner mechanism. This mechanism supports many trading partners (or individual users) without needing to configure an organization (identity representation in the system), specific certificates, and exchange details for each one.

Destination

A destination is an endpoint for delivering data to trading partners and other systems. A destination is generally the location where the exchange is sent. You can also use a messaging destination to notify the business application of errors that occur during the transaction.

Receivers

A receiver is a configurable endpoint for receiving data from a trading partner, and is selected as part of the exchange profile. The AS4 receiver is a bridge between the transport protocol (HTTP or HTTPS) and . For example, an HTTP receiver allows a trading partner to post information to the receiver by using the HTTP protocol. Similarly, for an AS2 receiver, a trading partner can connect to the receiver and send a payload by using the AS2 protocol to the receiver.

Triggers and actions

A trigger is a catalyst that causes exchanges to be created based on an external event. Triggers use information that they either have in their definition or information in an associated exchange profile to create the exchange. The triggering event can be an event such as the receipt of a file from a receiver hosted by the owner organization or a message on a defined queue.

The event causes the trigger to be run, which then creates the exchange instance and does an action. An exchange usually consists of multiple events.

After an exchange is created, it acts as the container for all events that are associated with the information that is sent and received between the parties involved. These events originate from the all the system components that are involved with the processing of the data that is associated with the exchange. The list of events provides visibility into what happened when the exchange took place.

Each event consists of a stage, action, and status. The stage represents the point in the system where the event occurred, and is either processing or communications. Multiple events can occur at each stage.

The action is what happened within that stage. For example, a sent file, received file, or translated payload. The status represents the state of the exchange (for example, receiving payload, waiting for MDN, or processing payload).

Message queue definitions

As part of configuring an exchange profile, you must define your internal message queues. A message queue enables the components in to communicate with each other. A component sends a message to a predefined queue. That queue holds the message until the receiving component retrieves the message from the queue and processes the request or information that is contained in the message.

You can configure message queues and associate them with the messaging receiver and messaging destination for communicating with the business application. You can also create message queues to send error notifications to the business application.