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 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

Field

Sample setting

Local URL

http://server1.domain.com:4080/exchange/routingID

Remote URL

(same)

Proxy

(none)

Results

Action

Value

Server binds to

<machines>:4080

Partner connects to

server1.domain.com:4080

Partner request

POST /exchange/routingID HTTP/1.1
HOST server1.domain.com:4080
<other headers and payload>

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

Field

Sample setting

Local URL

http://server1.domain.com:4080/exchange/routingID

Remote URL

http://edi.domain.com:5080/exchange/routingID

Proxy

(none)

Results

Action

Value

Server binds to

<machines>:4080

Partner connects to

edi.domain.com:5080

Partner request

POST /exchange/routingID HTTP/1.1
HOST edi.domain.com:5080
<other headers and payload>

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

Field

Sample setting

Local URL

http://server1.domain.com:4080/exchange/routingID

Remote URL

http://edi.domain.com:5080/inbound/stuff

Proxy

(none)

Results

Action

Value

Server binds to

<machines>:4080

Partner connects to

edi.domain.com:5080

Partner request

POST / exchange/routingID HTTP/1.1
HOST edi.domain.com:5080
<other headers and payload>

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

Field

Sample setting

Local URL

http://server1.domain.com:4080/exchange/routingID

Remote URL

http://edi.domain.com:5080/inbound/stuff

Proxy

proxy.domain.com:8080

Results

Action

Value

Server binds to

<machines>:4080

Partner connects to

proxy.domain.com:8080

Partner request

POST http://edi.domain.com:5080/inbound/stuff HTTP/1.1
HOST edi.domain.com:5080
<other headers and payload>

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

Field

Sample setting

Local URL

https://server1.domain.com:1443/exchange/routingID

Remote URL

https://edi.domain.com:1453/exchange/routingID

Proxy

(none)

Results

Action

Value

Server binds to

<machines>:1443

Partner connects to

edi.domain.com:1453

Partner request

POST /exchange/routingID HTTP/1.1
HOST edi.domain.com:1453
<other headers and payload>

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

Field

Sample setting

Local URL

https://server1.domain.com:1443/exchange/routingID

Remote URL

https://edi.domain.com:1453/exchange/routingID

Proxy

proxy.domain.com:8083

Results

Action

Value

Server binds to

<machines>:1443

Partner connects to

proxy.domain.com:8083

Partner request 1

CONNECT edi.domain.com:1453

Partner request 2

POST /exchange/routingID HTTP/1.1
HOST edi.domain.com:1453
<other headers and payload>

Related topics

Related Links