Interchange 5.12 Administrator Guide Save PDF Selected topic Selected topic and subtopics All content Send ebXML via an intermediary Interchange 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 Intermediary message-handling notes Supported transports Configuration of intermediary Configuration of end points Intermediary trading with HTTPS Overview of intermediary re-routing Re-routing is performed by configuring Interchange 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: Add a trading pickup Add a partner trading delivery 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 Interchange 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 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 Interchange. The protocol does not implement any standards relating to re-routing SOAP or ebXML messages. Interchange 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 Supported transports Configuration of intermediary Configuration of end points 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 Overview of intermediary re-routing Supported transports Configuration of intermediary Configuration of end points Supported transports See Community trading pickups and partner deliveries for the transports supported by the ebXML intermediary message protocol. Related topics Overview of intermediary re-routing Intermediary message-handling notes Configuration of intermediary Configuration of end points 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 Interchange 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 Overview of intermediary re-routing Intermediary message-handling notes Supported transports Configuration of end points Configuration of end points True senders and true receivers who use Interchange 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. <tp:Transport tp:transportId="transportHttps"> <tp:TransportSender> <!-- References endpoint certificate --> <tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol> <tp:TransportClientSecurity> <tp:TransportSecurityProtocol tp:version="3.0">SSL</tp:Transport SecurityProtocol> <tp:ClientCertificateRef tp:certId="Esx6_Cert"/> <tp:ServerSecurityDetailsRef tp:securityId="Esx6_Security"/> <tp:TransportClientSecurity> </tp:TransportSender> <tp:TransportReceiver> <!-- References certificate and URL for the intermediary --> <tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol> <tp:Endpoint tp:uri="https://intermediary.example.com:4334/exchange/ebxml-intermediary" tp:type="allPurpose"/> <tp:TransportServerSecurity> <tp:TransportSecurityProtocol tp:version="3.0">SSL</tp:Transport SecurityProtocol> <tp:ServerCertificateRef tp:certId="ebxml-intermediary_SSL_Server_Cert"/> <tp:ClientSecurityDetailsRef tp:securityId="ebxml-intermediary_SSL_Server_Security"/> </tp:TransportServerSecurity> </tp:TransportReceiver> </tp:Transport> Related topics Overview of intermediary re-routing Intermediary message-handling notes Supported transports Configuration of intermediary ebXML overview ebXML message lifecycle ebXML message metadata ebXML message metadata documents (MMDs) Supported ebXML trading transports Supported ebXML application transports ebXML message compression Set up a community for ebXML trading Extract KeyInfo element for a CPA Manage CPAs Tools for CPAs STAR BODs with ebXML HL7 payloads with ebXML ebXML partner self-registration ebXML troubleshooting Related Links
Send ebXML via an intermediary Interchange 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 Intermediary message-handling notes Supported transports Configuration of intermediary Configuration of end points Intermediary trading with HTTPS Overview of intermediary re-routing Re-routing is performed by configuring Interchange 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: Add a trading pickup Add a partner trading delivery 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 Interchange 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 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 Interchange. The protocol does not implement any standards relating to re-routing SOAP or ebXML messages. Interchange 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 Supported transports Configuration of intermediary Configuration of end points 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 Overview of intermediary re-routing Supported transports Configuration of intermediary Configuration of end points Supported transports See Community trading pickups and partner deliveries for the transports supported by the ebXML intermediary message protocol. Related topics Overview of intermediary re-routing Intermediary message-handling notes Configuration of intermediary Configuration of end points 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 Interchange 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 Overview of intermediary re-routing Intermediary message-handling notes Supported transports Configuration of end points Configuration of end points True senders and true receivers who use Interchange 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. <tp:Transport tp:transportId="transportHttps"> <tp:TransportSender> <!-- References endpoint certificate --> <tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol> <tp:TransportClientSecurity> <tp:TransportSecurityProtocol tp:version="3.0">SSL</tp:Transport SecurityProtocol> <tp:ClientCertificateRef tp:certId="Esx6_Cert"/> <tp:ServerSecurityDetailsRef tp:securityId="Esx6_Security"/> <tp:TransportClientSecurity> </tp:TransportSender> <tp:TransportReceiver> <!-- References certificate and URL for the intermediary --> <tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol> <tp:Endpoint tp:uri="https://intermediary.example.com:4334/exchange/ebxml-intermediary" tp:type="allPurpose"/> <tp:TransportServerSecurity> <tp:TransportSecurityProtocol tp:version="3.0">SSL</tp:Transport SecurityProtocol> <tp:ServerCertificateRef tp:certId="ebxml-intermediary_SSL_Server_Cert"/> <tp:ClientSecurityDetailsRef tp:securityId="ebxml-intermediary_SSL_Server_Security"/> </tp:TransportServerSecurity> </tp:TransportReceiver> </tp:Transport> Related topics Overview of intermediary re-routing Intermediary message-handling notes Supported transports Configuration of intermediary ebXML overview ebXML message lifecycle ebXML message metadata ebXML message metadata documents (MMDs) Supported ebXML trading transports Supported ebXML application transports ebXML message compression Set up a community for ebXML trading Extract KeyInfo element for a CPA Manage CPAs Tools for CPAs STAR BODs with ebXML HL7 payloads with ebXML ebXML partner self-registration ebXML troubleshooting