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. |
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 Then at the HTTP ingress connector, specify Now when a message is received by the ingress connector for |
||||||||||
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 |
||||||||||
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 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 |
||||||||||
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,
|
||||||||||
Prevent Remote Certificate Verification |
SSL Configuration |
Indicates whether not validate remote endpoint certificates. This parameter should be turned to |
||||||||||
SSL Protocol Version |
SSL Configuration |
Specify which protocol version to be used for HTTPS connections. This parameter defaults to TLS. Available values are,
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 |
||||||||||
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.
|
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.
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.
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.
Figure 3. Egress Connector’s SSL configuration
As shown in the above figure we set the identity key store location, where the egress connector’s identity key-pair will
be stored. Then we have to set the trust store location where the egress connector’s trusted certificates are stored. Also we
have to specify the passwords of the key store and trust store. Also you can do advanced configurations on this egress connector
like specifying the TLS version to be used, cipher suites to be enabled and the hostname verifier to be used which are described
under Parameters in this document.
Logger Configuration
Configuring the Logger processing element can be done as shown in the following figure. Both logger elements in the
integration flow are configured in the same manner to log the payloads of the messages.
Figure 4. Logger configuration
You can refer the Logger documentation for more details.
Proxy in action
In order to check whether our integration flow is working as expected, we can run a UltraESB Server from the IDE and then
use the HTTP Client in Ultra Studio Toolbox to send a request to out testing URL, https://localhost:8443/test/path. Following figures
show the expected results.
Figure 5. HTTP/S client’s response
The complete response received is,
HTTP/1.1 200 OK
Status: 200 OK
X-Request-Id: d3274bda-bb6c-42c4-88d3-505892f80452
Access-Control-Allow-Origin: *
X-Content-Type-Options: nosniff
X-Runtime: 0.004141
Date: Mon, 10 Jul 2017 11:47:34 GMT
X-Frame-Options: SAMEORIGIN
Cache-Control: max-age=0, private, must-revalidate
ETag: "5820854f62a6eb3d38ba7ba0d1b3ea75"
Access-Control-Allow-Credentials: true
X-XSS-Protection: 1; mode=block
Content-Type: application/json; charset=utf-8
X-Powered-By: Phusion Passenger 4.0.40
Server: AdroitLogic UltraStudio UltraESB-X
Content-Length: 20
Connection: close
{"status":"success"}You can also see the payloads of the messages being logged in the terminal. Here the request’s payload is not blank since we we sending a GET request with not content.
2017-07-10T17:28:18,555 [XPR12001I003] INFO LoggerProcessingElement
2017-07-10T17:28:18,817 [XPR12001I003] INFO LoggerProcessingElement {"status":"success"}In this topic
In this topic