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.
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
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:
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.
The following information relates to how the intermediary re-routes ebXML messages:
See
The intermediary does not use CPAs. The intermediary must:
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.
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.
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.
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.
|
|