Send ebXML via an intermediary

Activator has an optional message protocol for sending ebXML messages from a true sender to a true receiver via a third party. The intermediary’s role is to receive the message from the true sender and forward it to the true receiver. The intermediary does not use a CPA. However, if both the true sender and true receiver use Interchange or Activator, the end points must use CPAs, as though the message was or sent directly.

Related topics

Overview of intermediary re-routing

Re-routing is performed by configuring Activator in the intermediary role to receive and send messages via the ebXML intermediary message protocol. The protocol is available only if your user license enables it. If the protocol is not listed in the delivery exchange wizard, your license does not support it. For information about the wizard, see:

The CPA used by the true sender must include the URI for connecting to the intermediary instead of the true receiver. Other than this one change, the CPA is written as though the true sender and true receiver exchange messages directly between each other. An exception for the CPA, however, applies when trading is via HTTPS (see Intermediary trading with HTTPS).

The following figure illustrates the flow for sending an ebXML message via an intermediary. Partner A’s Activator packages and sends the ebXML message in the usual way. Upon receiving the message, the intermediary parses the message header to identify the true receiver, but does not unpack the message. The intermediary then sends the message as received to Partner B. Partner B receives the message as though it was sent directly by Partner A. See the following ebXML message sent via an intermediary.

The role of a third-party intermediary in the transfer of a message between a true sender and true receiver.

The true sender packages the message as if it is being sent to the true receiver. Except in the case of trading via HTTPS, the true sender’s only knowledge of the intermediary is the URI used to send to the intermediary.

After receiving the message from the true sender, the intermediary parses the following metadata from the packaged ebXML message header:

  • Action
  • ConversationId
  • CPAId
  • ebXML.SignalType
  • ebXML.StatusResponse.RefToMessageId
  • FromRole
  • MessageId
  • ReceiverRoutingId
  • ReceiverRoutingIdType
  • RefToMessageId
  • SenderRoutingId
  • SenderRoutingIdType
  • Service
  • ServiceType
  • ToRole

When the intermediary parses the received message, it only reviews the ebXML header before performing the re-routing. The intermediary re-routes messages internally; it does not write messages to integration. Of the preceding metadata items parsed from the ebXML message header, the intermediary only needs the sender and receiver IDs and the routing ID types. The intermediary does not use the other metadata.

The ebXML intermediary message protocol is proprietary to Activator. The protocol does not implement any standards relating to re-routing SOAP or ebXML messages. Activator must be used in the intermediary role, but the true sender and true receiver can use any interoperable trading engine that supports ebXML.

Related topics

Intermediary message-handling notes

The following information relates to how the intermediary re-routes ebXML messages:

  • The intermediary does not unpack or repackage messages. The intermediary message protocol supports end-to-end signing and encryption.
  • The intermediary does not validate signatures.
  • Because the intermediary message protocol is exclusively for re-routing ebXML messages, the protocol overrides the message re-routing control a community optionally may have available for determining whether to re-route partners’ messages.
  • Receipts are not matched up to the payloads in the intermediary’s Message Tracker. The intermediary only passes messages through. No context is kept from message to message.
  • Synchronous acknowledgments, synchronous signals and synchronous business responses are not supported. A SOAP fault is returned to the sending system for any message that requests a synchronous response of any type.
  • The intermediary does not check for duplicate messages. The true receiver should perform duplicate checking.
  • SOAP faults are not passed from the true receiver back to the true sender. This is because synchronous responses are not supported through the intermediary. Also, there is no standard way to match asynchronous SOAP faults to the original message.

Related topics

Supported transports

See Community trading pickups and partner deliveries for the transports supported by the ebXML intermediary message protocol.

Related topics

Configuration of intermediary

The intermediary does not use CPAs. The intermediary must:

  • Configure a delivery in the community to receive messages via the ebXML intermediary message protocol from the true sender. The community must have its own unique routing ID. This routing ID is used for logging and tracking messages, but is not included in packaged messages.
  • Add a partner for the true sender. Use the true sender’s routing ID as the partner’s routing ID. Add the ebXML intermediary message protocol to the partner.
  • Add a partner for the true receiver. Use the true receiver’s routing ID as the profile’s routing ID. Add the ebXML intermediary message protocol to the partner.

Certificates do not have to be associated with the partners for the true sender and true receiver. However, if HTTPS with client authentication is used, each partner’s client certificate must be trusted for SSL by the intermediary community. See Intermediary trading with HTTPS.

A community can be configured to receive messages via both the regular ebXML message protocol and the ebXML intermediary message protocol.

Moreover, a single partner can be configured to use both the ebXML message protocol and the ebXML intermediary message protocol. But to support point-to-point messaging, the ebXML message protocol must be listed as the default protocol in the partner. This is because Activator always uses the first listed protocol to send to the partner. The ebXML intermediary message protocol must be listed as the secondary protocol to support re-routing.

A community acting as an intermediary optionally can perform in-line processing. But such processing must not change the content of re-routed messages. Any change to the content could corrupt the ebXML message.

Related topics

Configuration of end points

True senders and true receivers who use Activator must use CPAs as though the parties are directly exchanging messages without an intermediary.

Certificates in the CPA must be the certificates of the end points, not the intermediary. The CPA should ignore the intermediary, except the transport end point URIs must point to the ebXML intermediary exchange point configured in the intermediary instance.

Intermediary trading with SMTP

When setting up an ebXML intermediary with SMTP, an embedded SMTP server must be used for the receiver. If the external SMTP server is used, the trading to the receiver fails.

Intermediary trading with HTTPS

If messages are sent via HTTPs, the partners’ HTTPS server certificates must be trusted by the intermediary community.

Two end points trading via ebXML through an intermediary can use one CPA. Not only must the TransportReceiver element reference the intermediary's HTTPS URL, the ServerCerticateRef and ClientSecurityDetailsRef elements must point at the intermediary's SSL certificate. The following CPA snippet illustrates these points.

Related topics

Related Links