HTTP (embedded) business cases

This topic provides examples of using various remote URL and proxy settings to achieve different results with the embedded HTTP transport servers. These business use cases apply to the global and community embedded HTTP transport servers.

Activator user interface provides flexibility for several setup variations. The use cases include the most common combinations.

Case A

Embedded HTTP

A partner connects to host:port from a remote URL and sends a POST request containing the path part of the URL.

UI settings

Results

Case B

Embedded HTTP with remote URL

A partner connects to host:port from a remote URL and sends a POST request containing the path part of the remote URL. The firewall or reverse proxy maps the remote host and port to a real server. In the following example, edi.domain.com:5080 would be mapped to a server listening to port 4080.

UI settings

Results

Case C

Embedded HTTP with remote URL including path remapping

This case is the same as the previous case, except that the remote URL has a different path than the local one, which means a proxy is present that is rewriting the path in the POST request based on an internal mapping. In the following example, the path is changed from /inbound/stuff to /exchange/routingID.

UI settings

Results

Case D

Embedded HTTP with proxy and remote URL including path remapping

This case is similar to the previous case, except the host and port of the proxy are explicitly specified. The partner connects to the proxy host:port and sends a POST request containing the full remote URL. The proxy uses this information to establish a connection to the real endpoint server. In the following example, the proxy sends the POST request for edi.domain.com:5080 to one of the servers in the cluster listening to port 4080. It also translates the external /inbound/stuff path to /exchange/routingID.

UI settings

Results

Case E

Embedded HTTPS (SSL) with remote URL

A partner connects to host:port from remote URL and sends POST request containing the path part of the remote URL. The firewall or reverse proxy maps the remote host and port to a real server. In the following example, edi.domain.com:1453 is mapped to a server listening to port 1443. This example does not show path remapping, though that might be present as well.

UI settings

Results

Case F

Embedded HTTPS (SSL) with proxy and remote URL including path remapping

This is similar to the non-HTTPS proxy case, except that the partner starts off by sending a CONNECT request to tell the proxy to establish a tunnel to the endpoint server. This allows it to perform SSL handshaking with the endpoint server before sending the POST request. Note in the following example that the POST request contains only the path, unlike the non-SSL proxy case, which includes the full URL in order to tell the proxy how to find the endpoint server.

HTTPS-capable clients that can handle non-transparent proxies are set up to perform these two steps (CONNECT followed by POST), which keeps the setup simpler for the user.

UI settings

Results

Related topics

• Embedded transport servers
• Types of embedded servers
• Usage summary of embedded servers
• Manage embedded servers
• Global embedded HTTP server
• Lockout settings for cXML (embedded HTTP) users
• Modify a global embedded SMTP server
• Global embedded Web Services API server
• User interface embedded servers
• HTTP (embedded) fields
• FTP (embedded) fields
• Lockout settings for FTP (embedded) server users
• SFTP (embedded) server fields
• Lockout settings for SFTP (embedded) users
• SMTP (embedded) configuration
• OFTP (embedded) fields
• OFTP X.25 over ISDN (embedded) fields
• PeSIT (embedded) fields