nio https egress connector

NIO HTTPS Egress Connector

Version: 17.07

Supported Since: 17.01

What is NIO HTTPS Egress Connector?

This is simply the secure version of NIO HTTP Egress Connector. That is, this egress connector use encrypted HTTP connections to send messages to other endpoints which are accepting HTTPS connections. In order to achieve that, this connector can be configured to use SSL (Secure Socket Layer) security and TLS (Transport Layer Security).

In addition to the normal configurations required to be done in the NIO HTTP Egress Connector this connector require several other important configurations to be done. For example, since this connector is sending messages to other end points, we have to configure a trust store to tell that these are the certificates of the endpoints which are to be trusted when communicating. All those configurations required are described in the sections below.

This connector cannot be used with query parameters; any included in the URL (service path) will be ignored. If you need to use query parameters, consider switching to the dynamic URL egress connector (see below).

NIO Https Dynamic URL Egress Connector

NIO Https Dynamic URL Egress Connector is a NIO Https connector which can be used to send messages to a dynamically assigned URLs to messages within the integration flow.

"NIO Https Dynamic URL Egress Connector" has the same functionality as the NIO HTTPS Egress Connector with one exception. It does not expect Hostname, Port and the Service Path as connector parameters. Instead it uses the Destination URL that is set to a message which comes in to the connector to extract those parameters.

In order to use the NIO HTTPS Egress Connector, you must first select the HTTP NIO Connector dependency from the connector list when you are creating an empty Ultra project. If you have already created a project, you can add the HTTP NIO Connector dependency via Component Registry. From Tools menu, select Ultra Studio → Component Registry and from the Connectors list, select the HTTP NIO Connector dependency.
https egress connector 1

Out Ports

On Exception

The message will be emitted from this out port if the processing element failed to process the payload due to some reason

Response Processor

The response message received will be directed to this port. You can use this port to connect any precessing element or connector that is supposed to process/consume the response.

Side Ports

Connector Operation

This port is used to connect operational elements to the Egress Connector. By-default, user does not have to connect any operational element and the default connector operation will be used.

Parameters

* marked fields are mandatory

Destination Address Type *

Basic

Select the type of the destination address. URL type will deliver the message into the specified absolute URL which is constructed using Destination Host, Destination port and Service Path. PREFIX type will deliver the message to the constructed URL from the prefix constructed using Destination Host, Destination port and Service Path, suffixed by the original requests path.

Suppose you want to forward all the requests coming to /front/.* service path of a NIO HTTP ingress connector to /back/.* endpoint.

Then at the HTTP ingress connector, specify /front/.* as the Service path. At HTTP egress connector specify PREFIX as the Destination Address Type and specify back for Service Path.

Now when a message is received by the ingress connector for /front/path/anotherpath/, then that will be forwarded to the /back/path/anotherpath/ resource path at the back end.

Destination Host *

Basic

The hostname of the endpoint to which this connector is supposed to send messages.

Destination Port

Basic

The port in the endpoint given by Destination Host to which this connector will be sending messages. The default value is 80

Service Path

Basic

The service path to which this connector will be sending the messages. If not specified, context path for the request will be used as the default value

Egress Timeout

Advanced

Timeout value in milliseconds for the egress message. After this time amount has been elapsed, the message flow will end exceptionally without waiting for the response from the external system.

Identity Store Location

SSL Configuration

Path to the identity key store where the key-pair used for this egress connector’s identity is located.

Identity Store Password

SSL Configuration

Password of the identity key store located at Identity Store Location

Identity Key Password

SSL Configuration

Password used to protect the private key of the identity key-pair.

Trust Store Location

SSL Configuration

Path to the key store where this egress connector’s trusted certificates are located.

Trust Store Password

SSL Configuration

Password used to protect the trust store located at Trust Store Location

Hostname Verifier

SSL Configuration

Mechanism used for checking if a hostname matches the names stored inside the server’s X.509 certificate. Available mechanisms are,

  1. Default - The hostname must match either the first CN, or any of the subject-alts. A wildcard can occur in the CN, and in any of the subject-alts.

  2. AllowAll - Disables hostname verification

  3. Strict - works the same way as java.net.URL, IE6 etc. Compliant with 2818 for wildcards. The hostname must match either the first CN, or any of the subject-alts. A wildcard can occur in the CN, and in any of the subject-alts.

  4. DefaultAndLocalhost - Same as Default, but a host of "localhost", "localhost.localdomain", "127.0.0.1", "::1" will always pass, no matter what is in the server’s certificate+

Prevent Remote Certificate Verification

SSL Configuration

Indicates whether not validate remote endpoint certificates. This parameter should be turned to true only in non-production usages. Turning this parameter on will cause no remote endpoint certificate to be validated. Therefore always be careful when turning on this parameter.

SSL Protocol Version

SSL Configuration

Specify which protocol version to be used for HTTPS connections. This parameter defaults to TLS. Available values are,

  1. TLS

  2. TLSv1

  3. TLSv1.1

  4. TLSv1.2

You can chose the TLS version depending on the level of security your ingress connector is expected to have when transporting data.

Supported TLS Versions

SSL Configuration

The set of TLS versions to be enabled for this Ingress Connector given here as a comma separated string.

Supported Cipher Suits

SSL Configuration

The set of cipher suites to be enabled should be given here as a comma separated string. This is an advanced SSL configuration where only the specified set of cipher suits will be used to encrypt connections between the ingress connector and the clients.

Proxy Host

Sender Configuration

The proxy server hostname, if there is a proxy server to go through

Proxy port

Sender Configuration

The proxy server port, if there is a proxy server to go through. (Should be a valid integer between 0 and 65535)

Proxy Bypass list

Sender Configuration

The proxy bypass list, Requests sent to these hosts will not be subjected to proxing. This list can be specified as a custom Spring bean in project.xpml

Keep-Alive timeout

Sender Configuration

The default keep alive time for re-usable outgoing connections in connection pool, in milli-seconds. Defaults to 30 seconds.

Keep-Alive safety threshold

Sender Configuration

The safety threshold to leave at the end of the keep-alive duration, where a connection is not re-used in the connection pool. (In milli-seconds). Defaults to 5 seconds.

Max connections per route

Sender Configuration

The maximum connections per route (i.e. scheme http/s, host and port pair). Defaults to 2048

Max connections

Sender Configuration

The total maximum connections to be opened at any time. Defaults to 4096

Continue on runtime exceptions

Sender Configuration

Whether the engine should continue execution on the occurrence of a runtime exception. If set to false, engine will shutdown and restart on such a situation

Continue on checked exceptions

Sender Configuration

Whether the engine should continue execution on the occurrence of a checked exception. If set to false, engine will shutdown and restart on such a situation

Zero copy enabled

Transport Configuration

Whether to enable zero copying or not. Read more about Zero-Copy

Connection debug

Transport Configuration

Whether to enable connection debug or not. Connection debug gives you a log if something went wrong in connection level

Connection debug headers

Transport Configuration

A comma separated list of HTTP headers to be dumped on a connection failure, when connection debugging is enabled. Specify as 'all' to dump all headers or as 'none' to prevent dumping of headers.

Replace User-Agent

Transport Configuration

If selected user agent header will be replaced by ESB’s server name

Unzip Response Entities

Transport Configuration

Select for unzip compressed responses. Where compressed responses are not required for processing, it may be better to leave them intact for extreme direct proxying cases

Tuning parameters

Sender Configuration

HTTP level tuning parameters as a map.

parameters

http.socket.timeout

TCP level socket timeout

http.connection.timeout

Time limit to establish a TCP level connection

http.tcp.nodelay

Use of nagle algorithm ? - default true

http.jvm.interest-ops-queued

Should NIO interest ops be queued? false for Sun/Oracle JDKs, true for IBM JDK

http.socket.buffer-size

Socket buffer size - default 8K

Sending Query Parameters

NIO HTTPS Egress Connector

The query parameters should be provided within the Service Path parameter value.

e.g.: Service Path = /getUser?id=1&name=mike

NIO Https Dynamic URL Egress Connector

The query parameters should be added using the Add Query Parameter processing element.

Sample Use Case

Prerequisites

Since this will be an extension to the use case provided in the NIO HTTPS Ingress Connector’s use case, having an idea about that would be very helpful to continue reading this document.

For a NIO HTTPS Egress Connector to operate there must be an ingress connector which is delivering the messages required to be sent to other endpoints. Therefore, we will use the NIO HTTPS Ingress Connector for our simple integration flow.

A Simple Proxy

The integration flow shown in the figure below is an example for our ESB working as a proxy. The NIO HTTPS Ingress Connector will be receiving messages from multiple clients. Then the ingress connector will submit the messages directly to the NIO HTTPS Egress Connector for them to be sent to a specific endpoint. The payload of the message will be logged by the Logger processing element in the middle. Finally, the response received by the egress connector will be sent as the response to the original client through the ingress connector’s input after the received payload being logged by the Logger in the response flow.

Integration Flow
Figure 1. Integration flow

Configurations

Since we have discussed how to configure the NIO HTTPS Ingress Connector, we will look at how the NIO HTTPS Egress Connector is configured. Following figure show the basic configuration of the egress connector.

Egress Connector’s basic configuration
Figure 2. Egress Connector’s basic configuration

As shown, we have to set the destination host name, destination port and the destination service path. Then we have to do the SSL Configuration. We have used an external endpoint, api.myjson.com:443/bins/54nmo which will return the JSON string,

{"status":"success"}

as the response. Therefore our port is 443, destination host is api.myjson.com and the service path is /bins/54nmo.